06-12-2015 02:41 AM
Greetings
I am still new to LabVIEW, but I have gotten a basic understanding of it.
I am working on a project where I have 3 signal, each of these is being sampled with 35 Hz, 35 Hz and a 2 kHz.
The 2 kHz signal is from a NI6024 and the samples to read have been set to 256. The two 35 Hz have no timestamp on them, so I have used a Build waveform and used the timestamp from the NI6024 to give them a timestamp.
I am supposed to analyses, display them on graph and log the data to a file. For this reason, I have used the Producer/Consumer approach inspired by the following https://decibel.ni.com/content/docs/DOC-26558. Where I have 1 producer loop, where the three of my data acquisitions unit is placed. Then three consumer loops, one for analyses another for display the data and the third is data logging in TDMS-format.
The three signals have to be synchronized and this is where I am stuck.
The queue that the producer/consumer method use, works after the principle FIFO and so I thought the data would be synchronized. But this doesn’t seems to be true, when I look at the graph, their seems to be a 10 sec. delay between the fast and the slow sampling rate. But in the TDMS file, it seems synchronized at least when I look at the timestamp.
Is there anyone who might help me?
Regards Christian
Solved! Go to Solution.
06-12-2015 07:17 AM - edited 06-12-2015 07:24 AM
It would be easier to give advice if you show us your code.
So you have all the 3 DAQmx acquisition in one while loop? I wonder how you do it, since they run at a different rate. A Queue does not sync just by its own, a Queue is just a Queue, you feed the data into it (even at multiple places) and you can dequeue the data. I think you have a kind of race condition due to the wrong framework usage...
I feel the following structure would be easier to handle:
edit: I just had a look at the link you mentioned with the example, and it does pretty much the same what I describe above. I did not look into the DAQ producer part however. Anyway, the above procedure should work...How you handle you data which is produced at different rates, it is really up to you! Depends on how you define data "to be synchronised"... Since they have different rates, they will not have equidistant points in time...there are different things you can do, for example you just plot them on a XY graph together...
06-12-2015 09:26 AM
You describe the device generating the 2KHz sample (I presume you use its on-board clock), but not the device generating the 35Hz sample -- does it also have an on-board clock so that you only have to start the two devices "in synch" and they (should) remain in synch because their clocks are accurate (or, even better, the same)?
I suppose you realize that 35 does not divide evenly into 2000. If you start them together, 35 and 2000 (respectively) samples later they'll be together again. Is that OK?
When you are dealing with devices having different rates of acquisition, and you want to save the data, you have a choice -- either save everything at the higher data rate (which means you'll "save" roughly 6 copies of the 35Hz signal at 2KHz) or have separate data streams, one at 35 Hz, one at 2KHz. "You Pays Your Money, and You Makes Your Choice".
Please provide additional information so we can be more helpful. As noted, posting code is an excellent way to do this. You need to provide code in a form that we can open it in LabVIEW -- this means a VI or ZIP attachment, or a Snippet attachment or Image (Snippets creation is an option on the Edit window of the Block Diagram).
Bob Schor
06-12-2015 01:42 PM
Since 2000 Hz is not an integer multiple of 35 Hz, you need to be clear about what you mean by synchronization. Even if all the acquisitions start at the same time the different timebases will eventually drift apart.
Do you mean a common trigger for all channels?
Lynn
06-12-2015 02:18 PM
Sorry for the late response!
There is no documentation for the device generating the 35 Hz sample, the only thing I know, is that it is sampling with 35 Hz. For the NI6024E I use the on-board clock.
What I know now, if I run the program, the program will sample with the speed of the DAQ. So now that I have put the sampling sampling rate up to 4500 and the samples to read to 128, witch yields 35, that might work.
I can’t test my measurement, because of the weather, so I can’t tell if this synchronized the data.
I have another question, sorry for that. If I set the sampling rate to 4500 and samples to read to 128, that gives me a cycle of 35 Hz. Now I get the correct number of samples from the device generating the 35 Hz. But should the NI6024E not give me 128 every 28 ms (1/35 = 28 ms) at the moment I get the same number of samples as my 35 Hz – device, namely 35 sample pr. Sec.
Sorry for the extra question!
The code attached should show what I have been doing.
Thanks in advance
regards Christian
06-13-2015 10:57 PM
Thank you for posting code, which gives a better idea of what you are trying to do.
I see that you are bundling samples from three devices (DAU 4011, DAU 4021, and NI 6024E) together in a single cluster in your Producer. I don't know what the DAU devices are, but I'm going to assume that they can accurately output data at 35 Hz.
You already know that 35 Hz and 2KHz are not even multiples of each other, but since you are bundling samples, you can consider doing something like the following:
Bob Schor
06-14-2015 10:13 AM
Thanks for the advice; I will look into it tomorrow. It sounds like something that will work for me
Regards Christian
06-17-2015 02:16 AM
Okay, it's working now!
Thanks for the help!
I just have one last question. What is the deal with the sampling rate being even with a number?
I know that 35 Hz and 2KHz are not even multiples of each other, but what if I had a sampling rate that was even. For example a sampling rate at 4500 Hz and 35 Hz. That would give 128, would that be even and why?
regards Christian
06-17-2015 01:08 PM
With sampling rates which are integer multiples you can derive both sample clocks from the same timing source. This will assure that they remain synchronized. With your external devices that may not be a possibility if they do not allow an external clock or do not export their internal timing source signals.
Lynn
06-17-2015 06:32 PM
@christianhm wrote:
For example a sampling rate at 4500 Hz and 35 Hz. That would give 128, would that be even and why?
regards Christian
Dear Christian,
I don't even have to do any division to see that 4500 and 35 aren't multiples of each other, hence 35 won't divide evenly into 4500. The easy way to see this is to see that 35 is divisible by 7, but 4500 is not (it can easily be factored into 5 * 9 * 100, none of which can be divided by 7).
BS