3 ms·

Raw oscilloscope data over USB sounds like a simple but bad idea. This is almost exactly the situation I'd expect to benefit most from realtime lossless data co

Raw oscilloscope data over USB sounds like a simple but bad idea. This is almost exactly the situation I'd expect to benefit most from realtime lossless data compression e.g. Huffman coding. It's the nature of scope measurements that you're measuring something mostly predictable and continuous. Virtually all adjacent samples will be within +/-10% (especially as sample rate increases) so only very special cases would need beyond 12 MB/s to reconstruct the original 48 MB/s data while staying no more than one 64 byte packet behind.

IshKebab 5y ago
Sure but you lose quite a lot by going from "this always works" to "this works some times depending on your data". Clearly a hardware trigger is easier than adding compression. Another option would be sending single-bit "above/below trigger" values. Then it's only 6 MB/s which is fine.
rasz 5y ago
There is no software touching the data between ADC and USB. Cypress EZ-USB FX2LP bridge chip is running in GPIF mode https://www.cypress.com/documentation/application-notes/an66806-getting-started-ez-usb-fx2lp-gpif https://www.cypress.com/documentation/application-notes/an66... https://www.cypress.com/documentation/application-notes/an63787-ez-usb-fx2lp-gpif-and-slave-fifo-configuration-examples https://www.cypress.com/documentation/application-notes/an63... Its a state machine pumping raw data. Problem is with clocking, you can only use one clock source and few dividers. 48MHz is too fast and you will miss samples. I dont know why Hantek firmware is missing the 30 MHz option, maybe it required different main crystal?
- zokier 5y ago
  Well this gets messy. It doesn't have bandwidth to stream the full ADC data to PC, but it also doesn't have any capability on the device itself to do triggering. I tried googling around and the best guess how it is supposed to work is that PC periodically polls the device for data and looks for trigger points from what it receives. If the trigger point happens to fall within the buffer that was there at the time of polling then great, otherwise apparently it just loses that trigger(!). No wonder people are commenting that it is crappy, that sounds pretty dubious approach.
  - rasz 5y ago
    It doesnt in advertised 48 MHz sampling mode, all lower speeds should be glitch free. I was mistaken, both original and openhantek software https://github.com/OpenHantek/OpenHantek6022 https://github.com/OpenHantek/OpenHantek6022 support 30 MHz mode. Seems Hantek put 48 MHz option in the product just to be able to claim it on the box https://sigrok.org/wiki/Hantek_6022BE#Protocol https://sigrok.org/wiki/Hantek_6022BE#Protocol Its fully unusable. Cypress chip maxes out in USB2 mode at around 40-42MB/s in optimal conditions - USB HDD connected to modern Intel chipset alone on the bus.

IshKebab 5y ago

Sure but you lose quite a lot by going from "this always works" to "this works some times depending on your data". Clearly a hardware trigger is easier than adding compression. Another option would be sending single-bit "above/below trigger" values. Then it's only 6 MB/s which is fine.

rasz 5y ago

There is no software touching the data between ADC and USB. Cypress EZ-USB FX2LP bridge chip is running in GPIF mode https://www.cypress.com/documentation/application-notes/an66806-getting-started-ez-usb-fx2lp-gpif https://www.cypress.com/documentation/application-notes/an66... https://www.cypress.com/documentation/application-notes/an63787-ez-usb-fx2lp-gpif-and-slave-fifo-configuration-examples https://www.cypress.com/documentation/application-notes/an63... Its a state machine pumping raw data. Problem is with clocking, you can only use one clock source and few dividers. 48MHz is too fast and you will miss samples. I dont know why Hantek firmware is missing the 30 MHz option, maybe it required different main crystal?

zokier 5y ago
Well this gets messy. It doesn't have bandwidth to stream the full ADC data to PC, but it also doesn't have any capability on the device itself to do triggering. I tried googling around and the best guess how it is supposed to work is that PC periodically polls the device for data and looks for trigger points from what it receives. If the trigger point happens to fall within the buffer that was there at the time of polling then great, otherwise apparently it just loses that trigger(!). No wonder people are commenting that it is crappy, that sounds pretty dubious approach.
- rasz 5y ago
  It doesnt in advertised 48 MHz sampling mode, all lower speeds should be glitch free. I was mistaken, both original and openhantek software https://github.com/OpenHantek/OpenHantek6022 https://github.com/OpenHantek/OpenHantek6022 support 30 MHz mode. Seems Hantek put 48 MHz option in the product just to be able to claim it on the box https://sigrok.org/wiki/Hantek_6022BE#Protocol https://sigrok.org/wiki/Hantek_6022BE#Protocol Its fully unusable. Cypress chip maxes out in USB2 mode at around 40-42MB/s in optimal conditions - USB HDD connected to modern Intel chipset alone on the bus.