Hello everyone, I have a question about sampling and clock sync. I'm using NI 9239 and a multiplexer to acquire voltage signal. The MUX make the sensor on/off 20 times per second. The NI 9239 is acquiring the signal at 2kHz. In 1 second, I have 20 data pulses for the sensor, for each pulse, 8 samples per 4 milliseconds which are useful data, 92 samples per 46 milliseconds which are useless data. I have a TTL module 9401, how can I make a clock which syncs with these pulses to only acquire the useful data, which is 20 pulses total of 160 data per second. The VI I attached is acquiring all 2000 data per second. Thank you very much.
Because your 9239 device uses a Delta-Sigma style converter, sampling sync won't really be possible in the way seem to be expecting. The 9239 cannot accept external signals as a sample clock, it must derive its own internally. There's also a significant delay (often dozens of samples worth) between the instant when an analog value is present at a terminal and the instant when that value becomes a digitized value.
I think you should consider physically wiring the pulse signals to another analog channel on the 9239. Put both channels into the same 2 kHz sampling rate task. Then post-process the pulse channel values to figure out where pulses occurred and which sensor values are relevant. Be prepared for the pulse signal to possibly look a little funky compared to the square wave you'd probably see on a scope.
I completely agree with Kevin. The best would be having enough NI 9239 channels for each of the signals, instead of using a MUX with it.
You can however sync things the other way around: using the NI 9239 as the master, you could export its master timebase to the NI 9401 and if you consider the start trigger and filter delay of the NI 9239, you should have a Counter Output generating pulses in sync with the NI 9239's input.
This is not exactly trivial. Attached is a Frankenstein VI I built (and had a lot of fun in the process ) based on the Voltage - Continuous Input.vi and Counter - Continuous Output.vi shipping examples. I have not validated this, but in theory, the output pulses should be in sync with the AI sample clock and it provides a mean to delay the PWM to compensate for the filter delay (see the notes in the block diagram for details about how to do that).
With the signals synced, you can just leave the tasks running continuously and chose the amount of samples to process by software, and simply ignore the rest.
This does not account for the fact that, you will have N invalid samples every time the MUX switches (N being the same amount of samples calculated for the filter delay). You will need to account for that by software.
Also, as pointed by Kevin, Delta Sigma devices are not really appropriate to measure square signals, so depending on what you are expecting to get out of the measurements, you may not get great results.
Notice this is just a workaround you can test if you have no access to enough modules for all your signals, but this is not an NI tested shipping example, so I cannot give you a warranty it will work for you or be adaptable to your project, but I hope it will of use to you.
I removed the notes from the original examples. Refer to the Voltage - Continuous Input.vi and Counter - Continuous Output.vi shipping examples for the specifics about the AI and CO tasks.
Last, I used an NI 9234 instead of an NI 9239, but all should apply just the same. Let us know if you have specific questions about any of the properties or items in the VI and we'll try to help.
Good luck with your project!!
I forgot, the article below will give you a lot of insight on C Series Synchronization. I learned a lot the first time I went through it (and possibly more the second, third... nth times).
I explains some of the delta sigma synchronization stuff that I did and a lot more.
Thanks very much for your advice. Actually, I got four separate VI, please see attached. The 5V MUX reset will be worked as a power source for the multiplexer reset terminal with user controlled HIGH/LOW from the front panel. the 160Hz MUX clock is actually a function generator sending the pulse signal to the MUX. I got 8 channels in the MUX, that's equivalent to a 20Hz sample rate for each channel. When I use 9239 to collect data, I want it to be synced with a 20Hz clock with 3ms high and 47ms low, or in other words, I want to make it an external clock source for 9239. I'm thinking that the first two VIs can just run independently from the data collection. Is it possible to physically wire to PFI0/1 on the cDAQ 9178? Thank you.
Thanks for your example. I have 9239 in slot 1 and 9401 in slot 2. I set counter 9401/ctr0 and output terminal 9401/PFI3. I would like the voltage input sync with a 20Hz counter with 0.06 duty cycle. Which clock source should I use for 9239? Thanks for your help.
I was writing this while your last post arrived.
You can physically wire to the PFIs on the cDAQ-9178, but the PFIs on the chassis have a bandwidth of 1 MHz. The problem with the 20 MHz signal is that the PFIs in the cDAQ have a bandwidth of 1 MHz.
(see chassis PFI characteristics)
We are getting there... Theoretically, you may get away with it if you have an NI 9402 (20 MHz), but the maximum timebase an NI 9239 will accept is 13.15 MHz (it will accept anything from 1 MHz to 13.15 Mhz). The article below will show you the maximum frequency you can use with different modules.
Time to get creative... I see two alternatives:
1. If you find a way to externally divide your 20 MHz external signal down to 10 MHz (or anything within the NI 9239's range), you can use an NI 9402 to import the signal and use it as the Sample Clock Timebase Source for the NI 9239.
2. You can create a counter output task using the external 20 MHz signal connected to a PFI from the NI 9402 as the CO timebase. Then, the CO can generate a signal up to around 6.something MHz because of several limitations, but 5 MHz would be fine. Last, you use the CO output as the master timebase of the NI 9239.
Either option would require the use of a NI 9402 to allow using the 20 MHz signal. The article I shared before will help with the required properties to access the timebase. Notice you need to specify both source and rate for the timebase.
Edit: If you have a way to divide down the signal to 1 MHz, you can use that as the timebase for the module using the chassis PFIs, but it will drastically limit your sample rate (max rate would be 3906.25 S/s).
Just noticed I was underestimating the NI 9401. If you are using 2 or less channels, you can import up to 30 MHz with it!! This means the methods I described will work with it.
Please see the attached VI, I'm generating two digital output for the MUX, the data is captured as 20 pulses per seconds, how to introduce a 20Hz clock with 6.25% duty cycle, and sync with analog input task so that it will collect data for 3.125ms, average them output one data point and rest for 46.875ms, then repeat. Thank you.
When I first read your posts, I made two mistakes. For some reason my brain converted 20Hz to 20MHz. My previous posts were based on that, so they are probably useless, so, apologies for not reading through your post with enough attention.
At this point, I will quote Kevin when he said that "Because your 9239 device uses a Delta-Sigma style converter, sampling sync won't really be possible in the way seem to be expecting". There will not be a way to set the 9239 to sleep based on an external signal.
If you don't have enough 9239 channels as pointed by Kevin, it would be better to just capture the 2000 data points and process the signal in software to extract the valid data. You can use the Get Waveform Subset VI to extract a portion of the complete waveform based on a duration and a number of samples or time respecting the start of the waveform.
Is the counter output only intended to "enable/disable" the AI, or does it control something external? maybe you are using the counter to control the MUX transitions? If you are, we can at least use one of the methods I mentioned to synchronize the output with the NI 9239's timebase so that there will be no long term drift in the counter output and the analog inputs.