Using an external train of pulses to acquire

[cobayatron]

Hi,

I'm using a cDAQ9185 chassis with a NI9202 to acquire pressure signals. There's a company coming to the lab to show their technology and I want to synchronise their measurements with mine to compare during postprocessing.

Now the third party acquisition system acquires a 1 kHz and in a standard acquisition mode, outputs through a Sync Out port a train of pulses of the same frequency of the sampling rate. I want to use this train of pulses as a timing for the acquisition in Labview. I uderstand I could connect the Sync Out port of the other device to the PFI port of cDAQ9185 chassis and then select it as my Sample Clock. Is that correct? 

Now, I couldn't find in the documentation of the other device if their acquisition is in line with the rising or the falling edge of the pulse, so I want to try both ways. How can I tell the clock in Labview to use one or the other to sync the acquisition?

Thanks for your help!

[cobayatron]

Sorry I've realised now that the Sample clock has inputs to choose between rising and falling edges. Ups! I got a question though regarding the sample rate input which should be wired to that VI. If the clock is set to match a train of pulses of fixed frequency and I set a different sampling frequency, which one governs the acquisition?

[GerdW · Accepted solution]

Hi cobayatron,

when you use an external trigger signal to trigger the sample acquisition then that external trigger signal will be used.

(It helps to set a reasonable "expected" sample frequency anyway as DAQmx might adapt other internal settings/parameters, too.)

[cobayatron]

Understood! Many thanks GerdW

[Kevin_Price]

Apparently you haven't tried this out yet.

Bad news.  I looked up the cDAQ 9202 and found that it uses a Delta-Sigma converter.  The implication of that is that you *cannot* use external pulses directly as a sample clock signal.  About all you *can* do is to trigger off the first such pulse.  But even then, there will be an unavoidable delay caused by the built-in filtering, so you'll need to compensate for that after the fact.

If you have a different cDAQ module with a SAR-style converter, then you *can* use the external pulses directly as a sample clock.  What you tell DAQmx about the (alleged) sample rate will have no effect on when the samples are *actually* taken -- the incoming pulse signals control that, whatever their timing might be.  However, it will affect the default buffer size and the "dt" field if you read your data as a waveform.  So it's worthwhile to give a good estimate, but if anything, err on the high side.  And then remember that "dt" will likely be untrue.

-Kevin P

[cobayatron]

Hi Kevin_Price,

Many thanks  for the heads up

No I haven't tried this yet, this will happen sometime next week when this other technology arrives at the lab. 

I also have a NI9223 we use for very high acquisition rates, would this be controllable by external pulses?

Ok so, if I understood correctly, sample rate I set will define the dt in the waveform  but it won't be a true value because that's actually defined by the pulse frequency. So, if I plot that waveform as I acquire it, time axis won't be correct, right? 

[Kevin_Price]

The 9223 is indeed based on a SAR-style converter (or converters?), so I would expect it to be able to use external pulses directly as a sample clock.  But you'll need a way to get those pulses into the chassis.  Dunno if your chassis has direct connections for TTL signals, else you may also need a digital module for the sake of signal routing. 

I don't work with cDAQ much, so am not 100% sure of the syntax for setting it up.   One would typically need to reference a "PFI" terminal when it comes to such routing of digital timing signals, and I *think* digital modules typically have PFI designations for their terminals.

When you guess at your sample rate, the time axis of your waveform plot can't be counted on to be correct.  DAQmx does *not* auto-detect actual external clock rates.  Plus, the waveform datatype depends on having a constant sample rate, something that can't be assured when using an external signal as a sample clock.  One common example is equi-distant sampling when using an encoder edges as a sample clock.  Speed variation makes the sample interval vary in time.

-Kevin P

[cobayatron]

Hello again Kevin,

I now have the other system in the lab and when trying to run the VI it produces the error: -209836

The devices in your task cannot be synchronized. This may be because there are no available synchronization mechanisms between the devices.
Some synchronization paths are not available in interactive tools like the DAQ Assistant. To determine whether synchronization between these devices is possible, try deploying and executing your task in your application environment.

Everything here is connected to same local network, laptop connected directly through ethernet cable to the cDAQ9185 chasis, the cDAQ also connected through ethernet cable to the other system. I can see the both devices from the laptop. The sync out port of the other system connected to the PFI port of the cDAQ chasis.

Could you please explain more in detail what you mean by referencing the PFI terminal?

Thanks in advance

[Kevin_Price]

The code you posted doesn't seem to match your description.  You have an error about synchronizing devices (plural) while the code uses only 1 device.

If the device in question is based around a Delta-Sigma converter, you'll get an error when trying to designate a PFI pin as a sample clock.  I wouldn't expect the specific error you reported, but can't say for sure.   As I mentioned back in msg #5, Delta-Sigma devices *cannot* directly use an external sample clock (and are very constrained in what they can use indirectly).

If you have a dedicated PFI terminal on your chassis, then the stuff I said about accessing a PFI timing signal via a DIO module isn't really necessary.

-Kevin P