i haven't answered these questions about wfrm/s and Agilent equation because i was waiting for an answer from
Hantek, however they still looking/validating my observations and measurments, so still no answer to that.
But here my temp. answer :In principle the Agilent equation is correct, but it will not work for any scope with
with DPO-like/virtual-screen/x-zoom window - meaning with more than 10div displayed per window.
Actually everybody is making the divs much wider to get always 10 totally, why Tekway/Owon/Hameg
decided to do it in a different way? i don't know. However, we can make it easy and calculate
wfrm/s per 10DIVs to be able to use Agilent equation.
I was about to answer like above immediately after concerns from marmad,
with a equation to calculate the wfrm/s for 10DIV but then i recognized something is strange
with these results. I got over 3200 wfrm/s for 2us/div and i'm sure HanTekway will not miss to tell
people that the hardware is capable of 3000 wfrm/s - so the equation must be wrong (which is not)
or the scope is showing bullshit in 2us/div range.
On a true DPO/virtual-screen/x-zoom window scope you can show/hide menu and the wfrm/s should remains
the same, well HanTekway is only DPO-like, so you have of course differences (especialy because
the scope is really switching from 16 to 20div) - which is good for calculation.
Based on that we can then calculate the estimated wfrm/s increase per div :
((wfrm/s menu on - wfrm/s full screen) / wfrm/s full screen ) / 4 = that's the wfrm/s increase per 1div
then multiplicated by 10 and with (wfrm/s full screen)
and finally add the (wfrm/s full screen).
So based on that the example of 20ns/div:
20div - 1900 wfrm/s
16div - 2100 wfrm/s
diff 200 wfrm/s by changing 4 div, so 50 per div = 500 wfrm/s extra when the screen would
be 10div wide = 1900 + 500 =2400wfrm/s.
From what Tekway said just before they started to ship first models these scopes can do up to 2500wfrm/s
in 20ns/div - this is the fastest timebase range for the firmware (just before the firmware is switching to 1GSs
which costs time , and the shortest timebase for 800MSs), so comparing the equation for wfrm/s of 10DIV
to the announced 2500 wfrm/s we can "prove" that the equation is correct.
So i wrote down all values (20div and 16div) for all timebase ranges and from 2ns to 800ns everything looks good,
but then 40s/div to 2us/div are much too high. There is a big jump (from 3150wfrm/s by 2us/div to 1781wfrms by 800us/div)
When you look on my previously posted results this peak is also visible.
The explanation seems to be very easy, the wfrm/s calculation is wrong in the firmware, the developer forgot to change
this function when switching from 1:2:5 sample rate ration (40s/div to 2us/div) to 2:4:8 (800ns/div to 2ns/div) sample rate ratio.
It is of course hard to trace the ARM asm code, but something like /4 works seems to be close to what i expect.
And of course no surprise, for long timebase settings there is somewhere a point where you will
get always a zero, and actually when on 20/8/4ms/div there is no increase when we change 16 to 20div
screen (and calculation with these correction from above shows 0)
The last "usefull" rate (calculated as above) is by 2ms/div and giving me ~44wfrm/s (for 10div), so 12% dead time.
Looking closer on the wfrm/s procedure i found out that of course in 40s/div to 40ms/div the procedure
is getting an overflow and is showing wfrm/s values which Agilent can only dream of ... so don't
take these values seriously.
So that's about the values displayedover UART and posted by me before.
Now pure visually, HanTekway seems to be fast (yes your/my eyes can imagine things).
I do have here two other DSOs, one with 400 wfrm/s and TDS2012 with 60-100 wfrm/s, from
a pure visual observation HanTekway is faster. At time of my decision to chose Tekway I did compared
with Rigol too, and also Rigol E was slower - today we know Rigol E have 800 wfrm/s (you remember
maybe Dave's video, 50000events, after ~60second first event was shown on Rigol).
I can setup my Yokogawa FG to create glitches, but this works to measure the shortest glitch size
with a specific frequency and not that god for pure wfrm/s calculations (as there are some random glitches too).
For wfrm/s measurment all i can test with my Yokogawa is 1ms (2step) sweep between two waves,
so this is good up to 2000wfrm/s. With such setup i can see difference when changing the sweep time,
pure visually a big difference on all 3 scopes - when a scope is on limit it starts blanking one or the other waves.
HanTekway is blanking sometimes the one or the other wave when running on 1ms/2step, so 2000 wfrm/s.
However such measurment is having continously the gltich (every second wave is gltich), so DPO-like functionality
might help to think "it is capturing all of them".
For more random glitch there is a different way to do it too , take a µC and program a simple counter with glitch,
here code for Atmega8 running on 8MHz:
int main(void) {
DDRB |= (1<<PB0);
unsigned int i = 0;
while(1) {
if(i != 0) {
PORTB &= ~(1<<PB0);
_delay_us(10);
PORTB |= (1<<PB0);
_delay_us(10);
PORTB &= ~(1<<PB0);
}
else {
PORTB &= ~(1<<PB0);
_delay_us(15);
PORTB |= (1<<PB0);
_delay_us(5);
PORTB &= ~(1<<PB0);
}
i++;
}
}
This will generate after 65535 cycles a glitch, on a analog scope you will see something about ~1s the glitch.
With this code i have to wait between 5:30min and 6:00 min - meaning HanTekway have only about 200 wfrm/s.
wtf ? yes, 200 wfrm/s in 800ns/div timeabe setting (as i know that the calculated values for everything that bigger
than 800ns/div i'm not measured in these ranges anymore).
Note - Full persistency is slowing down the firmware (you can see over uart the wfrm/s dropping from 2000+ to 1100-1300 wfrm/s).
I was thinking first that maybe this is trigger issue, but setting to trigger on pulse the scope
is refreshing the screen every 1s so it can definitely catch these glitches.
Then i was thinking, maybe Hantek as they bought Tekway and rewrote firmware, maybe they
did something wrong, so i installed the oldes Tekway firmware i have (which was installed on my
early device - that's the firmware which was specified for 2500 wfrm/s by Tekway)- and well,
i have to wait 4:45 minutes to see an event - so ~230 wfrm/s.
So i spend the whole day (yesterday) building different glitch generators (with different rates)
and of course murphy's law catched me - depends on how many glitches there the HanTekway
is capable to catch them fast or really slow.
Best scenario was with 20000wfrm/s gen, worst with 5000 wfrm/s gen - nothing capturd after 20 minutes

)
This gives me agan to think about the firmware. The counter we can see over UART is
based on postprocessed frames (so sampled, stored, filtered - whatever apply, and shifted to memory from
where they will get displayed). However, there are separate thread doing capture/postprocessing,
statistics and display refresh.
So maybe here is the problem, the DSO is postprocessnig frames with 2500 wfrm/s maximal, but then
the UI thread is skipping result, then of course persistency (or cam pictures) will shows the
true wfrm/s divided by skip-error.
Now when you we know that persistency is slowing down 800ns/div range to 1100-1300 wfrm/s and that
measured and calculated (via picture shot) wfrm/s is about 5 time lower, it's easy to answer
that these DSOs are skipping every 5th wave while displaying. This expalin now the pure visual observation
as then has been done with fastest screen refresh and no persistency - a 500wfrm/s refreshed with 50/s
on screen looks "faster" than a 400wfrm/s or 100 wfrm/s DSO or than whatever Rigol really have - with this
code above you can see on Agilent DSO3000 400wfrm/s, where Tektronix tried to measure it (see picture) and got #
no real result - probably because of same issues - when the gltich is always in the skip window
(display skip or postprocessing blind time) you will not see any results.
Now, let's hope Hantek will have an explanation for that - when the DSO is really skipping 5th wave on display
wel then they have to correct the user manual and webpage - and when all these observations and measurment are
bullshit then they have to provide a proper measurment - and of course even if the UART displayed
value is not for everybody eyes, an answer to the 1:2:5 and 2:4:8 error (so results for 40s-2us/div timebase).
If you have any comments or questions to my posting, please give me some time : i spend last days on reversing/interpreting
the ARM code, building generators, measuring values - now i need some time for my family.