no, i'm not protecting HanTekway in any case, they still have, let me think, 10+ bug for sure,
but let's compare a bit to Owon to see the MAJOR hadrwae difference (and this was already said multiple times here
and in Tekway thread).
Yes but only on 1K.
no, it's not like that, you have to understand the hardware first.
Generally I recommend www2.rohde-schwarz.com/file/1ER02_1e.pdf
HanTekway when sampling with 1GSs and 4k buffer is able to capture 2500wfrm/s (4us capture time).
These 2500wfrm/s are back calculated relative to 10DIV, which is in real live 2100 when 16DIV visible and
1900wfrm/s when 20DIV visible.
While capturing with 40k buffer the sample rate is 400MSs or 500MSs (which depends on hw model version),
when you take the latest model this give us 80us capture time.
The relation between active acquisition time and fixed(blind) time is not fixed to screen refresh rate (which is the case for Owon),
it is like on every other DSO an dynamic value. As long we do not change the setup (e.g. by adding an extra FFT measure or what
so ever affecting postprocessing - even timebase!) while sampling with different sample depth the ratio change proportional to active
acquisiton time. This mean when sampling witk 40k buffer and 500MSs you can assume that the 80us need to be divided by
known value 4us (from which we know its equal to 2500wfrm/s). This give us factor 20 ... now divide the 2500 by 20 and you
will get 125 wfrm/s per 10DIV (real live for full 20DIV screen 95 wfrm/s) which is the value for 20ns/DIV and 40k depth single channel.
When you do the same with 1Mpoint, this is 2ms capture time and 500 times slower than when with 4k, give us 5 wfrm/s
per 10DIV, real live worst case value is then 3.8wfrm/s. This seems to be what visually observed by others on these DSOs.
So what is wrong with Owon? Well, they decided to made the fixed (blind)time fixed to somewhat 25ms - no matter what memory
depth or sampling rate. When the depth is set to 1k the buffer will be of course postprocessed very fast (smallest capture time is 1us)
- but then the loop takes still 25ms - that's 39.99 wfrm/s. Now when you take 10Mpoint, that's 10ms capture time giving total loop
time of 35ms - that's 28.57 wfrm/s.
We might wonder where this 25ms is coming from. My guess: this is one thread system, therefore you need to have some kind
of fixed post-processing turn around on which then display buffer, sample buffer, i/o and all other systems are (relative) based.
The 25ms seems to be good value, that's 40 display buffers per second, or 40 x 10Mpoint (so 400M/s for buffer memory)
and for sure fast enought to capture i/o (this is why you don't see any front panel lag when in 10M in compare to 1k on Owon).
This calculation might be of course wrong, only Owon can answer it in detail, however for my hardware understaing it makes
sense why it works like that.
Based on that I agree with marmad, Owon need to change the "base" in the firmware to speed-up to wfrm/s rate. The sample buffer
when smaller than 10M need to be postprocessed multiple times per one cycle, but then we would have a DPO-like and not
DSO-like device. Sure there are other non-DPO-like devices on the market having higher wfrm/s rate than Owon, this is not
because they better implemented but only because they do have variable cycle time for data processing and fixed for display
which means the data will be shown asynch to acquisition (this could be a good implementation for Owon too).
However in such systems you need to have two "clocks", which is not the case in one thready Owon firmware.
As Owon never ever managed to develop such implementation (SDS is the latest hardware and it does have the same gaps
as older Owon models - they also based on Samsung SoC and one thread firmware) i doubt they will be able to fix it now.
However what they can do is to implement all other missing things, then only the wfrm/s would be worse than on competitor models,
and that would be already very good thing for all of us using Owon hardware.
You are a hobbyist/semi-professional: you want large screen OR hackability - AND PC ctrl/comm is NOT important - get the Hantek.
PC ctrl/comm is luckily not a dark hole anymore, we have all the information how to control these DSOs and how to
understand the data. There is already great custom PC software (for Mac/Linux/Win) allowing to remote control,
to export buffer to csv (few standards), to capture screenshots or ot capture data to PC screen, etc.
What missing if only FFT (on the to do) and access to raw data buffer (not on to do as still some company confidential information
unknown - but i'm working on that).
Check screenshots on
http://www.dreisiebner.at/dso-usb-tool/http://www.dreisiebner.at/dso-usb-tool/screenshots.htmNevertheless LabView support is still missing, however it can be easily build based on the PC protocol
informations posted in here
http://elinux.org/Das_Oszi_Protocoland here
http://www.mikrocontroller.net/articles/Hantek_Protokoll