Jump to content

oeser

Members
  • Posts

    6
  • Joined

  • Last visited

oeser's Achievements

Newbie

Newbie (1/4)

2

Reputation

  1. I am currently working on a C# data logger application. I want to read measurement data of an Analog Discovery Pro ADP 3450 oscilloscope with the WaveForms SDK. The data aquisition should be performed when a Rising Edge is detected. I set the trigger condition with the following command dwf.FDwfAnalogInTriggerConditionSet(hdwf, trigcondRisingPositive) However, the aquisition is still triggered on rising and falling edge conditions. The behaviour can be reproduced with the python example "AnalogIn_Trigger.py" provided in the WaveForms SDK and e. g. a function generator connected to oscilloscope channel 1 (Sine wave, 5 kHz, 2 Vpp). Even though the trigger condition is defined as rising edge, the aquisition is perfomed on rising and falling edge conditions as can be seen in the attached pictures. (Trigger Level is 0.5 V, Position at sample 4096) I tried to read back the trigger condition with "FDwfAnalogInTriggerConditionGet()" which gives the value I expected (trigcondRisingPositive). The function "FDwfAnalogInTriggerConditionInfo()" returns 0b111 which means that the device supports rising edge, falling edge, and both. "DwfTriggerSlopeEither", as written in the reference manual, is not defined in the WaveForms SDK (C# and Python). I assume that the third bit corresponds to this value. What can I do to perform an ONLY rising edge triggered aquisition. Is there a workaround? Thank you in advance.
  2. While programming, I recognized that there is a difference between the WaveForms SDK Reference Manual and the dwf.cs file provided in the samples. Lines 23 - 26 are: public const int devidADP3X50 = 6; public const int devidEclypse = 6; public const int devidADP5250 = 6; public const int devidDPS3340 = 6; I think they should be: public const int devidADP3X50 = 6; public const int devidEclypse = 7; // Not mentioned in the reference manual public const int devidADP5250 = 8; public const int devidDPS3340 = 9; According to reference manual section 3 "Device Enumeration". Best regards oeser
  3. Hi, I am thinking about buying one of the Analog Discovery Pro oszilloscopes (ADP3250/ADP3450). I want to make sure, that the device is suitable for my measurement application: I want to sample an analog signal with 5 MHz (1 Channel). 14 Bit resolution should be enough. I want to record the signal continiously. If this is not possible, then at least for 5 seconds. Unfortunately this is not possible with a standard oszilloscope. I want to transfer the data to my PC for further processing. According to the specs, both oszilloscopes can work in the so called "record mode" and provide an input buffer of up to 128 MSamples. This should be enough for me. However, it is mentioned, that the record mode is not available in linux mode at sample rates over 1 MS/s. For the normal operation mode there is no limit specified. Anyway, I can not believe, that it is possible to transfer the maximum data rate (100 MS/s / 125 MS/s) to the PC via ethernet. So the maximum possible sampling rate should depend on the ethernet connection between the PC and the device. If I use the WaveForms application in demo mode, I lost samples if the sample rate was higher than 2 MS/s. I dont know, wether this is representative. Does someone has experience what the maximum sample rate in normal record mode is? Is the device capable of measuring 25,000,000 sample points at a sample rate of 5 MHz, with an resolution of 14 Bit? Thank you for your help. Best regards, oeser
  4. Thank you very much for your response. Yes, you got me right. I want to sample just a single ADC-Channel. I did some research on the hardware you mentioned. At our project stage a custom hardware design is not a real option for me. I want to log the data just for an experiment (I want to evaluate a new method for environmental measurements, not the hardware). This would cost too much development time. So I would prefer a system based on "standard" components. I had a look on the "non-ZYNQ board with a SYZYGY port". I think you mean the USB104 A7? Digilent offers an API for the USB-connection (Data transfer from PC to FPGA). Unfortunately the maximum data rate is specified with 40 MB/s. This is not enough for this application. I think a custom USB solution can achieve much higher data rates. Unfortunately, I have never done something with USB before. At the moment this does not seem to be a good solution for me at all. However, I had a look on the "competing instrument class product" (ADP3450/ADP3250). Although I would strongly prefer a solution with our current hardware, this could be a serious alternative for my measurements. The devices have a maximum buffer size of 128 MS in record mode. The device can operate in standard or linux mode. It is stated, that the linux mode does not support record mode for sample rates higher than 1 MS/s. In standard mode there is no limit mentioned. Anyway, at 100 MS/s there would be generated far too much data, than could be sent over the ethernet interface. So I think there must be a practical limit (Defined by the network speed). Does someone has experience what the maximum sample rate in record mode is? If I use the WaveForms application in demo mode I lost samples if the sample rate is higher than 2 MS/s. 5 MS/s (16 Bit) require a minimum netto bandwidth of 80,000,000 Bit/s. This should not be a problem with a direkt ethernet connection to the PC. Does someone have an ADP3450 or ADP3250 and can confirm this? Best Regards.
  5. Dear Digilent community, we are currently working on a data logger application. Our goal is to sample an analog input signal for more than 5 seconds. The desired sampling frequency is 5 MHz. Our hardware setup consists of the Digilent Eclypse Z7 development board (Zynq-7000 SoC) and the Zmod Scope 1410. We are using ethernet (TCP) to transfer the data to the PC. Our system works like this (please refer to block diagram in attachment, block_diagramm.PNG): We have 4 BRAMs (16 kB each), an ADC (IP from Digilent), and a 16 bit counter. With each clock cylce we increment the counter by 4 to address the correct BRAM register (32 bit data). The first two bytes of the counter value are used to enable or disable write operation for the BRAMs. The other bits are used to address the correct register for the adc data. This way we ensure, that only one BRAM will be written at a time. When the current BRAM is full, the adc data is written to the next one. This event generates an interrupt and indicates the Software to read out the last BRAM.From there we copy the bram memory to a ringbuffer (using memcpy()). The data inside the ringbuffer is then sent to the PC. I noticed that some parts of our sampled data are corrupted. With the Vitis debugger i was able to trace back the error to the BRAM memory. E. g. if I generate a 500 kHz sine wave with the function generator and give this to the adc input I would expect a maximum or minimum every 10 samples. As shown in the picture (bram_memory.PNG) this is not the case (Some other memory areas are as expected). So, I used the Vivado debugger to have a closer look on the read and write signals of the BRAM-IPs (Block Memory Generator). The input (write) signals look as expected (write_signals.PNG). Every 5 MHz clock cylce new ADC-Data is given to the BRAM. What I found a little bit strange are the read signals (read_signals.PNG). In order to increase the throughput I have enabled "Read Commad Optimization" and "Support AXI Narrow Bursts" in the corresponding AXI BRAM controller. What I wonder about, is that the read address is not increased continiously. As can be seen in the picture above, there are some jumps. E. g. from address 152 (DEC) to address 192 (DEC). Is this behaviour normal? However, we tried multiple things to get our data logger system working: Block diagram: The original design was implemented with 2 bram blocks. If one bram is full the other one is written. In the meantime the other is read out by the software. I changed this to 4 BRAM blocks. This way I want to ensure that the bram to memory transfer is done when I read the data from the memory. BRAM "web" and "enb" inputs: We also tried to give the enable signal to the write enable bits of the BRAM. We also tried to give a constant '1' to the enb input and enable the write operation with the enable signals. Different memory configurations: In the normal configuration the memcpy() function was too slow (Approx. 840 µs for 4096 uint32_t values. The Interrupt occures every 8192 µs). So I changed the memory configuration with Xil_SetTlbAttributes((UINTPTR)bramA.Config.MemBaseAddress, NORM_WB_CACHE). Now the memcpy() function was fast enough. The bram memory is corrupted in each configuration. Clock speed: Initially, the AXI clock for the bram controllers was set to 100 MHz. We got some timing errors in the implementation. So we tried different clock speeds (down to 20 MHz). At 60 MHz, and below, we did not get any timing errors. But the system behaviour was the same. Unfortunately, we had no success with our data logger application. The corruption in the bram memory does still exist. We must have overseen something. Do you have any idea or solution for us? Thank you in advance. Best Regards, oeser
×
×
  • Create New...