06-09-2022 04:13 AM
I want to measure 10 signals continuous acquire data at 1MS/s for 30 minutes . Please suggest reliable hardware.
06-09-2022 05:18 AM
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.
06-09-2022 10:17 AM
Better to go with PXIe based hardware for the high-channel density and high-bandwidth bus.
06-09-2022 10:41 AM - edited 06-09-2022 10:42 AM
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.
06-09-2022 11:28 AM
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.
06-09-2022 11:46 AM
@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.
06-09-2022 12:45 PM
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.
06-09-2022 01:25 PM
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.
06-09-2022 02:20 PM
@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.
06-09-2022 02:35 PM
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.