Can Analog Discovery Pro ADP3250 stabil reach 125 MSamples/s in record mode?

[egonotto]

Hello, can the Digilent Analog Discovery Pro ADP3250 in record mode reach really stable 125 MSamples/s with one channel or 62.5 MSamples/s with two channels in intern memory?

In the RoadTest Review: Digilent Analog Discovery Pro ADP3450 USB/Ethernet Mixed Signal Oscilloscope is said not to run stable.

 

My two Analog Discovery 3 can't even reach 8 MSamples/s.

Best regards

egonotto

[attila]

Hi @egonotto

With newer software version it can capture 4 channels 4x32M samples at 125MHz, or 2x64M, or 1x128M samples, or 8 channels (real+filter+wavegen loopback) at 62.5MHz.

[JColvin]

Hi @egonotto,

What settings do you have the Analog Discovery 3 set to / what are you attempting to record? For best results, make sure you have chosen the configuration that allocates the most buffer to the particular instrument of interest (such as Configuration 2 for the Oscilloscope or Configuration 4 or 5 for the Logic Analyzer). It should be able to reach up to 10 MS/s for a single channel when recording to host Computer RAM (changing the Mode dropdown from Repeated to Record) and up to 5 MS/s when Recording directly to file (Control -> Record to file or the "Rec." option next to Export).

Let us know if you have any questions.

Thanks,
JColvin

 

[Guest]

@egonotto

How long do you want to record?

The AD3250 can be configured with a pretty large buffer, but if you want to record indefinitely, that's no help. In the end, the bandwidth over USB or Ethernet will be the limiting factor, and the protocol is rather inefficient; thus the limits for such usecases are pretty low in my experience (less than 10 MS/sec).

[zygot]

3 hours ago, reddish said:

In the end, the bandwidth over USB or Ethernet will be the limiting factor, and the protocol is rather inefficient; thus the limits for such usecases are pretty low in my experience (less than 10 MS/sec).

Sounds about right. For USB, which is not DMA oriented on the upstream host end but highly software coupled, software latencies can wreck havoc with attempts at streaming. There are a lot of moving pieces in any particular USB implementation. The hardware involved can be a factor, but host OS considerations might be an even bigger factor.

There's a lot of gamesmanship in high end data streaming instruments; shouldn't be too hard so see why there would be more for low-end instruments. No one wants to tell potential customers to look elsewhere to accomplish their goals. Most customers buy stuff with one application in mind and then are disappointed when it stumbles on the next application.  

[egonotto]

Hello,

thanks for the answers. Now the consideration continues, whether the ADP3250 is something for me. I don't have a specific task for it yet.

I have now connected an AD3 instead of a USB 2 hub directly to the computer with a USB-C adapter. Now I sometimes even reach 12.5 MSamples/s for one channel or almost 6 MSamples/s for two channels. But sometimes there are errors at 5 MSamples/s for two channels.

 

Best regards

egonotto

 

[attila]

Hi @egonotto

Some other application or background service could sporadically increase the system load causing a longer latency, device buffer overflow.
The ADP3X50 has 128M sample buffer which should prevent such problems and the infinite recording should top at about 20M samples / sec (40MBps/16bit samples) over USB and 35MS/s for Ethernet (I have not tested these)

[zygot]

5 hours ago, attila said:

Some other application or background service could sporadically increase the system load causing a longer latency, device buffer overflow.
The ADP3X50 has 128M sample buffer which should prevent such problems and the infinite recording should top at about 20M samples / sec (40MBps/16bit samples) over USB and 35MS/s for Ethernet (I have not tested these)

Gee, how did I miss all of that fine print in the product advertising? Since these types of products include a customer's PC, doing who knows what, in addition to being part of the functionality of the product isn't testing something that should precede marketing claims? How does the word "should" ever get into a sentence by a vendor describing performance of a product?

[attila]

Hi @zygot

I have not tested "infinite" (extremely long) recording only limited.
Here 4 channels x 200M samples are recorded (streamed) fine over USB at approximately 40MBps, 20M (4x5M) samples / sec, the device having buffer for 4x32M samples. This rate being at the USB bandwidth limit, over time the device buffer may overflow, so for 'infinite' a bit lower rate should be used, < 4x5MHz or < 2x10MHz or 1x20MHz

[zygot]

So, you are saying that 1600 MB over USB 2.0 or 2800 MB over Ethernet is a guaranteed gap free session for streaming ADC samples as long as the total sample rate is 20 Msps for USB or 35 Msps for Ethernet? Do you have an example of this for Ethernet?  The only practical way to test for gap less data collection is to use the ADC triangle test waveform. It's hard to tell from the screen grab.

You don't provide any information about your host, like PC, OS, memory etc. Since this is part of your instruments, I'd imagine that performance has a dependency on such information. Certainly a RPi4 wouldn't be expected to provide the same results.

 

[Guest]

Hi @attila,

I do agree with @zygot that you should only quote performance numbers that you have tested, and are willing to guarantee.

I disagree that more info is needed on your test setup, per se. Just take a high-end system, with an optimal connection (point-to-point USB or Ethernet), ensuring that the bottleneck is not in the communication or host PC's processing, and add a disclaimer like "performance may be bottlenecked by your test system or sub-optimal communication", or something like that.

A complicating factor is that the AD3450 is really behaving differently in Linux and non-Linux mode, and in USB vs Ethernet mode. Ideally, all four combinations should be reported on. If not, the next best thing is to report the best-case performance, static clearly what you're using.

A very desirable thing would be to have a long-duration acquisition (i.e., so long that the device-side buffer size doesn't matter anymore) bandwidth test as a standard part of your pre-release test process. Not only would this give you a rather central performance figure to report to prospective and current customers, but it would also help to iron out bugs. One thing I have noticed is that spurious errors occur on long acquisitions with both the AD3450 and AD2, and the prevalence really depends on the mode and communication medium.

The problem is all this costs time; but this kind of attention to quality is what differentiates low-end from high-end measurement equipment. While I like Digilent hardware and software, overall, this is really a potential area for improvement.

 

[zygot]

7 hours ago, reddish said:

I disagree that more info is needed on your test setup, per se. Just take a high-end system, with an optimal connection (point-to-point USB or Ethernet), ensuring that the bottleneck is not in the communication or host PC's processing, and add a disclaimer like "performance may be bottlenecked by your test system or sub-optimal communication", or something like that.

This argument is certainly debatable.

Certainly there have been users reporting problems getting expected performance and use a RPi, which is a supported host.

I do a lot of USB work involving FPGA-PC connectivity, on a lot of different host platforms. In my experience the capabilities of the host as well as the OS, OS version, and other details do have a significant impact on performance. For USB 3.0, even the driver/OS combinations can be problematic. The major issue with USB is variable latencies, because USB is so tightly coupled to software support being involved in data transport. It's really hard to quantify USB performance for a given host. The basic concept of a large device buffer absorbing random latencies is OK, the problem is that, obviously, it's not sufficient. My sense is that the reason for buffer overflows in the device for long data streaming sessions is due to the host not being able to drain data fast enough. I may be wrong about this.

I'm betting that a lot of AD3xxx users aren't using high-end PCs with lots of available memory not taken up by the OS.  Obviously, streaming 8 GB of data into memory on a host with only 2 GB of available memory is going to be a problem.

For Ethernet, data transfers use DMA both in the device and host end. I'm guessing that the 70 MB/s limit here, where something closer to 120 MB/s might be expected, is due to the device architecture, not the host capabilities.

There are two basic ways to deal with data transport issues.

• decouple the host from the instrument. This would mean that the instrument would either do everything, like an oscilloscope or waveform generator, without involving the host. That means a lot of potential storage capabilities in the instrument, less customization and certainly a higher cost. Allowing the user to pay for optional storage capabilities would make marketing simpler.
• If an instrument design can't accommodate "infinite" data acquisition or waveform generation, however you choose to define "infinite", then simply proudly advertise that the product doesn't support such a mode of operation. That's the simplest solution.

However Digilent deals with marketing it's products, and this includes videos and demos that suggest use cases and performance that Digilent might not want to specify as guaranteed, one thing is for sure: customers who buy a product with an expectation based on what they read from the vendor and then get a product that can't perform to expectations are going to be unhappy. The real question is whether or not National Instruments cares about their customers or it's own reputation. Some customers are corporations or entities with a significant budget to spend on equipment.

The ADxxxx line of instruments is, largely due to the efforts of Atilla and his colleagues who supply really good responsive after the sale support, are fantastic niche products. It's this support that makes the products unique. As to whether the performance of the higher cost AD3xxx products represent enough "bang for the buck" justifying their cost, well that's up to the individual customer. Customer's can't make that analysis without clear performance specifications.  

For test instruments costing $50-200K clear guaranteed specifications is a requirement if you expect to sell anything. This costs money which then drives product cost. The Digilent AD3xxx instruments are a special class of low cost, but not insignificant cost market where you can sell stuff without the testing and hard specifications. That doesn't mean that you can abuse customers with impunity.

Edited July 18, 2023 by zygot