Analog Discovery Pro (ADP3450/ADP3250) Linux Mode Survey

[artvvb]

Hi Everyone,

The R&D team here is digging into the possibilities for future products along the lines of the Analog Discovery Pro 3000 series and is looking to know a bit more about how important/useful it is that we include Linux Mode and related features into future devices.

We’ve been putting this survey out through some other channels and are curious for y’all’s thoughts and ideas. Both your answers to survey questions and any other discussions that naturally come up are greatly appreciated.

Survey:

Quote

 

• Do you know about the Embedded Linux Mode in the ADP3450 and ADP3250? (Yes|No)
  • Have you used it? (Yes|No)
  • If YES:
    • Please describe the application for which you used Embedded Linux Mode.
    • What was your overall experience with Linux Mode? (Scale 1-5)
    • What would you improve?
  • If NO:
    • What is the reason for not using it? (Open Text)
• Do you know about network connectivity (Ethernet) for the ADP3450 and ADP3250? (Yes|No)
  • Have you used it? (Yes|No)
  • If YES:
    • Please describe the application for which you used the device's Ethernet features. (Open Text)  
    • What was your overall experience with network connectivity? (Scale 1-5)
    • What would you improve? (Open Text)
  • If NO:
    • What is the reason for not using it? (Open Text)
• Do you know about WaveForms SDK? (Yes|No)  
  • Have you used it? (Yes|No)  
  • If YES:  
    • Please describe the application for which you used WaveForms SDK. (Open Text)  
    • What was your overall experience with WaveForms SDK? (Scale 1-5)  
    • What would you improve? (Open Text)  
  • If NO:  
    • What is the reason for not using it? (Open Text) 
• What sampling rate and analog bandwidth do you typically need for your current and future measurements? (Open Text) 
• What features or improvements would you like to see in future products? (Open Text) 

 

 

[Guest]

 

Hi @artvvb here's my answers.

Please take heed that I'm Dutch, and as per dutch culture I won't hold back on criticism ... We like to think that's efficient rather than impolite.

Do you know about the Embedded Linux Mode in the ADP3450 and ADP3250? (Yes|No)

Yes.

Have you used it? (Yes|No)

Yes.

Please describe the application for which you used Embedded Linux Mode.

To be frank, it's more of a "cool that it's possible" than that it's a truly useful feature.

On the 3450 I have seen spurious errors while accessing the device using the SDK that seem to be related to low-level communication bugs. In some usage scenarios, switching between Linux / non-Linux mode makes the frequency of these issues very different (or makes the issues go away). In some cases, the Linux mode is more stable; in other cases, the non-Linux mode.

What was your overall experience with Linux Mode? (Scale 1-5)

5/5

As an avid Debian user, I appreciate that it's essentially a full-blown Debian. I've installed enough software on it (recent gcc, Python 3.11, etc) to be able to test my pydwf binding, and was delighted to find that this was relatively painless.

I have /considered/ using the AD3450 as a stand-alone device, running serious software on it in a lab environment, but I haven't had a need to do that. But, it's cool that it is an option.

What would you improve?

Nothing really.

Do you know about network connectivity (Ethernet) for the ADP3450 and ADP3250? (Yes|No)

Yes.

Have you used it? (Yes|No)

Yes.

Please describe the application for which you used the device's Ethernet features. (Open Text)  

Lab environments for physics research, with many devices in a setup. Generally Ethernet-based devices are much preferred by me because the flexibility, remote accessibility, and overall buggyness of many device's USB implementations. If given a choice for any bit of lab equipment, I will give big preference to options that provide Ethernet connectivity, preferably with an open, well-documented protocol (that Digilent unfortunately doesn't have), so I can control the devices using nothing more than a socket, and do not have to rely on a closed-source library that will at some point become unsupported.

What was your overall experience with network connectivity? (Scale 1-5)

1/5

I was rather shocked to find that using the AD3450's ADC to get 1 sample/second transfers something like 60 MB/sec over the Ethernet interface.

Looks like the approach you guys took with the communication library is DEEPLY suboptimal. I consider this a serious quality-of-implementation problem and I won't be suggesting to buy any more AD/ADPro devices in the labs I work in for serious work until this is fixed. Which will probably be never, because this looks like a rather fundamental problem in the data handling approach.

What would you improve? (Open Text)

Fix the ridiculous bandwidth usage.

Do you know about WaveForms SDK? (Yes|No)  

Yes.

If YES:  

I made the pydwf package, a Python binding for the SDK.

What was your overall experience with WaveForms SDK? (Scale 1-5)  

4/5, but trending downwards to 3/5 with recent releases.

There is much to appreciate and some things to improve, see below.

What would you improve? (Open Text) 

- The documentation is really not up to standards. There's a lot of behavior in the devices that can only be found by a lot of reverse engineering.

- The fact that you guys present raw ctypes code as if it is proper Python support is pretty disappointing. The pydwf package is close to what I think you guys should have made in terms of Python support, but I can attest it's a lot of work to make and maintain.

- In recent versions of the SDK, functionality is creeping in that doesn't belong (eg the FFT stuff and windowing functions). These have nothing to do with device control and are completely out-of place; better alternatives are available in other libraries. This is just feature bloat for an already extremely heavy API, and an overall bad idea.

- The WF_SDK (https://digilent.com/reference/test-and-measurement/guides/waveforms-sdk-getting-started , https://github.com/Digilent/WaveForms-SDK-Getting-Started-PY/tree/master/WF_SDK) seems to be an attempt to lower the barrier of entry to using the SDK from python, but honestly, it is sub-par quality and mostly serves to confuse potential users, as its intended use and relation to the "raw" ctypes-based SDK is not made very clear. Also, because of my experience with implementing pydwf I can look at that code and conclude that the person(s) who made this really didn't have a deep understanding of what they were doing.

What sampling rate and analog bandwidth do you typically need for your current and future measurements? (Open Text) 

The more the better.

In the enviroment I apply the Digilent devices (physics research in the area of quantum applications), we use the Digilent devices for the "low end" stuff. They are pretty capable for their pricepoint, and the flexibility, programmability, and the Waveforms GUI application is far ahead of anything in this market segment I've seen.

For streaming input and output, the hardware is much more capable than what the API can deliver. The aforementioned Ethernet issue means I cannot stream beyond a few MS/sec in AnalogIn record mode, for example, which is very disappointing.

What features or improvements would you like to see in future products? (Open Text) 

- For the love of all that is holy, please fix the Ethernet bandwidth issue; It's a complete turn-off. This should enable MUCH higher sustained sampling rates in AnalogIn record mode. The hardware can do it; this is currently bottlenecked by a sub-par implementation which is super frustrating.

- Implement proper (frequency) counting support (the counter support in the latest SDK versions is not well thought out I think).

- Sampling at low sample rates should do proper averaging, yielding more bits of resolution. The current implementation loses potential information gratuitously by using 14 bits not only for the samples, but also for the averaged values.

- A proper clock-in connector for a 10/100 MHz reference clock.

- Ditch the ADPro 5250 (Windows only, for heavens sake) and similar future endeavours. It's no secret that it's a rebranded NI machine that looks to have been given DWF-support by pressure from some marketing dept inside NI. Strong Frankenstein vibes.

- Make harder stress- and duration-tests for your SDK. I see too many spurious errors with both the AD2 and ADPro 3450 on intensive use.

Edited April 6, 2023 by reddish

[Anthocyanina]

I only have an AD2, and my experience with it, and the support on the forum (including your team listening to user suggestions, which I don't know of any other company that does this, much less as fast as it's been here), has been absolutely amazing, and that has led me to consider Digilent's products for the future, but there are a few things which make the pro series hard to justify, so i'll comment about the last 2 questions

What sampling rate and analog bandwidth do you typically need for your current and future measurements? (Open Text)

The bandwidth of the pro series currently offered is really ok, the sampling rate however could be higher. for a 14 bit oscilloscope, of course faster AD converters would of course be significantly more expensive, but a 200MSPS sampling rate would be a good match for the 55MHz bandwidth.

What features or improvements would you like to see in future products? (Open Text) 

A big thing would be more voltage ranges than the current two. It being 14 bit makes it liveable, but it would be a really good improvement if more ranges were added, and in that form factor, I would think it wouldn't be impossible to accomplish.

I don't know about the acquisition rate of the pro series, but the AD2 seems to be about a few dozen waveforms per second. If the pro series is in that ballpark, it would also be a very welcome improvement if it could do at least a few hundred waveforms per second, and perhaps if this was accompanied with intensity graded display, it would make for some nice qol improvements, as it would allow us to find rare events more quickly and without having to resort to the persistence view. This, again, from having no experience with the pro series, so I don't know if it already works this way, but from video reviews i've seen, it doesn't.

Buffer size, while 16k points in the AD2 are still useful, and so 32k in the pro series would as well, having at leat 1M points for repeated acquisition would be really good as it would allow for a faster sample rate at slower time bases, and some times that is really important. I use my AD2 for most of what i do, but there are cases in which i have to use one of my bench scopes because of the buffer size(or when i need more bandwidth), so having one of Digilent's instruments with a larger amount of memory, with how incredibly good the waveforms software is, it would, at least in my case, result in me pretty much never again needing my bench scopes.

Input impedance would also be a nice qol improvement, if it had a switchable 50 ohm/1Meg input impedance, but this isn't super critical, at least for my uses, just something that would be really nice to have, and i think would make sense under the "pro" label :)

[zygot]

I have no interest in the "Pro" series products. They seem to be a half-hearted attempt at making a more expensive version ot the AD2 with marginal added utility. The AD2 is a great educational product; not so much a serious engineering or scientific tool.

Here is some unsolicited and random thoughts.

No one cares about what's inside your product enclosure. They only care about what it can do. Running Linux on a ZYNQ device is not a feature; it's a way to simplify your design effort, maybe, or maybe not depending on how you structure your design architecture.

The AD type devices are merely instruments that send collected data to a PC for processing. You could make an instrument that does all of that remotely in one box. Is that the kind of product that you want to make? Probably not at the low to mid price market range. So, this raises the issue of connectivity to a PC. Some customers for such a product can't locate a PC near the sensors being measured. Some customers can. Do you want one product that serves both more or less adequately at a lower price point, or do you want separate products that excel at either? Ethernet in ZYNQ PS has well known limitations, especially of you try and minimize costs. What is ZYNQ really getting you in terms of product functionality? Does a product need a PS to connect to an PC via Ethernet? Of course not. If you are going to burden your product design with a ZYNQ you certainly don't have to connect your Ethernet PHY to a PS. GEM. BTW, 1 GbE isn't the sexy thing that it was 10 years ago. There are PHYs that do 2.5, 5 or 10 GbE over copper these days. There's no question that an Ethernet connection is nice, if it performs well and is well supported. A much faster PC interface would be USB 3.2 or Thunderbolt. Of course you aren't going to connect an instrument to a PC using such an interface over 100 meters of media, at least not directly. But having this option would be easier to implement and customers would likely be willing to pay a premium for a fast PC interface to acquire data. [edit] I realize that USB at 10 GHz or above is unrealistic, but USB 3.0 certainly isn't]

A bigger concern for a data collecting instrument is the amount of contiguous samples that can be collected and either streamed or stored locally. [For about $2500] I can buy an Oscilloscope that samples at 1 GHz on 4 channels and stores 70 Gsamples. Why would I want to spend almost the same thing for an instrument that is essentially a lousy oscilloscope with very limited storage capability? USB and Thunderbolt can stream at very high data rates. 10 GbE can as well. Absent those interfaces, you need to have a large external memory connected to your samplers. A ZYNQ, even an UltraScale version, running Linux out of a limited PS external memory and having ADC data DMA'ed into it concurrently, while also trying to DMA data into a GEM isn't going to cut it. There's no requirement to construct an architecture that does this.

It shouldn't be too hard for an engineering team skilled at FPGA design ( who also uses FPGA based hardware to accomplish things ) to create instruments in the low-mid price range that make similar NI products obsolete. It's probably not reasonable to assume that NI would buy a smaller company and allow them to do that. It's also no secret that the Eclypse-Z7 is not so much a product as it is a scheme to get funding to pursue the development of the AD3xxx line of instruments. One has to do what one has to do if one wants to do something interesting and exciting in pursuit of new product ideas. Nonetheless, both of those products scream of the concept of "let's pitch an idea that the boss will buy into and throw some cheap hardware concepts together into a prototye and figure out later how to make it all work out". I'd suggest that any new products along the lines of the ADxxxx start out differently. Edited April 8, 2023 by zygot

[Robert White]

I am new to this product line but so far I am finding it very useful.  The linux mode seems very useful to me - I plan to deploy systems for environmental measurement using ultrasound, and the ability to easily program the system to autonomously collect data (with no connection to a PC or even needing a separate raspberry pi or something) and write to the local flash memory or a USB flash is extremely helpful.

[oltechie]

I use mostly AD2 for test equipment automation but have looked into the ADP series as well. 

Do you know about the Embedded Linux Mode in the ADP3450 and ADP3250? Yes, looks very intriguing.

Have you used it? No

If NO:

What is the reason for not using it? 

My uses need a user interface, typically a touch screen. Mostly it ends up being a tablet PC or a Raspberry PI derivative, and if so I already have an operating system. 

Do you know about network connectivity (Ethernet) for the ADP3450 and ADP3250? YES

Have you used it? NO

If NO:

What is the reason for not using it? Using the less expensive AD2 instead, which doesn't have this feature. If I had a need for the higher performance features of the ADP series I would certainly use the Ethernet as I can with other power supplies and so on. 

Do you know about WaveForms SDK? YES 

Have you used it? YES

If YES:  

Please describe the application for which you used WaveForms SDK. Two board test systems so far. Using the ADC inputs, GPIO inputs and outputs, waveform generator. I used the Python version communicating to a Node-red GUI front end as a daemon. Timing measurements and simulated IO. 

What was your overall experience with WaveForms SDK? Once you get it working, it is very stable and effective. The feature set is very good, you can do just about anything that can be done with larger systems once you figure out the quirks. 

What would you improve? Documentation is really hard to read. In most cases it is necessary to actually use the Waveforms app to do a parallel task, figure out which settings are reflected in which calls to the API, and then code it in the API. I agree with Reddish about the ctypes implementation, it is extremely non-Pythonic though it does work. 

It would really help if there were some way to translate a Waveforms setup file to SDK calls that could then be copy-pasted into Python etc. The scripting language in Javascript is not related to the SDK at all, so you can't just get a script working and then translate it to SDK calls. Leaves you poring over the documentation trying to figure out what the cryptic function names really mean. Or trying to edit an example that almost does what you want but leaves out an important feature. Lots of cut-and-try. 

What sampling rate and analog bandwidth do you typically need for your current and future measurements? 20 MHz is fine for what I am doing. 

What features or improvements would you like to see in future products? Really implement USB C, not just USB 2 in a USB C cable. My cheap devices don't have USB 2 slots anymore. Not necessarily taking advantage of the higher power capabilities, as most of the USB C slots in the cheaper devices don't correctly implement the power features. Better winky light that actually shows connection state. (Dreaming:) Add Segger device programming code to the digital profiles. Make a unit in the ADP series with a touch-screen and Linux. 

[SpinWizard]

On 4/6/2023 at 3:51 PM, artvvb said:

Hi Everyone,

The  Questions:

Do you know about the Embedded Linux Mode in the ADP3450 and ADP3250? (Yes|No)

Have you used it? (Yes|No)

If YES:

Please describe the application for which you used Embedded Linux Mode.

What was your overall experience with Linux Mode? (Scale 1-5)

What would you improve?

If NO:

What is the reason for not using it? (Open Text)

Do you know about network connectivity (Ethernet) for the ADP3450 and ADP3250? (Yes|No)

Have you used it? (Yes|No)

If YES:

Please describe the application for which you used the device's Ethernet features. (Open Text)  

What was your overall experience with network connectivity? (Scale 1-5)

What would you improve? (Open Text)

If NO:

What is the reason for not using it? (Open Text)

Do you know about WaveForms SDK? (Yes|No)  

Have you used it? (Yes|No)  

If YES:  

Please describe the application for which you used WaveForms SDK. (Open Text)  

What was your overall experience with WaveForms SDK? (Scale 1-5)  

What would you improve? (Open Text)  

If NO:  

What is the reason for not using it? (Open Text) 

What sampling rate and analog bandwidth do you typically need for your current and future measurements? (Open Text) 

What features or improvements would you like to see in future products? (Open Text) 

1. Yes
2. No,   Don't own the higher end units.
3. Yes
4. No
5. Yes
6. No  I'm actually a new user to Digilents offerings and haven't had a need yet to use an SDK.

With respect to the last two questions:

Right now I'm happy with the 2230 and its bandwidth, Sampling rates needs vary.   As far as current and future needs there likely is a need in the future for more channels and even better isolated channels.   Ideally more channels with out a significant loss of sampling rate.   Realistically though my interests are more industrial so extremely high bandwidth / sampling rates are seldom needed.   In any event more channels, including a trigger channel go a long ways.

As for features or improvements, in all honesty I'm a new owner and have not had a lot of exposure yet.   However that has never stopped me from making suggestions:   (realize I'm a new owner / learner)

1. PC's these days almost always come with some sort of "Sound Card", I'd like to see these used via another instrument that is always available and can handle basic oscillator duty.   In fact you can literally call it an Oscillator instrument though most sound cards can do better.   Now I realize that we have the WaveGen Instrument but I look at this as additional capability and frankly parallel capability that does not interfere with the channel to the Analog discovery.
2. A higher voltage range on a per div spec.   This would make the platform even more useful.
3. Add supported external DVM's instead of or in cooperation with the Analog Discovery.   These days that means a USB interfaced DVM's.   The idea would be zero effort implementation on the part of the user, even if that means a limited number of DVM's.   You can never have too many DVM's available and sometimes you need the safety of system multi meter.
4. I will likely have more to add as I learn about the hardware and software.   I'm especially interested i how the logic instrument works with slow electromechanics.

[artvvb]

Hey @SpinWizard

9 hours ago, SpinWizard said:

PC's these days almost always come with some sort of "Sound Card", I'd like to see these used via another instrument that is always available and can handle basic oscillator duty.   In fact you can literally call it an Oscillator instrument though most sound cards can do better.   Now I realize that we have the WaveGen Instrument but I look at this as additional capability and frankly parallel capability that does not interfere with the channel to the Analog discovery.

This is actually supported out of the box, not as a separate instrument, but as a separate device that works with most of the non-digital instruments like Scope and Wavegen as-is. It's at the bottom of the device manager list:

Thanks for the feedback!

Arthur

[attila]

Hi @SpinWizard

1. Adjust the format, channels and frequency according your hardware specs or requirements. The autodetection of this is not working due to the software abstraction layers.
2. Higher voltage rating would require different protection, certification, costs.... 10x probe increases the voltage range but above 50V with 1x can damage the device.
3. I'm not sure I understand what you are asking for. Do you need digital multimeter with USB and software support ?

[SpinWizard]

On 4/26/2024 at 12:23 PM, artvvb said:

Hey @SpinWizard

This is actually supported out of the box, not as a separate instrument, but as a separate device that works with most of the non-digital instruments like Scope and Wavegen as-is. It's at the bottom of the device manager list:

Thanks for the feedback!

Arthur

Thanks for that info.   I did eventually find how to assign the sound card to the signal generator.  

[SpinWizard]

On 4/26/2024 at 1:21 PM, attila said:

Hi @SpinWizard

1. Adjust the format, channels and frequency according your hardware specs or requirements. The autodetection of this is not working due to the software abstraction layers.
2. Higher voltage rating would require different protection, certification, costs.... 10x probe increases the voltage range but above 50V with 1x can damage the device.
3. I'm not sure I understand what you are asking for. Do you need digital multimeter with USB and software support ?

1.   I did eventually figure out what was going on with that part of the software.

2.  Yes I understand but a higher voltage capability just makes for a more flexible unit. 

3.  It would be nice if the software would integrate with external DVM's.   Most meters that have any communications capability support USB connections, so an easy add for most PC's.   Ideally the meters would show up as an additional channel on the "Voltmeter" instrument.   Voltmeters are a the most common instrument on a bench which is why the idea came to me.

 

At this point I'm really learning a lot about the analog discovery.