Author Topic: Hantek - Tekway - DSO hack - get 200MHz bw for free  (Read 1668330 times)

0 Members and 4 Guests are viewing this topic.

Offline A Hellene

  • Frequent Contributor
  • **
  • Posts: 601
  • Country: gr
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #775 on: August 04, 2011, 02:14:10 pm »
Thank you, tinhead!

This is a great idea! Re-balling manually the BGA chip with standard solder balls is the best solution, in order to have a homogeneous and uniform solder quantity on every pad! Without even the need of the special stencil equipment!

All I will have to do is to wait for the local stores to open after their summer break; or, to place an online order. But, something tells me than I may have not yet finished reversing the PCB...

Anyway, your idea is marvelous! Thank you, again, for the solution you gave me!


- George
Hi! This is George; and I am three and a half years old!
(This was one of my latest realisations, now in my early fifties!...)
 

Offline walt

  • Contributor
  • Posts: 42
  • Country: ua
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #776 on: August 07, 2011, 10:08:56 am »
Hi, all!

All the complaints about my English-   to google-translator.
In English I translate all the same it is better   :)

About Hantek noise.
On page 6 "samples | hold offset control" published schemes, it is clear that there is a DAC, switch on 74HC4051, and repeaters on operational amplifiers.
Some circuit have a ripple capacitances, some nothing.

It seems to me that the reason for the strong noise in this part of the scheme. The rest of the analog special crime unnoticed.
My point of view, confirms that the on high-frequency scan, noise is greatly reduced. I.e. with increasing frequency voltage is kept more accurately.

Given that, TLC has a field-effect transistors at the input, input current is low , it begs option to install after the 74- switch   RC-chain in the most critical circuit.
Who has a good analog oscilloscope- could determine which one.

Sincerely, Walt.

P.S.
Or the easiest and cheapest way - much to raise the switching frequency of the reference DAC and switch in firmware.
« Last Edit: August 07, 2011, 10:13:45 am by walt »
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #777 on: August 12, 2011, 04:25:50 pm »
All the complaints about my English-   to google-translator.
In English I translate all the same it is better   :)

:)

About Hantek noise.
On page 6 "samples | hold offset control" published schemes, it is clear that there is a DAC, switch on 74HC4051, and repeaters on operational amplifiers.
Some circuit have a ripple capacitances, some nothing.
right, and actually when you look on PCB these caps are really missing. I have no idea who started first
to same money like that, but when you look on Rigol CA, Rigol E or HanTekway and exact same
position these caps are missing - i don't like it either.

The error is not that high (but it sumirize to other small errors), the potential spikes in analog switch before
switched sample&hold are not that critical, but in a perfect design there would be decoupling can everywhere.

It seems to me that the reason for the strong noise in this part of the scheme. The rest of the analog special crime unnoticed.
My point of view, confirms that the on high-frequency scan, noise is greatly reduced. I.e. with increasing frequency voltage is kept more accurately.
on hw1007 Hantek optimized it a bit

Or the easiest and cheapest way - much to raise the switching frequency of the reference DAC and switch in firmware.
there is nothing we can do as the DAC is controlled by FPGA design


Btw, i'm testing right now two new firmware versions - they not public yet, but i can already tell you the changes:
- FFT is more accurate than before, compared some measurment with my SA and i like it
- Timebase have now fine adjustment (up to 200ps)
- XY bug of course fixed
- CSV export and import works for memeory depth settings
- the actual Sample rate and few other system informations will be displayed in separate infobox

« Last Edit: August 12, 2011, 04:37:06 pm by tinhead »
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline patb

  • Regular Contributor
  • *
  • Posts: 54
  • Country: pl
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #778 on: August 12, 2011, 05:21:18 pm »
Btw, i'm testing right now two new firmware versions - they not public yet, but i can already tell you the changes:
- FFT is more accurate than before, compared some measurment with my SA and i like it
- Timebase have now fine adjustment (up to 200ps)
- XY bug of course fixed
- CSV export and import works for memeory depth settings
- the actual Sample rate and few other system informations will be displayed in separate infobox

Do you know when can we expect it to be released? I assume that this will be official firmware, right?
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #779 on: August 12, 2011, 06:31:17 pm »
Btw, i'm testing right now two new firmware versions - they not public yet, but i can already tell you the changes:
- FFT is more accurate than before, compared some measurment with my SA and i like it
- Timebase have now fine adjustment (up to 200ps)
- XY bug of course fixed
- CSV export and import works for memeory depth settings
- the actual Sample rate and few other system informations will be displayed in separate infobox

Do you know when can we expect it to be released? I assume that this will be official firmware, right?

i assume very soon, there is a small bug in fine timebase when i'm under 40ns/div (higher ranges works perfect),
they checking right now my bug report. And of course that's official firmware versions.


##########################################################################

I'm working on inoffical version too (patched 110531.1, but will switch to latest version when ready and patch it).
Nothing really big but i noticed a bug in FFT/timebase which i don't like.
When you switch to FFT and compare the frequency span with actual sampling rate everything
below 2us/div (or 50MHz span) is ok - the sampling rate is at least twice the span frequency (2x to 4x).

Now when you switch to 800ns/400ns/200ns/80ns/40ns/20ns/8ns/4ns/2ns the span
is higher than twice sampling rate. This means only 8 from 10 division on the screen are within Nyquist,
and these two division on right side are only crap data. And of course when the test signal
is withing these two division on right side you see automaticall tons of aliasing things.
The fix is very simple - i'm increasing the sample rate (or actualy the clock from 100Mhz to 125MHz)
which gives me then in these timebase settings always higher sample rate - exact 2x span freq.

So far everything works, i can switch on/off (unfortunately not automaticaly for only these affected timebase ranges)
- but sometimes the FFT is crashing.  This is not a heat problem (measured - and if i don't move anything works for days).
It is not that easy to fix such things by modifying firmware with hexeditor, the space i can use for additional functions is
splitted to many jump here and there (everywhere where i found some space in spare menu functions).

Sure, the best option would be when Hantek would compile the firmware to do the same. I know why they
not did it in first place - due sampling memory/record length (it is reduced then), but actually when in FFT
this didn'r really matter (the sampled data is still big enough). I asked them to implement a variable
timebase for FFT, they evaluating right now if this is possible.

If not, well then i will have to show them that this can be done by simple switching of clock frequency,
of course just two clocks is not the same as variable clocks for FFT, but at least it is enought to see
in all 10 divisions proper data.

Attached some pictures to show what i mean and how the patched version works.

And yeah, i know, i can always switch to higher range to see the signal properly again with org. firmware, but when you
have harmonics withing these two division you will see also the aliasing - so not a real workaround.
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #780 on: August 16, 2011, 12:32:44 pm »
As already posted in Owon thread

https://www.eevblog.com/forum/index.php?topic=4412.msg59464;topicseen#msg59464

here some wfrm/s values from Hantek/Tekway values (fw 110531.1) - note these values might vary
a bit from what on your DSO when you have different firmware version, e.g. the latest beta fw i have (110807.0)
is doing always 100 wfrm/s while in FFT mode (which is still accteptable because the accuracy of FFT has been improved)

You can see these values over UART, since some time the firmware is measuring wfrm/s and showing results
every 10s, actually really interessting feature, most manufacturer are hiding such things and
telling only the max. rate.

(sine, half screen Vpp, default DSO settings, 4k memory depth)
2ns/div      - 1350 wfrm/s (100MHz test signal)
20ns/div    - 1820 wfrm/s (10MHz test signal)
200ns/div  - 1450 wfrm/s (1MHz test signal)
2us/div      - 2460 wfrm/s (100kHz test signal)
20us/div    - 2385 wfrm/s (10kHz test signal)
200us/div  - 1000 wfrm/s (1kHz test signal)
2ms/div     - 166 wfrm/s (100Hz test signal)
20ms/div   - 20 wrfm/s (10Hz test signal)


(sine, half screen Vpp, default DSO settings, dots instead of vectors, 4k memory depth)
2ns/div      - 1480 wfrm/s (100MHz test signal)
20ns/div    - 2100 wfrm/s (10MHz test signal)
200ns/div  - 1700 wfrm/s (1MHz test signal)
2us/div      - 2740 wfrm/s (100kHz test signal)
20us/div    - 2600 wfrm/s (10kHz test signal)
200us/div  - 1100 wfrm/s (1kHz test signal)
2ms/div     - 168 wfrm/s (100Hz test signal)
20ms/div   - 20 wrfm/s (10Hz test signal)


(sine, half screen Vpp, default DSO settings, 40k memory depth)
2ns/div      - 432 wfrm/s (100MHz test signal)
20ns/div    - 435 wfrm/s (10MHz test signal)
200ns/div  - 440 wfrm/s (1MHz test signal)
2us/div      - 405 wfrm/s (100kHz test signal)
20us/div    - 295 wfrm/s (10kHz test signal)
200us/div  - 280 wfrm/s (1kHz test signal)
2ms/div     - 135 wfrm/s (100Hz test signal)
20ms/div   - 20 wrfm/s (10Hz test signal)


(FFT full screen - hanning window, sine half span freqency when possible - or max DSO frequency,
half screen Vpp, default DSO settings)
2ns/div      - 222 wfrm/s
20ns/div    - 268 wfrm/s
200ns/div  - 246 wfrm/s
2us/div      - 274 wfrm/s
20us/div    - 275 wfrm/s
200us/div  - 275 wfrm/s
2ms/div     - 150 wfrm/s
20ms/div   - 150 wrfm/s


These values above are of course for one channel measurment, edge trigger measurments.

Interessting is the fact that in alternate trigger mode (both channels half screen 100kHz sine, 2us/div)
in the best case scenario Hantek/Tekway is still doing 2430 wfrm/s, which is really good.

If you don't know what wfrm/s are and "how to eat them" look here:
http://cp.literature.agilent.com/litweb/pdf/5989-7885EN.pdf


I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #781 on: August 16, 2011, 04:33:28 pm »
This discussion is continued from Owon SDS7102 review thread... but it makes more sense here.

Well, tinhead, according to Agilent's formula, (at least some of) your wfrms/s are provably incorrect.

Their stated formula:
% DT = Scope’s dead-time percentage
= 100 x [(1/U) – W]/(1/U)
= 100 x (1 – UW)
where
U = Scope’s measured update rate
and
W = Display acquisition window = Timebase setting x number of divisions (which is 19 on full-screen Hantek - probably 20 inside firmware - but I'll use 19)

For example, if I take your specification: 20ms/div = 20 wrfm/s;   that would mean:
100 x (1 - (20*0.38))
And the Hantek has a dead time at 20ms of:  -660%??
Or, with 16 divisions (menu displayed on Hantek):  -540%?

Another example, your spec: 200us/div = 1000 wfrm/s;  would mean:
100 x (1 - (1000*0.0038))
And the Hantek has a dead time at 200us of:  -280%??
Or, with 16 divisions (menu displayed on Hantek):  -220%?

You can see, given Agilent's formula, that your wfrms/s specs are too high.  I have to surmise that either your figures or Agilent's are incorrect; that's why I think your figures need to be /10.
« Last Edit: August 16, 2011, 05:09:28 pm by marmad »
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3071
  • Country: cn
  • Born with DLL21 in hand
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #782 on: August 16, 2011, 05:19:31 pm »
with 4k capture memory (without dead time).
No matter how many divs is display. It have not so much to do with this. Display is display and capture memory is capture memory imho, display (or display and display memory sometimes)  is only more or less processed "window" to capture memoy adjusted related to place where is trig. (and becouse triggerjitter some scopes also  may highly proces this adjustment.

20ms/div 4k mem samplerate is 10ksa/s.
IF memory is exactly 4000 (for making this simple)
we start capturing. capturing is ready and memory full after 0.4s. If dead time is zero and after zero time start new capturing it make full memory captures 2.5 times per second. So wfms captured/s is 2.5. (In practice it is only possible with continuous "ring memory" untriggered capturing. (yes ringmem capturing and even some kind of oscilloscope is possible of course if we have method to read this memory independent of data transfer to memory.) If now dead time is example 0.1s (it is not) we get exactly 2wfms/s. (exept not exactly... becouse signal and trig and how designer have made this pretrig buffering etc. This is why there read, use enough frequency for signal if measure wfms/s rate.

This is not exactly how some real scope work, only for some kind of poor language imagination.

But this is only if we have "single" ADC what pruce 8 bit datastream and capture mem is 8bit wide single 4000byte memory and all sampled data is stored to memory.

What happends then example 8ns/div = 1Gs/s. With zero dead time.  Filling memory takes 4us. So if zero dead time it means 250000 wfms/s. But of course here dead time take whole show.  IF real wfms/s is now 2500wfms/s it means that ~99% of time scope is blind. (if forget many things and make thinking simple)

Why capture more than display can refresh. This is DPO. Far away from display is "digital phosphor". There is processed "picture" about captured waveforms together. There need be also some way to show what image pixel have more weight than other. There need be pixel intensity (or sometimes color) control realted to captured waveforms. Then it is useful.
Many think that DPO mean "digital display" and TFT or LCD or these make DPO. DPO may also do with old analog picture tube, raster or vector monitor (in practice and in theory but not very clever today but possible.  Intelligent captured data processing make DPO, not TFT display contra tube. Now with DPO display may refresh example 25 times per second but you can see 5000 or more captured waveforms. (just as good old analog scope - oh but yes - better becouse phosphor have limited writing speed and limited and fixed intensity decay time)
« Last Edit: August 16, 2011, 05:50:41 pm by rf-loop »
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #783 on: August 16, 2011, 05:29:09 pm »
No matter how many divs is display. It have not so much to do with this.

Of course it does (at slower rates), because the scope bases the sampling rate or sampling depth on this.  Sampling rate = Sample depth * (1 / (sec/div * divisions)) - or, inversely - Sample depth = Sample rate / (1 / (sec/div * divisions).  Of course, this follows only up to the maximum sampling rate or depth.

Quote
is only more or less processed "window"

The "window" is sec/div * divisions (or a little more.. see below)

BTW, the Owon display screen always shows 15.2 divisions of the timebase on it, but it ALWAYS calculates sampling rate and creates waveform records (captures) based on 20 divisions - so 4.8 divisions are included in it's calculations, but not visible on screen unless stopped.
« Last Edit: August 16, 2011, 07:12:27 pm by marmad »
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3071
  • Country: cn
  • Born with DLL21 in hand
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #784 on: August 18, 2011, 05:09:23 pm »
I'm now very confused with these wfms/s.

I do not know what is going on in scope. (Hantek)

What is meaningfull and important is: what we can see.

Ok, becouse my eyes are slow...

I set fixed 50 frames/s udate rate for display.

Then I insert fast sweeping signal so that it can imagine changes in SUT. (Signal under test)

Then becouse my eyes are slow I want look how many capured waveforms I can see in one TFT frame (1/50s)

First, sweeper is set to linear freq sweep. (small amount) Pulse. So that I can calculate hom many falling edges I can see becouse trig is on the rising edge.

I set camera so fast shutter speed that sure there is only one frame.

Mostly I can see 4 falling edges. Sometimes 3, sometimes 5, mostly 4. I can not tell what are more, 3 or 5. With this accuracy I can only tell that average is more close 4 than 3 or 5.
50 frames/sec and average 4 captured waveforms. This is around 200 captured and displayed waveforms/sec.
Also I can see that positions of falling edges vary very highly and also time between these are nearly as random (maybe there influence many things.. about processing chips busy times and also trig is not of course synchronised with capturing so sometimes it need wait more and sometimes less trigpoint and becouse freg linearly change and also forward and backward sweep is different... etc... so. But still, how many falling edges in one frame. This is markable in my opinion.

Scope settings.
4k
dots
menu off
200ns/div
1 channel in use.
signal 100kHz - 120kHz linear sweeping square and sweep time around 1ms
(this time and place I have only one old analog Wavetek sweeper for quick test.)

Scope adjusted so that these falling edges are around center of screen.

Pictures I take with 1/200s shutter. (only rare there is just TFT picture update but no matter becouse I do not look these.
Then I take many fast continuous "burst" of 12 pics. Nearly always 4 and some times 3 sometimes 5, and even 6 but very rare.

Also I try with 20ns/div and around 1MHz and narrow sweep. Around same result with camera.

(becouse eye is more slow, eye can imagine more falling edges..becouse eye "remember" many frames with 50f/s).

Only conclusion what I can tell now is:
This is "finding" is  something what need analyze and think more. (yes I have see it also before but jump over it becouse before it was not so meaningfull to me)

Where is whole truth - maybe somewhere. Maybe some find it.
But I think it is NOT now there where scope itself show wfms/s data.

« Last Edit: August 18, 2011, 05:29:30 pm by rf-loop »
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #785 on: August 18, 2011, 09:28:12 pm »
Nice chart from .pdf link posted by rfloop - www2.rohde-schwarz.com/file/1ER02_1e.pdf
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3071
  • Country: cn
  • Born with DLL21 in hand
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #786 on: August 18, 2011, 09:59:37 pm »
Maybe some think I do not know how digital scopes overall work becouse I use old fashion "oscilloscope camera method" haha.
These simple explanations about "how stuff work" can read everywhere. Also in this Aglent paper. But there is problem to use it directly becouse it is partially adjusted for Agilent scope for selling purpose..
Owon (afaik) and Hantek have not this Agilent InfiniiVision special systems.
"Memory depth was optimized at
each timebase range by selecting
the minimum amount of acquisition
memory
that would also provide the
maximum available sample rate.
Note that with Agilent’s MegaZoom
technology, this is automatic
."

Now case is to find WHAT is Hantek (or Owon) real wfms/s.

This my very very simple camera test show only that something is wrong and not as we have thinked before Hantek. What is wrong, I do not yet know. If one display screen with 1/50s update rate draw only around 4 separate captures it can not be 2500 or 1500wfms/s. Becouse human eye is not so fast I use camera for proof it. Becouse in Hantek we have not good HW method for this becouse there is not "true" trigout (and not any kind of trigout).
Scope UART raport calculated wfms every 10 second. This is NOT wfms/s value. (maybe it is nearly right using some time settings (samplerate) but I did not find it and mainly it show something wrong IF think that this number value is captured wfms/s. It simply can not be, but this is only what I can now think.  Even if I put very low speed so that I can count with clock and eyes how many times scope make waveform. This number value is totally wrong.

So, before someone proof it exactly and also explain his proofment theory and with measurement instead of calculus with imagined variables and constants, I do not believe ~2500wfms/s anymore.

Or if it do it "hidden", what use is it for if it can not show to user.

I have look this question with DSO5102B  HW10070 and FW110806

Note: Also how ever measure it, there need always use enough speed signal in scope input.

There is small difference with display settings "auto" or fixed 50frames/s. But with camera test (just becouse camera is more fast than eyes it can image just one screen frame and frame time is now known. With auto I do not know framerate.

Pictures clearly show that there is not more than 4-5 waveforms  in memory to display. This is reason why I use small amount of freg sweeped square and fast enough base freq and fast enough sweeptime. So that I can separate every capture. It can not drav same pixels but only once with this settings..  Who think that my camera can filter something out from picture? There can not see more waveforms! But yes IF it is example max 300wfms/s it is very good still becouse my old Agilent High-End DSO can not more than about 5-10 wfms/s. (I do not mainly use Hantek, I use HP and Tektronix if I need scope. But these old work horses can not easy store pic to USB so sometimes I use also Hant.)

Scope itself give information about wfms rate. This information can not be right or what we have thinked.

Ps. R&S paper (linked before) is lot of better than Agilent this paper.

With 4ns/div (1Gsa/s 4k) ... Hantek Blind time percent is maybe more than 99,9% But it is not so bad.. it is not 99.99999%


« Last Edit: August 18, 2011, 10:15:13 pm by rf-loop »
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3071
  • Country: cn
  • Born with DLL21 in hand
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #787 on: August 19, 2011, 08:59:32 am »


What I wanted to explain, is that having a large wvfrm/s figure is only useful not to miss an event, if you don't have a "digital phosphor" display.


This is not only wfms/s question. It is still also blind time persentage question.
Propability to find as fast as possible some rare single event is highly related to capturetime and blind time ratio.  capturetime is many times related to our signal what we are looking. Signal is what it is and related to this  we need set t/div (somehow).  So our signal under testing is master and this can not change. Maybe in so,e special scope is some special acquiring mode and scope is clever enough to optimize capture time minimum and also there need not be high blind area out of display if we want look with eyes. (so for this purpose it is also good that there is posibility to set display window just as capturememory lenght. What can do for rise propability to find rare single event, example some glitch in one pulse.  We need reduce t/div so that we still have enough resolution and samplerate. This give more to visible becouse scope have after every capture some blind time what we can not forget. Of course we do all what can do for reduce blind time. All extra stuff off, all measurements, cursors, pixel connections etc off. After then there is blind time what is and this we can not reduce more by user settings.  Blind time is example very easy so that 95% is blind and 5% "is eyes open" what is good value if use fast horizontal speed and most low capture memory for "speeding". Some times it may be that blind time is 99,99% and 0.01% scope is "eyes open" if speed is high and even if wfms/s is quite high.

In this point it start... you rise price to around 1-2kUSD... oh what bullshit still (exept that Agilent have good offer with X2000 series infiniivisoon).. you rise it to 10kUSD--- well, something, maybe you just get cheapest possible R&S includind some few useful options... you rise it 100kUSD. Ok you may have extremely short blind time, extremely fast capturing maybe tens of GSa/s and superfast capturing memory and superfast segmented capture and extremely high speed parallel processing etc.

If wfms/s is slow but blind time percent is also low... well, Using human intelligence you can still do lot of. Even if wfms/s rate is 10 or 100 or 1000Wfms/s.

And always need remember, hunting rare single events in signal stream. It is only one thing. Are you always sure that in all cases oscolloscope is right tool. ;)

« Last Edit: August 19, 2011, 09:03:21 am by rf-loop »
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #788 on: August 19, 2011, 09:15:01 am »
A few points:

1) Both the Agilent paper and the R&S paper were written by companies trying to sell their products, so both need to be taken with a grain of salt.  But both papers have basically the same formula (starting with different variables) for calculating blind-time (I prefer the word blind to dead - since dead implies the scope is doing nothing else - but blind just means it can't see, but it's still working).  In the Agilent formula, they assume you already know the total waveform update rate at a sec/div setting, and calculate from that.  For example, with the Tek TDS2000, 100 wfrms/s at 1us/div, the formula is 100 x (1 - (100 * 0.0001)) = a blind-time percentage of 99.90%.  In the R&S formula, they assume you know a single acquisition cycle time and blind-time, and calculate from there.  But you would end up with the same final ratio.

2) If the Hantek is reporting a wfrms/s rate after every 10 seconds, assume that is the total rate of the last 10 seconds.  Tinheads figures above, divided by 10, are very much in line with the figures in the Agilent literature for other scopes - and much more expensive scopes for that matter.  Even with those figures divided by 10, they are VERY respectable rates for a DSO of this price range.

3) The Owon SDS wfrms/s rate is between ~1-25.  This has been confirmed.  So you can see that the Hantek rates (divided by 10) are very good (likely best in class).

4) Given all of this information, I find that the figure quoted by tinhead in the first post of this thread of the Rigol DS1052E achieving 2000 wfrms/s as highly unlikely.  Does anyone know where this figure has originated? Obviously the tiny screen of the Rigol allows faster updating (and less acquisition time), but I still think the figure seems high.

5) If it's not obvious by now, the wfrms/s rate is very much related to screen size.  Having to capture the minimum amount of data needed to cover the horizontal real estate - plus refreshing big LCDs - takes a lot of time - and this is obvious due to the fact that very expensive scopes STILL have the small screen sizes (even though large LCD panels are cheap these days).  The new Agilent series has less pixels to refresh than either the Owon SDS line or the Hantek: it's active waveform area is 640x400 - compared to 760x500 on the Owon SDS - and 770x420 on the Hantek (no menu displayed).
« Last Edit: August 23, 2011, 10:02:50 am by marmad »
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3071
  • Country: cn
  • Born with DLL21 in hand
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #789 on: August 19, 2011, 10:38:53 am »
Only some fast comment with sidehand as I'm running.

Hantek do NOT tell wfms/s!

This is exactly what UART0  send out (always):

(copypasted directly from CryptoTerm 1.5 screen)

Quote
(049)mem valid cnt=545..time 10s wave frames = 1150...
(050)mem valid cnt=546..time 10s wave frames = 1177...
(051)mem valid cnt=543..time 10s wave frames = 1163...
(052)mem valid cnt=541..time 10s wave frames = 1178...
(053)mem valid cnt=546..time 10s wave frames = 839...
(054)mem valid cnt=546..time 10s wave frames = 232...
(055)mem valid cnt=545..time 10s wave frames = 231...
(056)mem valid cnt=545..time 10s wave frames = 232...

49 - 52 scope 200ns/div display 50 frames/s
only dots, no any menu display, persist auto.
memory 4k, acq realtime, mode normal
trig auto, rising
Signal, sine  10.0000000MHz input

After 52  I connect signal off in random time compared to counting.
So 53 is not meaningful now and it can forget.
54-56 agen ok and tell how many waveforms are counted. (note, NO signal, scope mode Autotrig, If trig is normal and it do not trig becouse no signal  then count is: ((236)mem valid cnt=546..time 10s wave frames = 0...)

No one know how it count and what it count and how reliable is this counting becouse this is not documented feature afaik (becouse UART is NOT for end user!)
HW10070;FW110806 (set so that dso5062B is as 5102B)

Also: This is not inconsistent with my trivial simple photographic method what I only want use to show that there is something wrong in hypothesis about 2.5kwfms/s. (After then when I woke to doubt it,  after Owon thread rise this question)
« Last Edit: August 19, 2011, 11:00:00 am by rf-loop »
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline grenert

  • Frequent Contributor
  • **
  • Posts: 446
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #790 on: August 19, 2011, 12:10:05 pm »
4) Given all of this information, I find that the figure quoted by tinhead in the first post of this thread of the Rigol DS1052E achieving 2000 wfrms/s as highly unlikely.  Does anyone know where this figure has originated? Obviously the tiny screen of the Rigol allows faster updating (and less acquisition time), but I still think the figure seems high.
Based on the findings of the owner of an Agilent 1000 series scope, it appears that the 1000 series is equivalent to the Rigol 1000B series, which looks to be much higher in their range than the DS1052E. 
http://mightyohm.com/blog/2009/11/agilent-dso1000-firmware-update-confirms-rigol-connection/
http://www.rigolna.com/products/digital-oscilloscopes/

Agilent's datasheet for the 1000 series lists a waveform update rate of 400 wfrms/s.
http://www.home.agilent.com/agilent/redirector.jspx?action=ref&lc=eng&cc=US&nfr=-34250.0&ckey=1691876&cname=AGILENT_EDITORIAL

So it would seem unlikely that the bottom-of-the-line Rigol is five times faster.
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #791 on: August 19, 2011, 12:22:24 pm »
4) Given all of this information, I find that the figure quoted by tinhead in the first post of this thread of the Rigol DS1052E achieving 2000 wfrms/s as highly unlikely.  Does anyone know where this figure has originated? Obviously the tiny screen of the Rigol allows faster updating (and less acquisition time), but I still think the figure seems high.

these scopes are originaly designed by Tekway:

http://www.tekwayins.net/views2.asp?newsid=205&sess=2

from any king of prerelease prospects which i got before the scope was ready (see picture)
and of course form usr manual where the 2000wfrm/s has been never corrected to 2500 like on wabpage.
Hantek in principle copied the world formated user manual (and replaced logos/pictures).
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #792 on: August 19, 2011, 12:39:23 pm »
Ahh... and I see you got the Rigol 2000 wfrms/s spec from the Rigol website for the CA series: http://www.rigolna.com/products/digital-oscilloscopes/ds1000ca/

I wish all manufacturers would just show acquisition rates on the LCD - along with sampling speeds - so that you could use that information to better tune your DSO settings for the particular way you're using it at any given time.  Sometimes wfrms/s is unimportant to what you're doing - and you'd rather use the time for other pre/post-processing.
« Last Edit: August 19, 2011, 01:17:16 pm by marmad »
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #793 on: August 19, 2011, 01:17:09 pm »
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 :P)

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.
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #794 on: August 19, 2011, 02:01:19 pm »
@tinhead - thanks for all your tests, the detailed response, and all of the info.  It will take some time to digest  :o
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3071
  • Country: cn
  • Born with DLL21 in hand
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #795 on: August 19, 2011, 02:57:58 pm »
@tinhead

Note that UART out do not show wfrm/s
Look agen what UART exactly send out!
I can not find any wfrm/s.

"time 10s wave frames = nnnn"

this is what Hantek tell.

Btw, what is meaning of waveforms what can not see or settled. How you set 10div capture.

Only captured waveforms what are really usable and/or also  they can relly see or can use for some useful things are meaningfull. If there are behind processing (before processing) some captured waveforms what can not see or what do not affect anything... they are just to garbage collection.  Also poersonally I'm not interest any kind of calculated unreal speeds. Only what moves me is what can really use in practice and they are meaningfull.

 If I want know what is wfrm/s speed what I can see on the "tube" it is meaningful as long as I want inspect something with my eyes on the "tube".  What my eyes can see it can also measure after find good method.  Now I have seen around 200-300 wfrm/s. Nothing more yet.
Stop capture, also there is ONLY one capture. Where are these others what need be in "digital phosphor" memory. Why they disappear every time I stop capturing. ;) So this DPO "effect" is done only for human eyes as scope is running.



If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #796 on: August 19, 2011, 05:04:16 pm »
@tinhead

Note that UART out do not show wfrm/s
Look agen what UART exactly send out!
I can not find any wfrm/s.

"time 10s wave frames = nnnn"

do not expect from the developer to spell that properly, waveforms or waveframes look similar,
there are any other translation mistakes. Imagine when if the original engineer said
"waveframes" and someone later translated it into waveforms ... this could be also be an
explanation ?

No i don't think so, because the previous Tekway model is capable of
398 wfrm/s (i see event every 2:45 seconds with testing with the code above) and they
promised up to 400 wfrm/s,s everything ok.

But of course the firmware is very simple made and there is a big difference to run simple
firmware with less memeory (2.5kpoints) on very similar hardware (ok, 33% slower but similar platfrom)
as complex firmware, with many features, larger samplepoint memory on only only 50% faster hardware,
so it might happens that waveframes are there but UI thread is not able to follow the sun
and is skipping every 5th frame.

Anyway, all that are observation/measurments and speculations - we have to wait on Hantek statement.

?????????2500???????????????


Btw, what is meaning of waveforms what can not see or settled. How you set 10div capture.

i can't, but there is a change in postprocessed waveframes when you switch from 20 to 16div (or vice versa),
the SoC is already running almost on limit so you can assume when we could change to 10divs the
postprocessing/capture thread would be able to use more CPU time just because the UI thread is
using less time.

Only captured waveforms what are really usable and/or also  they can relly see or can use for some useful things are meaningfull. If there are behind processing (before processing) some captured waveforms what can not see or what do not affect anything... they are just to garbage collection.  Also poersonally I'm not interest any kind of calculated unreal speeds. Only what moves me is what can really use in practice and they are meaningfull.

actually all they have to do is to store the postprocessed waveframes (like persistency is doing in UI thread),
compare and write the "event frequency bit" to it - then the UI thread can show the result.
From a cpu time point of view not that big change (no matter where you store), this would be then fix
the skipping issues (of course the reserved memory need to be also moved from UI to capture/postprocessing thread)
and improve the DPO effect, see below

Stop capture, also there is ONLY one capture. Where are these others what need be in "digital phosphor" memory. Why they disappear every time I stop capturing. ;) So this DPO "effect" is done only for human eyes as scope is running.

This will also bring back the digital phoshor effect back - i rememery one of the eraly firmware version was doing this
really nice, no idea why they moved it into UI thread, this is now only while in run mode  there but gone in
stop mode.

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3071
  • Country: cn
  • Born with DLL21 in hand
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #797 on: August 19, 2011, 06:03:14 pm »
When I put trig to AC...

"time 10s wave frames = nnnn"

nnnn  = ~500 (often vary between 496 - 499.)

(Conclusion removed because of too few observations as well as information about what is really going on a scope.)



Also it is just logical to explain all or some what I have seen by my eyes using different signals  so that it tell how many different captures I can see same time on the screen. This all is very close so that 10s counting need simply divide by ten and you have value for one second. But this is not whole truth becouse with all t/div settings it is not. It looks like some settings divide by 10 is not right and it can see that acquire cycle is more fast. So, this all is so muddy.


I hope I'm wrong. But still if it is truth, it is not very bad. Exept that blind time is long.
I do not understand area after 20ns/div. (8,4,2) what happends there?

I'm also waiting you get info from Hantek but strongly I afraid you do not get truth from Hantek. This FW is more and more after all  "repairs" growed to class: "spaghetti" maybe FW developing is more and more then as: "a desperate attempt by trial and error method" by Hantek ... also this I really hope that I'm wrong.

Do you remember what version it works.. (multiple captures on the screen after stop (without persistence))

Disclaimer:
This all seems so illogical, or at least confusing that it is best that does not now hold any definite statement until more information is obtained by examining and testing the scope in more detail. Something important information is maybe missing, and maybe that's why it seems crazy.
So all opinions what I have write about this wfrm/s case is inaccurate and not truth. Only truth are settings signals and results what I have tell.
On this basis, you can not expect anything other than the ones mentioned in the findings. Conclusions can not take place until a broader and more detailed investigations.


« Last Edit: August 19, 2011, 08:26:12 pm by rf-loop »
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #798 on: August 19, 2011, 09:24:29 pm »
... and everything started because i posted something which was not supposed for public eyes :)

In principle nobody will ever check or doubt on what in user manual or manufacturer website,
especially not for more or less no-name manufacturer.

I personaly would even accept the waveframe counter / 10 as waveform, but it does not
match too (1100-1300 waveframes / 10 are still 110/130 wfrm/s and i can see/measure 200-230)
Now these 500 when you set to line trigger are even better, /10 looks good but also /5 ...

i wish i would have the HexRays ARM decompiler, analyzing ARM assembler code is taking so much time.
On the other side as you said, the firmware is up to specific level good written (probably this is the part written by "rgj"),
where you can clearly see variables, function names, what so ever - and then on many places a piece of
junk code - mostly all these repairs/things coded in last 12 months are weird, really weird.

Btw, the translation issue hehe, imagine discussion engineer <-> marketing, or even better
"rgj"<->"engineer in china"<->markeiting.

When you look on the SVN IP address from which the "DSO2 design" is coming you will see it is not China,
it is DSL address in Mexico and i really doubt the developer was on vacation and setup during vacation
SVN to allow ppl on Tekway site to get the code - and this (when i check all fw's) at least twice in 2yrs.
« Last Edit: May 27, 2014, 11:00:35 am by tinhead »
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline walt

  • Contributor
  • Posts: 42
  • Country: ua
Re: Hantek - Tekway - DSO hack - get 200MHz bw for free
« Reply #799 on: August 20, 2011, 06:56:50 am »
Hi,tinhead!
Can  see the raw data from the ADC via the console?

Something I have some suspicions that the noise is the result of dithering or mathematical artifact.

Because at the ADC input, with shorted at the input on BNC, voltage noise is less than 0.25 bits(<1mV). Reducing supply ripple ADC twice does not lead to any result.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf