12-30-2011 07:05 AM
acording to this page
With 32 MB of acquisition memory, a digitizer with a sampling rate of 100 MS/s can maintain its maximum sampling rate for up to 320 milliseconds.
But I think because Digitizef has 8 bit resolution so a 32MB of acquisition memory only could save 32MB/2^8=131702 sample.
so for a digitizer with a sampling rate of 100 MS/s can maintain its maximum sampling rate for up to (131702/100MS/s)=1.3 milliseconds.
Which is correct?
12-30-2011 12:37 PM - edited 12-30-2011 12:39 PM
Units are your friend. If the resolution on a digitizer is 8 bits per Sample, that translates to 1 Byte per Sample. This means 100MS/s = 800Mb/s = 100MB/s:
Samples/s [MS/s] * 1Byte/ Sample [B/S] =
= 100MB/s (the [S / S] units cancel out)
If you want to know how long you can acquire at this rate, you divide your memory option [in Bytes] by your acquisition rate [in Bytes]:
MB / 100 MB/s)
= 0.320 seconds (the [B / B] units cancel out, and [1 / (1/s)] just becomes [s] ).
Instead you are using 2^8, which is the number of quantization levels representing an electrical signal. It has nothing to do with the storage capacity of the digitizer. If we used that in the math, the units don't really line up, so we can't make practical use of the resulting number.
12-30-2011 12:54 PM
Thanks so much.
But for example in Specification of NI PXI 5114 Maximum Number of Records in Onboard Memory for 8 MB/channel is equal with 32,768 and for 32 MB/channel is euqal 262,144.
Would you please tell me this difference and connection it with Sample rate?
01-03-2012 12:12 PM
As per the specifications for the PXI 5114, which can be found here, page 13 states that the16M/channel & 32Mb/channel both have 100,000* maximum records, so I'm not quite sure where you were pulling these numbers from. Similar documentation can be found on this page.
The spec "Allocated Onboard Memory per Record" will explain what this cap means. Each record size for storing the data and indexing must be in a multiple of 128 bytes with a minimum of 256 bytes. This means that even if you have a record of 1 sample (the minimum record size), 256 bytes will still be allocated for this one sample which is actually just 1 byte. As another example, if you were to have a record length of 500 (500 samples), you would have 500 bytes + 240 = 740 bytes required to store the data on the onboard memory, but because you must allocated in multiples of 128 bytes, 128*6 = 768 bytes are actually used.
So this cap comes from how many possible records you can store in memory. In this case the smallest record size would take up 256 bytes. If you have 8Mb of on board memory, you would be able to store 8MB/256Bytes = 32,768 records. This number just lets you know how many records you can store in memory. To maximize your data storing capabilities, you would want to take a number of samples per record such that your record size is a multiple of 128bytes, otherwise memory on your 5114 will be wasted. Of course this can be overcome by fetching data off of memory as you are acquiring.
01-03-2012 12:16 PM
Sorry, to clarify the spec I used in one of my example calculations, I looked at Allocated Onboard Memory per Record, which states that "(Record Length × 1 byte/S) + 240 bytes, rounded up to next multiple of 128 bytes or 256 bytes, whichever is greater", which was where I pulled 240 bytes from in one of my example calculations.
01-03-2012 02:01 PM
I want you to be aware that the specific board you are referring to only has 3 onboard memory sizes which are 8MB/channel, 64MB/channel and 256MB/channel. In the case that you have another board with 16MB/channel, the maximum amount of records (collection of samples) you could have is 16MB/256bytes = 65536. Which is for record sizes of 1 to 16. To allocate 256bytes of data for a record, you could have 1 sample + 240 bytes = 241 to 16 samples + 240 bytes = 256.
1. Suppose there was a 16MB/channel board and that you have 16 samples per record as your record size. This would mean that the maximum number of samples or data points you could store in memory is 65536 records * 16 samples/records = 1,048,576 samples for a hypothetical 16MB/channel. Now this is by no means the maximum number of samples you could store in memory. This is only if you want records of size 16.
2. Suppose there was a 16MB/channel board and that you just have 1 record to store in memory and you want to max out the record size to store the most samples in (remember that each record needs to allocate an additional 240 bytes, so with less records you will have more space for samples). If you set the record size to take up 16MB - 240 bytes = 16777216 bytes - 240 bytes= 16,776,976 bytes to store samples at 1 byte per sample, you could store 16 million or so samples.
Note that case 1 and 2 are the same device, a "16MB/channel board" but depending on the record size, you can take a different amount of samples. This is because of the way the boards allocate memory for records. In either case, if you fetch (take data off of memory and into your computer memory) you can store even more data than what I have indicated above. The above calculations assume that you are not taking the samples off of the memory as you acquire.
I just want to reiterate once more that the board you were mentioning before (NI 5114) does not have a 16MB configuration.
01-04-2012 07:30 AM
I don't know if it is still the case, but when I was using these boards a few years ago, some of the onboard memory was being used for housekeeping tasks, making the maximum number of samples a bit less than what you would calculate based on the memory size. I ended up getting this number empirically (it is really easy to do - just take data with increasing buffer sizes until you get an error; you don't need to fetch it, just take it; simple fetch could easily result in running out of memory in LabVIEW).