4

I want to bring a continuous 30 MByte/s stream of 8-bit values from parallel-output ADC (AD9283) into the memory of a standard PC (laptop under Windows 10 if possible). My software does real-time analysis and logging of relevant events. Some latency (100ms) is OK, but I can't loose samples.AD9283 board

I'm considering an FT232H permanently set to "FT245 Synchronous FIFO Write mode" (see text §4.4.2 and drawing §4.4), with WR# asserted on every odd period of the 60 MHz CLK signal (ignoring TXE# should it go high), so that the data rate would be 30 MByte/s. On the software side I'm planning to use the FTDI D2XX driver, which uses USB High Speed bulk mode.

Will I get data loss? I'm ready to assume

  • FT232H connected to a dedicated USB port on the motherboard of the PC, and if that helps, some other requirement on the PC, like USB3, and no shared device on the USB root hub
  • no other high-traffic USB device (camera, storage, networking, audio) on the whole PC; but that should not prevent casual use of USB mouse/trackpad/keyboard
  • no physical USB error
  • my application software is able to keep up.

I see that the FT232H has only a 2×512 byte FIFO (but 512 bytes buys a mere 17 µs). The FT2232H does not improve on that. I guess "the two buffers continually swap between each other to increase the performance" also applies to the FT232H.

TN_167 FIFO Basics is somewhat encouraging: it gives a "Synchronous FIFO Performance" of "40 Mbyte/sec" for the FT232H,but does not tell in which direction, and if that's sustained.

An earlier version of this question detailed how I semi-reliably get 24MByte/s using a cheap USB 8-channels logic analyzer, and asked for alternatives, but was deemed not focused enough. Still, feel free to propose another solution!

fgrieu
  • 1,542
  • 2
  • 14
  • 24
  • 1
    20Mb/s x 8b = 20MB/s, so should fit on USB 2.0's 60MB/s theoretical throughput. Possibly a USB microcontroller to buffer, packetize, serialize, and stream the data. Will have to include CRC/ACK and provision to resend any missing data packets before the buffer expires. Sounds like quite a challenging project. – rdtsc May 31 '23 at 11:43
  • The "resend missing data" issue should be prevented entirely as it presents a massive complication. A DMA stream into the PC RAM is the minimum requirement, I guess.. I don't know how such things are done, but it sounds implicit to me ;) I know that there are expensive high end digitizers for PCIe which stream into PC RAM, so there are probably also simpler devices for USB, possibly even simpler than the ones you mentioned, e.g. by using USB2 instead of USB3. – tobalt May 31 '23 at 11:58
  • 2
    @rdtsc: problem with USB2 is that it's 480Mb/s (60MB/s) _peak_ but protocol overhead lowers that. 24MB/s continuous is hard to achieve. AFAIK 48MB/s is not achieved in practice. – fgrieu May 31 '23 at 12:10
  • 1
    I think you won't be able to get this running without an additional buffer memory. A single USB frame from your HID (1ms, low speed) is a gap of 500 kBit in your data stream that needs to be buffered somewhere. – asdfex Jun 01 '23 at 18:48
  • 2
    The very small fifo makes this a poor choice for real time streaming unless you are ok with losing data periodically. Realistically you want at least a few milliseconds of buffering when sending over USB. – user1850479 Jun 01 '23 at 19:02

1 Answers1

1

All FTDI chips have some buffers on-board, beyond what the mere packet size would need. Retransmissions are handled automatically by the host chip without intervention from USB drivers on the Windows side, nor user software.

I've purposefully corrupted packets by injecting spikes onto the USB data lines just to see what happens. It's mostly invisible, as long as the first retransmission succeeds. That's the typical case as long as interference doesn't come in bursts.

There's another bigger problem: the latency of the USB stack. That can occasionally spike and then there are data losses if the FTDI chip's buffer gets full.

The simplest, from the hardware point, solution is to use a parallel 2-ported FIFO chip between the FTDI chip and the A/D. IDT makes such chips, and made many more but the market for those had shrunk. They are not cheap, but certainly much cheaper than trying to come up with microcontroller firmware between the ADC and the FTDI chip.

As long as you're using a dedicated host port for the data acquisition device, it should have no problems pushing 20MB/s. USB 2 storage devices could easily do more than that, so I don't see a problem there.

Note: IDT is now a part of Renesas.

Kuba hasn't forgotten Monica
  • 32,734
  • 1
  • 38
  • 103
  • 1
    USB and Windows is challenging..Screen turning off and locking the account (which turns off the screen briefly) can lead to latencies and buffer underruns on the order of seconds. – tobalt Jun 01 '23 at 21:15