48MHz mode

[merbanan]

While working on the FX2 before I always theorized about the 48MS/s mode. As I understood you should be able to sample to the internal FIFO (1-4kib) without drops at that rate. One would then have to transfer the buffer and thus incurring a drop-out. Each buffer would then have to be re-aligned to be able to visualize a nice signal.

Is there support for something like that or does the current handling of samples assume almost a drop free transfer? Or is it the actual FX2 firmware that doesn't wait until all samples are transferred and just overwrite with newer samples in the FX2 FIFO?

[Ho-Ro]

The FX2 firmware does nothing more than initialize the GPIF, which generates the sample clock for the ADC and transmits the result in 512-byte blocks in USB bulk mode at constant data rate. If the USB bus cannot transfer at this high data rate, it drops one or more of these blocks. This was investigated in the big eevblog thread some time ago. My firmware supports the isochronous mode as alternate 1, but OpenHantek6022 does not (yet) support this mode at the moment.

EDIT: Due to systemic limitations, the iso-mode does not provide a viable solution for the high sampling rates. The fastest iso-mode you can define has already been chosen for the alt 1 setting, it offers three transmissions (the maximum) of 1024 bytes (max. size) during each microframe (3072 B / 125 µs = 24576000 B/s). This matches also with my testing with the cyusb test suite, where I get about 22 MB/s out of the dso6022be-firmware.hex in alt mode 1. This is what the system also provides quite reliable in bulk mode, while 30 MS/s drops some frames (this is the reason why I limited the maximum automatically chosen sample rate to 24MS/s (single channel, 12MS/s for two channel mode), but you can overrule it manually to 30/15 MS/s when your prefer speed over accuracy. With latest commit c3c1648 the program tries to get higher real-time priority (if this right is available to the user), either with the regular kernel, even better with a -RT kernel (e.g. available from debian) to get better USB allocation. Nevertheless iso mode could make sense for accurate long time recordings at lower sample rates where every glitch must be avoided, e.g. for protocol analysis.

; Isochronous interface 0, alt 1
....
; Endpoint 2 (IN)
.db DSCR_ENDPOINT_LEN
.db DSCR_ENDPOINT_TYPE
.db 0x82            ; EP number (2), direction (IN)
.db ENDPOINT_TYPE_ISO   ; Endpoint type (iso)
.db 0x00            ; Max. packet size, LSB (3*1024 bytes)
.db 0x14            ; Max. packet size, MSB (3*1024 bytes)
                ; 12:11 = 0b10 (2 additional transmissions = 3 tr. per microframe)
                ; 10:00 = 1024 (max block size)
.db 0x01            ; Polling interval (1 microframe = 125µs)

EDIT2: linkfix to EEVBLOG

[merbanan]

Ok, my memory is getting back to me. The idea was to run a GPIF state machine so it starts filling the quad-buffered 1k FIFO. When the FIFO is full the GPIF stops. The buffers are supposed to be fetched as quickly as possible and when the first (or second) 1k buffer has been received the GPIF is started again via a usb command.

This would fill the USB link with as many continuous 4k buffers as possible. And that is running with a 48MHz sample clock. Using this method periodic signals should be possible to visualize as long as they fit the 4k buffer. Even 2 channels should be possible but with half the buffer size.

And with 30MHz working real-time it should be possible to overrun the 4x1k quad-buffer 2 times (2x1kb) for a possible 6kb large continuous buffer.

[Ho-Ro]

Your 4K@48MS/s proposal is an interesting approach. As I'm not such a FX2 expert, I need to deep-dive into the TRM when I have a little more time. Please keep in mind that it is important to clock the ADC constantly - due to its common mode input voltage out of spec it needs a long settle time when starting.

[merbanan]

Ok, even with this limitation it should be possible work around it. Ideally a GPIF state machine should be able to handle the sampling of the buffers on its own. If we start it and it fills 6 1k buffers then we can be sure we get 4 1k blocks of good samples. Then it would be nice if the state machine restart automatically after the last buffer is transferred. Then one could just transfer as fast as possible and still get viable data. Anyway I don't see a way to get the GPIF to operate in that way (yet). One would have to manually start it via the command interface (8150mcu).

For good visualization you want 60fps (or more if you want to apply some filtering) that needs 60*4kb=240kib/s (double that for 2 channels). That is far from what USB can handle but you have to add the control channel traffic to it. But that still sounds doable.

Anyway I just wanted to post the idea. We'll see how far it goes.

[Ho-Ro]

I'll also use this thread to collect ideas and documents

• Cypress Knowledge Base Article (KBA): Maximizing Transfer Rate with the FX2/FX2LP (EHCI Controller: Intel ICH8 -> BULK IN: ~40.722 MBps; ISOC IN: ~24.023 MBps)
• KBA: Practical data rate for USB 2.0
• KBA: [Throughput for Isochronous Transfers for FX2LP™]()
• AN4053 - Streaming Data through Isochronous or Bulk Endpoints on EZ-USB® FX2™ and FX2LP™

[Ho-Ro]

No progress so far - I will close for the moment - can be reopened in case of new ideas.

[dmantione]

Just a small comment: Just migrated from OpenHantek to OpenHantek6022 and I noticed the 48 MHz samplerate is no longer available. As a developer I understand the above discussion, as a user I don't: The oscilloscope resolution is noticeable lower at 30 MHz. I hacked the source code back to 48 MHz and got back the original resolution. Maybe there are USB congestions, but I don't notice them, and can use the scope at its normal resolution again.