Analog input recording Issue with USB X series NI USB-6343

[AdamBarnett]

I am having a synchronisation issue when recording analog inputs.  I have replicated this in a few different mediums now but my example from NIMax is below.

I've set up a task recording on 2 analog input channels recording a 500Hz 0.5 duty cycle digital pulse which I set externally and which is fed into both channels.  As you can see from my first attached image 'recordingTimingCorrect.png' this gives the readout you would expect with the two recorded signals perfectly synchronised

However if I add a digital edge trigger then the signals are now offset as seen in 'recordingTimingIncorrect.png'.

I first discovered this from C# and from my tests there I know that there is a single extra sample on the first channel used.  It is also always on the first channel used (in NIMax this is the first channel in the order). This means if I now add a different channel to start of the channel order but keep the two which are there afterwards they are now correctly synchronised even with the trigger.

Is this a known issue?  If so is there a known workaround?  I would really like my inputs to both be externally triggered/timed and synchronised.

[Kevin_Price]

What you are seeing is a side-effect of the specific way you're wired and configured, with some possible influence from multitasking since it appears that might be the kind of board you're using.  There is *not* generally some special behavior where the first channel shows a different behavior from all the others.  

It looks like you just might have a situation like this:

1. you're sampling at exactly 2x the incoming pulse train so you can expect exactly 1 sample per digital state

2. you may be triggering off an edge of that same pulse train.  Coupled with #1 above, this looks a lot more dramatic due to the very special phasing relationship you've set up between the incoming signal and your ADC multiplexing

Interestingly, your "Incorrect" snapshot shows 2 channels that are not just offset by 1 sample, but they also have different (but consistent) peaks.  See what happens if you change your AI sample rate to at least 10x the incoming pulse train frequency.

-Kevin P

[AdamBarnett]

Thanks a lot for the reply Kevin, I am indeed using an edge of the input pulse train as a trigger.  If I instead use a separate pulse train as my trigger then I no longer see the delay so that solves my issue.

Since you were curious, if I sample at 20x the pulse train frequency (achieved by slowing down the pulse train) what I see looks much more like the first input is on a slightly different phase than the second and is catching a cross-section of the on and off ticks (see attached Image). 

I'm still a little confused about why this is happening and how I should prevent it in future so if you were able to explain a bit more I would greatly appreciate it (as I would generally like to share a timebase across my different tasks going forwards).

Thanks again,

Adam 

[Kevin_Price · Accepted solution]

Sure.  It'll make sense once you understand what to look for and then think it through carefully.

1. The first thing to understand is multiplexing.  Your board has only 1 analog-to-digital converter, but it can take samples from many distinct analog channels.  How?   The answer is that it multiplexes.  This means that for each sample period, there's a separate faster multiplexing clock that briefly switches in the signal from one of your channels and fires the converter.  It keeps going through the channel list until each channel has been sampled.

   A consequence of this is that the exact sampling time on each channel is offset slightly from the time of neigboring channels.  If you feed the same sine wave signal to 4 multiplexed channels, your data will look like 4 sine waves that have a small phase offset from one another.

2. This is very likely what you're seeing in the latest snapshot.  The 1st channel is the one that looks like it lags behind even though in reality it was sampled before the 2nd channel.   In fact, the reason it looks like it lags behind is because it was sampled earlier.  First you capture a sample of a waveform at a specific point in time and assign that value to channel #1 sample #N.  A very short time later, you capture a sample of the same waveform at a slightly later time and assign the value to channel #2 sample #N.   Eventually you plot channels 1&2.  At each sample point N, channel 2 has sampled the waveform at a slightly later time than channel 1.  Channel 2 shows the waveform after it has progressed farther in time than does channel 1, so channel 2 appears to be leading channel 1.

3. It's possible to configure the speed that the multiplexer uses to go from channel to channel.  Going faster puts you at more risk of having voltage from a previous channel influence the reading on a subsequent channel.  The max usable speed depends on board specs, signal source, and proper connections with bias resistors.  (Lookup the "Field wiring..." guide here.)  Going slower puts more phase shift between the channels.  The min usable speed depends on the sample rate.

You can't really *prevent* the phase shift effect in a multiplexing board.  You'd need a more expensive simultaneous sampling board which has a separate ADC dedicated to each analog channel.   You *can* conceivably compensate for the phase shift by knowing the multiplexing frequency.  That will tell you the time offset between the channels.  Then you can be more careful in your post-processing and account for this time offset as you process each channel.

For example, let's say you sample 4 channels at 1 kHz and the multiplexing clock runs at 5 kHz.  Let's assign t0 to be the time for the 1st sample on the 1st channel.  Then the times for the 1st sample on the other channels will be 0.200, 0.400, and 0.600 msec.  They shouldn't *really* line up vertically on a graph, it's just that it takes some extra work to put the data onto a graph or into a file in a way that shows their *true* relationship in time.

-Kevin P

[AdamBarnett]

Thanks so much for the comprehensive description.  I assume then that what I was seeing is that this effect is made more extreme when I trigger from a source that I'm also recording.  Is that correct?

[Kevin_Price]

Yeah, that's correct.  Triggering will happen somewhere along transition *edge* of the pulse train.  The first sample will be taken some short time after that.  That short time might not be enough for the signal to have arrived at its post-transition voltage or for the ADC to have fully settled.

There are properties that could be tweaked to help with this, probably via a DAQmx Trigger property node.  There should be one that lets you set a post-trigger delay.  With a 500 Hz pulse train you've got 1 msec per state.  Try setting the delay to be something like 100 microsec, that should clear up the effect you saw if my theory's right.

-Kevin P