Hantek - Tekway - DSO hack - get 200MHz bw for free

[firehopper]

time to install getright and try and see if that can download it.. we shall see

[firehopper]

time to install getright and try and see if that can download it.. we shall see

okay one is done, took nearly 10 hours to download with getright, the other file is still downloading. they have such a bad connection apparently.

[tinhead]

okay one is done, took nearly 10 hours to download with getright, the other file is still downloading. they have such a bad connection apparently.

yeah, their server is not having the best connection, but good enought to use download manager, so who cares.

[sorin]

And about my questions?
"Do you know what is the max sample rate/second than can be transfered to pc through lan on DSO5000P Series (for real time data login)?"

[tinhead]

Do you know what is the max sample rate/second than can be transfered to pc through lan on DSO5000P Series (for real time data login).

the maximal sample rate remains the same, no matter how fast or slow the link is. I think you wish to know how much of that sample rate, or better said on what rate the data can be read by PC over ethernet. With other, or better said all models based on S3c2440, the link over USB was slow (one of the reasons why i build ethernet card for my old hw0 DSO).

In the theory you cold read the data directly from FPGA device driver, so the max link is USB link speed, or ethernet speed, reduced of course by some latency of the device drivers. When the firmare is not running this could be not that bad. However when you use the firmware itself and try them to read the data over the official way, well then you have to remember that the DSO itself need lot of the resources to get the data processed.

I can't tell you how fast DSO5000P can be over USB, which is btw USB 2.0 as the S3C2416 can 2.0, all models based on S3C2440 can only USB 1.1 and that was a big diff! However over ethernet, and this is someone else tested, you can get (when the firmware is busy with DSO itself) 16Mbits something:

iperf: [  3]  0.0-60.1 sec   120 MBytes  16.7 Mbits/sec

With the models based on S3C2440, i got only 5-6 Mbits, so DSO5000P is already 3 times faster over ethernet.

Both measures over ethernet has been made when the firmware was bus doing DSO thigns, here as said above is a way to improve it to max. what the FPGA can get (which can be max. 80MBit assuming 4k buffer * 25000wfms/s - without latency of device drivers of course).

[Marphy]

Hi folks,
My DSO3062C had a firmware crash a few days ago, so I started diving into all this tons of information available here and on some other websites. It takes some time to read into the topic but the modifications are done quite easily and quickly.

That's why I decided to write a quick guide summarizing the most important information and providing step-by-step instructions. Maybe I am a bit late with this, but I hope it can still help some people saving some time.

Feel free to have a look:
http://marcowuen.wordpress.com/2013/09/01/dso-hacking-quick-guide-voltcraft-dso3062c-hantek-dso5062b-tekway-dst1062b/

Feedback is welcome.


Last but not least a big thanks to tinhead for all the great work he has done over the past months and years! I doubt that all this would be possible without him.

[tinhead]

Feedback is welcome.

so far ok, maybe except this :
"After a bandwidth upgrade it is recommended to also upgrade the hardware input stage of your DSO as described below".

I do not recommend to change anything in the hardware without real need. There are multiple variation of the hardware, currently even two complette different frontends. So for sure, for these with bad response it make sense to apply modifications. But not based on what the enduser think or measure, but based on components values! I know lot of professionals not capable of doing simple measurment^^.

Something like :
"After a bandwidth upgrade it make sense to check, as described below, if upgrade of the hardware input stage of your DSO is necessary"
would be better.

[uh9lab]

Sorry, does anyone have a copy of new DSO5202P firmware? I'm trying to upgrade my 5072p, have no problems with 5102 version, but link to 5202P from the http://www.hantek.com.cn/en/PagesFW_Vzxgj.html doesn't work...

[tinhead]

Sorry, does anyone have a copy of new DSO5202P firmware? I'm trying to upgrade my 5072p, have no problems with 5102 version, but link to 5202P from the http://www.hantek.com.cn/en/PagesFW_Vzxgj.html doesn't work...

ask Hantek! I told them already 4 weeks ago that this link didn't work, but still not fixed.

[Marphy]

so far ok, maybe except this :
"After a bandwidth upgrade it is recommended to also upgrade the hardware input stage of your DSO as described below".

Thanks, the section is revised now.

I do not recommend to change anything in the hardware without real need. There are multiple variation of the hardware, currently even two complette different frontends. So for sure, for these with bad response it make sense to apply modifications. But not based on what the enduser think or measure, but based on components values! I know lot of professionals not capable of doing simple measurment^^.

If I get you right you think it is wrong to recommend a hardware mod for everyone just measuring an overshooting square wave (as you think there is too much risk of measuring bullshit)? Makes sense somehow.

But how to distinguish between a good and a poor input stage then? You say based on component values, but as you say there seem to be a lot (or at least several) different component values out there... Which are worth upgrading and which are not?

[tinhead]

how to distinguish between a good and a poor input stage then? You say based on component values, but as you say there seem to be a lot (or at least several) different component values out there... Which are worth upgrading and which are not?

for "P" models, as far i know no need to change anything. Haven't tested that, so can't confirm anything.

For all other models - as long they using LMH6552 check these few resistor, compare them with what i draw/wrote on schematic.

[tinhead]

e.g. here, the latest DSO5000B and MSO5000D mainboards, hw1.01. (other hw versions are known and already published by me and others).

blue marked are things need to be checked - here clearly 33R on input, 12R in compensation snoober, 280R arround LMH6552 (they can stay 280R, optimal is however 270R), 4x22R array (and all the things in another channel as well), and of course the trigger 100R trigger resistor. All these things need to be changed if one wish to get real 200MHz model performance. Pink marked are additional changes, to get even better results. There are other minor mods possible, e.g. reduction of 1kHz test signal rise time, from 1.8us to 750ns, by removing of these two green marked caps.

Btw. check red marked "design in china", i'm not native speaker but i would say that should be "designed in china".
Or maybe it was done for a design event, http://www.design-china.org/

Another nice detail, no single word about "Hantek" on mainboard.

[tinhead]

Feedback is welcome.

i found something else:

>> Original response with severe over-/undershoot- This is one of the main points of criticism from
>> Dave in his review of the Tekway DST1102B (see from 32:50 onwards).

Dave his review was made with broken unit, i would not necessarily use that as reference to check if
DSO have good or bad response. There is a huge difference between what i measured on working
DSO (but with bad response due sw hack only):



and what Dave measured on his test unit:



So the pictures you linked, they providing good reference.

[rigrunner]

My first post, and unfortunately it's asking for help.

My Voltcraft DSO-1062D was running 2.06.3(130114.0) on 10070 555583eb.

I was seeing some odd readings this evening, so before posting with the odd readings I thought i'd flash with later firmware just to make sure it wasn't a firmware issue.

I've flashed with the contents of dst1kb_2.6.3_15102d_fact130321.1.zip and was prompted to restart the DSO.

DSO boots and shows a boot image and then shows the usual scope screen. After that it's dead. No buttons work, no traces and i can't connect to the DSO with the USB tool to copy the contents of the flash drive as per the remainder of the instructions in post #1842.

Under windows the DSO is shown as USB\VID_0000&PID_00005&FEC3355&0&1.
Windows suggests that the driver from Hantek's website isn't for this device.

How do i fix this?

[tinhead]

How do i fix this?

check that link/link

https://www.eevblog.com/forum/testgear/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg285295/#msg285295

"Fixing DSO firmware crash / hangup"

You might as well remove, if any, files from /mnt directory, i saw already some DSOs where that directory was full of screenshots, then need to be removed by

 rm /mnt/*.*

Under windows the DSO is shown as USB\VID_0000&PID_00005&FEC3355&0&1.
Windows suggests that the driver from Hantek's website isn't for this device.

that looks like nothing properly loaded on DSO side, so proceed as described above, wipe content of /mnt and delete /param/sav/ru* first.

[rigrunner]

The instructions in the link didn't resolve anything.

On the console i'm seeing this after copying dso_update.exe and rebooting:

dso-spi: install ok
dso-uart: install ok
dso-buzzer: install ok
0x60c
gpio_major_n = 6, io_minor_n = 12, output 1
fpga download file_name :/dn.rbf
dso-spi: open fpga file failed.
have dso_update.exe
do backup and update the sysytem
now run app .....
/etc/init.d/rcS: line 60: /dso.exe: not found

dso_update.exe is being copied to dso.exe correctly, but something is preventing execution.
chmod 777 /dso.exe
/dso.exe

returns:

-/bin/sh: /dso.exe: not found

busybox /dso.exe

returns:

dso.exe: applet not found

[rigrunner]

Update:

I've extracted the dso.exe from the current .up file on Hantek's site and that loads and displays the main screen ok.
Still no button functions or scope traces.

If i replace the dso.exe with the one in your dso.zip file Tinhead i get the load errors again.

The md5 for the dso.exe i have that fails to run is b1f714ff53c0ffe56147b8e042a036b1
Size: 4142140
Date: Jul 12 22:05
Filename: dso.exe

[tinhead]

-> fpga download file_name :/dn.rbf
-> dso-spi: open fpga file failed.

the /dn.rbf seems to be missing as well, that looks generally bad when already two files are broken.

> dso_update.exe is being copied to dso.exe correctly, but something is preventing execution.
> chmod 777 /dso.exe
> /dso.exe
> returns:
> -/bin/sh: /dso.exe: not found

that looks like wrong dso.exe or missing one or more libs, probably libc

I can for sure attach more files, but that looks here as broken NAND/file system.

[Jantle]

hello,

thanks to that great information found in this thread I decided to order one of those oscilloscopes to sort out my old analog one. I think, tinhead, you definitely deserve some kind of commission from hantek/tekway, I am pretty sure their sales were heavily increased by this thread. 

So, few weeks ago I ordered DSO5072p and I am pretty happy with this device except for reproduceable crashes on specific settings.
With both channels displayed, "Acquire" settings set to "Type: Real Time;  Mode: Average;   Averages: 128;   Mem Depth: 20k" the scope always crashes after a few seconds (with fast time scale).
With slow timescale (like 40.0ms) I can count the changes of the "a"/"T"-icon which always stops after about 120 acquisitions.

These crashes don't happen with any other setting (single channel / 40k mem depth  or  64 averages). Is this a general bug, can anyone reproduce this behaviour? or is this some hardware/software issue with my device?

My device information:
model:    DSO5072P
sw ver:   3.40.0 (130717.0)
hw ver:   10000xffff8103
serial:     T 1G/035 0001xx

I upgraded software to 3.40.0 myself with official download from hantek site, the crashes also happened with previous version (3.02.?)

Another question: The latest software shows a menu entry which I didn't notice with old version: "Utility / page 3 / Option ... / Video" . This entry is always disabled, what is it supposed to do ?

[tinhead]

--- reproduceable crashes on specific settings---
With both channels displayed, "Acquire" settings set to "Type: Real Time;  Mode: Average;   Averages: 128;   Mem Depth: 20k" the scope always crashes after a few seconds (with fast time scale).
With slow timescale (like 40.0ms) I can count the changes of the "a"/"T"-icon which always stops after about 120 acquisitions.

These crashes don't happen with any other setting (single channel / 40k mem depth  or  64 averages). Is this a general bug, can anyone reproduce this behaviour? or is this some hardware/software issue with my device?

i'm not able to reproduce this (can run DSO for minutes) however i don't have FPGA attached so no data acquired (on the other side no data is data as wel, but maybe the pure fact that my SoC can't get anything from FPGA is not stopping the firmware from working).

So it would be more usefull if someone else could test it as well and let us know the results (together with the HW/FPGA design version, your is hw ver:   10000xffff8103)

[tinhead]

Another question: The latest software shows a menu entry which I didn't notice with old version: "Utility / page 3 / Option ... / Video" .

this is the video player option known from DSO5xxxBMV

This entry is always disabled, what is it supposed to do ?

nothing, i don't think all the necessary libs/apps (mplayer) are available on P models, on the dump i'm working with they not there.
Sure, you could enable that menu, but for what when the player is not working.

I know however that current B/BM/BMV models got same SoC and new mainbiard as well, so once we have these files compiled for that SoC it could be possible to copy them over and then to enable the menu.

[rigrunner]

the /dn.rbf seems to be missing as well, that looks generally bad when already two files are broken.

that looks like wrong dso.exe or missing one or more libs, probably libc

I can for sure attach more files, but that looks here as broken NAND/file system.

The dso.exe is from post 1843.

How do i flash the firmware via uart? I'd like to revert to an older version to test.

[rigrunner]

I've installed 2.06.3(130814.0)  and I have the DSO back up and running.

There's obviously something weird going on with the files i have here. Tinhead can you post the correct links to the files i need to update my DSO to your latest software and firmware please? Just to be sure i'm using the correct files?

[richardbb]

So it would be more usefull if someone else could test it as well and let us know the results (together with the HW/FPGA design version, your is hw ver:   10000xffff8103)

I can confirm this bug. dso.exe crashes with:

dso.exe: opt/average_opt.c:469: Avg_AvgArrayAddAndAvg: Assertion `((void *)0) != pt_average' failed.

ver 8101

[Jantle]

i'm not able to reproduce this (can run DSO for minutes) however i don't have FPGA attached so no data acquired (on the other side no data is data as wel, but maybe the pure fact that my SoC can't get anything from FPGA is not stopping the firmware from working).

Thanks for checking this, however I am a little confused... what do you mean by "don't have FPGA attached" ?  Did you unsolder it from mainboard? 
I am not very familiar with this kind of electronics, but as far as I understand the SoC is running the main system (Linux) and does all the UI-stuff and FPGA is responsible for all the fast things like acquiring data and doing all the math like averaging? So it might be a issue within FPGA?

Another question: The latest software shows a menu entry which I didn't notice with old version: "Utility / page 3 / Option ... / Video" .

this is the video player option known from DSO5xxxBMV
[...]
Sure, you could enable that menu, but for what when the player is not working.

Well,... I don't think I'd ever watch Videos on my Oscilloscope     .. so, no I don't want to enable it.
I thought I might have been some functionality to record video of the DSO-screen for educational purposes or something like that.

So it would be more usefull if someone else could test it as well and let us know the results (together with the HW/FPGA design version, your is hw ver:   10000xffff8103)

I can confirm this bug. dso.exe crashes with:

dso.exe: opt/average_opt.c:469: Avg_AvgArrayAddAndAvg: Assertion `((void *)0) != pt_average' failed.

ver 8101

Thanks for confirmation, so I am glad it's no hardware issue with my mainboard and might likely be fixed somewhen. With knowing this bug it can be easily be avoided and honestly I don't really need these settings very often.