Two-channel samplerate is not limited after start

OpenHantek / OpenHantek6022

OpenHantek6022 is a DSO software for Hantek USB digital signal oscilloscopes 6022BE / BL. Development OS is Debian Linux, but the program also works on FreeBSD, MacOS, RaspberryPi and Windows. No support for non-Linux related issues unless a volunteer steps in!

GNU General Public License v3.0

867 stars 152 forks source link

Two-channel samplerate is not limited after start #185

Closed cryptozoy closed 3 years ago

cryptozoy commented 3 years ago

Under Windows 10 after starting the program, it is allowed to turn on samplerate above 15MS/s until you turn off and turn on again any channel.

Ho-Ro commented 3 years ago

I tried to reproduce this issue:

select two channels
select time base 1µs/div
set sample rate e.g. 10 MS/s (or 12 or 15)
switch off
switch on again
time base is 1µs/div
sample rate is 12 MS/s
increase sample rate
will not go > 15 MS/s

Please give a step-by-step instruction how to reproduce your issue - thx.

cryptozoy commented 3 years ago

It happens only under Windows 10. In Fedora 34 Linux everything is normal.

cryptozoy commented 3 years ago

It works with e8e27c9. Thank you.

Ho-Ro commented 3 years ago

@spam-receiver Thx for reporting - update is available in unstable now. How does the program behave the other way round? Starting with CH1 mode, can you go up to 24 and 30 MS/s? I cannot check on a win system with real HW, only Demo Mode that starts always with 2 channels. So I leave this issue open 'til your positive feedback.

cryptozoy commented 3 years ago

You right. Now one channel-mode can't go upper 15MS/s after start until on/off any channel. I forgot to check it out.

Ho-Ro commented 3 years ago

Ok, but better this way round. But nevertheless I will look for a correct behaviour if I can spare some time.

Ho-Ro commented 3 years ago

Tl;dr: It will take some more time...

I created some test builds with extensive tracing output and it seems that the described behaviour is caused by a race condition between the startup default setting (always started with 1 channel in the past, now defaults to 2) and the persistent setting from the last shutdown. This sets always the correct (stored) number of channels, but misses to update the max sample rate limit according to the actual number of channels - it still uses the one from the startup value. The communication between the core and UI of the program is based on Qt's signal/slot mechanism that obviously adds some unpredictable delays.