LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

data acquisiton at 1Ms/s

I want to measure 10 signals continuous acquire data at 1MS/s for 30 minutes . Please suggest reliable hardware.

0 Kudos
Message 1 of 12
(1,407 Views)

Resolution?

Min/Max Input?

 

Maybe NI-9223 three times.

 

Keep in mind that USB 2.0 only supports 480 Mbit/s which will lead to 48 Mbit/s per channel wich will lead to a max. resolution of 6bit. And you don't want a resolution of 6bits.

0 Kudos
Message 2 of 12
(1,387 Views)

Better to go with PXIe based hardware for the high-channel density and high-bandwidth bus.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 3 of 12
(1,351 Views)

I have used a USB-6366 to acquire continuously at 2MSa/s, but this device only has 8 channels. Not sure if there is a device that has 10 channels on it, may have to combine a couple of PXIe or PCI cards for the acquisition.

0 Kudos
Message 4 of 12
(1,346 Views)

I've used a pair of X series cards with a shared clock to do continuous 1Ms/s sampling, but that was a total rate across all channels. Not 1 Ms per channel.

 

If you need 1 Ms/channel you'll need something faster than USB. I'd also recommend streaming directly to SSD via TDMS since you'll be generating a crapload of data. 8 bytes per sample means 8 MB/second/channel, or 80 MB/second. That's 144 GB of data for 30 minutes, assuming you need all of the data.

 

If you're processing it on the fly you won't need to stream it to disk.

0 Kudos
Message 5 of 12
(1,336 Views)

@BertMcMahan wrote:

I've used a pair of X series cards with a shared clock to do continuous 1Ms/s sampling, but that was a total rate across all channels. Not 1 Ms per channel.

 

If you need 1 Ms/channel you'll need something faster than USB. I'd also recommend streaming directly to SSD via TDMS since you'll be generating a crapload of data. 8 bytes per sample means 8 MB/second/channel, or 80 MB/second. That's 144 GB of data for 30 minutes, assuming you need all of the data.

 

If you're processing it on the fly you won't need to stream it to disk.


 

Although there are exceptions, typically the high data rate cards are 16 Bits, thus 2 Bytes per point. USB 2, (NI cards are USB 2), has a theoretical maximum of 64MBy/s; 8 16 bits channels at 2MSa/s is 32MBy/s, 1/2 the max speed and most likely the fastest practical USB transfer possible. This is doable on USB as I have had colleagues stream continuously for weeks at this speed over USB. For it to work, everything needs to be set correctly in DAQmx, buffer size, numbers of samples, etc. You need to write in even multiples of the disk sector size for it to work reliably.

 

I agree PXIe is better suited, but much more expensive to start with.

 

Note the built in TDMS logging in DAQmx saves raw data with scaling information, not doubles, so 10 channels 1MSa/s, 16 bit, 30 minutes is about 36GBy.

 

image004.png

Message 6 of 12
(1,331 Views)

Ah, didn't know the TDMS streaming just wrote 2 bytes to the disk. Very cool! I was obviously assuming doubles. And thanks for the correction on the USB math.

 

Still- 36 GB is a lot of data for a single test. Hopefully the OP can do their processing on the fly. Loading that much data up for later review will be non-trivial. I haven't tried it myself but having to keep all of that in a page file on disk doesn't sound like a fun experience. Reading in sections at a time would probably be the way I'd do it, decimating the data to show an overview. You could then reread in sections if you needed to "zoom in" on a given section.

0 Kudos
Message 7 of 12
(1,318 Views)

The TDMS logging feature of DAQmx is highly underrated. All data is saved in raw form with scaling information, when possible the logging will do direct DMA transfers to the disk with no CPU intermediary, and will split files automatically if programmed that way. In addition, if you run as an admin on Windows, not sure why you have to be an admin, you can pre-allocate the file size which makes things a tiny bit more efficient.

 

Most, if not all of the people I work with, that is, the ones who use the programs I write, do NOT like TDMS files; but because the logging is so efficient I supply a file converter to them to save the data in an alternative form, that way I can use the logging feature.

0 Kudos
Message 8 of 12
(1,309 Views)

@mcduff wrote:

The TDMS logging feature of DAQmx is highly underrated.


It very much is underrated.  I specifically remember when it was released with DAQmx 9.0.  I was about to write a logging system for the test set we were building.  I was given a month, full time, to write this logging system.  I played with the DAQmx Logging for a week and was done.  It was the only time in the entire (very large) program where we had to write a program variance report because we got something done early.

 


@mcduff wrote:

Most, if not all of the people I work with, that is, the ones who use the programs I write, do NOT like TDMS files; but because the logging is so efficient I supply a file converter to them to save the data in an alternative form, that way I can use the logging feature.


Out of curiosity, what do they not like about TDMS?  I have some thoughts (not exactly a commonly used format outside of niche markets, was optimized for writing data, not reading).  If they just want to look at the data, Scout by SignalX is a great (free) utility for viewing and editing TDMS files.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 12
(1,300 Views)

Colleagues dislikes about TDMS - Mainly it does not fit their workflow. Some people here use Matlab, (yes, there is a reader but always seems to have problems with some files), Python (same reason as Matlab), IDL (no importer available I believe), and to a lesser extent sometimes Igor or another program. (Igor may have an importer, I know Origin does.) They want to analyze the data, not just visualize it, and often batch process the data.

 

In addition, the data needs to be archived for future use if needed, typically H5 is used for this endeavor, as it is the only format everyone can agree on.

 

Aside: Using the logging feature and setting the buffer, number of points, etc, correctly,  a colleague was able to log 16 channels from two PXIe 6386 cards continuously at 10MSa/s for each channel for 8 hours or until disk space ran out.

0 Kudos
Message 10 of 12
(1,293 Views)