How to sync. 50Hz sample rate with 5Hz external digital trigger signal?

[OlLu]

Dear all,

I already posted this question some time ago and I got an answer that works in principle on my PCMCIA-DAQ 6036E. The answer was to use a retriggerable pulse train as sample clock which is triggered by the GPS PPS signal every 0.2s.

However, this solution does not work 100%: I would like to sample an analog input *continuously* at 50Hz, so I set the retriggerable pulse train to 50Hz and I configure 10 pulses (corresponding to the 5Hz GPS PPS external trigger). The result is shown in the attached JPEG 10samples_perpulsetrain and you can see that a pulsetrain is generated only with 2.5Hz. When only 9 pulses are generated then a pulse train is produced every .2s, i.e. with the 5Hz I would expect (cf. the other JPEG).

So the problem seems to be that when 10 pulses are generated, the retriggerable pulse train misses one rising edge of the PPS.

Is there another way to solve this problem? BTW: my software platform is Visual C++, I have no access to LabView.

Thank you in advance for any hints.

Kind regards,
Oliver

[Kevin_Price]

I would expect that in the hardware, the 10 pulse train at 50 Hz is not *quite* done yet when the next 5 Hz trigger comes in.

I'm afraid I can't help with the syntax b/c I'm a Labview-only guy, but here's a rough idea that I think may work:

1. Don't use the builtin easy method for defining a finite pulsetrain.  Essentially a finite pulsetrain is formed by having one counter generate a pulsetrain that's gated by the output of the other counter.  Under DAQmx, "gating" is called "pause triggering."  When you use the easy method, I *think* that the single "gating pulse" is configured to have a high ("ON") time that's exactly equal to 10 full periods of your 50 Hz train.  That makes 0.2 seconds, the exact trigger interval.  Once you add in even a minimal low ("OFF") time, your finite pulsetrain now requires just a little more than the 0.2 seconds between triggers.  So you catch one, just miss the next, catch one, just miss the next, etc.

2. If you manually setup the 2 counters to work together as a retriggerable finite pulsetrain, you stand a chance.  The key is to make sure that the retriggerable single pulse has a total ON time time long enough to allow 10 "active edges" to occur, but a total OFF+ON time very slightly < 0.2 sec.  Not sure how much, but I'd guess that even a microsecond is enough for the hardware.

3. This sorta assumes that the 50 Hz pulsetrain is phased conveniently relative to the 5 Hz triggers.  I don't know your board enough to know if there's a way to enforce that.

Do you see more-or-less what I'm getting at?  What exactly is the purpose of the app?  Do you really need the continuous 50 Hz sampling to be exactly 50 Hz sampling?  Another possible solution is to produce 10 pulses at, say, 50.001.  Then the gap until the start of the next set of 10 is only a few microseconds longer.  Could you live with that?

-Kevin P.

[OlLu]

Kevin, thank you for your detailled reply.

About my app: I need to do measurements with two separate devices: one is my DAQ card, the other one is a commercial Inertial Measurment System that logs the data with GPS time stamps and where the sampling clock is sync'ed with PPS.

To be able to compare both measurements I  need to allign the DAQ samples with GPS as well. I also noticed with another DAQ board that setting the sampling rate to, say 50 Hz, results in a slightly different sampling rate, eventually resulting in a drift w.r.t. to GPS time. Using the PPS,  I want to enforce an accurate time reference solving both problems.

However,  I think I will follow your suggestion to change the pulse train frequ. to some slightly higher value (it seems that 50.01 Hz works fine, while 50.001 Hz leads to some random misses of the PPS rising edge). The PPS should make sure that the 50.01 Hz will not lead to a constant drift over time.

Cheers,
Oliver

[Ben_at_SIO]

I have this same problem, and in the past have used the same solution - setting the frequency slightly higher. On a USB-6251, I used a 1 PPS coming from GPS to retrigger a 10 pulse finite train at 10.08 Hz. This was used to trigger a camera, and we just worked the 10.08 into the post processing.

Now I am revisiting the problem (now with a usb 6211), and since it has been a few years, I'm wondering if this issue has been solved in a better way. In my current application, the finite pulses are tied to analog sampling, and a fixed sampling frequency is important so that I can do some spectral analysis without interpolating to a fixed time interval in post processing.

Now I am using a 1 PPS GPS line to start off a finite pulse train of 100, ideally at 100 Hz. In this case, precise absolute time is also important (experiments over several hours will be synchronized in post-processing to a GPS-IMU for airborne sensors), which is why I am retriggering with the GPS pulse every second.

This seems like it would be an issue affecting many and would be solved by NI by now. Maybe it has and I just haven't found it. I'm sure there are multiple applications where a fixed rate counter must be resynchronized periodically to prevent long term drift. I look forward to any insight or replies by others in the same situation.

Thanks,

Ben 

[John_P1]

Hi Ben,

It sounds like you guys have observed that you cannot re-trigger the pulse output while the previous generation is still taking place.  The issue is that the pulse generation must complete all of the high and low ticks before it is re-armed for another trigger.  With your current hardware, the workaround that you have found (generating a slightly faster pulse train so that it is guaranteed to complete between triggers) is unfortunately the only solution that I can think of as well.

Having said this, I believe we do have a solution available using our newly released X Series DAQ devices (63xx).  The key difference is that we now have the option of cutting off the unnecessary low duty cycle of the last pulse so we don't have to be actively generating up to the point where the next trigger takes place.  The line will stay low after the generation is complete so the result will look something like this:

Here are two ways to accomplish what you need using an X series (new features are in Bold😞

1.  Finite Implicit Buffered Pulse Train Generation -- A bit of a mouthful, but you can read more about it in the X Series User Manual.  Essentially the way this works is to give an array of high and low ticks which the counter will sequentially output.  The last pulse in your generation should have a two sample (the minimum) low time--as soon as this is complete the trigger will be re-armed.  A couple other related facts about the X Series Counters:

• Finite Pulse Generation no longer requires the use of two counters.
• There are four counters available on all X Series.

2.  All Subsystems are Retriggerable on X Series -- So, another option would be to configure a Hardware-Timed Digital Output to re-trigger off of the reference clock.  Using the same idea mentioned above, we define a digital waveform of high and low values that will correspond to a pulse train that ends on 0, but does not completely generate the last duty cycle up to the point where the trigger occurs. 

There should also be a way to do something similar on an M Series device that supports correlated Digital I/O (622x, 625x, 628x)--it's a bit tricky but here's what I would try:

-Create a Retriggerable Finite Pulse Generation that's a multiple of the frequency that you want to generate.  This will be the "timebase" for a digital output task.  As an example, if you want a 100 Hz signal, you could generate a 1 kHz signal from the counter.

-The number of "timebase" pulses to generate should be enough such that we have entered the low period of the last pulse that we will be generating, but should be less than what would bring us up to the next trigger signal.  In the above example, if pulses were coming in every 1 second you should generate 996 timebase ticks (a 100 Hz signal will be 5 high and 5 low ticks of the 1 kHz "timebase").

-Build a digital waveform that alternates between high and low ticks at the desired rate.  Using the above example, we would alternate between generating 5 high and 5 low ticks.  The last sample (996th) will be a low value so that the digital line will remain low until the next sample clock edge is received.

-Configure a continuous digital output task, using the counter's internal output as a sample clock.  Write the waveform to the task before starting (regeneration is enabled by default, so you only have to write once).

Unfortunately, the USB 6211 does not support correlated digital I/O, so you will have to use another board anyway.  If you are purchasing new hardware, I would strongly recommend the X series if PCIe or PXIe is an option (they are priced the same as the equivalent M series boards).  The M series solution would require both counters and the digital output subsystems, whereas the X series can do the same task with a single counter.

I hope this is helpful, let me know if you would like any clarification.

Best Regards,

John

Message Edited by John P on 09-16-2009 09:41 AM