Jitter on high frequencies

[bmentink]

I notice quite a bit of Jitter on the edges when the frequency get's higher than about 70khz, is this a hardware limitation or this software ..?

I have tried this on both external signal generator and the internal Calibration output ..

To duplicate just set Cal Out to 100khz .. Jitter appears to be around 300ns at 100khz ..

I also notice that the max samplerate is only 24Mhz, where on the old software (pre fork) was 48Mhz

[Ho-Ro]

I checked it with my signal generator, 460 kHz, CH1 only, 30 MS/s, 500 ns/div: There is a jitter of ~50 ns that fits with the uncertainty due to sampling every 33 ns.

If you look at the calibration out with a "real" scope you can detect the massive jitter at high frequencies. This signal is created by the firmware running on the scope, interrupt driven by counter 2 running at 4 MHz, for 100 kHz the interrupt is called every 5 µs and toggles an output pin while the 8051 core runs at 48 MHz. Therefor the jitter is expected, but the frequency on long term is quartz stable. I changed calibration out from fixed 1 kHz to the 50 Hz ... 100 kHz range to have a "poor man's function generator" at hand to play around, but never as a precision measurement device.

30 MS/s is the maximal sampe rate that the high speed USB can support - raw USB data rate is 480 Mbit/s -> 60 MByte/s - BUT you have protcol overhead and (very important) the USB bulk transfer shares the bus with other devices and has to claim and release the bus. So from 60 MByte/s only half of it is useful as netto data rate. My program selects the sample rate automatically from chosen time/div setting, but never uses the max. value (30 MS/s for CH1 only, 15 MS/s as soon as CH2 is selected, even CH2 mode transfers both channels), but instead 24 or 12 MS/s are selected - but you can select 30/15 manually. 48MS/s is physically nonsense and only a marketing gag. See also #1

Long story short: Hantek6022BE drives the USB to its limits.

EDIT: It's important that the Hantek is alone on its (high speed) bus, you should avoid a situation like this, where Dev 35 and Dev 36 share the same Bus 03

$ lsusb -t 
...
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 1: Dev 29, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 36, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
        |__ Port 3: Dev 37, If 0, Class=Mass Storage, Driver=usb-storage, 480M
...

Another good practice is to connect the scope directly to the PC without additional USB hubs. The strange black/red Y-cable isn't needed (the scope draws < 200 mA), just use a good USB 2.0 cable.

[bmentink]

Cool, thanks for the explanation ..

On Thu, Dec 12, 2019 at 10:17 PM Martin notifications@github.com wrote:

I checked it with my signal generator, 460 kHz, CH1 only, 30 MS/s, 500 ns/div: [image: image] https://user-images.githubusercontent.com/12542359/70695247-90185100-1cc1-11ea-9e21-b7b5ce840a3e.png There is a jitter of ~50 ns that fits with the uncertainty due to sampling every 33 ns.

If you look at the calibration out with a "real" scope you can detect the massive jitter at high frequencies. This signal is created by the firmware running on the scope, interrupt driven by counter 2 running at 4 MHz, for 100 kHz the interrupt is called every 5 µs and toggles an output pin while the 8051 core runs at 48 MHz. Therefor the jitter is expected, but the frequency on long term is quartz stable. I changed calibration out from fixed 1 kHz to the 50 Hz ... 100 kHz range to have a "poor man's function generator" at hand to play around, but never as a precision measurement device.

30 MS/s is the maximal sampe rate that the high speed USB can support - raw USB data rate is 480 Mbit/s -> 60 MByte/s - BUT you have protcol overhead and (very important) the USB bulk transfer shares the bus with other devices and has to claim and release the bus. So from 60 MByte/s only half of it is useful as netto data rate. My program selects the sample rate automatically from chosen time/div setting, but never uses the max. value (30 MS/s for CH1 only, 15MS/s as soon as CH2 is selected, even CH2 mode transfers both channels), but instead 24 or 12 MS/s are selected - but you can select 30/15 manually. 48MS/s is physically nonsense and only a marketing gag. See also #1 https://github.com/OpenHantek/OpenHantek6022/issues/1

Long story short: Hantek6022BE drives the USB to its limits.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OpenHantek/OpenHantek6022/issues/44?email_source=notifications&email_token=ACNHVBZZKDVUIE3ZRGZ3HHTQYH6TVA5CNFSM4JZFWFC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGV73SA#issuecomment-564919752, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNHVBYYSD6TWLMGG3MKWSLQYH6TVANCNFSM4JZFWFCQ .