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

[NCG]

I noticed it too with first DSO upgrade firmware, have not tested if it is also there with latest MSO firmware.

I am testing my new MSO5102D (updated to latest Hantec SW but not hacked) and notice that the logic analyser results seems to lag the analogue channels by one trig.
ie. I get the data sampled on the previous trigger for the analyser part and fresh result for the two analogue channels.
Is this a know issue? I do not seem to find anything about it elsewhere.

from system status screen:
model: MSO5102D
SW: 2.07.1 (130321.0)
HW: 10070x555583e9

[tinhead]

I am already at step 2 (tested dso.exe check removal for kernel version too) - just curious what does regular BM/BMW update does (the relevant files are)?

btw NCG, you can switch to higher linux version by doing following stept:
1-  run http://embdev.net/articles/Tekway_MSO#Firmware_upgrade to get Linux and MSO firmware
(with all these steps -> backup of your factory files, installation of MSO fw, resotre of your factory files)
2- install special BMV model firmware on your temp MSO model, http://www.mikrocontroller.net/topic/289260#3094394
You need to run the *dodso* file, http://www.mikrocontroller.net/attachment/173447/dst1kb_2.06.3_dodso.up
3- use the regular BM/BMV firmware once. You might consider changing logo as well, as described in this thread here somewhere.

yeah, here we go ... on your DSO(MSO) it is bad idea to use regular BM/BMV updates, they will of course replace the rcS,
for a regular B model user this does not matter, but for you it does as you have MSO.

For you make sense to use this solution

http://www.mikrocontroller.net/topic/289260#3126759

and then to copy (as you haev anyway network on your MSO) the unpacked firmware files instead of install them.
For sure this "sucks", on one side you have 2M on board, on the other side you have MSO.

[morris6]

I am testing my new MSO5102D (updated to latest Hantec SW but not hacked) and notice that the logic analyser results seems to lag the analogue channels by one trig.
ie. I get the data sampled on the previous trigger for the analyser part and fresh result for the two analogue channels.
Is this a know issue? I do not seem to find anything about it elsewhere.

Can you please give some more details and maybe illustrate with an example? I would like to try reproducing this issue.

The only 'place' I have seen a thing like this is during S condition, repeatedly pressing 'single seq'. You probably will need several pushes anyway before the analog signals in the display refreshes ( bug #40 ) and then you'll see the digital traces lag behind the analog for one refresh event( #41 in my personal buglist ).

A proper buglist for the MSO(MST) models has not been published yet, allthough Tinhead might be working on one, as far as I know.

[Mike Warren]

Just an update on the Pass/Fail crash.

I received an update from Tekway that appears from the file name to be the same version (130306) we have all been using, but I have not had a crash in the last 3 days. And I was running Pass/Fail tests for about 9 hours yesterday.

Pass/Fail was unusable for me before this.

The only thing that suggests it is not the same version is that the file size s quite different.

dst1kb_2.06.3_15202b_fact_130306.0_.up - 2888019 bytes

dst1kb_2.06.3_01102b_fe(130306.0).up - 2,800,232 bytes

[cosmos]

I have seen this lag issue both with normal and with singel trig.

Just now looking at a digital signal that changes a lot over time so it makes a good example.
I have one of the analyser signals also attached to CH2 and trigger on CH2, adjusting the trigger level high (trigger on overshoot) so it just barely catches events reduces the rate of trigs so I can see what it captures.
I have about 1 trig every 2 second, the common signal does not match, if I take note of the analogue signal I will see it on the analyser track on the next trig.
What seems to produce the correct result (analyser and analogue in sync) every time I tested it is to do RUN/STOP then halt it with Single.

I too noticed the slightly random lack of response from the "single SEQ".

Other thing to consider for a bug list:
With high trig rate I have random flashes on all analyser tracks with masses of random content, screen can be packed full of transitions on all analyser channels (connected channels and unconnected alike).   
Looking over time it seems as if the random flashes can be related to content of the analogue channels, I sometimes see gaps corresponding to the high or low state of the analogue channels but it is not consistent even if I have a fixed pattern on the analogue channels.

memory depth in the analyser seems to be fixed at 4k.
Sampling a signal with ~10ns long pulses for 40us (display says 4.00us per division) of sampled data I start to miss pulses, with 80us captured i can miss all, or none, at 20us I do not see any misses.
Changing memory depth in Acquisition menu makes no difference.

I am testing my new MSO5102D (updated to latest Hantec SW but not hacked) and notice that the logic analyser results seems to lag the analogue channels by one trig.
ie. I get the data sampled on the previous trigger for the analyser part and fresh result for the two analogue channels.
Is this a know issue? I do not seem to find anything about it elsewhere.

Can you please give some more details and maybe illustrate with an example? I would like to try reproducing this issue.

The only 'place' I have seen a thing like this is during S condition, repeatedly pressing 'single seq'. You probably will need several pushes anyway before the analog signals in the display refreshes ( bug #40 ) and then you'll see the digital traces lag behind the analog for one refresh event( #41 in my personal buglist ).

A proper buglist for the MSO(MST) models has not been published yet, allthough Tinhead might be working on one, as far as I know.

[morris6]

Thanks for the info on your measuring details.

The other bug about the noise on the LA traces has been seen before. It really becomes unstable at high horizontal speeds.

About memory depth: This could be an issue because up to 512KB per channel is specified.

[morris6]

Just an update on the Pass/Fail crash.

I received an update from Tekway that appears from the file name to be the same version (130306) we have all been using, but I have not had a crash in the last 3 days. And I was running Pass/Fail tests for about 9 hours yesterday.

Pass/Fail was unusable for me before this.

The only thing that suggests it is not the same version is that the file size s quite different.

dst1kb_2.06.3_15202b_fact_130306.0_.up - 2888019 bytes

dst1kb_2.06.3_01102b_fe(130306.0).up - 2,800,232 bytes

Can you please attach this new update? I, and maybe others, would certainly like to have a look at it.

[Mike Warren]

Can you please attach this new update? I, and maybe others, would certainly like to have a look at it.

Sure. Just keep in mind that I know nothing about this update or if it will have negative effects on other models. My model is a Tekway DST1102B.

The forum won't let me post the file for some reason, so I've put it here:

http://mike-warren.net/play/dst1kb_2.06.3_01102b_fe(130306.0).zip

I've used the Pass/Fail a bit more and still it hasn't crashed for me.

[tinhead]

only help.db is different, Tekway's firmware have as well two extra languages "Spanish.lan" and "Portugal.lan"
but it lacks "Chinese.lan" and "Tridchn.lan".

This might be already reason why something work or didn't work properly.

[Mike Warren]

only help.db is different, Tekway's firmware have as well two extra languages "Spanish.lan" and "Portugal.lan"
but it lacks "Chinese.lan" and "Tridchn.lan".

This might be already reason why something work or didn't work properly.

That's really weird then. Surely different language files would not effect stability of the Pass/Fail. If it does, then there is some very poor programming being done.

[tinhead]

in principle only the set as active lan file is in use, all others are only loaded once during startup.
If there is somewhere memory overflow due wrong character in one of the lan files, then it can be that the
executable is crashing. Due all these foreign languages you never know.

On the other side, as i tested this fw version, i loaded only English.lan (which i do by default, everything else deleted)
but i had same pass/fail error, so hard to say what the problem was. Maybe indeed the help.db, which is definitely
loaded the whole time. I will test this tomorrow.

[NCG]

To clarify - the 2M capture works as selectable menu option:

* with hacked kernel check,
* suitable kernel,
* with files from BM/BMV.

Actual 2M capture does not work fully - the sample buffer size seems still to be 1M or there is some other glitch - a bit from capture is missing or the capture is folding back after 1M and is repeated - have to test with sweep signal to see how much and what is repeated or missing.

As I understand it, the CPLD design is exactly same for both handheld and benchtop. Handhelds have differing CPLD pin connected to SDRAM address pin SRA18 - are both CPLD pins (62 [benchtop] and 47[handheld]) then outputting simultaneously SRA18 signal on two CPLD pins?

btw NCG, you can switch to higher linux version by doing following stept:
1-  run http://embdev.net/articles/Tekway_MSO#Firmware_upgrade to get Linux and MSO firmware
(with all these steps -> backup of your factory files, installation of MSO fw, resotre of your factory files)
2- install special BMV model firmware on your temp MSO model, http://www.mikrocontroller.net/topic/289260#3094394
You need to run the *dodso* file, http://www.mikrocontroller.net/attachment/173447/dst1kb_2.06.3_dodso.up
3- use the regular BM/BMV firmware once. You might consider changing logo as well, as described in this thread here somewhere.

yeah, here we go ... on your DSO(MSO) it is bad idea to use regular BM/BMV updates, they will of course replace the rcS,
for a regular B model user this does not matter, but for you it does as you have MSO.

For you make sense to use this solution

http://www.mikrocontroller.net/topic/289260#3126759

and then to copy (as you haev anyway network on your MSO) the unpacked firmware files instead of install them.
For sure this "sucks", on one side you have 2M on board, on the other side you have MSO.

[morris6]

Learned a lot lately, reading about toolchains and cross compiling. I am thinking about an utility to write characters to the frame buffer as part of a menu system before dso.exe is started. Specially the 'EDIT:' section in your post gave me the idea that it must be possible for me to set up the 'environment' and cross compile some stuff.

in the gpl code (e.g. for MSO) there is in "third_part" directory the 4.3.3 gcc toolchain, with all the libs whcih need to
be set in ldconfig flag. I made it very simple, created new directory in third_part, copied fpga code there, re-used make file
from "bmptogif", added section in make file in dir above nad in top dir - that's all. Now, when i compile kernel and drivers
and what so ever tools the fpga code will be compiled as well (with proper gcc, libs, etc. - no need to spend any unnecessary
second on that).

EDIT:
attached my sources and make files. All you need is to download the MSO GPL sources, install them into /opt/build/mso_env,
untar attached file to / and build it (make from /opt/build/mso_env or /opt/build/mso_env/third_part)

I have a 'MSO_env.tar.bz2' file, from a cd that comes with the Voltcraft MSO5062B. When I 'tar xvjf ~/MSO_env.tar.bz2' from a new /opt/build directory it looks like a complete environment: actually it untars to a 'dso_handheld_env'. A (sudo) 'make' from here ends in errors. As expected, since my host system is different from the one the 'environment' is copied from.

I guess this is what Tinhead means with: "install them into /opt/build/mso_env". But a 'configure' script is not available here, where do I start?

[tinhead]

it does make sense to compare if the version you got from CD is the same as on website.

I'm using this one

http://www.eedownload.com:8888/mso.zip

but there is also older version available

http://www.eedownload.com:7635/MSO_env.tar.zip

You don't need to configure anything, simply make clean and make.
I had to, for some reason, to make first bootloader and then make all, probably because i missed first time to clean first.

[morris6]

I just started these new downloads, they will take some time since it's going slowwwwwwly. In the mean time I will compare the cd file with earlier downloads, from the suggested ones at the top of this thread or so.

[NCG]

Had time to check it over- 2M seems to still adress 1M only. The signal is just sinus with continiously falling amplitude. First trigger with 2M mode also does not respond - waveform appears after second trigering. Also the save to USB function does not function at 2M.

[morris6]

it does make sense to compare if the version you got from CD is the same as on website.

I'm using this one

http://www.eedownload.com:8888/mso.zip

but there is also older version available

http://www.eedownload.com:7635/MSO_env.tar.zip

You don't need to configure anything, simply make clean and make.
I had to, for some reason, to make first bootloader and then make all, probably because i missed first time to clean first.

About the newly downloaded (10 hours download time) GPL sources for the MSO : mso_env.tar.bz2:

Although this archive has a later date than the one from the cd it results in the same 'environment': directories and files have the same dates. And, as expected, 'make clean' and 'make' did not work correctly.
The 'bootloader first' trick did away with a faulty path variable, visible in the screen output, but still the process ended in errors. Here an 'old' path was set to '/home/GPL-Source/handheld_scope/project_handheld_dso/dso_handheld_env/bootloader/' while '/opt/build/mso_env/bootloader/' was intended.
Most prominent error: "/arm-linux-gcc : Command not found", while this file is indeed present. Looking for the dependencies I found /lib/ld-linux.so.2 file missing. Google learned me this is needed but missing on 64 bit systems, like mine. Can be solved by installing 'ia32-libs'. This provides the ability to run 32 bit programs and installed the missing file, amongst others.

Now my system is happily churning away on its 'make' task. It ends with an error: where it wants to do 'chmod 777 release/rootfs/dso/app/*', No such file or directory. But that is to be expected, I think, because that is where some non GPL utilities are supposed to go into. Now there's nothing there.

Another lesson learned.

[tinhead]

Another lesson learned.

i spend half a day to fix all these things, that's why i have made vmware with "running debian env".

[spaceman]

Hi

I am about to purchase a Hantek DSO1102B Oscilloscope,
and I would like to ask a small question..

Is it true that the Hantek Handhelds do not have a Wave Generator?


This is the model that I am about to purchase:
http://www.diyertool.com/measuring-equipment/oscilloscopes/handheld-digital-oscilloscope-hantek-dso1102b.html


Will I not have a Wave Generator in it? :/

[tinhead]

Hi

I am about to purchase a Hantek DSO1102B Oscilloscope,
and I would like to ask a small question..

Is it true that the Hantek Handhelds do not have a Wave Generator?

yes, only DSO8060 have wave generator

[spaceman]

yes, only DSO8060 have wave generator

hmm..

the DSO8060 is relatively an old model, If I understand correctly.
It's 60MHz, 250MSa/s.

Compared to the DSO1102B, which is 100MHz, 1GSa/s.


Since this will be my only scope,
Will it be a wise decision to buy it?  to buy a scope that does not include a Wave Generator?

[spaceman]

Small Update:


In this image, in the top part of the DSO1060 we can see 2 terminals:


http://toolboom.com/en/Articles/Review-of-Hantek-DSO1060-Handheld-Oscilloscope-Oscilloscope-plus-Multimeter.html


That review says that the DSO1060 has a "connector output of square-wave generators".

Does the DSO1102B have those?
Can the Frequency an Voltage of that square wave be set?

[tinhead]

That review says that the DSO1060 has a "connector output of square-wave generators".

Does the DSO1102B have those?
Can the Frequency an Voltage of that square wave be set?

this is 1kHz, 5Vpp square wave output for probe compensation, this is not a waveform generator nor awg generator.
You will find such probe compensation test signal on 99% DSOs, some with 1kHZ/1MHz, or 5MHz, some with 500mVpp, etc.

From Hantek product palette (as of today) only the DSO8060 have waveform generator (in this case AWG) functionality,
this is actually an "integrated DDS-3x25". The disadvantage of DSO8060 is of course the 250MS/s sample rate.

[spaceman]

OK 1KHz won't be good ..

From Hantek product palette (as of today) only the DSO8060 have waveform generator (in this case AWG) functionality,
this is actually an "integrated DDS-3x25". The disadvantage of DSO8060 is of course the 250MS/s sample rate.

I must say, very weird decision by Hantek.
It's a functionality that is easy to embed,
and more over, if they already wrot the UI for it, in the 8060, why not continue using it in all subsequent models..


OK,
since I really like the Hantek Handhelds,
my decision now should be:

1102B   (with 100MHz and 1GSa/s)
or
8060   (with 60MHz and 250MSa/s)


May I ask for your opinion?

I must admit that I am mostly playing with Microcontrollers, like Arduino and such..
I am not an expert..

[jellytot]

Well my Hantek DSO5102B  hw version 1005 is now unusable, over the past few months it was having difficulty passing its self calibration stopping at different parts of the calibration sequence.
I decided to remove the board to clean it as there was some flux deposit still visible.
Well after assembling it , it appeared to be working fine and passed calibration repeatedly, so I left it
overnight only to find that it started failing again the next day. and now it doesn't get pass test
25/36 failing with the error 0x702 and then rebooting, when i try to use the scope its measurements are all over the place any ideas as to what is happening? has it happened to anyone else, or have i just been unlucky, is it curable? anyone got a spare board for sale? Regards jellytot