Jump to content
  • 0

Rapid Block Streaming of ADP Data via USB Triggered via TTL


b4byhulk

Question

Hello there,

 

since support asked me to put my question out in the forum:

we are thinking about purchasing an Analog Discovery Pro product. In our use case, we need to capture ~600 samples of analog data (min. 12 bit) at min. 64 MSa/s (1 channel) when a falling edge of a logical input is detected. We want to stream these triggered blocks of data continuously to a PC via USB. The minimum trigger rearm time between those events should be in the single-digit microsecond range. Implementation via SDK by us is required. Which product meets those specifications?

Some clarification: With the current USB oscilloscope, we can either continuously stream analog and digital data to a PC and check for trigger events there (data rate limitation, high computing power requirements) or we can use a block trigger mode that captures up to ~150k waveforms until we need to empty its memory which introduces downtime.

Thank you in advance!

Link to comment
Share on other sites

4 answers to this question

Recommended Posts

  • 0

Hi @b4byhulk,

I believe this question of yours emailed to me from the Sales team, but I don't know how much of my reply got communicated back to you, so I'll send the relevant portions of the material again.

The two products I'll be mentioning are the ADP2230, https://digilent.com/reference/test-and-measurement/analog-discovery-pro-2230/start, and the ADP3450, https://digilent.com/reference/test-and-measurement/analog-discovery-pro-3x50/start. Both of these products have 14-bit analog input resolution, but the samples themselves are stored in 16-bit samples.

The Analog Discovery Pro ADP2230 (at 14-bit analog input resolution, trigger re-arm time of 1-2 us) will be the best suited device for this task thanks to the USB 3.0 connectivity, with two caveats.

I do not know how many channels you are wanting to record, but because you used the unit of mega samples per second (MS/s) for your requested minimum 64 MS/s, the ADP3x50 simply lacks the hardware capabilities to continuously transfer data at that rate. With my ADP3450, I could achieve is around 66 MB/s, which for 16-bit analog samples translates to 33 MS/s:

 

However, if you are not wanting to stream data continuously, this might not be a problem (see second caveat).

On the other hand, the ADP2330 can sustain a constant streaming rate to the host computer of nearly 300 MB/s. You can see my results here where I streamed 5 billion samples for both of the analog inputs running at a rate of 62.5 MHz (half of the 125 MHz system clock):

The first caveat (though not really a problem) with this is that due to the way the internal hardware clocking works, you will have to set the system clock speed (directly adjustable within WaveForms) to 64 MHz (closest I can get in hardware is 64.0625 MHz) in order to achieve the 64 MS/s sample rate, but you can then continuously stream to a binary file at that rate as I just did with my own ADP2230 on my desk:

thumbnail_image002.png

I don't have a script/SDK version on hand for the test I just did, but there are many example scripts built into WaveForms SDK that will perform the recording operation.

The second caveat (which also might not be a problem) is that you indicated that you wanted single captures of a relatively low number of samples (600 samples vs the buffer size of 64 million per channel for the ADP2230 and 32 million per channel for the ADP3450). Thanks to the fast trigger re-arm time of the two devices (1-2 us for the ADP2230 and 0.2 us for the ADP3450), you may be able to may be able to use a script that just does repeated single captures at up to 125 MS/s (since the input buffer won't be anywhere close to filled with the desired 600 samples), as indicated in this Forum thread:

What I don't know regarding this approach is how much the USB transaction lag will be with multiple completed handshakes for all of these repeated single transactions as the handshaking for the start and completion of each USB transaction is by far the slowest aspect of USB.

Let me know if you have any questions.

Thanks,
JColvin

Link to comment
Share on other sites

  • 0

Thank you for this long answer! Some clarification:

1: I only need one analog channel with at least 64 MSa/s.

2: I don't want to stream all the data all the time, I am asking for a mode where data is only transferred from the device under a digital trigger condition.

3: I need to do this with us downtime between those data blocks and continuois transfer of these blocks to the PC.

Is that possible using any of the ADP devices?

Thank you in advance;
Johannes

Link to comment
Share on other sites

  • 0

Hi, is there any update? Which device would you recommend in terms of maximum possible USB data streaming of one analog and one digital channel?

 

Thank you! :)

Link to comment
Share on other sites

  • 0

Hi @b4byhulk,

I apologize for the delay.

If you are wanting 'maximum possible' streaming, then the ADP2230, https://digilent.com/reference/test-and-measurement/analog-discovery-pro-2230/start, with the USB USB 3.2 Gen 1 connectivity is going to be your best bet.

If you don't need a large amount of samples and want to do it all in app, you could set something up like this where I have device buffer enabled (only available on devices with DDR memory), the samples set to 4 k (as an example number; this translates to 4096 samples being taken every acqusition, so at 100 MHz, this translates to 40.96 uSec), and Logging enabled to log the results to a .bin file for each triggered acquisition, where in this case the trigger is a rising edge coming in on DIO 1. You can, of course, do other trigger conditions, I just picked this as a known consistent trigger condition.

DIO 1 happens to be running as a 500 kHz clock (2 uSec period), so this translates to each acquisition taking between 40.96 and 42.96 uSec. The ADP2230 is advertised as having a 1 to 2 uSec re-arm time, so realistically we should see the acquisitions happening every 42 uSec to 44 uSec, leaving a the re-arm time after subtracting out the acquisition + trigger occurrence time.

The small video clip below shows advertised timestamp difference between data acquisitions for recording both analog input channels to a series of .bin files:

 Let me know if you have any questions.

Thanks,
JColvin

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...