Hantek 6022BE - nonexistent raising and failing edges is periodically displayed

[y-ponomarev]

Hantek 6022BE All two probes connected to calibration 1 KHz 2 Vpp output. Software trigger mode. Digital phosphor is on. Nonexistent raising and failing edges is periodically displayed. Sorry for my English.

[dendvz]

Those exponential rise and decay shapes are real ones, time constant calculated by rise to 1V (50%) is ~300nS. Which in turn can be evaluated as built-in LP filter R14 + C16, e.g. 100 Ohm * 3nF. Just speculating about exact values :) The sharp edges, however, are false.

[y-ponomarev]

I tried reading the data from the Hantek 6022BE using libusb1. Oscilloscope with custom firmware (https://github.com/rpcope1/Hantek6022API). Up to 16 MSps on 2 channels and up to 24 MSps on one channel, there were no problems. With a further increase in the sampling frequency, distortions began. I guess the reason is the overflow of the internal scope fifo.

[dendvz]

Hmm... probably you're right. I have enabled timestampDebug() printouts . The log looks weird:

"Received 20480 B of sampling data" is pretty useless, 20K packet exceeds CY7C68013A-100AXC FIFO capacity. Need more time to dig into details.

[y-ponomarev]

The CY7C68013A reads data from the ADC to the FIFO and transmits data from the FIFO via USB simultaneously. I assume that with a high ADC read rate (samplerate), the fifo overflows and the data reading from the ADC is suspended.

[dendvz]

Yes, it is an overflow. The sample rates of 2*16MHz and above are too high for isochronous transfer over USB 2.0, see https://github.com/rpcope1/Hantek6022API/issues/35

What needs to be fixed in openhantek is: 1) FIFO cleanup, i.e. wrapping bulkReadMulti(data.data(), dataLength) into equivalent of start_sampling() / stop_sampling(); this will also reduce required DROP_DSO6022_SAMPLES from 1040 to few samples (https://github.com/OpenHantek/openhantek/pull/69/files#diff-4a6d5b45d6d75db64a4d605dda5d5164) 2) Add shorter record length to be used for high sample rates - at a cost of ~10x lower chance of successful SW triggering.

[y-ponomarev]

The actual length of the edges of the calibration output is less than 50 ns (probe = 10MOhm, 15pF).

[dendvz]

@y-ponomarev So, it is not the built-in generator. Nice catch! Just curious, have you also tried Hantek probe on MSO-X? Generally speaking, it is normal to observe 10x shorter step response on a (50x more expensive) device w/ proven 100 MHz vs. 20 MHz claimed bandwidth :)

[y-ponomarev]

The capacitance of the hantek probes stretches the front of the calibration output signal (sorry for my bad english). Yellow - MSO-X probe, green and blue - hantek probes.

1. Only MSO-X probe connected to calibration output:
2. MSO-X probe and hantek probes (1:10) connected to calibration output:
3. MSO-X probe and hantek probes (1:1) connected to calibration output: Also callibration output has duty cycle jitter:

[dendvz]

Thanks for collecting the data, results are quite predictable:

Setup	Capacitance	Rise time (0.63 Vc)
Keysight probe	15pF	<15ns
Keysight + 2 * Hantek 1:10	15 pF + 2 * 20 pF = 55 pF (3.66x)	40ns
Keysight + 2 * Hantek 1:1	15pF + 2 * 100 pF = 215 pF (14.3x)	250ns

Hantek probe spec

Obviously, Hantek 6022BE has an equivalent output current limiting resistor of 1 kOhm.

[davidgraeff]

How do we proceed here?

[dendvz]

The root cause of an issue is FIFO overflow at high sampling rates. Fix will require deep refactoring of HantekDsoControl. For 6022BE/6022BL we need to introduce several sampling methods:

• Recent one, which uses bulkReadMulti() with a buffer size exceeding device capacity (hopefully I will be able to get rid of dropped samples, but it is not a strong limitation for 10K buffer). The method works if sampling rate is below 8MS/s.
• High sampling rate, receive window is aligned with FIFO size. The sampling rate of 48MS/s will then produce an effective duty cycle of ~15%, which in turn should reduce sw triggering performance.
• Finally, for very low sampling rates, we should probably acquire single FIFO buffer at 100kS/s and then leave device free-running until next sample.

For now, the proposal is to postpone the issue and document the visible effect of high sampling rate on 6022Bx (missing waveform fragments).