2-Channel Analog Acquisition with Digital Trigger

[iDetect]

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:

1. Write the software with python using the Waveforms SDK running on Windows 10.
2. 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.
3. 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.
4. 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.
5. 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

[xc6lx45]

Hi,

I hope someone will be able to solve your problem. That said, ...

>> So my capture time was almost 5 times too long.    I confirmed that even with two pulses the system cannot transfer fast enough
>> python
>> 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 suspect your job calls for hardware in a different price segment. Take this just as a general opinion without having studied the details of your specific problem.

An NI 5840 (or 5820 if you don't need its RF frontend) would turn it into a routine job, more or less. Obviously, priced very differently, just pointing it out as an instrument that I know works well.

Some PCI AD/DA card would probably cover the functionality you need but think twice about synchronizing multiple devices with accuracy sufficient for TOA measurements, and long time stability - here be dragons... If I needed something cheaply, I'd look at 192k sound cards, they can do reliable streaming data at low price. But the bandwidth will limit your Doppler range severely, plus a null at DC (offset Tx/Rx LO might fix that but yes it starts to look like a bad hack).

[iDetect]

On ‎9‎/‎28‎/‎2019 at 2:42 PM, xc6lx45 said:

... I suspect your job calls for hardware in a different price segment. Take this just as a general opinion without having studied the details of your specific problem.

Our current A/D board (which has been in production for 16 years) is based on an Analog Devices chip that has been retired.    It had the same basic capabilities of the AD2, but it had deeper memory, worked on a PC-104+ bus, and had a sustained transfer speed of about 27 MBPS.    We would capture 256 pulse groups, with each group of about 2000-4000 samples.    This board cost us several thousand dollars each.    Our new A/D board (which has been under test for a year) has four 16-bit channels and samples at 160 MBPS..   But it uses a 2 GBPS bus.   This one costs us over $4k each.   Both old and new boards were -40 to 75 C rated.   The latter board is very capable, but it has really driven up costs of our low-end radars.     So your point that a different price point device may be required is one we've been experiencing for many years.   So good observation.  

This exercise was to see if we can use this lower cost solution on our lower cost radars.      Even if I had to interleave a couple of boards for this effort, it would be worth it and my purchase volume of more than a  thousand a year would save us millions in production cost.   Especially since the AD2 can supply other needed capabilities.   

An NI 5840 (or 5820 if you don't need its RF frontend) would turn it into a routine job, more or less. Obviously, priced very differently, just pointing it out as an instrument that I know works well.

Some PCI AD/DA card would probably cover the functionality you need but think twice about synchronizing multiple devices with accuracy sufficient for TOA measurements, and long time stability - here be dragons... If I needed something cheaply, I'd look at 192k sound cards, they can do reliable streaming data at low price. But
the bandwidth will limit your Doppler range severely, plus a null at DC (offset Tx/Rx LO might fix that but yes it starts to look like a bad hack).

The RF bandwidth needed = the 1/ pulsewidth of the radar.   Most pulsewidths we use are 150 to 500 ns, which results in a bandwidth of 6.7 MHz to 2 MHz, respectively.   So the AD2 bandwidth is sufficient.   Doppler Bandwidth is a function of the PRF (Pulse Repetition Rate) of the radar.   So in the my case, the 14 mph limitation mentioned above is based on the Doppler bandwidth resulting from the slow AD2 trigger rate that was measured.      192k sound cards recorders/digitizers are way too slow.    The physical size of a single sample at the maximum sample rate of the AD2 (100MBPS) is 1.5 meters.     The smaller the physical size of the sample on the ground, the higher the resolution of the radar and the greater the object signal strength relative to the background strength.     A 192 k sound card would have a resolution of 781 meters (as opposed to 1.5 meters of the AD2).    That would result in the radar detecting railroad cars and larger -- not too sensitive.     Plus the 192k sound card bandwidth is too narrow to support the RF bandwidth of the radar.  

But thanks for bringing this all up.   I should have mentioned some of this as background.  

My main questions are:

• Am I sampling and triggering and transferring data in the fastest available manner with the software I wrote given my restriction of requiring a digital trigger?
• Is the AD2 capable of sustained transfer above 20 MBPS?    At least with my current setup, it can't keep us with 1 MBPS.    So If it is possible, what am I doing wrong?

 

[attila]

Hi @iDetect

The about millisecond latency you see between the captures (0.156ms/128) is the time needed for the data to be fetched from the device to computer over USB.

For continuous/record capture the rate will be limited to about 1MHz, streaming data over the USB 2 controller of the device.

[xc6lx45]

OK, never mind the soundcard idea ? as said, I had not studied your requirements in depth.

Just wondering, you want to use the AD2 as a module, not as test instrumentation? With the budget you mentioned, subcontracting a customer-specific FPGA image is not unheard of (this comment for FPGA-based hardware in general, not Digilent-specific)

If your requirements are somewhat flexible: The Xilinx 7 series devices (Artix, Zynq, Spartan 7) have two built-in, independent AD converters with 1 MSPS, 12+4 bit . The ubiquitous FTDI USB chip can manage close to 30 megabit per second. If you can re-spec to those limitations, modules start at $50, give or take some (e.g. CMOD A7). I implemented a fun project that demonstrates dual-channel 700 ksps streaming data acquisition via USB on the CMOD A7 module (can use that e.g. to quickly check whether streaming is still reliable when other software is running on the PC). Probably performance is too low, but the hardware option would be very cheap. If that matters, roundtrip latency slightly below 125 microseconds is possible this way (this is my USB interface code but it's not for the faint-of-heart, 5x faster but by necessity much more complex than plain UART-based IO)

I'm personally wary of building on top of USB with its DNA deeply rooted in consumer electronics (GPIB anybody?). That said, if I had to come up with USB streaming data higher than 30 MBit/s (standard FTDI chip in serial mode) but still cheaper than your expensive 2 GBit/s bus that is quickly demonstrated as a prototype, I'd grab one of those modules and use it in parallel mode.

When that works reliably, making a custom PCB with converters, some FPGA module as glue logic and the FTDI module seems like a routine design job, with the expected difficulties mostly on the software side (PC side code, RTL and the protocol in-between).

My $0.02...

 

[iDetect]

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.   

[attila]

Hi @iDetect

Soon you may find devices at Digilent better suited for your needs.

I'm planning to add support for lower latency captures with Analog Discovery, but it will take some time to implement it.

Thank you for your post. Such feedback/requests direct the soft/hardware developments.

[iDetect]

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.