Can/Does the ni5105 perform simultaneous sampling on its channels?

[sideways_the_dog]

Hi,

I'm getting pretty frustrated because I can't tell if I'm having a problem with the triggering, the data collection, the saving of the data, or if the card just doesn't behave the way I think it should.  Any help would be very much appreciated- even if it's just to tell me that the card should be returning identical data for the identical signal going in.

I'm using the settings posted in this link to try to do some digital beam forming.  The samples in each channel need to be lined up within nanoseconds.  If I split a signal from a signal generator and look at it on an o-scope, I see identical signals.  But I am not seeing the data align for the two channels captured with the NI5105- the samples are also offset in magnitude.  Using a 100kHz signal the two channels are off by 30 samples using a 6MSa/s capture rate- at least 5us offset.  The wfmInfo returned indicates I'm getting the same number of actual samples on all of the channels.  I am currently performing a self calibration before every time I start collecting data.

I have also discovered that when I do a capture it seems like the data doesn't seem to start collecting for all of the channels at the same time.  Initially I was only looking at the first file and assumed the data wasn't being sampled ever.

I am using a variation of the FetchForever routine using the software trigger, but I'm using the FetchBinary16 command. 

Before we bought the card we were assured by the pre-sales tech support that the channels would be sampled on the order of nanoseconds, so I have to assume I'm not doing this right in software. 

Thanks,
Greg

[sideways_the_dog]

While I suspect I'll have this figured out by trial and error before I get a response, I've figured out more about this for anyone interested.

I'm not sure why this is the case, but I've tracked down something that makes this code kind of work.  I really have two threads running, which I'll psuedo-code below (hiding details like how I save and the fact that really I'm using Mutexs).  If I just do Fetch commands in one of the threads the saved channels do not line up.  If I do a cout command (which does have some thread sync'ing implications but I don't think that's related) after each fetch, everything works.  I suspect this is still more of a triggering issue (giving the card time to catch up perhaps) than a thread issue, but at least the code is working.  I still don't have confidence yet that I'm not missing something.  I might need to find some attribute which says it's okay to Fetch again, but I'd think for the continuous acquisition I could call Fetch right after each other.

---

volatile bool bDataToSave1, bDataToSave2;  // there is data available to be saved

FetchThread()

{

   while(1)

   {

      while(bDataToSave1);

      handleErr(niScope_FetchBinary16 (vi, channelName, 0, actualRecordLength , (ViInt16*)waveformPtr1, wfmInfo1));

      cout << "whatever" << endl;  // remove this and the channels don't line up

      bDataToSave1 = true;

      while(bDataToSave2);

      handleErr(niScope_FetchBinary16 (vi, channelName, 0, actualRecordLength , (ViInt16*)waveformPtr2, wfmInfo2));

      cout << "whatever" << endl;  // remove this and the channels don't line up

      bDataToSave2 = true;

   }

}

SaveThread()

{

   while(1)

   {

      if(bDataToSave1)

         SaveData(waveformPtr1);

      if(bDataToSave2)

         SaveData(waveformPtr2);

   }

}

[Jeff_B.]

Hi Greg,

The 5105 does sample simultaneously on all 8 channels.  You should be able to use a simple NI-Scope example (like ConfiguredAcquisition) to convince yourself of this.  As you mentioned, split your signal to multiple channels and you should see simultaneous data regardless of trigger source.

If you are performing a continuous acquisition, then your problem is not likely due to triggering since a continuous acquisition works by configuring a SW trigger that will never occur.  I would be more suspicious of how the read pointer is being manipulated.  This will determine what data is fetched back.

Message Edited by Jeff B. on 08-11-2008 01:52 PM

[sideways_the_dog]

Thank you so much for responding.  I am intrigued by your "read pointer" comment.  I'm getting gaps in my captured data (though it's aligned now that I added the cout commands). 

Could you please be more specific about "how the read pointer is manipulated"?  I'm thinking this means I need to use a FetchInChunks style capture for continuous acquisition.  I have been using the FetchForever scheme, which I now think is more for benchmarking than data collection.  The data is coming in aligned as mentioned in my last post, but I'm getting gaps in the captured data.

Also, is there a document that explains the attributes in one place?  The help file seems to touch on the attributes here and there, and the quick reference guide shows how to read/write the attributes, but I haven't found a comprehensive list and description.

Thanks again,

Greg

[Jeff_B.]

Hi Greg,

The fetch relative to attribute is what I was referring to.  The behavior you are describing sounds like it could be caused by fetching relative to "now" instead of "read pointer".  From the NI High-Speed Digitizers Help file:

NISCOPE_ATTR_FETCH_RELATIVE_TO

Description

Position to start fetching within one record.

Default Value: NISCOPE_VAL_PRETRIGGER

Defined Values

NISCOPE_VAL_PRETRIGGER (477)—Fetches relative to the first pretrigger point requested with niScope_ConfigureHorizontalTiming.

NISCOPE_VAL_NOW (481—Fetch data at the last sample acquired.

NISCOPE_VAL_START (482)—Fetch data starting at the first point sampled by the digitizer.

NISCOPE_VAL_TRIGGER (483)—Fetch at the first posttrigger sample.

NISCOPE_VAL_READ_POINTER (388)—The read pointer is set to zero when a new acquisition is initiated. After every fetch the read pointer is incremented to be the sample after the last sample retrieved. Therefore, you can repeatedly fetch relative to the read pointer for a continuous acquisition program.

Hope this helps.

Message Edited by Jeff B. on 08-11-2008 04:50 PM

Message Edited by Jeff B. on 08-11-2008 04:50 PM

[psisterhen]

Greg,

Examining the code you posted to the other thread, you never set the Fetch Relative To attribute and you use a Timeout of 0.0. 

If you don't set the Fetch Relative To, it should default to Pre-Trigger.  However, since in your case you never send the Software trigger, there is no first pre-trigger point.  Now, when you call FetchBinary16, the timeout value you use (0.0), tells the driver to give you whatever is currently available. 

It seems this causes the driver to treat Fetch Relative To as "Now," since it can't fetch any pre-trigger points.  This is exactly what Jeff is suggesting above (just wanted to give the rationale from the driver perspective).

Patrick

[sideways_the_dog]

Hey,

I'm still tweaking the settings a bit but based on a limited amount of testing I think it's working.  I'm stepping through some of the settings like minRecordLength and the timeout to see what's most efficient but that's just details. 

Thank you so much for your help!

Cheers,

Greg

[sideways_the_dog]

Hi, I hope you're still watching this thread.

The code is not really working after all, not as I expect.  There is something I'm not getting about the minimum record length, the minimum number of samples to fetch, the number of channels, and probably some other related parameters.

If I set the minimum number of samples to fetch low (to ~8k when the device would move 12k chunks at a time if it was higher) then the data I capture is syncronized between the two channels.  If I set the data high (~128k) then the data is no longer syncronized.  However with the low number of fetch samples, I am missing data from chunk to chunk- the data is obviously not aligned correctly from chunk to chunk when I feed an AM modulated signal into both channels, even though .

I would think a higher fetch number is better.  Sometimes even when the data starts saving as syncronized from channel to channel it drifts out. 

When I save the data to file, I do save the actualSamples from wfmInfo and use that to reconstruct the data.  Also if I output the data to the console I can see the channels are not reading the same values.  I'm very confused.

The following is in my code:

// Start acquiring data

handleErr (niScope_InitiateAcquisition (vi));

// this is a low level set command to perform continuous acquisition

checkErr (niScope_SetAttributeViInt32 (vi, VI_NULL,

NISCOPE_ATTR_FETCH_RELATIVE_TO, NISCOPE_VAL_READ_POINTER ));

[sideways_the_dog]

Attached is what happens during a transtion from one chunk to another (transition occurs at time 200)

[sideways_the_dog]

If I use a timeout of 5.0 and set the number of samples to fetch to 128k I consistantly get the data from all channels to align, but I still have a gap of missing data between the chunks.