continuous fetching time for PXIe-5122 always greater than 400us ?

[Anil_AFM_CranesSci]

Hello All,

I am using PXIe-5122 digitizer which has a maximum sampling rate of 100MS/s. And I have configured the digitizer in continuous acquisition mode, that is I have enabled software reference trigger and I am never sending any trigger. And for fetching the data while acquiring, I have set the property 'fetch relative to' to Read Pointer. Fetching VI is put inside a while loop. Also I am using RT Get timestamp for analysis.

My calculation is,
No of records = 1
Record lenght= 10
Sampling Rate selected =10MS/s
Hence, I consider that digitizer will acquire in each 1us (record leght/sampling rate)
So at any point T, digitizer's on board memory will have ((T/1us)*10) number of samples

The best fetch cycle time I could achieve is around 500us.
No of samples to fetch = 5000 (I16 format)
T, if number of samples is 5000 would be = (5000*1us)/10, from the above conclusion. = 500us

My doubt is whether the fetch is updating its wfm array once in 500us with a chunk of 5000 samples or it is updating wfm array element by element in each 0.1us (500us/5000)?. In short, is my output (fetch VI output array) lagging the actual signal by 500us or its just by 0.1us?

If it is lagging by 500us, how can I resolve my problem?, because my aim is to process the signal and send an output using another daq card as soon as possible.

Since I am using a PXIe bus with 400MS/s speed, data transfer speed won't be a concern. I hope so ( might take around 25us for this operation).



Anil K M
Indian Institute of Science

[Jennifer O]

Hi Anil,

Can you tell me a little bit more about what you mean by record length?  Since you are running in continuous mode & not triggering, no records are being recorded.  If you do configure a record length of 10 then this will be the number of points acquired as a record if/when you send the software trigger to stop the continuous acquisition.  Otherwise the number is never used.

If you set the sampling rate to 10MS/s then the digitizer will acquire 10 million samples in one second, or a sample every 0.1us.  If you have not fetched any data from the board, at a given time T in seconds, the board will have 10T milliion samples.

If you try to fetch 5000 samples at a time, it will take the digitizer 5000S/10MS/s=500us to have that data available. So assuming you are keeping up with the acquisition on the board, your waveform will be approximately the period from 500us ago until now.  If your loop is not running fast enough, then this could be longer (all depends on whats in your loop to hold you up.  Displaying the data can be taxing for example).

To get the data sooner than 500us, you would need to reduce the number of samples you are fetching at a time.  For example 500 points would be acquired on the digitizer in 50us.  However, there is some overhead in transferring the data in the first place and setting up the transfer will begin to dominate over the actual time to transfer the data.  It is more efficient to transfer more samples at a time.  So even though the data is ready in 50us, you may not be able to keep up with that loop rate, and a backlog of data can build up on the card.

Have you seen our streaming examples?  Information on streaming can be found at ni.com/streaming.  There is some LabVIEW code you can use as a guide which you can configure the amount of data to fetch per loop cycle, and it uses property nodes to keep track of the data backlog on the card.  The example can be navigated to from the previous link I mentioned, but just in case, here is a direct link: Streaming Example (http://zone.ni.com/devzone/cda/epd/p/id/5273) You can experiment with the fetching to memory examples to determine the optimal data fetch size for your application.

- Jennifer O.
Product Support Engineer - High Speed Digitizers

[AlexDubya]

Hi Anil,

Call up NI and ask about a 5122EX. It may allow you to get a smaller number of samples out faster and in effect speed up your inner loop. I believe that is what you're trying to accomplish.

[Anil_AFM_CranesSci]

Hello Jennifer,

Thanks for the quick reply

"Can you tell me a little bit more about what you mean by record length?  Since you are running in continuous mode & not triggering, no records are being recorded.  If you do configure a record length of 10 then this will be the number of points acquired as a record if/when you send the software trigger to stop the continuous acquisition.  Otherwise the number is never used." - I didn't know, Thanks! So in short, if I am using continuous mode and not triggering, digitizer would just keep on storing the samples at the specified sampling speed in the on board memory?

"So assuming you are keeping up with the acquisition on the board, your waveform will be approximately the period from 500us ago until now."- What do you mean by keeping up with the acquisition? does it mean that the read pointer (for fetching) and write pointer (for acquisition) needs to be as close as possible? Also, if the wfm array (output of fetch block) would contain datum 500us ago until now, do you mean that the wfm array would be updated with each new sample points (if true, wfm array doesn't lag behind the actual signal input to the digitizer, which is our requirement) or it is updated just once in 500us (i.e, it updates the wfm array with 5000 new samples just once in every 500us. In this case wfm array would be lagging behind he actual signal by 500us, bad situation for us!). This is where I am stuck in fact ! ! 

I am sticking to 5000 samples, because whenever I tried to reduce the number of samples to be fetched (even just 10 or 100). Some how the fetching time is not going below approx. 420us. Is the "overhead and setting up transfer" which takes this much of time or I am wrong some where !

I have gone through those examples.

[Anil_AFM_CranesSci]

Hi AlexDubya,

Thanks for the suggestion!

[Jennifer O]

Hi,

Yes you are correct, the digitizer stores samples at a constant rate until you kill the process with an abort or close.  So long as you pull data off as fast as it is going onto the card, then you can continue indefinitely. 

If you pull data off slower your memory will begin to fill up.  You can imagine holding a funnel under a tap.  If you run the tap faster than the water can escape out the bottom of the funnel, the water will fill the funnel and overflow over the top.  In this case your sample rate is the tap, and the fetch size is the size of hole in the funnel.  If the digitzer fills up and overflows, an error will occur.

By keeping up I mean that the data must be pulled out as fast as it goes in.  So the read and write pointer will grow from 0 to the number of samples you wish to fetch and jump back to zero when you fetch the data and repeat. 

Let's imagine the time period 0 - 2ms.  We start the digitizer and it will begin sampling at t=0s.  We immediately call fetch with a fetch  block size of 5000 samples=500us of data.  This is not yet available on the card so we sit and wait.  At t=500us the data is available for fetch and retrieve it back to the PC.  So now we have the samples for now, the current time t=500us as the final point in the array, as well as all the samples back to t=0.  Then we loop back for another fetch.  By this point several microseconds have passed and the next 5000 points will be ready for us by t=1ms. The data is not really lagging as you have data for the current time, but you will not have seen the previous 500us of info until now.

It sounds like what you would like to see is a circular buffer so that you see 0-499us, then 1-500us, 2-501us etc.  It would be wasteful to pull the data again if we already have it so you would basically throw out sample 0 and grab sample 500, throw out sample 1 and grab sample 501 etc.

Unfortunately you cannot keep up with a sample rate of 10Ms/s while pulling a single sample off the board at a time.  You would be limited by two factors.  The first is that the fetch of a single sample might take on the order of a couple hundred microseconds.  So at the rate that data is flowing in you will be filling up your digitizer.  This means the sample you pull in is no longer from the current time.  It also means the board will fill up and overflow.

It sounds like the overhead for your system is in fact around 400us minimum.  I tried a PXIe-8130 for comparison.  I see around 250us with this setup.  I plotted fetch times on my system for your comparison:



The x-axis is actually samples, and the y axis is time in ms.  Note the mutliple points for a fetch size of 5000.  The top point of 0.5ms is when the data is not yet available and the fetch is waiting.  The smaller fetchtime shows a backlog in data, where the data had already been available when the fetch was called, or soon after.  This backlog occurred when I was fetching only 100 samples from the board

Perhaps you could provide more background details on the requirements of your system  (Signal bandwidth, signal processing, is this for some type of PID control loop etc)?  The forum community might have some more ideas on how you can achieve your goals.  If not, try Sales or Technical Support.

- Jennifer O.


Message Edited by Jennifer O on 06-17-2008 12:19 PM