From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

High-Speed Digitizers

cancel
Showing results for 
Search instead for 
Did you mean: 

Determining Sample Rate

Thanks Nathan! I may have lead with the wrong question. Or at least wrong phrasing in my question.

 

When I say I need 400 samples, I mean from a continuous acquisition, I need 400 samples (EVERYTIME during a test) to extract information. That is the minimum. "At any given tiime" was poorly used phrasing as I see how you interpreted it.

 

Basically, I want 10MS/s decimated to 2MS/s. With that sample rate, I need to read 400 samples every 'dt' to create a stream of info. From that stream of info, I will write only 10 S/s into my data file (.csv)

 

I have attached images to show the 'initializedaq' and 'readdaq' cases.

 

Thanks for your patience and help with my questions.

Download All
0 Kudos
Message 11 of 32
(3,716 Views)

Yes, I think I understand you now.  Everytime you want to perform a test/measurement, you need 400 points.  Since you will be decimating, you will need the record size to be larger such that after decimation, you will be left with 400 points.  So if your decimating by a factor of 5, you will need to acquire 2000 samples, to end up with 400 samples after decimation.  

 

What is your "dt" that you need between each 400 sample set?

 

In your end application, you want to save your calculated measurements 10 times/sec.  For how long will this test run?  Forever, 24hours, 1 hour?  

 

What are you still unsure about?

 

 

Systems Engineer
SISU
0 Kudos
Message 12 of 32
(3,707 Views)

I am lost again. What is confusing me is the "number of records" in Configure Horizontal Timing and "minimum record length" and then "numSamples" on 1D WDT Fetch.

 

I just ran a test and 'number of records' can never be greater than 1. What does that indicate?

 

The 'dt' between each 400 sample set can be anything. Fastest that the loop will run becuase I am not setting any delay value as suggested. Now, As shown in the 'readdaq' image, if my 'min sample rate' is 10MHz, then should the 'numSamples' be 2000? How does that relate to 'min record length'?

 

Let's say my test runs for 10 minutes. My .csv file will have data at 10*60*10 = 6000 rows of data with timestamps at 0.01 'dt'.  I understand there is a flow to this data acquisition. Data to buffer and buffer to computer memory and computer memory to LabVIEW Front Panel. But, all these parameters are quite confusing that I am not getting the right combination. 😞

0 Kudos
Message 13 of 32
(3,703 Views)

For a 10 minute test, technically, I would have 6,000,000,000 samples of voltage information of which I use decimation factor of 5, so 1,200,000,000 samples of voltage information of a sine wave.

 

1.2 billion / 40 (samples per sine cycle) gives me a total of 30,000,000 sine cycles. I need to chunk 10 sine cycles at a time i.e. 400 samples. Therefore, 30,000,000 / 10 will give me my (Freq,Vrms,Irms,Phase) stream of data for the entire test which is 3,000,000.

 

Out of 3,000,000, I am only recording 6000. Sorry for the crazy numbers, but I am just trying to understand. Unless, there is an easier way to understand.

 

Given these numbers, What would be my "min sampling rate". "min sample record length", "numSamples", "num of records"? Or do I even need to bother with some parameters?

 

I don't understand why NI chose to use MINIMUM in the first place.

0 Kudos
Message 14 of 32
(3,699 Views)

First, let me explain why you need to configure "minimum record length", instead of just using "numSamples" on the Fetch VI.  When you configure "minimum record length", you tell the hardware how many data points/samples you want it to acquire, and store into the onboard memory buffer.  If you don't configure this, then it will only acquire and store the default number of samples (1000).  When you call the Fetch VI, this is what allows you to transfer the samples from the onboard buffer into LabVIEW memory.  In LabVIEW, you take your samples, perform operations on them, and write the results to file.  This is the process.

 

Since you are going to decimate by 5, and want to end up with 400 samples, you need 400*5 = 2000 samples.  (2000 samples & save 1 out of 5 = 400 samples).  You will want to configure "minimum record length" to be 2000.  This will tell the hardware that 2000 samples need to be taken from the ADC and stored into the onboard memory buffer.  You will then set "numSamples" on the Fetch VI to "2000" also.  This tells the NI-SCOPE driver that you want 2000 samples transfered from the hardware memory buffer into LabVIEW.  

 

For you, it will be easier if you set "number of records" to 1.  If you want to learn how to configure NI-SCOPE to do multi-record acquisitions (number of records > 1), see the links below.

 

 

Summary for your application:

"minimum record length" == 2000

"numSamples" on Fetch == 2000

"number of records" == 1

 

 

Here is some documentation of what a multiple-record acquisition is (set to > 1):

http://zone.ni.com/reference/en-XX/help/370592E-01/digitizers/making_multiple-record_acquisitions/

 

Since you are using LabVIEW, you can open the following shipping example for a demonstration of how this looks/works: Usinng the LabVIEW Example Finder (Menu Help>>FInd Examples...), open the example "niscope EX Multi Record.vi" found under: Hardware Input and Output >> Modular Instruments >> NI-SCOPE >> Getting Started >> niScope EX Multi Record.vi

 

If you set the "Number of records" to 1, then you will perform a single-shot acquisition.  If you set more than 1, you will perform a multi-record acquisition, which allows for multiple records to be acquired without calling niScope Initiate.vi.  This allows for the hardware to take records without software intervention.  For your application, this doesn't sound necessary.  For your application, set "Number of Records" to 1.

 

 

 

 

Systems Engineer
SISU
Message 15 of 32
(3,695 Views)

We chose to use MINIMUM because the hardware can't do everything the user specifies.  You specify minimum sample rate, the driver then determines if it can do it, if it can't, it will bump up the sample rate to a value it CAN do.  For example, you set "minimum record length" to 4.9MHz.  The driver sees this, say nope, and sets the ACTUAL sample rate to 5MHz.  

 

This is true for sample rate, record length, and all other parameters that have the word Min or Minimum in them.

 

Now, until now, I've been advising you on howto setup the NI Digitizer as a software timed, single-shot acquisition.  It looks something like this:

multirecord.jpg

 

The waveform data is only saved during a record acquisition.  You are not able to fetch data between records, and that is what I mean by "dead time".  Is this acceptable, or do you need to acquire samples continuously?

 

Edit: You can configure the digitizer to acquire data continuously, but its strange/complicated.

 

 

 

 

Systems Engineer
SISU
Message 16 of 32
(3,693 Views)

Thanks for bearing with me Nathan! I really appreciate it.

 

I get it now. Minimum record length will be 2000 for ADC to buffer. numSamples will be 2000 for Buffer to LabVIEW memory. From here, I decimate by 5. My datalogger will log at 10 S/s. Perfect.

 

One more question: Will I run into errors (especially with timing and no available samples and so forth) if I am reading ALL samples from buffer as they are being loaded into buffer? GIven my 2 jpegs, would you think that would work?

 

Basically, I would be doing "SINGLE SHOT ACQUISITIONS" multiple times until the test is done is my understanding.

0 Kudos
Message 17 of 32
(3,682 Views)

To address the dead time, is it possible to have adjacent records? Wouldn't "mminimun record length" = "numSamples" do that?

0 Kudos
Message 18 of 32
(3,681 Views)

There will always be dead-time between records.  In the device specifications, we list the minimum amount of time this will be. (Sometimes listed as re-arm time)  For the 5922 this is 144*Sample Clock Period).  If your acquisition is at 10MS/s, then the minimum dead-time will be 14.4us, for multi-record acquisitions.  Since we are doing software timing, it will be longer.

 

The dead-time is caused by the amount of time it takes the digitizer to transition from the post-trigger sampling state, to the pre-trigger sampling state of the next record.  See the digitizer state diagram below for reference.  Only during the green states are samples being transfered from the ADC to the onboard memory buffer.  So the time to transition from the last green state to the first is dead-time, the time in which no ADC samples are being saved.

 

Systems Engineer
SISU
0 Kudos
Message 19 of 32
(3,675 Views)

14.4us might be ok. If that delay is too much, then I may choose sample rate of 15MHz and decimate by 5 to get 3MHz to be over the required 2MHz rate.

 

One final question I guess. This is with regards to timing the loops. As you mentioned, I don't need a delay in my "readdaq" case as shown in the .jpegs I attached. But, lets say m "Read Data Buffer Delay" is 10ms. My CH1 Sample rate is 10MHz. So, the number of samples in this case that would feed into 1D WDT Fetch would be "Read Data Buffer Delay" x "CH1 Sample Rate" right?

0 Kudos
Message 20 of 32
(3,673 Views)