JColvin

Hi @rpatel,
For the SMT4, I have been informed that the worst case for Vdd is 115 mA and the typical usage is 90 mA with JTAG running at max speed and UART running at 1 MBaud. The Vref current at 30 MHz is 12.5 mA typical and 35 mA max (unless you short the outputs, then Vref would probably peak out around 170 mA).
You didn't ask about minimums, but when the USB controller is held in reset, the current consumption is ~20 mA. When it comes out of reset and enumerates on the bus it's ~87.5 mA.
Let me know if you have any questions.
Thanks,
JColvin

Hi @rpatel,
I received confirmation from the design engineer that all of the needed decoupling is built into the SMT4 module, so you will not need to implement anything extra for that.
Let me know if you have any questions.
Thanks,
JColvin

Hi @AndyMessier
It can generate waveform or pattern from device buffer up to system frequency sample rate or higher, by skipping some, see AnalogOut_Custom.py example
The system frequency, for all instruments can be adjusted with DwfParamFrequency.
In play mode the data is streamed, transferred in chunks from computer, limiting the sample rate to 1-2MHz
The newly added idle hold option keeps the last output value in done state, with finite run time.

Hi @bobql,
The built-in AnalogIO_DigitalDiscovery.py example should cover everything that you are looking for; the main detail is that the AnalogIO functions handle power supplies, reference voltages, voltmeters, on-board temperatures, etc for all devices.
Section 14.4 (Digital Discovery) and the Section 7 (AnalogIO) within the WaveForms SDK reference manual have some additional documentation.

Let me know if you have any questions.
Thanks,
JColvin

Hi @Kevin.C,
I believe the latest beta versions (3.22.14 onwards) of WaveForms are now signed as per this thread from last month:
The beta versions are freely available here:
The next release version of WaveForms will be signed as well, but I am not certain when the next release will be; it usually coincides with a compatible product release, but Digilent does not have anything to announce as of yet.
Let me know if you have any questions.
Thanks,
JColvin

You can simply reassign a MAC address on your new system to be the same as what you had in the old one, and license will work just fine. I've done it for my license which came with my Genesys 2 board when the time came to replace my PC.

Hi @yildizabdullah,
I have sent you a PM with some instructions on how to recover the JTAG HS2.
Thanks,
JColvin

Hello,
I have moved your question to a more appropriate section of the Forum where the WaveForms developer will be able to see and respond to your question with more accuracy than I can provide.
Thanks,
JColvin

Hello again @JColvin
apologies for not getting back sooner, yer it works fine without issues
got an api based around the library finished and fully tested today without issues
thank you very much for your help

Hi @Evan Cleary,
I do not believe there is a way to access the DMM from the Digilent LabVIEW VIs and at least as of yet have not heard any plans to
There is an existing Python example that uses the DMM on the ADP5250 (AnalogIO_ADP5250_DMM.py); you can find it in the samples folder alongside the PDF version of the WaveForms SDK Reference Manual; you can readily open this folder from the Welcome tab of the WaveForms application.

Alternatively, if you happen to have existing VirtualBench VI material that runs the DMM, you can replace some drivers to make it work with the ADP5250 as mentioned in this post and the one immediately following it:
The catch with this, of course, is that this is technically a work-around as opposed to an official workflow.
Let me know if you have any questions.
Thanks,
JColvin

Hi @Luke Aldrich
The demo mode is intended to explore the application and device options; triggering, record... are not its strengths. 
The ADP2230, AD3X50 have deep onboard memory so even if the computer is slow on data transfer or storage it should be able to capture up to device buffer size lossless.

Hi @Takashi "The Yaka mein",
I reached out to the Engineering Services Manager about this last Friday. I will follow up again today to hopefully learn an update.
Thanks,
JColvin

Hi @Takashi "The Yaka mein",
I have sent you a PM with some additional information.
Thanks,
JColvin

Hi @Takashi "The Yaka mein",
Yes, this voucher should have been included with the Genesys 2. If I remember correctly, this would be on a piece of paper that is inside the Genesys 2 cardboard box.
If this voucher was not in the box for the new product, then I will look into this and work with you to get this resolved.
Thanks,
JColvin

Hi @Jones (cc: @JColvin in case other people ask):  
Software:
GNURADIO (gnuradio.org) is to SDR what gcc/gpp is to C/C++ (see also: radioconda).  Much of Ettus' most readable how-to documentation for the B210 (and other USRP devices) is in the form of presentations at GRCON.   GNURADIO is written in C/C++ (core API / tools) and Python (high-level interface and tools).   MATLAB has lots of SDR-related toolboxes that are easy-to-use, convenient, and remarkably slow.   MATLAB code for SDR can be made more performant by spending $12,000 (per seat) on their C++ cross-compiler.  I wish I was kidding. radioconda (https://github.com/ryanvolz/radioconda) is exactly what it sounds like: a superset of conda that serves as a drop-in replacement for your regular conda distribution.  It contains the latest version of GNURADIO and other open-source SDR tools, and works out-of-the box for Linux, Windows, and Mac, including Arm64.  Not just python: it includes C/C++ tools and apis  It contains the full set of Ettus USRP/UHD drivers, tools and APIs. What's the catch?  Python version is usually 1 or 2 points behind, e.g. current radioconda python version is 3.10.13, latest stable release is 3.12.2 What are the benefits?  Radioconda "just works:" until a couple of years ago, GNURADIO was very hard to install on any platform that's not Ubuntu - back then, it made MATLAB  a viable choice for SDR.  Can GPIO be used for Signals? (short answer: no, and do not connect your TTL output to the SMA antenna port):
The relevant page for electrical characteristics of B2x0 is here: https://files.ettus.com/manual/page_usrp_b200.html#b200_hw_ref_ext   The 'definitive' guide to USRP GPIO (including B210) is here: https://events.gnuradio.org/event/18/contributions/234/attachments/74/186/GPIOs on USRPs.pdf On newer B210s GPIO header 504 is populated, so you can indeed use it, but not for signal. B2x0 GPIO is used for: controlling and monitoring the 'state' of the radio: e.g., which banks are transmitting or receiving, which lights are blinking, etc. communicating with the built-in FPGA.  10MHz clock ref (which, except on B200-mini, already has an SMA connector on the front panel). WARNING: "RX power -15 dBm max" (from the above electrical characteristics manual).  Applying a signal with greater than about 0.03 milliwatts of power to the Rx2 or Rx/Tx SMA connectors risks "magic smoke"-level damage to your B210. Other Resources:
The most comprehensive description of USRP, UHD, SDR, and gnuradio tools (somewhat dated, but still basically true): https://kb.ettus.com/images/4/47/Workshop_GnuRadio_Slides_20190507.pdf If you're new to SDR, watch Michael Ossman's video series on intro to SDR (using HackRF): https://www.youtube.com/playlist?list=PLu0BPYzTjiHru1KmPThmbY-8rRm3EWvUQ You can follow along and do the exercises with a USRP instead of a Hackrf. (Disclaimer: I do not work for Ettus/NI/Emerson/Digilent and I am sometimes wrong) 

Hi @digitalone,
For the split termination setup that is used on the Pmod CAN (both ends terminated if they are the ends in your system), my understanding is yes you will want to use JP2 to enable the capacitor load, at least based on this TI App Note (section 4.5.2), https://www.ti.com/lit/an/slla270/slla270.pdf, which is also reiterated in this Technical Article from TI here, https://www.ti.com/document-viewer/lit/html/SSZTB40.
Let me know if you have any questions.
Thanks,
JColvin

Hi @dr.whom,
I'm slightly surprised that you find the Digilent sold B200/B210s of better quality. My understanding is that Digilent is just, more or less, a different distributor for these boards, or at least I am not under the impression that we manufacture them as opposed to NI, or at least I have been told that the boards are identical. I might be wrong on that though, I'm not tied in to manufacturing side of things and it's been awhile since I've looked into it.
Regardless, Digilent unfortunately does not have RF Signal Generators or Power Meters of any kind.
I would personally, and have been recommended by Ettus team to, reach out to the Ettus mailing lists, https://kb.ettus.com/Mailing_Lists, where Ettus Research engineers, Ettus support, and customers themselves have been active for the last 10+ years to find out what signal generator or power meter they would recommend.
If anything, this will at least reduce the time it takes for you to receive an accurate response since the Digilent staff will end up reaching out to the Ettus team about this anyway and echoing the answer back to you.
Thanks,
JColvin

Hi @sceasary,
I am uncertain what the case might be for custom drivers, though I know that you can use the WaveForms software directly with the VirtualBench (at least the VB-8012 and presuming you are on Windows):
Similarly, I know you can also your own VB-8012 LabVIEW code and VirtualBench driver with the ADP5250:
To be clear, the ADP5250 is based off of the VirtualBench VB-8012, not the VB-8054. I am not familiar with the driver nuances, but at the very least the higher end specs for the Oscilloscope, Function Generator, and Power Supplies on the 8054 would not be accessible on the ADP5250.
Let me know if you have any questions.
Thanks,
JColvin

[SOLVED]
Hello everyone,
I am happy to announce that libqt5script5 and libqt5scriptools5 are now released from version 5.15.11 to 5.15.12 on my Linux distro, Tuxedo OS.
Thus, eliminating the compatibility issue.

Adding on to what zygot mentioned, you'll find that many mobile phones will also randomize their MAC address when connecting to a WiFi network by default (Android has some information on it here: https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior), because (in my limited understanding of network operation at large) this would be a localized address within that subnet, so the odds of matching somebody elses MAC address within that same small amount of devices is quite small.
Regardless, localized or unique MAC, you'll have a bad time if there is a match as the different communication frames will end up at the wrong device, so that neither device works properly.
But that is about as far as my knowledge goes on this particular topic.

Hi @M. Hamza Öncüer,
These are my personal testing results from a single ADP2230 on my work laptop with an M.2 SSD -- aka a single data point (albeit repeatedly tested from a pedantic engineer). 
Naturally, DDR is enabled on the ADP2230 during all the tests (the default option, though its worth noting that these rates are simply not possible when using the lower power BRAM only mode as the buffer size of 32 kS simply results in far too much USB overhead for all of those tiny transfers).
All recording to file results saved as a 16-bit binary file, interleaving the data sources when more than one is recorded (analog1 analog2 analog1 analog2...).
For a single analog input (the resolution is 14-bit at high sample rates, but each sample is recorded as a 16-bit value; you can get higher resolution if you sample at 1/2 or 1/4 of the set system frequency), I can repeatedly successfully record 5 G samples at 125 MHz (the maximum sampling rate).    For two analog inputs (16 bits each, or effectively 4 bytes per 'sample'), I can repeatedly successfully record 5 G samples for each channel at 70 MHz. I'm not certain how much faster this could be pushed and remain consistent with USB bus activity. I know for example 100 MHz is not realistic as that would require transferring data at 400 MBytes/sec which isn't viable thanks to the USB protocol overhead.  For all 16 digital inputs in the Logic Analyzer, I can repeatedly, successfully record 5 G samples at 125 MHz, with or without data compression enabled. Data compression meaning only data changes are occurred, rather than a sample at every 8 ns. Two 16-bit samples are recorded with data compression enabled, first the data at the change, then the timestamp.  Using the Digital view within Scope instrument, and recording both analog channels and the 16 digital channels simultaneously, I can repeatedly successfully record 5 G samples for all three at 41.667 MHz (a third of 125 MHz).  I would like to believe that 50 MHz is possible with further refinement, but expecting no issues for the mixed signal recording at the equivalent 300 MB/s is probably unrealistic. Currently I get a "samples could be lost" message, though it does complete the 27.9 GiB acquisition (3 data sources * 16 bits each * 5 billion samples = 30 billion bytes; 1024 bytes per kilobyte, 1024 per mega, 1024 per giga -> ~27.94 gigabytes).  For clarity, I picked 5 G samples as a representative arbitrarily large number of samples that far exceeds the on-board memory. In principle, you could record far more samples, but I haven't personally tested it.
Here's an example screenshot for recording all the two analog input channels at 62.5 MHz that I took today:

Let me know if you have any questions.
Thanks,
JColvin

Hi JColvin,
 
I was able use this part ordered on Amazon.
20 Pcs 5mm High Knob Vertical Slide Switch 3 Pin 2 Position 1P2T SPDT Panel (Pack of 20) CYT1107 (see picture)
Thanks and Regards
Steve
 

Hi @kbowling,
I fear that source materials have been lost to time, or at least I am not able to find source files within Digilent materials.
I have not gone through these materials (nor ever seen a XUPV5 in person), but it looks like there are some lab sources (the "no title" ones) on this AMD search result: https://www.amd.com/en/search/site-search.html#q=xupv5&numberOfResults=24. Briefly looking through one or two of those zip files, there seems to be some VHDL material in there, so hopefully one of them has material you are looking for.
Thanks,
JColvin

Hi @jfrenzel,
I believe this is because you have the Mode dropdown set to "Standard" rather than "3-wire".
With the Standard option, it looks like WaveForms still tries to read what is being transmitted on the DQ1 line; as there is no DQ1 line set, this ends up defaulting to all zeros.
Let me know if this does not resolve what you are experiencing.
Thanks,
JColvin

Hi @idegani,
As far as I am aware, it's not possible to have a particular configuration loaded on power up as the on-board FPGA will not maintain it's configuration once power is disconnected.
The workaround that might work for you would be to use the "Continue" option for what the device does when WaveForms is closed within the WaveForms Device Manager. As long as the device is still receiving power (either over USB or via an external supply), the device will continue to operate in whatever configuration/state it was last set in. I routinely use this when I'm testing other devices but want to limit the total USB activity and ports I am using.

There are a couple of other threads that discuss this option here:
Let me know if you have any questions.
Thanks,
JColvin