Buffering/Working of NI PCIe6537

[razor149]

Im using NI PCIe 6537 DAQ to acquire data from a digital pin. I am supposed to acquire data at a rate of 25MHz. The help provided in the discussion forums as well as KB, are more tuned to LabVIEW. But I am limited to Signal Express and I need specific guidance relating to this.

Sampling rate is 25MHz and this has to be a rigid requirement. I am using the Continuous Sampling mode.

1) When I set the "Samples to read" as 1k or 2k I immediately get an error 200279. This is because of the buffering problem, right?

2) I increased the "Samples to Read" with Options->Logging "Prepare data for viewing== "During Logging". Again I get an error 200279 in 1 second itself. Why ??

3)If I change that option from "During Logging" to "After Logging", the acquisition seems to work at least for 5 seconds as well as 1 minute.( I have not tried beyond 1 minute). The question here is that the PCIe 6537 Specifications mention that Maximum onboard FIFO buffer size is only 2048 samples. Then how is SignalExpress taking 25M as "samples to Read" ??

4) If I use the Sample Timing as "External" and give a 25MHz clock on PFI5, do i still need to input "Sampling rate" and "Samples to Read"? Wouldn't the external 25Mhz clock override my "Sampling rate" setting? And what would be the value of "Samples to Read"?

5) In one KB, I found that the general rule for NI DAQ is to keep "Samples to Read" as 1/10th of sampling rate, for computing resources to keep up. If I keep rate as 25MHz and "samples to read" as 2.5M, this definitely fails because I get very less samples in one second instead of 25M samples/second.

Please help me in the best way you can. I want to mention here that my final aim is to log data from the digital pin at 25MHz, for a total time of 24 hours non-stop.  1 min of 25MHz sampling gives  1.5GB TDMS and 5GB text ASCII file. I will run out of memory well before 24 hours. Do you have any other low-memory intensive formats? I have a 4GB RAM and running Windows 7, Intel Core i7, 420GB HD.

[Kevin_Price]

I've never really used Signal Express, but here are a couple quick general thoughts:

1 & 2.   Yeah, if you're buffering at 25 MHz, there's too much software overhead to read only 1k or 2k at a time.  Doing other things "during logging" can get in the way too.

3. The DAQmx driver is moving your samples from the board to system RAM using DMA over the PCIe bus.  That's why you're allowed to buffer 25M samples at a time -- the driver is moving them to system RAM for you.

4. Probably a good idea to provide a good estimate on "sample rate."   The DAQmx driver will "believe" what you tell it and may use that info to drive other settings (like buffer size, etc.).

5. Sorry, no immediate ideas.

6. Better think about a data compression scheme and better look into a producer-consumer architecture to prevent DAQ timing errors.

I don't know the 65xx family all that well, but it appears to support change detection.  I would *definitely* try to use that feature if you can because it could drastically trim down the amount of data you need to collect.

  Alternate schemes might include bit-packing some integers so you can store 8 samples per byte rather than 1.   Or perhaps you could do the measurement with a counter rather than a 1-bit digital input.  (You'd probably need to use a different DAQ board.)

-Kevin P

[Yupeng_Jia]

I think the following article will help answer your questions 1, 2 and 5

Why Do I Get Error -200279 from my DAQmx Read VI or Property Node?

[Yupeng_Jia]

This is a buffering error, so you can either increase the samples to read, or decrese the sampling rate.

[razor149]

Thank you for your reply.

I have read that document already, and thus realised that i should change it to 25M from 1k or 2k.

I have been doing some more runs, and have had interesting results, and more questions. I will get back with my questions soon!

Thanks.

[razor149]

Hi Kevin, and all other NI Engineers out there:

Thank you for your detailed reply. Most of your answers matched my inferences so that was good. As I "promised" 🙂 , I am going to post some really interesting results and figures in this post. I have done many runs and many cases, and reading the post may require time and attention or else it may be confusing. Most or all of these issues are with regards to the recorded waveforms.

So here it is:

Desktop Config: Intel Celeron, 4GB RAM, 64 bit System, Windows 7. ( Its Celeron, not Core i7, sorry for mistake in first post).   This desktop only has Signal Express running. Nothing else.

Software: SignalExpress 2011

NI DAQ mx: Latest 5.2 version.

DAQ Card: NI PCIe 6537.

Voltage: 2.5V peak-peak. 1.25V DC offset. (SO its 0V to 2.5V swing)

Voltage Family: 3.3V

Prepare Data for Viewing: After Logging.

Sampling mode Continuous.

Case 1: (OK)

Input Square Wave of 6.25MHz. Duty Cycle: 50%

Sampling rate: 12.6MHz;

Samples to Read 12.6M

Clock Type: Internal.

Trigger: <None>

Result: Duty Cycle is as expected (Visually)

 Case 2: (Issue: Higher Sampling Rate)

All same as Case 1, except:

Sampling rate: 20MHz;

Samples to Read 20M

Result: Duty Cycle incorrect! I thought oversampling should not be an issue. Sampling theorem cannot be wrong. 🙂

Please explain.

Case 3, Case 4: Same experiments were repeated with an external clock(Active edge: Rising) of 12.6M and 20M on PFI-5. Same results observed. 

Trigger: <PFI5 Rising Digital Edge.

Now experiment changes, more rigid requirements. Clock has to be 25Mhz(External) , and Data has to be 12.5Mhz. Duty Cycles of data: 25%, 50%, 75%.

Case 1: (OK) 50% DC

Input Square Wave of 12.5MHz. Duty Cycle: 50%

Sampling rate: 25MHz;

Samples to Read 25M

Clock Type: External PFI5, Active Edge:Rising

Trigger: Digital Edge, Rising,PFI5

Result: Duty Cycle is as expected (Visually)

Case 2: (Issue 25% DC)

Everything else same. 

Duty Cycle: 25%

Result: DC 0 Volts. (Low)

Case 3: (Issue 75% DC)

Everything else same.

Duty Cycle: 75%

Result: DC 2.5 Volt. (High)

This is very confusing because Clock is exactly twice the data, still its giving me a straight line. In my real application I cannot increase it beyond 25M. But for now I increased the Agilent Signal Generator to 30MHz, hoping to get a better waveform, but here is what I saw. Even 50% does not work now.

Case 1: (Issue) 50% DC

Input Square Wave of 12.5MHz. Duty Cycle: 50%

Sampling rate: 30MHz;

Samples to Read 30M

Clock Type: External PFI5, Active Edge:Rising

Trigger: Digital Edge, Rising,PFI5

Result: Duty Cycle non-uniform.

Case 2: (Issue) 25% DC

Everything same.

Duty Cycle: 25%

Result: Duty Cycle non-uniform.

Case 3: (Issue) 75% DC

Everything same.

Duty Cycle: 75%

Result: Duty Cycle non-uniform.

ASCII output:    111111 0 1111 0 111111 0 1111 0    (Obviously not 75% )

Now someone please explain all of this, or better still some NI DAQ Expert's opinion is most welcome.

I have tried 'n' combinations of Sampling rate, Internal, External, Sample Clock, Phase matching etc etc and almost all I can do with Signal Express. Its sad that such a basic data acquisition is being so unpredictable.

Signal Generators are working on a real-time scope.

Please Help as soon as possible.

Thanks.

[razor149]

DAQ MX Version: 9.5.1, not 5.2

[gharris]

I have a few thoughts for you that I hope will be useful - The on board clock of the 6537 is running at 400MHz, so at least for internal clock sources, that sets your time resolution (2.5ns).  So when you set your clock to 12.6MHz, the driver is going to round to the closest available frequency (12.5MHz). I think that is probably why the 6.25MHz signal looked so nice.  Maybe the external clock is being monitored and responded to by the card at 400MHz clock, explaining why the external clock behaved the same.

The same problem happens when you are sampling a 6.25MHz signal at 20MHz - you don't have an integral number of samples per signal cycle (20/6.25 = 3.2).  Also changing the duty cycle is effectively adding higher frequency signals into your 6.25MHz signal - you'll need to increase the sample rate if you want to accurately catch the time of the rising/falling edges.  The 6537 reads and writes on the rising edge of the clock, so you'll need a clock edge at the right time to catch your signal change.

For data compression, can you pack bits in signal express?  Instead of saving your data as 8bit values (I think thats what you're doing based on your file size numbers) can you shift and pack into U32 or something similar?  RLE could help if you're expecting infrequent changes in signal too.

[razor149]

Hi gharris,

Thanks a lot !

The "non multiple of 2" sampling rate is the issue. So if the sampling rate is2x, 4x, 6x, 8x etc, the duty cycle is maintained, but something like 3x is giving wrong results obviously.

It was so easy to overlook that one.

And yes, for the duty cycle too, a 25% duty cycle of 12.5Mhz will no longer sample at 25Mhz. I just drew it on a whiteboard, and got the answer, and 50Mhz sample rate for 25% DC works good.

Even though I cannot use a clock of more than 25Mhz, I think most questions are resolved now.

As for the data format, I will have to do post processing. Thats not a suitable method. I was looking for alternatives where NI SignalExpress or LabVIEW(If I end up buying it) if they can itself produce low memory formats.

Thanks.