Possible bug --> CompactDAQ synchronizing between AI and counter - sync error is a function of sample rate (exactly).

[Greg-A]

I have a compactDAQ system with a 9234 AI card in slot 4, and a 9401 in slot 5.

I am using a function generator to create a 5V square wave frequency sweep.

The frequency sweeps from 1 Hz to 10 Hz in 3 seconds.

I tee this into both my counter 0 gate (PFI1 - Pin 16) and analog input channel 0.

In LabView, I am doing a counter period measurement which has an ArmStart trigger set to the AI Start Trigger.

By teeing the signal into both channels, I should see the counter times correspond to positive slope zero-level crossing in the AI data.

By having a square wave with a changing frequency, I can know for sure that the timing is not off by a period.

I noticed that the slower I sample, the larger the time of the synchronization error . 

Here is the data I recorded:

Sample rate    1 / (sync error time)

51200            1250

25600            625

10240            256

2048                51.8

1651                37

This worked out to be Y = 0.0244X + 1.1262, with R^2 = 1.0

So it could be I have a programming error, or that there is some bug in the hardware or base software.

Thanks for any help in understand this issue.

BTW, I am using this system to do an in-vehicle order analysis program with live order analysis over time - of course as a function of revolutions.  I found the order analysis toolkit was not flexible enough for what I needed done, so I just started from the ground up.

[Doug_L._Bear]

Greg,

What do you mean by synchronization delay?  Do you mean the difference in the period measurements on the counter line and the analog input line?  Or do you mean the synchronization between the start of a counter period and the start of an AI period.

It seems exepected to me that as the AI sample rate decreases the sync error would increase because your timing resolution is reduced.  Please clarify if this is not correct.

[Greg-A]

Hi Doug,

Here is my short answer: I mean the inital start of both data collections.  There is always a delay between my 2 signals, and they are off by exacly the same amount every time (for a given sample rate).   The dalay error is about 41 times the sample rate!!

I am not talking about a resolution issue from coarser sampling rates.  That would make random "sync errors" within the time of one 1/Fs (between 2 samples).

2048 Hz sample rate is always has a delay error of 0.0193 seconds.

Let me try to explain a little more of what I am doing, and maybe you will see what I mean.

So there are 2 data measurements of the same signal.

  1. period measurement with a NI-9401, so I collect an array of delta-t's

  2. voltage measurement with a NI-9234.

I initially did my program development at 51,200 Hz, but had a synchronization error of about 1 ms and thought that was not bad.

But typically we collect data at about about 1K, so when I started to use the program, I reduced the sample rate to 2048 Hz.

I then saw the data had major delay issues (synchronization error), so I wanted to try to reduce that, so here are my generic steps:

A. I made the signal a TTL frequency sweeping square wave, so the counter would accept it and so I could see the period change over time.

B. I start the counter task first and have it waiting for the AI Start Trigger.

C. I collect some data.

D. I take the delta-t's collected from the counter and sum them to get an absolute time for gate level changes.

E. I compare those times to the time of AI signal.

At a sample rate of 2048 I noticed the time delay between the AI and counter times was always 0.0193 seconds.

At a sample rate of 51,200, the delay between the signals was always 0.0008 seconds.

No matter how many times I stopped and started, I always have the same delay error between the 2 measurements.

F. If I add my correction factor to the FIRST counter data point my data is synchronized extremely well - I did not try estimate the synch error with the correction factor applied.  Like you mentioned, I can only tell within the resolution of my AI signal.

Now I am just reading that difference off of my X-Y plot, so there is probably more significant digits and error is slightly different beyond the digits that I am showing here, but a 50 Hz timing error with a 2048 Hz sample rate is significant.

I noticed two issues with my sample program that I uploaded, so I uploaded another version (LV 2009).

  1.  The sample rate used in the post-processing, is a property node that might not have a value on the first run of the program.

  2.  The correction factor is added to every element the time array which was created from summing the counter delta-t's.

       This is the same as adding it only to the first delta-t and the summing the delta-t's, but is less clear.

There was also a Get terminal name VI that did not want to be automatically found, so I just hard coded the AI Start trigger terminal name.

Thanks for getting back with me.

Greg

Message Edited by Greg-A on 08-17-2009 06:32 AM

Message Edited by Greg-A on 08-17-2009 06:34 AM

[MarkGrot · Accepted solution]

Hi Greg,

It looks like you are seeing the input delay (group delay) of the NI 9234.   As specified in the NI 9234 operating instructions, the input delay is equal to 38.4 / fs + 3.2us.  This is because of how the delta sigma ADC operates--after starting, it has to acquire a set number of samples before returning the first valid sample.  This delay is expected.

Here is a knowledge base on the subject.  There are many more, just do a knowledge base search for "group delay"

Message Edited by MarkGrot on 08-17-2009 10:38 AM

[Greg-A]

Thank you Mark.

I incorrectly assumed that an AI Start trigger routed to Arm Start Trigger would synchronize the 2 modules without extra data on the delta-sigma ADC.

It would be really great if the LV help would mention "input delay" (especially when dealing with triggers) or if the 9234 manual stated anything more about input delay other than its value.

For 2048 Hz, my observed delay of 0.0193 seconds is close to the 38.4 / fs + 3.2 us (0.018753 sec).

I will have to read some more, but it sounds like I really have 0.01875 seconds too much data at the beginning of my NI-9234 data, rather than the first counter value being too small.

My next steps which will be effected by group delay will be synchronizing the following modules together:

  1 NI-9401 (counter function)

  2 NI-9234 (up to 8 accels)

  1 NI-9237 (4 strain gages)

  1 NI-9205 (volatges)

Thanks again for the info.

[MarkGrot]

You were on the right track with synchronizing the NI 9234 and NI 9401.   Once you account for the group delay your data should look much better.  Yes, you are seeing 0.01875 seconds of "old" data on the NI 9234.  If you shift your NI 9234 data by that amount it should match up with t0 of the NI 9401.

Something to consider is using the AI Sample Clock as the Arm Start Trigger instead of AI Start.  The NI 9234 is free running.  We return start returning data after AI Start but in the case of delta sigma modules AI Start is asynchronous.  The first sample will come from within one sample period of AI Start but there is no guarantee when in that period it will occur.

For your next step (adding modules to the setup), the NI 9205 data will not need to be shifted as it is not a delta sigma module.   Second, the NI 9237s will run at the same rate as the NI 9234 if they are in the same task because they will share a timebase.  This means that the NI 9237s will have a maximum rate of 51.2kHz.

Message Edited by MarkGrot on 08-17-2009 12:42 PM