Continuous Data Capture? - WAS: Display internal details (oversampling, hardware gain)

[Sogolumbo]

Is your feature request related to a problem?.
The SNR of the oscilloscope varies based on the settings. This is confusing at the beginning. I'm pretty sure this is due to the oversampling and hardware/software gain.

Describe the solution you'd like
Display the oversampling factor and the hardware/software gain. This will stop users from wondering about the varying SNR and will make it easier to achieve high SNR when necessary.

[Sogolumbo]

I have one more idea which relates to this:
It would be nice to calculate the quantization error in absolute units.
Based on that it is possible to calculate the signal to quantization error ratio (SQNR) and thus the minimum THD which can be measured at the current scope settings and the signal level provided.

One way to use this result would be to display "≤" in front of the THD reading when it reaches the SQNR.

References:
SQNR calculation

[Ho-Ro]

Interesting project, I will keep this in mind for the next version 3.5. Due to lack of time I cannot implement it at the moment, but I would ask you to provide a proof of concept or better a PR.

[Sogolumbo]

I currently don't have the time either.

Still there's one more thing which came to my mind: It would be nice to indicate what the chances are for the trigger to miss or hit based on the current settings. I don't understand enough about this process to say if the probability is always the same.

I would prioritise the display of hardware/software gain, oversampling and the trigger probability over the SQNR calculation. The SQNR wouldn't be fully accurate anyways since other deviations from the true value like noise and other errors which occur during the digital to analog conversion may apply.

[Ho-Ro]

Oversampling display was added with 7b8942a.

what the chances are for the trigger to miss or hit based on the current settings

The triggering is the weakest point of the Hantek HW (it's non-existing). I do it in SW, as described there:

Due to the missing trigger HW of the scope OpenHantek6022 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.
A DSO works like this: capture the input signal into a buffer (e.g. for 20 ms/div * 10 div = 200 ms) and when the buffer is filled refresh the screen with the new buffer content. This would give one refresh every 200 ms for a free-running signal. But to get a standing display you want to trigger. The Hantek6022 don't have any hardware trigger, so triggering is done completely in SW. Therefore the program samples (free running) into a bigger buffer that equates twice the screen size, searches for a sufficient trigger point and displays the corresponding section of the buffer. This leads to a refresh every 400 ms. If there is no trigger condition the sampling starts again until you catch the slope. You should check how it is done.

[Sogolumbo]

I read that part but I still don't understand everything:

Therefore the program samples (free running) into a bigger buffer

What does free running actually mean? Does the oscilloscope just send all the data?

The entire point of my questions is to find out:

1. which percentage (in the time domain) of the whole signal can be displayed for a given setting (in auto mode)
2. does the probability of the trigger not missing the signal equal to the percentage above?

My naive assumption for short time windows is that only part of the signal is shown because at some point part of the signal is discarded.
Is the 1ms delay rule in the settings the only reason that signals get discarded or are there more?

I'll introduce some math:
b: time basis (width of a division. there are 10 horizontal divisions)
w = 10*b: time span shown (width of the window, 200ms in the example above)
W = 2*w: time span captured (width of the data, 400ms in the example above)
fW = 1/W: refresh rate of the buffer if no sample where to be dropped
f = 1/T: actual refresh rate of the buffer
T: how long each buffer is the current one

So
W/T is the percentage of the signal which is shown and
1-W/T is the percentage of the signal which is discarded.

Now what is the value of T?
Can it be calculated or does it depend on system performance? If it depends on system performance it can just be measured.
It will depend on the 1ms rule, right?
That would mean that the percentage would start to drop a lot at rougly W=1ms which is b = w/10 = W/20 = 50µs.

Is T the same in auto, normal and once mode?
It should be if it doesn't depend on system performance and normal and once only change if the current buffer is shown on screen or not.

[Ho-Ro]

What does free running actually mean? Does the oscilloscope just send all the data?

1. The program requests 20K data points from the scope. This is needed to have enough date to cut off at both sides of the 10K display section depending on the trigger position on the screen.
2. The program searches for a valid trigger condition. Valid means

• A rising or falling edge (N values below the trigger value followed by N values above the trigger value, with N = 1 for HF, N = 20 for Normal, N = 400 for LF)
• Enough values left and right of the trigger to get a full screen for the given trigger position.

3. Save the "last triggered" buffer.
4. If Normal mode, just display the untriggered buffer.
5. If Auto mode display this buffer positioned around the trigger.
6. If no trigger was found then display the saved buffer. This keeps the UI running and you can move, narrow or widen the display.
7. If not Single mode then goto 1. else wait for Start before going to 1.

During 2. - 7. no data is captured, the scope is blind, the 1 ms or 10 ms Hold off is added too.

Have a look at developer_info.md and triggering.cpp where I wrote a lot of comments.

As already written above:

OpenHantek6022 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.

[Sogolumbo]

Enough values left and right of the trigger to get a full screen for the given trigger position.

This rule cuts the probability of a successful trigger in half.

So in a best case scenario we have:
h = 1ms: holding time (settings)
p = 0: processing time (unknown)
T = W+h+p: duration of each buffer
P = W/T/2 = W/(W+h+p)/2: probability of a successful trigger on a singular event.

If the processing time p is neglected we end up with this plot:

The maximum probability is strictly determined by Pmax = (W-w)/T≈(1-w)/W (The bigger the buffer compared to the displayed content, the higher the probability).
The position of the dropoff is at p+h≈W = W/w*10*b.

So both values can in theory be improved by having a bigger buffer size W compared to the width of the window w.

[Sogolumbo]

Here's the python code for the plot

import numpy as np
from matplotlib import pyplot as plt
# all numbers in SI units (e.g. seconds) unless specified otherwise

scale = np.array([1, 2, 5])
b = scale # time basis (5 s down to 1 ns)

for x in [1e-1, 1e-2, 1e-3, 1e-4, 1e-5, 1e-6, 1e-7, 1e-8, 1e-9]:
    b = np.append(scale*x, b)


W = 20*b # buffer size in time
h = 1e-3 # holding time (settings)
p = 0 # processing time (unknown)
T = W+h+p # duration of each buffer
P = W/(T)/2 # probability of a successful trigger on a singular event

#plt.plot(b, W)
#plt.plot(b, T)

plt.plot(b, P*100)
plt.grid()
plt.xscale('log')
plt.ylabel('probability in %')
plt.xlabel('time base in s')
plt.suptitle('Probability of a successful trigger on a singular event')
plt.title('(Neglecting processing time)')
plt.show()

[Sogolumbo]

How is the ratio of w/W defined in code? I think I would like to experiment with this in the future to get a better responsiveness. I found SAMPLESIZE in dsosamples.h. But how is the amount of samples on the screen defined?

It seems very likely to me that a maximum probability between 75% and 95% (W/w between 4 and 20) is achievable. This would be a very noticeable improvement if you ask me.

[Sogolumbo]

Another way to achieve an improvement would be to loosen the condition:

• Enough values left and right of the trigger to get a full screen for the given trigger position.

That would not be very elegant though.

Edit: Unless....
If the minimum distance of the signal captured where to be set by markers that might work. But it would cause a tradeoff between resolution and trigger probability.

On the other hand the W/w increase will cause a tradeoff between trigger probability and responsiveness at big time windows. Which is probably fine if it's communicated by an (expected or actual) fps number on screen.

[Sogolumbo]

The solution to these tradeoffs is a control which allows to switch between different modes/settings:
One Mode for a singular event and one mode for somewhat periodic signals (e.g. frequency modulated sinusoidal).
The single event mode can be optimized for a high trigger success probability, the other mode shall be optimized for response time (this is probably the current state of the application and thus won't need additional work).

[Sogolumbo]

Dead end

Ooh... I have yet another idea which seems pretty elegant to me. But it has an obvious problem which I missed when it first came into my mind: It all boils down to continuous data capture. If there's no gap between following blocks that would make it possible to put two following blocks of the window size (10kS) as one block. The blocks get put into a FiFo queue of length 2. This would achieve 100% trigger probability while halving the response time compared to the current approach.

It seems like it's somewhat similar to the rolling mode.

[Sogolumbo]

w/W=10 seems to be a good compromise between high success rate and low additional delay.
For very slow signals the roll mode is more useful because it doesn't introduce noticeable delay.
If anybody needs 100% success rate they have to record the signal, there's no way around that.

[Ho-Ro]

This topic is going in a completely different direction, I will move it to the Discussions section and give it a more appropriate name.
Nevertheless it's an interesting theoretical approach that would require a more or less complete restructuring of the firmware and (at least) the low level part of OH6022 to witch from currently used interrupt transfer (fire and forget, hope that the the data will arrive, works good for speed up to 12 or 15 MS/s) to isochronous transfer that uses a fixed amount of the USB capacity. There were experiments 10 years ago done by @rpcope1 as well as some FW modifications that could be used as a (re)starting point. His efforts are documented "down under", mostly in the Hantek6022 monster thread, you should reserve some hours to read it completely.