The sample rate spin box does not step up/down correctly

[pedropedro]

Simple scope test, reading single channel 20kHz calibration signal, "Voltage", "Horizontal" and "Spectrum" parameters set to achieve "nice" signal picture, see screenshot:

Sample rate is set to 5MS/s, calibration out to 20 kHz.

After closing the application, the .config/OpenHantek/OpenHantek6022.conf file contains 1) the chosen sample rate : [scope] :: horizontal\samplerate=5e+06 2) NO parameter for the calibration frequency

Reopening the application we can see: 1) sample rate preset to 15MS/s 2) (no wonder) calibration frequency preset to the default value 1kHz

1 ) Doing nothing at all but closing the application again, the content of .config/OpenHantek/OpenHantek6022.conf file changes to ... [scope] :: horizontal\samplerate=2.4e+07 ... => 24MS/s .... reopening the application again yields still 15MS/s in the spinner

or

2 ) Trying to change (using mouse) the value of the sample rate spinner: 2a) clicking spin-down-arrow :: the displayed value drops directly to "1MS/s", the spin-down-arrow gets disabled. Clicking 6 times on the spin-up-arrow does not change anything, first the 7th click changes the value to "2MS/s". Afterwards everything does function

2b) alternatively clicking spin-up-arrow :: the displayed value drops directly to "1MS/s", the spin-down-arrow gets disabled. Clicking 5 times on the spin-up-arrow does not change anything, first the 6th click changes the value to "2MS/s". Afterwards everything does function

Desired behavior: Both parameters (saved and) read from the conf file and applied appropriately.

Computer environment : OS: Xubuntu 19.09 amd64 on VirtualBox 6.1.4

Scope device : Device Hantek 6022BE Program top line OpenHantek6022 3.0.2 - FW0204 Input signal: calibration out 20 kHz Probe setting: probe X1

[pedropedro]

Hi, I just have built the newest version 20200325 build 620 / 6022BE / FW0206 but the problem #66 remains. Further, running ./OpenHantek in a terminal directly from the build/openhantek directory I can see tenths of warnings(?) in the terminal: ... qt.glx: qglx_findConfig: Failed to finding matching FBConfig (8 8 8 0) qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 8 8 0) qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 8 0) qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 0) .... apt-ed & built everything according the build instructions; sources downloaded as a zip.

[Ho-Ro]

• 1a7843e closes the error that you described above: setting 10µs results in 24 MS/s, but closing and reopening shows mistakenly 15 MS/s in the Horizontal dock on the right while the top line of the scope displays correctly the actual sampling rate of 24 MS/s. Ok, let my clarify the timebase and samplerate behaviour of the scope. Timebase is the lead setting and the samplerate is chosen appropriate so that the most possible number of samples is shown on the screen (10k of the 20k sample buffer, the other half is necessary to ensure the software trigger function) and the samplerate must be below 24 MS/s, because 30 MS/s is a little bit unstable. It is possible to change the samplerate manually in a range that 100..10k samples are visible on the screen, also 30 MS/s can be set manually. Setting a new timebase changes the samplerate automatically again. Therefore the samplerate setting from config is not used and not needed, I will remove it later for clarification.
• The calibration out frequency is not stored because the scope shall start up with 1 kHz every time to be consistent with the writing 1kHz on the scope's front. The behaviour is intended and will not be changed.
• The issue with the spinner is nasty (this is something deep in legacy code where I don't want to dig in). As I do not click but scroll the mouse wheel it doesn't bother me too much and therefore it has very low priority.

The qt_glx warnings could possibly fixed when you comment this line: https://github.com/OpenHantek/OpenHantek6022/blob/43cd7f423ce45fe974f76eb6018219a30ff9ccd9/openhantek/src/glscope.cpp#L44 Maybe caused by Virtualbox (?)

[pedropedro]

• Thank you for clarification, I noticed the behavioral one-way dependency time-base => sample-rate. For the monitored signal (CH1/2) is such auto setting fine. The problem is with the displayed spectrum - in my test case (this thread) the spectrum gets stable only when I pull the sample-rate to 10MS/s or less. Otherwise the spectrum graph is "dancing" on the screen - not so good for screenshots ;-) But, hey, why is the FFT more stable with less samples at all ? I would expect the opposite ...
• Okay, I had to put the scope's front under the microscope, but eventually found that label too :-D My idea was just to have the same behavior like with a TV set for instance - switching off when watching channel 123 would bring back the same channel when switched on again. But I respect your point.
• Yes, it is nasty, the same behavior can be seen also after any change of the time-base. I understand, for pure signal monitoring (no FFT) there are no much needs to debug it. Do you have perhaps a hint for me where to start (which source) ? Thanx in advance ...

[Ho-Ro]

But, hey, why is the FFT more stable with less samples at all ? I would expect the opposite ...

You get less samples on the screen, but the FFT is always taken over the complete sample buffer (20k samples) and averages over a longer time (->higher frequency resulution) and averages over more signal periods -> less jitter. Another reason could be that the USB transfer is less stable at (very) high sample rates, this is also the reason why I never select 30 MS/s automatically because this speed saturates a typical USB connection (this is valid for CH1 only, the rates are halved if CH2 is selected).

I renamed the issue and reopen it to track the nasty spinner issue. Your description (drop to 1M, six clicks without change, the next selects 2M) fits with the initial setting https://github.com/OpenHantek/OpenHantek6022/blob/43cd7f423ce45fe974f76eb6018219a30ff9ccd9/openhantek/src/hantekdso/models/modelDSO6022.cpp#L101

    specification.fixedSampleRates = { // samplerate, sampleId, downsampling
        { 10e3,   1, 100} , { 20e3,   2, 100} , { 50e3,   5, 100} , // 100x downsampling from 1, 2, 5 MS/s!
        {100e3,  10, 100} , {200e3,  10,  50} , {500e3,  10,  20} , // 100x, 50x, 20x downsampling from 10 MS/s
        {  1e6,  10,  10} , {  2e6,  10,   5} , {  5e6,  10,   2} , // 10x,   5x,  2x downsampling from 10 MS/s
        { 10e6,  10,   1} , { 12e6,  12,   1} , { 15e6,  15,   1} , // no oversampling
        { 24e6,  24,   1} , { 30e6,  30,   1} , { 48e6,  48,   1}   // no oversampling
    };

The setting of the time base triggers the calculation of the valid sample rates that 100..10000 samples fit on the screen: HorizontalDock::calculateSamplerateSteps(double timebase) that gives 1...30MS/s and sets 24MS/s (the highest value will never used automatically). Clicking the down arrow drops probably to index zero, but due to the limitation is selects 1 MS/s. Stepping up selects index 1, 2, 3, 4, 5 and 6 without change because they are all <= lower limit of 1MS/s, the next step selects index 7 (2 MS/s) see below the "debug" output from some printf statements (HD = HorizontalDock.cpp, SSB = sispinbox.cpp).

Select 10µs/div:

HD::timebaseSelected( 1e-05 )
HD::setSamplerateLimits( 1e+06, 3e+07 )
HD::setSamplerate( 2,4e+07 )
HD::setSamplerate return 2,4e+07

Click down arrow of sample rate:

SSB::stepBy( -1 )
HD::samplerateSelected( 1e+06 )
HD::setSamplerate( 1e+06 )
HD::setSamplerate return 1e+06

same for step up

HD::setSamplerate( 2,4e+07 )
HD::setSamplerate return 2,4e+07
SSB::stepBy( 1 )
HD::samplerateSelected( 1e+06 )
HD::setSamplerate( 1e+06 )
HD::setSamplerate return 1e+06

[Ho-Ro]

My idea was just to have the same behavior like with a TV set for instance - switching off when watching channel 123 would bring back the same channel when switched on again.

You're right, the scope should do the least confusing thing - the calibration frequency is now (26c1a49) as persistent as all other settings. Thanks for convincing me.

[Ho-Ro]

The irregular samplerate spinbox (...10/12/15/24/30 MS/s) got confused when a change in timebase sent a new samplerate and dropped always to index 0 (=10kS/s) from where you had to step up (without visible change) until you reach the valid range (e.g. 1MS/s..30MS/s) where the up arrow "worked" as expected. Solution 76793df: always synchronise the index before stepping.

[pedropedro]

Yes, the SiSpinBox::stepBy() I too identified tonight as the root cause for troubles :-) The 623er version is working fine. Merci !