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

[tinhead]

as i write on the first page - hackable - yes, backup tool - no, not yet (but you can copy all important files manually to flash drive)

[geostep]

Just watched dave's review and as an owner of this scope I'd like to know if anyone has any clue about why is the analog frontend makes the captured signal "jump all over the place", could it be his hardware revision? How can I test without that fancy evaluation board he got?

I have the Hantek DSO 5102B@200 MHz (equivalent to the Tekway in Dave's review).  I'd really like to know more as well. Any thoughts on this guys?  Tinhead?
That ringing Dave discovered really is horrible.  How can I trust the scope is displaying an accurate waveform without having to compare it to another scope?   

- George

[tinhead]

I'd really like to know more as well. Any thoughts on this guys?  Tinhead?
That ringing Dave discovered really is horrible.  How can I trust the scope is displaying an accurate waveform without having to compare it to another scope? 

comment to Dave's video

https://www.eevblog.com/forum/blog/eevblog-487-tekway-dst1102b-oscilloscope-review/msg251936/#msg251936

ringing

https://www.eevblog.com/forum/blog/eevblog-487-tekway-dst1102b-oscilloscope-review/msg252717/#msg252717

https://www.eevblog.com/forum/blog/eevblog-487-tekway-dst1102b-oscilloscope-review/msg252723/#msg252723

read what i wrote and when you didn't got something feel free to ask here

What Dave saw on the DSO he testes didn't matetr at all, even the person who provided him that test unit confirmed that there was repalcement board in used unit, that could be everything.

there is as well comment from Dave

Rigol has excellent signal and trigger integrity.

which is actually reall bullshit, i haven't responded to that as i give a shit about such statements. From an EE i would expect to check the facts and not respond like he did. One can compare Owon to Rigol/Tekway, or Agilent to Rigol/Tekway, but not Rigol to Tekway as both have:

- same frontend
- same trigger circuit
- same mux/opamps/ref
- same FPGA
- same ADCs

so from a signal flow there is no winner, both are exact good/bad, the signal from BNC to FPGA is looking on both devices same.
If there was soemthing worng with the DSO Dave tested (and that could be as i wrote one of the bad populated models, or broken or even not factory calibrated - as Charles said "repalcement board").

But it seems nobody is reading what i wrote (i shall use less words, simply no, fuck, no would be probably enouhgt instead of proper technical explanation for potential error or issue in test procedure/gear).

Anway, read what i wrote and come back when you still have questions.

[sorin]

But it seems nobody is reading what i wrote...

this don't is true

[geostep]

tinhead -

Thanks for the links.  I simply didn't know about the review post.  I didn't search for it. My bad. 
My questions were not meant to get you irritated! 

- George

[tinhead]

no problem at all George, i'm today bit too emotional (driven). I was today on peddlers market, and i saw really great Star Wars models, an old one from 80' or so .. any my wife said "no, we don't have money for that crap now". I have no idea what she means with crap, but my last wife got replaced as she was talking too much bullshit ^^

[brainwash]

Not sure if it's a bug or a 'feature' but software measurements while in Peak mode are wrong. I'm using the probe cal output and I get frequencies like 1.25Mhz, 500kHz, 250kHz and if I'm lucky I might get the expected 1Khz. The P2P measurement is correct so I don't think it's really catching glitches. It works as expected in Normal and Average modes.

Is there any way to let the scope save only .gif files and ignore .bmp files? Not sure, but probably the few seconds spent saving are actually spent writing the bmp file.

Is there any way to simulate segmented memory? I might be able to do some stuff with the recorder function if I know exactly the timing between RS232 messages, but is there a way to do this trigger-based instead of time-based?

You've said something about time-grading with 4/16 levels, is there any way to control this? Is it dependent on the wave intensity or contrast? Is it dependent on persistency duration? For me this is really not transparent how it works, I have more luck catching glitches with persistence set to off (50 fps, 4k buffer).

How fast is the rise time of the probe cal output? I seem to get a consistent 2us, but not sure how much of that is the actual probe (not much) and I don't have fancy equipment to measure it.

Another issue/feature: boot count and upgrade count get reset to zero after upgrade. I went from 130131.0 to 130425.0

[tinhead]

Not sure if it's a bug or a 'feature' but software measurements while in Peak mode are wrong.

haven't tested but i would say the selected memory depth is too small

Is there any way to let the scope save only .gif files and ignore .bmp files? Not sure, but probably the few seconds spent saving are actually spent writing the bmp file.

DSO firmware is saving first bmp to tmp location, copying from there the bmp to /mnt/flash drive (which takes "hours", lol, i don't like it, never liked bmp), then it's doing bmptoppm and ppmtogif and copying the gif to /mnt/flash drive. I wish they would implement something like bmptopng (sure, we could compile bmptopng and rename it, but ehh, the manufacturer could do it as well) and remove ths bmp savng complettly (or leave it as an option, png - bmp - both).

The bmp can be only "patched away", there are (the first is on MSO, 2M, "P" and Handheld models, the second on the others)

cp %s /mnt/udisk/%s/%s.bmp

and

cp %s /mnt/%s/%s.bmp

Open the dso.exe in hex editor and change "cp" to "ls", it saves a lot of time and it works as expected^^

Is there any way to simulate segmented memory? I might be able to do some stuff with the recorder function if I know exactly the timing between RS232 messages, but is there a way to do this trigger-based instead of time-based?

unfortunately only time-based mode is available, i wrote it down as "request". I don't mind the time-base mode, but triggered would be nice as well (the best would be to control the holdoff between triggered and saved waveframe).

On the other side, when you think about transmintion to PC you should not forget that the firmware is running multiple threads and that this linux is not rtos. For streaming it could be good idea to read directly the FPGA fifo, however this need some investigation.

You've said something about time-grading with 4/16 levels, is there any way to control this? Is it dependent on the wave intensity or contrast? Is it dependent on persistency duration? For me this is really not transparent how it works, I have more luck catching glitches with persistence set to off (50 fps, 4k buffer).

the intensity is controling both, wave and persistency color, as far i can see there are 4 levels of persistency and in each level the waveform can have 4 levels of intensity. You can achieve good results with e.g. intensity set to 4, refresh to 50, buffer to 4k and persistency to 0.2s.

How fast is the rise time of the probe cal output? I seem to get a consistent 2us, but not sure how much of that is the actual probe (not much) and I don't have fancy equipment to measure it.

the CPLD itself goes down to ps range, the driver however includes low pass. You can simulate that circuit to get exact values, see attached schematics (i need to update the pdf, few values were wrong)

Another issue/feature: boot count and upgrade count get reset to zero after upgrade. I went from 130131.0 to 130425.0

this is not bug, it is like that since first fw version. I have no idea why, i guess to remove any evidence of cross model/version updates. Both information are in /sys.inf and that file ie being replaced during update.

[brainwash]

Not sure if it's a bug or a 'feature' but software measurements while in Peak mode are wrong.

haven't tested but i would say the selected memory depth is too small

How fast is the rise time of the probe cal output? I seem to get a consistent 2us, but not sure how much of that is the actual probe (not much) and I don't have fancy equipment to measure it.

the CPLD itself goes down to ps range, the driver however includes low pass. You can simulate that circuit to get exact values, see attached schematics (i need to update the pdf, few values were wrong)

I have tried with 4k/40k/512k and various timebase settings. Something is aliasing when used in peak mode, could also indicate to other problems.

Would it be safe to increase the CAL bandwidth? I would assume it involves removing C03_57 and C03_58.

[marmad]

1500 replies and (nearly) 250000 views ... Dave, where is my DMM ? 

Damn you tinhead! I can never catch up!! 

Well - I spoke too soon.     6 months later and we've cracked 100 pages - just 14 shy of 1500 replies.  Although I know we'll never catch you in views, see you at the top (of replies) soon. 

[tinhead]

1500 replies and (nearly) 250000 views ... Dave, where is my DMM ? 

Damn you tinhead! I can never catch up!! 

Well - I spoke too soon.     6 months later and we've cracked 100 pages - just 14 shy of 1500 replies.  Although I know we'll never catch you in views, see you at the top (of replies) soon. 

and here is my answer

https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg260445/#msg260445

Btw, i got DMM from Dave, i will make a separate thread about that (well, because i hacked it already ...)

[marmad]

and here is my answer

https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg260445/#msg260445

Btw, i got DMM from Dave, i will make a separate thread about that (well, because i hacked it already ...)

And here is mine. 

And, yes, I'm hoping I might get a small prize too. 

[mepper]

Hi,

My first post here, so I'd like to start by thanking tinhead for some pretty heroic effort in maintaining information about these scopes - it's incredibly useful.

I have one question though.  I recently asked a seller offering the MSO5102D for the hardware version number, as I'm under the impression these are basically the same as the DSO5102B but with the extra LA board, and so hardware/FPGA versions should be comparable.  He replied with "1010X55558340", which doesn't look quite like any I've seen mentioned.  Was my assumption wrong, or could this be some really old (or really new) version?

[tinhead]

My first post here, so I'd like to start by thanking tinhead for some pretty heroic effort in maintaining information about these scopes - it's incredibly useful.

you welcome

I have one question though.  I recently asked a seller offering the MSO5102D for the hardware version number, as I'm under the impression these are basically the same as the DSO5102B but with the extra LA board, and so hardware/FPGA versions should be comparable.  He replied with "1010X55558340", which doesn't look quite like any I've seen mentioned.  Was my assumption wrong, or could this be some really old (or really new) version?

you right, the MSO i know are based on DSO plus extra LA PCB, so the hardware version is still the same 10070x555583E9, where 83E9 is the FPGA design version. However, as already mentioned the Samsug SoC used in hw0, hw1005 and hw1007 is EOL, so Hantek/Tekway announced hardware change. There are already these "P" models with new PCB/hardware revision and completly new FPGA design, it was only matter of time the other would change. These 1010X55558340 you reported, that make sense for me, hardware revision 1010 and FPGA revision 8340. That means Hantek/Tekway released already MSO with latest hardware (i wish i could see inside such DSO/MSO).

[jebcom]

I recently asked a seller offering the MSO5102D for the hardware version number

It would also be interesting to know what software version (and software date) they're currently shipping on these. My MSO5202D is hard version ...83e9, soft 2.07.1(date=130321.0) This software version was withdrawn, and now a much older version is available. Also whether the logic analyzer actually works properly, save to usb works, and system date can be set.

[mepper]

These 1010X55558340 you reported, that make sense for me, hardware revision 1010 and FPGA revision 8340. That means Hantek/Tekway released already MSO with latest hardware (i wish i could see inside such DSO/MSO).

OK, so this may be the S3C2416 hardware then.  I wasn't sure since the FPGA version is lower, but then I think I saw a post of yours mentioning much older Tekway scopes using higher FPGA numbers anyway.  I'm tempted to take a punt and see what it's like. 

It would also be interesting to know what software version (and software date) they're currently shipping on these. My MSO5202D is hard version ...83e9, soft 2.07.1(date=130321.0) This software version was withdrawn, and now a much older version is available. Also whether the logic analyzer actually works properly, save to usb works, and system date can be set.

I'll see what I can find out about software versions, but the sellers I've asked mainly appear to be box-shifters so I doubt I'll get any detail on how well it works.  If it's using the new SoC then it's pretty likely we'll see different versions anyway.

[tinhead]

right, the ARM firmware is not compatible (but for sure it can be compiled to run on "old" SoC), i assume the FPGA design/firmware will not run as well on "old" models (but in principle it could, well, we will see).

I'm tempted to take a punt and see what it's like. 

when its from local seller for sure not a risk, but even if not, it can't be worse than the "old" version.

It would also be interesting to know what software version (and software date) they're currently shipping on these. My MSO5202D is hard version ...83e9, soft 2.07.1(date=130321.0) This software version was withdrawn, and now a much older version is available. Also whether the logic analyzer actually works properly, save to usb works, and system date can be set.

there is firmware made for Voltcraft MSO

http://www.conrad.de/ce/de/product/122482/VOLTCRAFT-MSO-5102B-216-Kanal-Oszilloskop-Digitales-Speicheroszilloskop-Bandbreite-100-MHz-integrierter-16-K-Logik-A

direct link

http://www.produktinfo.conrad.com/datenblaetter/100000-124999/122482-up-01-en-Firmware_Update_MSO_5102B.zip

it can save snapshoots and csv, and it can set time (but still without 0:00, lol) but i didn't liked the rest of the firmware.

On my hardware (check the attached picture, isn't that a nice hardware?) the trigger point is complettly wrong, but it can be my hardware (soon i will get "real" MSO, but the "old" model), when you wish you can test the Voltcraft firmware on your MSO. So far i saw it should work.

EDIT: no, that firmware is really crap, i'm getting segmentation fault all the time when i try to set more momory, or PC comuniction, etc.

The latest "working" is 2.07.1(130321.0), i did modified it to swap L and H in LA trigger (which is swapped and actually a bad bug, you can think "ohh, LA is somehow triggering too late",  but in real it is only swapped stupid string in firmware).

I know that Hantek removed that firmware from their website, however i have them all, so attached the original 2.07.1(130321.0) and modified dso.exe, English.lan and protocol.inf files. The mods i made are as said above to fix the L/H bug, fix a bit Chinglish (not that i really speak english, lol, but my version is better. On DSOs they using my translation, on MSO not yet), and to fix the broken protocol.inf (new functions has been added, but numbers not incremented).

You can install the original firmware (that version have no problems with time change nor csv/screenshot save) , reboot the MSO and then copy the 3 files from the attached dso.zip to your MSO.

All you have to do is to unzip the content of dso.zip to empty flash drive, insert it to MSO, download and run that tool

http://peter.dreisiebner.at/dso-usb-tool/
 
go to shell tab and copy these files from flash drive to MSO, e.g.:


cp /mnt/udisk/dso.exe /dso_update.exe
sync
cp /mnt/udisk/OurLanguages/English.lan /OurLanguages/English.lan
cp /mnt/udisk/protocol.inf /protocol.inf
sync


and then reboot. After the reboot you will then see as version 2.07.1(130321.1), which indicates my modified version.

[tinhead]

.. and here the dso.zip, attachment limitation again

[tinhead]

Fan replacement

the specs from a latest models FAN is

PS: 12V
Noise: 26dBA
Air flow:9.42CFM
Static pressure:2.27mmH2O
Size: 50x50x10 mm

a good replacement fan is Noiseblocker XS-1, the specs are (at 12V):

PS: 8-12V
Noise: 16dBA
Air flow:11.5CFM
Static pressure:1.18mmH2O

of course it make sense to replace the 7812 by 7808, the new fan req. only 8V to start, the air flow will remain the same where the noise will be reduced by at least 10dBA.

[tinhead]

good news for Hantek DSO5072P/5102P/5202P owners, i got pictures and all the other things from eevblog user "richardbb".

I've made already schematics of the new frontend (LMH6552 has been repalced with THS4504, on paper it look good how the opamp has been configured, so no response issues i think).

On the pictures i got it is clearly visible that all P models can be modified to support LAN, all you need is the DM9000AEP (48LQFP), 25MHz quarz and of course magnetics (hiw to check which one). The Audio DAC and mono opamp for speaker can be populated as well. The SD card can be used as well, it seems that the bootloader have support for boot from SD as well.

More things, like backup tool etc, (and pictures) later.

[sorin]

Hello
Thank you again for your work!
Do you know if the "P" model can be "hacked" to add extra RAM?

[tinhead]

Hello
Thank you again for your work!
Do you know if the "P" model can be "hacked" to add extra RAM?

no it can't, there is no CPLD (which was used before as address counter) and no unpopulated SRAM/DDR what so ever RAM.
However one good news is, it seems that the current firmware supports 40k instead of 24k max. (that means user can choose 4k, 20k and 40k), at least something.

[tinhead]

Backup tool for DSO5000P models

How to use it (backup):

Unzip the attached file, go to Backup_P_models and copy the dso5kp_backuptool.up to empty usb flash drive.
Insert it into your DSO and run "firmware update" from DSOs "Utility Menu".
This will create a folder on your USB Flash drive containing all MTD partition dumps.

OOB will be not dumped, if need it you can edit this tool and remove the -o options from the command line inside.

How to use it (restore):

First create restore file

 copy /B boot.bin + logo.bin + kernel.bin + root.bin fw_backup.bin

then burn with JTAG the fw_backup.bin file (no OOB blocks inside!) to NAND

There is as well posibility to restore firmware from the uboot. However i can't use it as the UBI partition is larger
as the DSO RAM, so uboot is crashing. No idea if this works on real DSO, i don't have any "P" model, but on dev board
it was not working like that (i use always JTAG, so not a big deal for me, but maybe for you).

Power on your DSO, enter uboot bootloader (by pushing any key while boting),
connect DSO to PC over USB, choose in bootloader
 
 [5] Download UBIFS image (root.ubi) to Nand Flash

run on PC side the dnw.exe, (at first time you will be askd for driver, choose the secusb2.inf)
then choose in dnw menu USB Port -> Transfer -> Transfer and select the previously created backup file root.bin

Be patinet now! it takes few minutes to restore the root.bin

You can use similar way to restore kernel (kernel.bin, menu [3]) and the uboot itself (boot.bin, menu [1]).
The logo.bin is anyway only empty space, so no need to resotre it.

After you done with restore choose [r] to reboot uboot.

EDIT1: no, restore via u-boot didnT work due file length :\
EDIT2: i have updated the tools to create backup with following params:

nanddump -o -b -l 0x100000 -f /mnt/udisk/dump/boot.bin /dev/mtd0
nanddump -o -b -l 0x200000 -f /mnt/udisk/dump/logo.bin /dev/mtd1
nanddump -o -b -l 0x400000 -f /mnt/udisk/dump/kernel.bin /dev/mtd2
nanddump -o -b -l 0x7900000 -f /mnt/udisk/dump/root.bin /dev/mtd3

This seems to work better (at least on my test board), need confirmation from other users.

[echen1024]

Would it be possible to change the operating system distro on the Hantek scopes? Maybe install Ubuntu on it? Or would that just break the thing due to proprietary signaling methods. 

[tinhead]

Would it be possible to change the operating system distro on the Hantek scopes? Maybe install Ubuntu on it?

All neccessary GPL sources has been published, so the answer is "yes/f course", but one question remains, what for?