Jump to content

JColvin

Administrators
  • Posts

    6,659
  • Joined

  • Last visited

Posts posted by JColvin

  1. Hi @Duh,

    You should be able drag each of the signal groups via the small rectangle on the left hand side next to each group. It's not particularly visible when compared to moving a browser tab but it should work:

     

    I don't think you can readily change the order of things within a bus though (such as the chip select and clock within SPI), at least as far as I can tell. Maybe the WaveForms developer (not me) will consider that option for a future update.

    Let me know if you have any questions.

    Thanks,
    JColvin

  2. Hi @Clyde,

    The Analog Discovery 3 has 9 MHz bandwidth unless you're using the BNC Adapter which bumps the bandwidth up to 30 MHz: https://digilent.com/reference/test-and-measurement/analog-discovery-3/specifications#analog_input_channels, though the ADP3250/ADP3450 both have the 55 MHz analog input bandwidth like you indicated (ADP2230 has 50 MHz bandwidth for its two analog input channels).

    Regarding a SPI bus transaction on the AD3 specifically, I would probably be using the Logic Analyzer instrument on the digital channels and have a result more like the splash screenshot I took for AD3 reference manual: https://digilent.com/reference/test-and-measurement/analog-discovery-3/reference-manual#logic_analyzer.

    If you're instead looking for a more traditional MSO setup, you could use the Digital view inside the Scope instrument to view both the digital and analog input channels in a time correlated fashion (rather than having the logic analyzer and oscilloscope run simultaneously in two separate windows) along with the option to interpret one of the analog input signals as part of the digital bus directly, much like I've done here with the Scope Channel 1 being subbed in for the SPI peripheral out controller in line (MISO):

    image.png

    The catch with style is that the analog to digital interpretation is done in WaveForms, so you won't have the option to do any digital protocol triggering on a bus utilizing an analog input. If they are separated out, like how MISO is, you can still trigger off of the digital protocol values, like how I did above to trigger on the h40 value for MOSI.

    If you're looking to analyze digital protocols directly within WaveForms though, I personally think you'll have an easier time with either the ADP3250/3450 or the ADP2230 since they both have on-board DDR memory. That'll let you get much longer captures relative to the Analog Discovery 3 which are more helpful for digital protocols where there can be a comparatively long amount of downtime between the fast bursts of communication.
    The point is moot of course if you're only ever looking at a few frames at a time.

    Let me know if you have any questions.

    Thanks,
    JColvin

    P.S. The Analog Discovery Pro 5250 (a rebranded version of the NI VirtualBench 8012, now sold by Digilent) also has 100 MHz bandwidth for it's two analog input channels, but it lacks DDR memory and has a different price point than something like the Analog Discovery 3.

  3. Hi @Clyde,

    I have moved your question to a more appropriate section of the Forum where the engineer most familiar with the Analog Discovery Pro 3450 will be able to give accurate insight into this.

    I know that the trigger DIO signals themselves are protected by ESD diodes and PTC thermistors, but I am uncertain about digital supplies themselves regarding overcurrent protection.

    image.png

    Thanks,
    JColvin

  4. Hi @BEBERL,

    If the transducer is analog based, i.e. sends out some sort of voltage based on the measured pressure, it might be possible to interface the Analog Discovery device (whether AD2 or the newer AD3) with it. I'm guessing it is analog based on the picture that shows 3 wires (presumably power, ground, and the signal) going into the extension cable.

    If it instead uses some sort of serialized digital interface, you would then have to figure out the communication scheme that it uses, which could be quite a bit of debugging to figure out as I'm not readily seeing any documentation for it. If this is the case, the Analog Discovery device could still potentially interface with the transducer, but the level of effort to get it working, if at all, is a big unknown.

    If it is an analog output signal, you would need some sort of physical adapter to readily connect to the wires (or be willing planning on splicing the cable open to connect to the individual wires via a breadboard or soldering pin headers to them).
    You could then use the analog input channels on the Analog Discovery device to measure the variable voltage coming out of the transducer as well as some sort of math channel to convert the measured voltage to the correct units. I'm presuming there is some sort of documentation out there that would tell you what first or second order linear equation the transducer follows.

    As for powering the transducer, the Analog Discovery device can probably do that for you as well with its external power supplies. The catch with this is that I don't know what voltage the transducer operates at.

    If you have some sort of datasheet regarding the electrical specifications of the transducer as well as the wiring setup, I might be able to provide a more conclusive answer for you.

    Thanks,
    JColvin

  5. Hi @jenga,

    The record mode (I'm presuming that is what you are meaning by streaming) bottleneck for the ADP3450 is limited by the connection to the host computer; either the USB 2.0 connection or the Ethernet connection, depending on which configuration you chose.

    As both communication options are packet based, data is transferred in chunks. Because of the on-board DDR memory, the streaming of data in chunks is largely mitigated since the device can continue to capture data and store it in the DDR memory while some subset is transferred over to the computer (presuming you aren't attempting to capture data faster than you can transfer it over anyways). The WaveForms Help tab has typical values for transfer rates and latency:

    image.png

    In terms of other numbers, each analog input is stored in a 16-bit (2 byte) format, as well as the 16 digital channels being represented in a 2-byte format, so you'll correspondingly be limited in what maximum sample rate you can achieve based on how many channels you have enabled.

    There are several built-in Record mode examples in Python that should be of help:

    WaveForms SDK location.png

    image.png

    USB 2.0 with its overhead tends to top out at around 40 MByte/s, so with 3 two-byte channels acquiring data over USB, this ends up capping you at a sampling rate a bit over 6.5 MHz (best that I can tell, the screenshot from record to file is showing 13.1 MS/s // 26.2 MB/s for the measured rates because it is not taking into account the remaining third of the 6 bytes per sample bandwidth portion that the digital data is taking up):

    image.png

    With a gigabit Ethernet connection, you'll of course then be able to achieve the faster rates:

    image.png

    If you are wanting to have faster streaming, I would instead point you towards the ADP2230 with its USB 3.2 Gen 1 connection:

    Let me know if you have any questions.

    Thanks,
    JColvin

  6. Hi @Kevin.C,

    I am uncertain on the public key for WaveForms; that will be answered by the WaveForms developer (Attila) on the https://forum.digilent.com/topic/28525-digilent-adept-runtime-package-header-is-not-signed/. I saw you pinged him on it yesterday and that he got another ping from the Adept developer today, so I hope to hear some details on this once his European timezone is in normal business hours to confirm if the key is different than the Adept key and if the 3.22.2 release will be back-updated.

    The public GPG for Adept (you need to get Adept Runtime installed first on Linux prior to WaveForms) can be found here: https://cloud.digilent.com/myproducts/Adept?tab=2.

    Let me know if you have any questions.

    Thanks,
    JColvin

     

  7. Hi @Ayesha Zaman,

    It is the buffer size of the Analog Discovery analog input/scope (as that is what you are using) that needs to be kept under the value.

    For example, if you are wanting to acquire 10 us at 100 MS/s, that would be 1000 samples (1*10^-5 x 1*10^8). Correspondingly, the maximum amount of time for a single acquisition at 100 MHz for the AD2's 8192 sample buffer size would be 81.92 us.
    If you wanted to acquire data for a longer period of time, then the sample rate has to decrease to 50 MHz (or lower, depending on the length of time) for the 8192 sample buffer to be "spread out" enough to encompass the full desired time frame.

    Thanks,
    JColvin

  8. Hi @jcanion,

    The Network Analyzer instrument has a Bode plot as its default view. The Help tab has built-in documentation on all of the different settings:

    image.png

    There is also a tutorial version on using the Network Analyzer on the Digilent Reference site here: https://digilent.com/reference/test-and-measurement/guides/waveforms-network-analyzer, which is also listed on the Analog Discovery 3 Resource Center here: https://digilent.com/reference/test-and-measurement/analog-discovery-3/start#tutorials.

    Let me know if you have any questions.

    Thanks,
    JColvin

  9. Hi @mmessuri,

    I'm glad to hear you are having much more success.

    To be honest, even after I had added the twisted wire pair (I also used the high speed pair, I didn't check to see if I could accomplish the same thing with just random breadboard wires that don't have the embedded resistor), I would also receive an occasional lone "Leftover bit" error, but it was far less egregious than when I was getting the errant CS spikes.
    I'm not sure off-hand if these remaining bits are a remaining errant spike or a quirk in the CardInfo example (since I seem to recall that the leftover bit was in a somewhat consistent location); I haven't done further debugging to determine the root cause.

    Regardless, let me know if you have any questions.

    Thanks,
    JColvin

  10. Hi @Kevin.C,

    There is no repository for the beta versions; that one Forum thread started by the WaveForms developer is where all users, including myself, are able to get any of the beta versions.

    In terms of release versions (again, no release signed Linux variants at time of writing), the official location to get the latest release is within the My Products section of the Digilent website: https://cloud.digilent.com/myproducts/waveform?tab=2.

    Otherwise, in terms of a slightly more repository-like version, you can also get the previous release versions of WaveForms from here: https://digilent.com/reference/software/waveforms/waveforms-3/previous-versions.

    Let me know if you have any questions.

    Thanks,
    JColvin

  11. Hi @Nevermnd,

    The Nexys 4 DDR and the Nexys A7 are identical products for all intensive purposes (there might be transparent changes that I am unaware of that aren't branding related). There are a couple of threads on this topic here and here, though clearly this never actually made it into the Resource Center(s), or as a comment into the board files, .xdc, or other HDL materials. I will see about getting that clarified.

    For what it's worth, my FPGA also has the Nexys 4 DDR silkscreen label and have never encountered an issue using materials labeled for Nexys A7 instead.

    As for why the product branding changed at all for Digilent (or any other company; see Xilinx AMD or National Instruments NI / Emerson), that's because stakeholders with the power said to make the change and the rest of us said 'yes boss'.

    Regardless, I'm glad to see you are willing to try out the board while being in Data Science. It's probably an easier climb than coming from Chemical Engineering like I did.

    Thanks,
    JColvin

  12. Hi @DBT,

    Unfortunately, Digilent does not have any plans to distribute the programming files for the Power Supply ICs on our various boards.

    I'll I'm able to offer is the public schematic, https://digilent.com/reference/_media/reference/programmable-logic/genesys-zu/genesys_zu-5ev_sch_public.pdf, and the Reference Manual, https://digilent.com/reference/programmable-logic/genesys-zu/reference-manual#power_supplies, though I have no doubt you have already combed through those.

    Let me know if you have any questions.

    Thanks,
    JColvin

  13. Hi @shaur,

    I was told a couple of days ago (April 10) that one of the engineers migrated both uboot and Petalinux as well as the Genesys ZU OOB projects for the 3EG and the 5EV to their 2023.1 versions.

    However, they wanted to test all of the updates on real hardware, so that is currently in process. I will reply back once I hear that the updates have been tested and pushed live.

    Thanks,
    JColvin

  14. Hi @Nevermnd,

    I apologize for the delay. I don't know if it was a typo on your part, but I think the main problem you ran into is that you have the Nexys 4 DDR (now known as the Nexys A7), but, at least based on the link you provided, you were working with the "Nexys 4" which does not have the on-board DDR memory.

    The correct link for the Nexys 4 DDR / Nexys A7 OOB demo (also accessible from it's Resource Center) is here: https://digilent.com/reference/programmable-logic/nexys-a7/demos/oob. The more recent releases, including 2023.1, give you a completed project that will already have the correct .xdc included, and only need you to click "Generate Bitstream", rather than making you go through the whole create_proj.tcl process.
    On my machine at least, I was able to generate the bitstream without errors.

    Feel free to let me know if you have any additional questions or feedback about the process at large.

    Thanks,
    JColvin

  15. 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.

    image.png

    Let me know if you have any questions.

    Thanks,
    JColvin

  16. Hi @jostikas,

    I suspect that this is a software bug rather than a hardware one (I verified your experience was also present on the 3.16.3 release) since, as far as I understand, all DIO pins for both the Analog Discovery 2/3 are implemented identically on the PCB side of things.

    Regardless, thank you for bringing this up since I do not recall anybody mentioning this before on the Forum or otherwise.

    I'm not personally don't have any further information, but am hoping that Attila will have some further insight when it's no longer the weekend in his timezone.

    Thanks,
    JColvin

  17. Hi @mmessuri,

    The breakout setup I have uses the Pmod TPH2, https://wiki.digilent.com/reference/pmod/pmodtph2/start, which is just a dedicated test point header module, and the SD card adapter I am using is the Pmod SD, https://wiki.digilent.com/reference/pmod/pmodsd/start, but I anticipate there will be effectively zero difference between the Digilent branded SD adapter and the mikroElectronika one you have.
    Maybe the breadboard setup is contributing to the crosstalk happening on the CS line, but having extra long pins on the SD card to extend on both sides should take care of that.

    As for why the other Logic Analyzer is giving better/more consistent results, it looks like from the photo where I can see the Logic Analyzer, it appears to run at 24 MHz (or at least that is what it has labeled on the shell) and ends up missing (or maybe filtering via software? Not certain what options it has) the tiny cross talk pulses.

    This is what I see with the ADP2230 (has 50 MHz bandwidth oscilloscope inputs) when I probe the CS line and also treat use the Scope to Digital functionality to interpret the Scope Channel 1 as part of the SPI bus.

    example of spurs that I see:

    image.png

    zoomed in on a spur:

    image.png

    Or at least that's my theory of what the Digital Discovery also operating at a high sample rate is detecting.

    I'm hoping @attila may have some more insight into this when it's a more reasonable timezone hour for him.

    Thanks,
    JColvin

  18. Hi @bobql,

    I believe you'll only be able to get up to 40 bits wide:

    but otherwise I believe the protocol tool itself is limited to 32 bits per word. I haven't tried outside of direct loopback, but I believe you should be able to send 32-bit words at a time. Splitting up the transaction into multiple 8-bit words would be the way to proceed for samples larger than that though.

    Let me know if you have any questions.

    Thanks,
    JColvin

  19. 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

  20. Hi @mmessuri,

    None of my co-workers in my timezone had the hardware to replicate my setup, but I think got it working, including getting rid of the excessive leftover bits. I have attached the WaveForms workspace that I am using. 

    To be honest, I'm not exactly certain what changed in terms of software, since all I had done was roll back to an older version of WaveForms to test out the SPI MOSI triggering, found it was working, and then could not get it to fail to trigger again despite having repeatedly seen it fail all morning and the fact that I had not made any hardware changes yet. I tested multiple two different Digital Discoverys and multiple versions of WaveForms (20.1 release, 22.2 release, and latest beta 22.16) and multiple known MOSI transaction values (h40, h51, h02).

    The main hardware change that I did was to use a twisted wire pair for the Chip Select signal with a ground signal wrapped around it, as recommended by the WaveForms developer for this thread on the same CS spikes that I was seeing:

    I happened to use the high speed twisted wire pair to accomplish this, which I believe I saw you also had from your photos.

    Otherwise the wiring is all the same. 3.3 V supply, ground, and regular SPI pins from the Arduino Uno to the SD card; DD using DIO 24 for Select, DIO 25 for Clock, DIO 26 for MOSI, and DIO 27 for MISO.
    I put the ground for the twisted CS pair wire on the ground line for the 3 boards and the other end into DIO 28 (since I didn't want to split that wire apart) and had DIO 28 and 24 pulled low in the Supplies instrument.

    image.png

    Let me know if it this works for you, and I'll be more than happy to continue debugging if you are still not able to get the expected results.

    Thanks,
    JColvin

    DD-SPI-SD-analyzing.dwf3work

×
×
  • Create New...