iDetect

Members
  • Content Count

    4
  • Joined

  • Last visited

  1. From attila: I'm planning to add support for lower latency captures with Analog Discovery, but it will take some time to implement it. The AD2 is a near-perfect device for embedded solutions in the RF world. Higher transfer rates would make it perfect! If it helps at all, our transfer needs are as follows: Samples per trigger event are 1000-4000 per analog channel (simultaneously triggered); trigger rate per second = 4000-12000 (4000 would seal the deal, but higher would permit it to work with more product line); Data rate must be sufficiently high to a PC array (or list in Python) and rearm well before the next trigger; Based on the above, the sustained transfer data rate must be faster than 10 MBPS over the bus at a minimum, and above 20 MHz as a desired performance. Given the AD2 has other needs of the bus, like DAC and digital IO, the above may be difficult with USB 2.0. Optionally sacrificing performance of some features to boost ADC transfer performance would be a desirable trade -- especially since we could use a second AD2 for the other functions. Thanks for listening and for your support.
  2. Thanks for the comments and information. The 1 MHz sustained transfer rate matches what I empirically found. We are going use the AD2 as a test instrument. I'm expanding the code to use it for triggering our radar systems and generating pulses during production builds. xc61x45's suggestion above is VERY similar to another project underway. We do like to use off-the-shelf solutions when we can, though. The software and hardware are more sustainable as the manufacturer takes on the responsibility of software expansion, and end-of-life issues on components. It's often worth it to pay more if the product is going to be around for years. I've seen a rapid growth in the USB-based instruments, so I do think it will be around for the long haul. We'll continue looking at solutions with USB and busses like the PCI Express. I am impressed with the ease of use of the AD2. Hopefully there will be a USB 3.x version that comes out in the future! Thanks for the help/suggestions.
  3. I build radar systems for a living, and I'm testing the Analog Digilent 2 as an A/D, timing control for other RF hardware, RF switch control, trigger source. Here's what I need to do: Write the software with python using the Waveforms SDK running on Windows 10. Acquire signals on 2 analog channels simultaneously. This must be triggered at a periodic rate on an input other than the two analog in channels. Generate a pulse width of p nanoseconds at an x kilohertz rate. This is a TTL signal. This pulse is used for RF pulse generation, but also as a trigger for the analog channels. All digital out signals must be synchronized. Capture n samples on both channels for a maximum of 256 triggers. Typically 128 or 256 is used -- a 2^n number of triggers is used for FFT processing. Capture to arrays (or lists in the case of python) must be real time. Rearrange the lists so that an FFT can be taken from the ith sample of each trigger event. So if I have 128 trigger events, and I capture 1024 samples on each event, then I take 128 values from index 0 of all trigger events and compute a complex FFT. Then I repeat for index 1, 2, … 1024. In radar terms, each sample relates to a range value. If sampling at 80 MSPS, each sample equates to 2 meters of range. So 1024 samples = 2048 meters of total range. The complex FFT computes the Doppler frequencies seen for each of those sample range points. Progress: A. I have successfully used the example SDK program named Digital_Duty.py to generate a x kHz pulse rate with p width in nanoseconds. I modified it to continue doing it until the program is terminated. The test values are 4 kHz pulse rate (trigger rate) and the pulse width is 300 nanoseconds. The output is on DIO Channel 1. The AD2 works great at this. B. I have successfully used the example SDK program named AnalogIn_Trgger.py to acquire signals. I modified this source to: digitize Channel 0 and Channel 1; trigger on an External Trigger, which is now the inputted by placing a jumper wire between DIO Channel 1 and Trigger 1 Channel; Continue to trigger for 128 times; Plot last set of data. C. I am using a 10 MHz and 20 MHz signal on Channel 0 and Channel 1, respectively. This is correctly plotted by the application. D. I was delighted to see the code was working...or so I thought. I added a time check to confirm 128 triggers were completed in the appropriate time. The time check came back as 0.156 seconds for 128 triggers of 1024 samples. The answer should have been (1/4000)*128 = 0.032 seconds. So my capture time was almost 5 times too long. I confirmed that even with two pulses the system cannot transfer fast enough. And even if I get down to 10 samples per trigger, there is little change in timing. I computed that the fast PRF (trigger event speed) = about 850 Hz. There is still some unexplained overhead time, but it is close to that number. So keeping under 850 Hz, the system is real time. Unfortunately, that equates to about 14 mph at usable radar frequencies. I need to get up to about 4000 Hz to be of use. See my attached Code written in python. I am using a Windows 10 Pro laptop running an i7 processor with 64 GB of RAM. I have the AD2 plugged into a spare USB port. 10 and 20 MHz signals feed the analog channels from a crystal oscillator as a test of the capture. I have available external waveform generators, oscopes, and spectrum analyzers. So given my test in D, does anyone know what I can do to improve performance? Is there something wrong in my code? Am I misunderstanding the capabilities of the AD2? If the system had a USB 3.0, I know it would be able to keep up. But given that is not available, what should I try if anything? Radar Data Capture With Internal Trigger.py