Jump to content

JColvin

Administrators
  • Posts

    6,608
  • Joined

  • Last visited

Reputation Activity

  1. Like
    JColvin got a reaction from Takashi "The Yaka mein" in 410-300 didn't includes voucher code?   
    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
  2. Like
    JColvin reacted to dr.whom in Data input/output for an SDR board   
    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) 
  3. Like
    JColvin got a reaction from digitalone in Connecting two Pmod CAN together   
    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
  4. Like
    JColvin got a reaction from dr.whom in Digilent Analog Discovery* or (Digilent Products) for RF Power Calibration of B200-B210 SDR?   
    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
  5. Like
    JColvin got a reaction from sceasary in Drivers written for VB-8054, relevant for ADP5250?   
    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
  6. Like
    JColvin reacted to Adrian Campos in Cannot mix incompatible Qt library (5.15.11) with this library (5.15.12)   
    [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.


  7. Like
    JColvin got a reaction from Sunil kumar in MAC address of Genesy2 FPGA board   
    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.
  8. Like
    JColvin got a reaction from M. Hamza Öncüer in ADP2230 data streaming   
    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
  9. Like
    JColvin reacted to cactuskooler in Zedboard slide switch (power on/off) part number?   
    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
     

  10. Like
    JColvin got a reaction from kbowling in Files for XUPV5?   
    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
  11. Like
    JColvin got a reaction from jfrenzel in Protocol instrument - SPI Spy mode   
    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
  12. Like
    JColvin got a reaction from idegani in Is it possible to set a startup configuration for the Digilent Analog Discovery 3?   
    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
  13. Like
    JColvin reacted to zygot in Is the RPi5 suitable for paring with an FPGA?   
    Is the RPi5 suitable for paring with an FPGA?

    You may have noticed that the latest generation of RPi5 uses an asic, referred to
    as a Southbridge, for IO. All of the IO, Ethernet, USB connectivity etc. are implemented
    in the RP1 Southbridge whic is connected to the BCM2712 processor though a 4-lane PCIe
    Gen2 interface. This makes it substantially different from the RPi4 or RPi3
    boards. So you might be wondering if the new version can be connected to an FPGA. That
    is a question that I decided to investigate for myself.

    The RPi5 has a single lane PCIe Gen2 ( perhaps even a Gen 3 ) header on it that someone
    will eventually create an FPGA add-on board for. Most people will want to use that interface
    as a higher performance alternative to the SD card. But the RPi3 and RPi4 could always
    connect to an FPGA board using a USB 2.0 bridge device like the FT2232H supporting synchronous
    245 mode operation. I've done this and performance for the RPi3 and RPi4 is OK for moving
    small blocks of data between the processor and the FPGA. As the amount of data being transported
    increases the performance drops off considerably, unlike an x86_64 processor.

    For my experiments I'm using a Genesy2 board with a FMC_UMFT601BX mezzanine board. This
    allows the HDL application in the FPGA to act as a USB 3.0 endpoint with a peak data rate
    of 400 MiB/s. The design of the Genesys2 application used for my tests is pretty straight-forward.
    All data uploaded to the FPGA from the USB Host gets stored in DDR3 that functions as a very
    deep FIFO. The USB Host can retrieve the upload data once it's been downloaded. The HDL expects
    n sectors (4096 bytes/sector), to be uploaded and then downloaded. The DDR3 interface in combination
    with sufficient FIFO storage can accept up to 1 GB of upload data and return it without delays.
    In addition to the simple up/down data scheme the HDL has performance timers to timestamp the
    important events in the tests. These are: the time that the first 32-bit word is uploaded, the
    time that the last 32-bit word is uploaded; and the same events for download. Since it's a
    free-running counter, I can calculate the total time that has elapsed between reading the
    first 32-bit upload word from the FT601 FIFO to the last 32-bit word written to the FT601 FIFO.
    This provide a much more accurate picture of the USB Host OS/Software behavior and performance
    than typical software timing methods provide. It must be noted that from the perspective of the
    USB Host data rate performance is more complex than just time spent in the driver filling or
    emptying the FT601 FIFOs. I have my own Software application that is mostly identical for Windows
    and Linux platforms. The D3XX drivers for these platforms are not the same however.

    The FT601 is not the only way to connect an FPGA to the RPi5 via USB 3.0. I also tested the
    XEM7320 with the Infineon FX3 bridge.

    For the FT601 Test I used this setup:
    - Genesys2 FPGA board
    - RPi5 8 GB w/ heatsink/fan
    - Raspios Bookworm 64-bit
    - libftd3xx-linux-arm-v8-1.0.5
    - FT601_245.cpp Host Application
    - G2_FT601_TESTER.vhd

    In FT601_245.cpp I do software elapsed time calculation. The test runs in this manner:
    clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start);
    ftStatus = FT_WritePipe(ftHandle, 0x02, pBufOut, SectorSize*up_sectors, &BytesWritten, NULL);
    clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start);
    ftStatus = FT_ReadPipe(ftHandle, 0x82, pBufIn,RxBytes,&BytesReceived, NULL);
    clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &stop);

    So, there is some processing between the upload and download calls to the D3XX driver.


    Without further ado, here is a sampling of results for the Genesys2/FT601/RPi5 testing

    Test Upload Average Download Average
    Length Time Upload Time Download
    Bytes Data Rate Data Rate
    ------- ------------ --------- ----------- ---------
    16384 42.09 us 389 MiB/s 44.68 us 367 MiB/s
    65536 170.66 us 384 MiB/s 196.35 us 334 MiB/s
    262144 682.51 us 384 MiB/s 848.43 us 309 MiB/s
    1048576 2.73021 ms 384 MiB/s 3.37639 ms 311 MiB/s
    4194304 10.92282 ms 384 MiB/s 12.13967 ms 346 MiB/s
    8388608 21.84317 ms 384 MiB/s 24.26676 ms 346 MiB/s

    This is rather surprising that the upload data rate is consistently around 380+ MiB/s
    for blocks of data ranging from 16 KB to 8 MB. Download rates were less consistent from
    run to run but still near 350 MiB/s. For USB 3.0 the RP1 Southbridge performance is
    outstanding. I believe that the low rates in 310 MiB/s range were outliers, but within
    the range that one should expect. BTW the performance with the same setup, but using my
    Ubuntu 22.04 i7-13700K box was dismal; about 44 MiB/s up and down for 1 MB test.

    I also tested the RPi5 using this setup:
    - XEM7320
    - RPi5 8 GB w/ heatsink/fan
    - Raspios Bookworm 32-bit
    - FrontPanel-Raspbian10-armv7l-5.3.0
    - EthAppliance.cpp Host Application
    - EthAppliance_1.vhd
    - Genesys2 configured with Genesys2_Eth_DUT.vhd ( Ethernet echo application )

    A few months ago Opal Kelly had posted a 32-bit beta ARM driver for FrontPanel; it's
    since disappeared from their download website.

    I didn't try to do do a performance test with this setup. All I wanted to know was
    if I could run the application on the RPi5 and see if it worked as well as on my
    x86_64 Windows and Linux platforms. The application streams TX Ethernet 1 GbE packets
    through a SYZYGY Ethernet pod. It stores RX packets simultaneously into a DDR3 buffer
    that can be read later. I was able to run the HDL and software applications with
    performance that was equal to that on x86_64 Win10 and Ubuntu 22.04 platform; that is
    sustained 120+ MiB/s full-duplex Ethernet.

    So, do I think that an RPi5-USB 3.0 FPGA could be interesting? Absolutely I do! The RPi5
    is an impressive bit of gear with some interesting possibilities.
  14. Like
    JColvin got a reaction from sand in No constant type in Waveforms API   
    Hi @sand,
    You'll be wanting FDwfDigitalIOOutputEnableSet and FDwfDigitalIOOutputSet which are defined in the Digital IO section (section 8) of the WaveForms SDK Reference Manual.
    DigitalIO.py in the samples folder uses these two functions, enabling DIO 0 to 7 as outputs and then setting IO pins 2 and 5 as logic high.
    Let me know if you have any questions (or if I misunderstood what you are wanting to do).
    Thanks,
    JColvin
  15. Like
    JColvin got a reaction from Anthocyanina in Visible screws don't hurt anyone   
    Hi @Anthocyanina,
    Thank you for the feedback; you have been heard. I will be sure to communicate this to the team for future T&M devices.
    Please let me know if you have any additional feedback or questions.
    Thanks,
    JColvin
  16. Like
    JColvin got a reaction from artvvb in PMOD connectors on BASYS 3   
    The female host Pmod connector on the Basys 3 (and other Digilent products) is a Sullins PPTC062LJBN-RC, with 100 mil pitch between each of the pins.
    Thanks,
    JColvin
  17. Like
    JColvin got a reaction from SINAPTEC COMBLEZ in Analog Discovery 3 3D Model [Step File]   
    Hi @jmag999,
    The pins themselves are 6 mm in length, total depth from outside the plastic shell to the plastic housing on the 2x15 connector is 8.8 mm.
    Let me know if you have any questions.
    Thanks,
    JColvin
  18. Like
    JColvin got a reaction from Mohamed Kamal in Automate impedance analyzer   
    Hi @Mohamed Kamal,
    In general, you only need to calibrate the Analog Discovery device once; it will retain and use the user-determined calibration each time until you choose to manually re-calibrate it or load the factory calibration from the WaveForms Device Manager.
    There is no specific timeframe for how often you should calibrate your Analog Discovery device. Personally, I only recalibrate my devices when my hardware setup has drastically changed or feel inspired to recalibrate, but when those situations occur is completely arbitrary.
    Otherwise, I don't believe the calibration process is supported within the SDK API.
    Let me know if you have any questions.
    Thanks,
    JColvin
  19. Like
    JColvin got a reaction from Norm-12 in Looking for Audio Anaylzer Suite   
    Hi @Norm-12,
    Digilent did not create the Audio Analyzer Suite; from my understanding this was created by a third party outside of the Digilent Forum:
    The WaveForms software has both a Network and Spectrum Analyzer which should have most if not all of what you are looking for. The WaveForms Help tab has extensive documentation on each of the instruments.
    Let me know if you have any questions.
    Thanks,
    JColvin
  20. Like
    JColvin got a reaction from Charlotte123 in Hi! Questions about Analog Discovery 3   
    Hi @Charlotte123,
    Yes, the WaveForms SDK is compatible with all of Digilent's Test and Measurement devices.
    Thanks,
    JColvin
  21. Like
    JColvin got a reaction from Mohamed Kamal in Automate impedance analyzer   
    Hi @Mohamed Kamal,
    There are a number of examples built into the WaveForms SDK that should help get you started:
    Let me know if you have any questions.
    Thanks,
    JColvin
  22. Like
    JColvin got a reaction from mvernengo in Restore ZedBoard factory booting   
    Hi @mvernengo,
    What revision of the Zedboard do you have? Neither the Rev D nor the Rev F of the Zedboard that I have match the silkscreen image you posted with the Mode numbering (my two versions list the MIO numbers), though the jumper numbering (JP7..11) does match. My concern is that if the jumper numbering is identical that then the Mode[X] silkscreen labels would not readily line up with the orientation listed in Table 18 of the Zedboard User Guide that Avnet created here: https://digilent.com/reference/_media/reference/programmable-logic/zedboard/zedboard_ug.pdf.
    Presuming the latter situation, your setup of Mode3 and Mode2 being set high would have the device boot from Quad SPI flash memory (which is based on Mode2 high, and both Mode1 and Mode0 low), which from my understanding is not loaded or prepared by default with the Out-Of-Box material. That would be loaded through the SD card image (Boot Modes 2 and 1 set to logic high), which you can find in the Zedboard Resource Center here: https://digilent.com/reference/programmable-logic/zedboard/start#additional_resources.
    I would also put Mode3 to logic low to set the device to Cascaded JTAG rather than Independent JTAG so that you can more readily access the device as per Table 22 in above linked user guide.
    As for the serial terminal not responding in readable characters, my gut reaction would be to double check the baud rate (by default Zynq designs use 115200 baud, but Tera Term uses 9600 baud by default).
    Let me know what you find out.
    Thanks,
    JColvin
  23. Like
    JColvin got a reaction from thirtyy in Zybo Z7 MIPI Common Mode Voltage question   
    Hi @thirtyy,
    My understanding is that as per the Zybo Z7 Reference Manual, https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#pcam_port, Digilent implemented the MIPI connector based the guidelines described in this Xilinx Application note: https://docs.xilinx.com/v/u/en-US/xapp894-d-phy-solutions.
    I have reached out to some engineers a bit more familiar with the hardware implementation for their insight into your query (though with the holiday timeframe, it may be awhile till I hear back).
    Thanks,
    JColvin
  24. Like
    JColvin got a reaction from thirtyy in Zybo Z7 MIPI Common Mode Voltage question   
    Hello,
    It was pointed out to me that the XAPP894 mentions that if external termination is used (which the Zybo Z7 uses the style shown in Figure 11), the common mode voltage can drop to 100 mV, which is what you are measuring.
    Let me know if you have any questions.
    Thanks,
    JColvin
  25. Like
    JColvin got a reaction from Simple Minded Engineer in Gee, Another New User   
    While it could be argued that this violates the rules as written, I'll allow it. 😋
×
×
  • Create New...