Hantek 6022BE freezes after switching to single trigger mode.

[HTD]

Describe the bug Program works, starts in AUTO trigger mode. Then as soon as I switch to single - it captures a single data burst properly. Then stops communicating with the device. I see a STOP icon on the left, it can be in "on" or "off" state, which is invalid, in on state the "START" icon should be displayed. The program is dead. All graphical controls, options and menus work, but actual readings are stopped and cannot be started again. After restarting the program, everything works again.

To Reproduce Connect to any known signal source. Start the program. Observe normal operation. Switch to a SINGLE trigger mode. Try to switch triggering to AUTO.

After changing triggering to AUTO disconnect the signal source and short circuit the probe. The reading, when the program is working correctly - should flatline, since AUTO mode samples the inputs even when no trigger pulse is present. With my version of the program and 6022BE - the last measured signal is still on the screen unchanged - indicating that nothing is read from the scope anymore.

Program works properly again only when restarted. So - when the signal connected to the probe is connected or disconnected - the reading updates accordingly.

Expected behavior In SINGLE mode the START icon (and menu option) should be displayed instead of STOP. Clicking it, or pressing the S key should make the next reading. Switching to AUTO should make continuous readings.

Computer environment (please complete the following information):

• OpenHantek version: 3.3.0
• OS: Windows 11
• Video hardware: NVidia GTX1060
• OpenGL version: 4.6.0 NVIDIA 512.77 - GLSL 1.20
• Qt version: 5.15.2

Scope device (please complete the following information):

• Device: Hantek 6022BE
• Program top line OpenHantek6022 (3.3.0) - Device DSO-6022BE (FW0210)
• Input signal: 1-Wire DS18B20 signal.
• Probe setting: 1x

[Ho-Ro]

To Reproduce

Sorry, I tried many times to reproduce. What I do is

Connect to any known signal source.

I attached a sine signal of about 1Vpp and 1Hz to the 1st channel (or 2nd, it doesn't matter). The signal has some jitter which makes it easy to distinguish the running and stopped signal.

Start the program. Observe normal operation.

Yes. I set to Normal and adjust for a stable triggered picture. The trigger indicator at the top left is green. The Start/Stop button is activated (dark) and shows ||. SPACE stops (light >) and starts (dark ||) alternately.

Switch to a SINGLE trigger mode.

The trace stops, the trigger indicator stays green. Start/Stop is deactivated and shows >. SPACE starts the next capture (the scope captures until a trigger condition is detected, then it stops).

Try to switch triggering to AUTO.

The trace starts again, the trigger indicator stays green. Start/Stop is activated (dark) and shows || again.

[HTD]

About testing if the program stopped to sample - just DISCONNECT the singal. In AUTO mode the plot should flatline, because according to the user's manual it should sample ignoring the trigger pulses. I'll edit the isue to make it clear.

For now as I workaround I use only Normal mode, which is perfect in most scenarios, even when capturing binary data if the stream is not continuous.

[Ho-Ro]

About testing if the program stopped to sample - just DISCONNECT the singal. In AUTO mode the plot should flatline, because according to the user's manual it should sample ignoring the trigger pulses.

• Trigger a pulse in SINGLE mode - ok.
• Now I disconnect the signal - no change.
• Now I switch to AUTO - flat line at GND level (not triggered).
• Now I switch to NORMAL - screen blanks until I reconnect the signal.

Nevertheless if you check how the trigger works (see my comments there) you will detect that the hardware of Hantek is

best suited for repetitive signals in the extended audio range (1 Hz .. 100 kHz). If you want to catch single events reliable - get another hardware.

[HTD]

I've read how it works. It makes sense and I agree this hardware model has obvious limitations, but this issue is not about it.

The SINGLE mode still works incorrectly basically crashing the software and requiring the program restart. It would not be a problem if the single mode was unreliable with capturing a single event. It is a problem when this option crashes the program and requires a restart to recover. It happened I selected that option by mistake. There's no going back. I have to close the program.

IDK what to think - maybe on different systems (OS/PC/6022) it doesn't crash. In my case - in the crashed state the app reacts to clicking. I can change all settings, the window and the controls are responsive. However - restoring the normal operation of the scope is impossible. The displayed signal is frozen forever until the application is closed and restarted. It looks like "lost connection". The program seems to work, but like in "offline / disconnected / waiting forever" state.

[Ho-Ro]

maybe on different systems (OS/PC/6022) it doesn't crash

One of these systems is on my desk :) so it is difficult for me to debug your issue. What you can do:

• Try playing with the option --verbose with different values.
• Do you have the possibility to check it on a different system?

[HTD]

--verbose 4:

   HDC::setTriggerMode() 0
   HDC::updateSamplerateLimits() (100, 200, 500, 1000, 2000, 5000, 10000, 20000, 50000, 100000, 200000, 500000, 1e+06, 2e+06, 5e+06, 1e+07, 1.2e+07, 1.5e+07)
  HDC::setTriggerMode() 1
   HDC::updateSamplerateLimits() (100, 200, 500, 1000, 2000, 5000, 10000, 20000, 50000, 100000, 200000, 500000, 1e+06, 2e+06, 5e+06, 1e+07, 1.2e+07, 1.5e+07)
  HDC::setTriggerMode() 2

(dead)

--verbose 5

 HDC::setTriggerMode() 2
    HDC::stateMachine() 501
    HDC::convertRawDataToSamples() 501
    Triggering::searchTriggeredPosition() 501
    Triggering::provideTriggeredData() 501
    HDC::getRecordLength() -> 202752
    HDC::stateMachine() 502
    HDC::convertRawDataToSamples() 502
    Triggering::searchTriggeredPosition() 502
    Triggering::provideTriggeredData() 502

(dead).

--verbose 6

  HDC::setTriggerMode() 2
    HDC::stateMachine() 88
    HDC::convertRawDataToSamples() 88
    Triggering::searchTriggeredPosition() 88
     Triggering::searchTriggerPoint() 1 2 -1 0
     begin: 4855 end: 14855
     swT: 4925
     Triggering::searchTriggerPoint() 1 2 1 4925
     begin: 4925 end: 19979
     swT: 4968
     Triggering::searchTriggerPoint() 1 2 -1 4968
     begin: 4968 end: 19979
     swT: 5009
     nextSlope: \ triggeredPositionRaw: 4925
    Triggering::provideTriggeredData() 88
     HDC::stateMachine() stop sampling 88
    HDC::getRecordLength() -> 202752
    HDC::stateMachine() 89
    HDC::convertRawDataToSamples() 89
    Triggering::searchTriggeredPosition() 89
     Triggering::searchTriggerPoint() 1 2 -1 0
     begin: 4855 end: 14855
     swT: 4863
     Triggering::searchTriggerPoint() 1 2 1 4863
     begin: 4863 end: 19979
     swT: 4906
     Triggering::searchTriggerPoint() 1 2 -1 4906
     begin: 4906 end: 19979
     swT: 4946
     nextSlope: \ triggeredPositionRaw: 4863
    Triggering::provideTriggeredData() 89
     HDC::stateMachine() stop sampling 89

In "dead" state, changing the triggering mode does nothing. At least nothing is shown on the console. When "alive" console is constantly flooded with text. After changing the triggering mode to single messages stop.

With --verbose 255 I got countless messages even when the program was in a "dead" state. Here's a sample:

      ScopeDevice::controlTransfer() Vendor Out STARTSAMPLING 0 0 { 1 } = 1
      ScopeDevice::bulkReadMulti() 405504

These 2 lines are repeated forever.

[Ho-Ro]

Thx, please give me some time to analyse your data.

[robertofgm]

I have exactly the same problem.

• OpenHantek version: 3.3.0
• OS: Windows 10
• Video hardware: NVidia RTX2060
• OpenGL version: 4.6.0 NVIDIA 511.79 - GLSL 1.20
• Device: Hantek 6022BE
• Program top line OpenHantek6022 (3.3.0) - Device DSO-6022BE (FW0210)

[thomasstauffer666]

Exact same issue here. Also when switching to "Single" mode and then closing the software (via File/Exit), it never exits and I have to press Ctrl+C, while in Auto and Normal mode, closing works as expected.

• OpenHantek version: 3.3.0
• OS: Ubuntu
• Device: DSO-6022BE (CF417A644520), FW0210
• Graphic: 3.0 Mesa 21.2.6 - GLSL version 1.20
• Qt version: 5.12.8

Also like HTD, the log looks like:

    Triggering::provideTriggeredData() 414
     HDC::stateMachine() stop sampling 414
      ScopeDevice::controlTransfer() Vendor Out STARTSAMPLING 0 0 { 1 } = 1
      ScopeDevice::bulkReadMulti() 102400
      ScopeDevice::controlTransfer() Vendor Out STARTSAMPLING 0 0 { 1 } = 1
      ScopeDevice::bulkReadMulti() 102400
      ScopeDevice::controlTransfer() Vendor Out STARTSAMPLING 0 0 { 1 } = 1
      ScopeDevice::bulkReadMulti() 102400
      ScopeDevice::controlTransfer() Vendor Out STARTSAMPLING 0 0 { 1 } = 1
      ScopeDevice::bulkReadMulti() 102400
      ScopeDevice::controlTransfer() Vendor Out STARTSAMPLING 0 0 { 1 } = 1
      ScopeDevice::bulkReadMulti() 102400
      ... (repeated forever)

[thomasstauffer666]

There is a while loop inside HantekDsoControl::stateMachine

while ( raw.tag == lastTag )

which is IMHO somewhat problematic in itself, as there is no condition to leave this (let's imagine the HW has an issue, the SW should not stay in a loop forever IMHO). Also, IMHO, from the perspective of the compiler both this variables may never change (atomic, or lock is release/reacquired, ...) and at least from a short glance, the compiler may even optimize it to access both variables only once.

Anyway if I do the following

while ( raw.tag == lastTag ) { 
    QThread::msleep(1);
}

(or just a qDelay) then this ugly hack seems to get rid of the issue.

[Ho-Ro]

Please check 45beac0 The whole single stepping has evolved over time and is a big mess. You're right, this blocking loop is critical, it was supposed to solve the problem of a new single trigger being fired on data that was already in memory and didn't reflect the current state of the external hardware after hitting SPACE. So I just waited (busy) for the next new samples - unfortunately this created a race condition that I didn't detect on my slow computer (an old Thinkpad T400). Now I leave the sampling thread running and only stop the data conversion as soon as the single trigger has been fired. Restarting via SPACE starts the search for a new trigger edge using the latest data.

[Ho-Ro]

@HTD, @TeoremaPi , @thomasstauffer666 Please check latest unstable if this solves your issue - thx.

[robertofgm]

With the new version the program does not freeze but I still have problems with the trigger. Sometimes the program does not detect rising edges (as seen in the pulse at 00:06 in the video) but, even when it detects them and stops, it only shows the signal for a short period of time.

https://user-images.githubusercontent.com/49719701/173666639-84e7aa57-2f10-4fb3-bdb2-e17430c86ede.mp4

[Ho-Ro]

The pulse at 06 is not triggered because it doesn't fulfil all trigger prerequisites - right slope AND enough samples before and after the slope to fill the complete screen (remember, the scope samples blindly and checks then for the trigger conditions). And regarding the vanished pulses - I will investigate when I find some spare time in July, until then see SINGLE mode as not working properly, but at least it doesn't block anymore. Edit: closed by accident - reopen.

[robertofgm]

Thank you very much. Single mode seems to work correctly in version 3.2.5. Meanwhile, I'll use it if I need that feature

[Ho-Ro]

Single mode seems to work correctly in version 3.2.5.

It has a logical flaw that you don't see immediately, but IMHO can lead to very wrong conclusions, because it shows the triggered status of the signal before the START button was pressed, see attached Single_Trigger_3.2.5.mp4:

• Press START at 05 without connected signal (no trigger, OK)
• Connect the signal at 10 (trigger, OK)
• Press START at 20 (trigger immediately, OK)
• Disconnect the signal at 21
• Press START at 25 (trigger immediately with stable signal, FALSE, because when I press START there is no signal connected anymore).
• Press START at 30 (no trigger, OK)

https://user-images.githubusercontent.com/12542359/173808054-fe251fba-a40e-46fe-94fb-2c2f26dff5c8.mp4

Compared with Single_Trigger_New.mp4 for latest unstable (fae8b16) you can see the difference.

• Press START at 05 without connected signal (no trigger, OK)
• Connect the signal at 10 (trigger, OK)
• Press START at 20 (trigger immediately, OK)
• Disconnect the signal at 21
• Press START at 25 (no trigger, OK)
• Connect the Signal at 30 (trigger, OK)

At least on my system, it is triggered after START when the trigger condition first occurs and the display doesn't magically disappear after it is triggered either.

https://user-images.githubusercontent.com/12542359/173811759-9cb52b9e-fca2-4429-8bfa-09d8dfa93594.mp4

[Ho-Ro]

Ok, to replace the buggy 3.3.0 I will issue a (bug fix) release 3.3.0.1 (== latest unstable) before I'm AFK for the next two weeks. Please feel free to test and improve.

[thomasstauffer666]

Thanks for your update, I didn't look at it as closely as others, but the Single Mode does not freeze the application anymore. Thank you.

[karlp]

3.3.0.1 fixes this for me, much better thanks!

[Ho-Ro]

@HTD: can we close here?

[HTD]

Yes, it works! Thank you!