Firmware 

2.06.3 issue list: 

 
2.06.3 2.06.3 2.06.3
Issue number
120224.0 120423.0 120507.0

1 Only on B models Only on B models Only on B models

2 see description see description see description

3 see description see description see description

4 X X X

Partially fixed -GPL Partially fixed -GPL

released, released,
5 X SDK some SDK some
documentation documentation
shared shared

6 see description see description see description

7 X X X

8 X X X

9 X see description see description

10 X see description see description

11 X X X

12 X X X

13 X X X

14 X X X

15 X X X

Fixed,
Fixed,
/dso/app/dsod as
/dso/app/dsod as
16 X WD checking
WD checking profile
profile and dso.exe
and dso.exe state
state

Partially fixed, see Partially fixed, see

17 X
description description

18 X X X

19 X X X

20 X X X

21 X X X
 22 X X X

New bug or fix in

progress???,
23 X X
function disabled
in this fw version

24 X X X

25 X X X

List of bugs/improvement requests 
 

1. Select any of the new functions like “Printer Cfg”, “Option, Wave” (any many others), push HELP 
button on the front panel and the DSO is crashing and not responding anymore. 
 
 
2. Apply test signal, do auto setup to trigger properly. Set time base to 4ns/DIV, change Acquisition 
mode from “Real Time” to “Equ Time”, hide menu by pushing F0, turn time base knob from 
4ns/DIV to 2ns/DIV and DSO is crashing and not responding anymore. This bug seems to be only 
valid for DSOs where the factory calibration (not self‐calibration!) is somehow invalid. After 
user‐executed factory calibration bug disappeared. Is there something in “chk1kb_091023” 
which can be changed to fix that? (User‐executed factory  calibration is not an option). 
 
 
3. Apply test signal, do auto setup to trigger properly. Set time base to 4ns/DIV, change Acquisition 
mode from “Real Time” to “Equ Time”, hide menu by pushing F0. When menu hidden you can 
see artifacts on the right side of the screen. They don’t need to be there. This bug seems to be 
only valid for DSOs where the factory calibration (not self‐calibration!) is somehow invalid. 
After user‐executed factory calibration bug disappeared. Is there something in 
“chk1kb_091023” which can be changed to fix that? (User‐executed factory  calibration is not 
an option). 
 
4. Digital Filters to be implemented. 
 
5. SDK to be released  
 
6. Update FPGA design to match ADC skew/timings in 125MHz/1GSs mode  
(this is already known issue and listed in old “issue list”, posting once again in  
this list as reminder) 
FPGA design revision 83E8 sample rate 1GS/s clocks skew (must be always  1000ps): 
Clock 8‐>Clock 1: 1010ps 
Clock 1‐>Clock 7: 1250ps 
Clock 7‐>Clock 2:  550ps 
Clock 2‐>Clock 6: 1230ps 
Clock 6‐>Clock 3: 1000ps 
Clock 3‐>Clock 5: 1280ps 
Clock 5‐>Clock 4:  500ps 
Clock 4‐>Clock 8: 1250ps 
FPGA design revision 83E8 sample rate <= 800MS/s clocks skew (must be always 1250ps): 
Clock 8‐>Clock 1 1250ps 
Clock 1‐>Clock 7 1260ps 
Clock 7‐>Clock 2 1280ps 
Clock 2‐>Clock 6 1230ps 
Clock 6‐>Clock 3 1260ps 
Clock 3‐>Clock 5 1280ps 
Clock 5‐>Clock 4 1230ps 
Clock 4‐>Clock 8 1260ps 
 
FPGA design revision 83E9: 
not yet measured, but Hantek statement “It's impossible for us to achieve it now”
is not really optimistic.
 
7. add 20ksamples/16ksamples/8ksamples (whatever possible, if possible) to memory depth,  
preferred with highest possible sample rate.  This is in principle what already published as 
“available” In the user manual or on Tekway and Hantek websites.  
 
 
 
 
8. In single window, sample memory >=40k, both channels (ch1, ch2) enabled and time base from 
400ns/div up to 2ns/div the position change (fine and coarse) control is not working. Only scale 
is moving, but not the waveform. See attached picture to understand issue: 
 
with 4k memory when changing position waveform is moving 
 

with 40k and above, when moving changing time base position waveform is NOT moving when 
in RUN mode (but works in STOP mode) 

 
9. In single window mode, sample memory 40k, both channels (ch1, ch2) enabled – while  
switching to dual window mode artifacts on screen and DSO later crashing and not responding. 
Artifacts disappear when changing timebase just after switch to dual window, so just an init error? 
 
Set  like on picture  

 
and switch dual window mode to see artifacts like this: 
 

 
10. In single window mode, sample memory 512k, both channels (ch1, ch2) enabled – when 
switching to dual window mode artifacts on screen and DSO later crashing and not respondin 

Artifacts disappear when changing timebase just after switch to dual window, so just an init error? 
Set DSO like on picture 

and switch dual window mode to see artifacts like this: 

 
11. In FFT mode the Display ‐> Grid option is not changing the grid, it is always “real line” and not 
possible to change to “dotted line” or “off”.  
 

12. In FFT mode “Full span” is higher than Nyquist (sample rate /2 ) 
Example: 800ns/DIV, sample rate is 200MSs, full span 125MHz. Easy to fix by enabling from 
800ns/DIV to 20ns/DIV 1GSs sampling (when 4k memory or FFT enabled) 

 
13. AC trigger indicator and line wrong. Set ch1, signal DC coupled, trigger AC coupled. The trigger 
lowest level below signal : 

highest level only mid of signal  

 
But both should look like when trigger coupled in DC mode: 

 
14. Dithering/interpolation filter of waveform too sharp. When enabling both channels (this also 
occurs in single channel mode and 1GSs, but test signal need to be higher to get same error) and 
applying for example 16MHz square wave the waveform is switching between proper square: 

and crippled square every second:

15. Display / Time base scaling strange behavior. When you apply e.g. 1kHz signal, set time base to 
80us/DIV and move the waveform to 500us/DIV : 

When you now change time base to 40uS/DIV the falling edge (which should be still in the 
middle of the screen) has been moved to 454uS position (but it should stay on 500uS). The same 
happens of course with 20uS/DIV. 

 
 16. Develop failsafe into rcS script. 
Currently when firmware does have bug and DSO is crashing, or even with no bug but when  
user is powering off the DSO while the dso.exe is saving the profile/DSO settings into the 
 
/param/sav/run1kb_xxxxx 
 
file it is possible that this file will get damaged. When this happens DSO is not starting up 
properly.  

The failsafe can be separate executable loaded in rcS before dso.exe is loaded. This file will then 
check if “default button” is pressed. If so, this executable will purge settings/profiles and 
terminate itself. The dso.exe will then start up with default settings as no profiles saved. 

17. The new function “Wave” is no working properly in some models. There is missing the directory 
/param/sav/wave_sav on 2.6.13 kernel loaded DSOs. 
Additionally there is typo in ARM source code,  
 

a_hws    DCB ".hws",0  
 
once the file extension is .hsw and another time it is .hws – this is preventing the save/reload 
from USB to work properly and even sometimes crashing DSO. 
 From the file format I assume .hws is the proper file extension name 
18. The protocol.inf file in every 2.06.03 firmware (DSO5xxxB, BV, BMV and DSO1xxxB) contains 
error in the definition of [TRIG‐SWAP‐CH1‐PULSE‐TIME]. It is defined as “1” byte long but it 
should be “8” byte. The firmware itself is using 8 byte, only the “protocol.inf” file is wrong. 

19. The protocol.inf file in ever 2.06.3 firmware (DSO5xxxB, BV, BMV and DSO1xxxB) contains error 
in the definition of ALT trigger. The entries for ALT‐O.T.CH1 and ALT.O.T.CH2  are missing : 
[TRIG‐SWAP‐CH1‐VPOS]       2 
[TRIG‐SWAP‐CH1‐OVERTIME‐NEG] 1 
[TRIG‐SWAP‐CH1‐OVERTIME‐TIME] 8 
[TRIG‐SWAP‐CH2‐VPOS]       2 
[TRIG‐SWAP‐CH2‐OVERTIME‐NEG] 1 
[TRIG‐SWAP‐CH2‐OVERTIME‐TIME] 8 
 

20. Every 2.06.3 firmware (DSO5xxxB, BV, BMV and DSO1xxxB) contains error in the ” 
Trans_DSOeachData” and “Trans_PCeachData” functions. The “g_FFTWin” table is defined too 
small, due this SYSData FFT status is having only  
0x00 : hanning 
0x01 : flattop 
0x02 : rectangular 
Barlett and Blackman are missing (always sending 0x00 and 0x01 instead of 0x03 and 0x04) 
 

21. In every 2.06.3 firmware (DSO5xxxB, BV, BMV and DSO1xxxB) in SYSData definition the field for  
FFT ‐> Vrms is missing, only dBrms available. 
 

22. Every 2.06.3 firmware (DSO5xxxB, BV, BMV and DSO1xxxB) contains error in the 
“Trans_DSOeachData” and “Trans_PCeachData” functions. The “g_MSItem” table is defined too 
small, is having only 0x0B size but since year there are 22 measurement’s available.  

23. Equivalent sampling not working properly. 

24. No real difference when changing Screen Refresh rate (Auto, 30, 40, 50). It looks like “30” is 
maximum what the current firmware is able to handle, when changing to “40” or “50” no visible 
difference. This seems to be the case in all firmware’s since end of Nov 2011. This was one of 
the unique features and need to be changed back to what it was before! 

25. Waveforms in memory (in some combination of Timebase and memory depth), in display 
memory and exported data having at begin or/and end of the waveform random data. Also the 
buffer length seems to be not as it should be, e.g. 4100 instead of 4000 samples. This error 
seems to be in all firmware’s since Mid‐December 2011. 
 List of workarounds – by bug number 
I’ve marked all workarounds with colors: red – bad one, yellow – sill bug, but workaround exists, 
green – not a bug or I don’t care about. Note – these colors represents what I think and feel. 

1. Don’t use help  

2. Run factory‐calibration (only Edge calibration) and after that self‐calibration. This bug seems to 
be only valid for hacked models, it does not exist on real 200MHz models (on which the factory 
calibration was executed after 2ns/DIV and other 200MHz features has been enabled). 

3. Run factory‐calibration (only Edge calibration) and after that self‐calibration. This bug seems to 
be only valid for hacked models, it does not exist on real 200MHz models (on which the factory 
calibration was executed after 2ns/DIV and other 200MHz features has been enabled). 

4. No Workaround available.  

5. Well, you can build your own SDK/LabView/what so ever support based on the already 
published information’s: 
http://www.mikrocontroller.net/articles/Hantek_Protokoll 
http://elinux.org/Das_Oszi_Protocol 

6. There is no affordable workaround for now.  Changes to hardware are possible but expensive. 
I’ve tested Silicon Labs jitter cleaner, Murata LDHxxx delay lines and a combination of other 
solutions. I was more than satisfied with achieved results, expect the costs. 
For now we have to use what available, both manufacturers developed within last 2 years few 
FPGA design versions, the best is from upcoming Tekway MST DSOs and Hantek Handhelds – 
however they not allowing dual channel  500MS/s sampling in long memory; Hantek’s bench 
DSO hw1007 83E9 design allows such faster sampling but the skew is still far from perfect. I did 
publish all these FPGA designs, you can play with them to which is best for you. But note – do 
not do this when you own hw1005 DSO, they can’t be modified! 
For those of you who don’t know what this bug means – Google for waveform/interleave 
distortion and/or Agilent 5989‐5732EN. 

7. This is improvement proposal and not a bug  

8. This is a very unfortunate bug; possible workaround is to use dual window mode or less memory 
depth (both with disadvantages) 

9. Workaround is to change Timebase (just one step forward and back) right after dual window 
enabled.  Note – the main window (top) need to be activated, the bug have something to do 
with main TB buffer initialization. 
10. Workaround is to change Timebase (just one step forward and back) right after dual window 
enabled.  Note – the main window (top) need to be activated, the bug have something to do 
with main TB buffer initialization. 

11. This is improvement proposal and not a bug. 

12. Use my firmware (2.06.3_120507.6), I removed that bug. 

13. Use DC trigger coupling or “add offset” when you set trigger point. 

14. For sure a stupid bug, but since you can see when the signal is “wobbling” you can quick change 
(when necessary) to single channel to observe the waveform with better resolution and without 
wobble. 

15. Funny bug, but easy to omit since we know it. 

16. This is already fixed, the /dsod (or /dso/app/dsod – this depends on fw/DSO model  version) 
binary is working perfectly as watch dog monitoring potential profile issues. 

17. Not a big deal and it is already fixed in my firmware (2.06.3_120507.6) 

18. Not a big deal and it is already fixed in my firmware (2.06.3_120507.6) 

19. (yellow as this is an bug only when accessing remotely) ‐ need to be implemented properly in 
the firmware; a pure protocol.inf change is not enough. 

20. (yellow as this is an bug only when accessing remotely) ‐ need to be implemented properly in 
the firmware. 

21. (yellow as this is an bug only when accessing remotely) ‐ need to be implemented properly in 
the firmware. 

22. (yellow as this is an bug only when accessing remotely) ‐ need to be implemented properly in 
the firmware. 

23. No workaround, it was never properly implemented, now even completely disabled. 

24. Workaround could be to switch back to firmware from Mid‐2011, but honestly this is really 
annoying bug. I can’t understand why there is no QC?  

25. No workaround, it looks just crap. Sure, when we know that there is crap on begin and end we 
can think the crap away, but what when there is a real spike?