New Hantek DSO2X1X models?

[DavidAlfa]

Not exactly, because they key presses are still shown in dmesg.
It's something related to the shell.
The only thing I know is that libanolis starts the update package with "sh -c", which probably affects it.
I'm not a pro at linux

[AndrewBCN]

Not exactly, because they key presses are still shown in dmesg.
It's something related to the shell.
The only thing I know is that libanolis starts the update package with "sh -c", which probably affects it.
I'm not a pro at linux

When the shell is started with "sh -c <string>" then the shell does not accept input from the keyboard but instead takes the string and processes it as a command.

[DavidAlfa]

Not exactly, because they key presses are still shown in dmesg.
It's something related to the shell.
The only thing I know is that libanolis starts the update package with "sh -c", which probably affects it.
I'm not a pro at linux

When the shell is started with "sh -c <string>" then the shell does not accept input from the keyboard but instead takes the string and processes it as a command.

And as that's done by the updater process, I guess it's impossible to escape that.
I mean, the updater script is executed inside that shell.

In the end I made a doom package anyways, but it runs automatically when the doom files are found.
You can see my issue more detailed in the hacking thread.

To run doom, check my drive folder! (Fixed the link in my profile) 

[SimonM]

after the firmware(dso3kb_20210416) usb stopped working.
Sorry for my English.
https://youtu.be/8ov14v8Vshg

Sergey,

I have the same version of DSO2D15 - ordered it earlier in the week and it arrived yesterday.

I put the latest version of the firmware from the hantek.com website on it without issues except I didn't know that the .rar file has to be unpacked to be a .upk file before it becomes accessible. Not had any issues with the old firmware or the new one. USB stick continues to work and I saved some .bmp (see the attached) when learning how the scope works.

Are there different versions of the hardware as I see references to 3000 and similar numbers of the forum?

Simon

[DavidAlfa]

It appears there're 3000, 3101, 3102 and 3200 versions.
Apparently 3200 breaks calibration on other versions. Nothing to worry about, as it's easy to restore it.
But none of the system updates from hantek changes that (except 20210510, which was removed fron Hantek site)

[imk]

after the firmware(dso3kb_20210416) usb stopped working.
Sorry for my English.
https://youtu.be/8ov14v8Vshg

Sergey,

I have the same version of DSO2D15 - ordered it earlier in the week and it arrived yesterday.

I put the latest version of the firmware from the hantek.com website on it without issues except I didn't know that the .rar file has to be unpacked to be a .upk file before it becomes accessible. Not had any issues with the old firmware or the new one. USB stick continues to work and I saved some .bmp (see the attached) when learning how the scope works.

Are there different versions of the hardware as I see references to 3000 and similar numbers of the forum?

Simon

(Attachment Link)

Hello SimonM

I have the DSO2D10 and if you follow this thread you will see i only received my scope couple of weeks ago and have found some very annoying bugs
The most significant of these was it crashed and had to be power cycled to get it going again.
What caused it to crash was using the rotary encoder controls like Vertical Position, Volts/Dev  and timebase Sec/Dev.
My scope came with installed Software 20210416, i contacted Hantek about this lockup issues and they sent to me a link to download dso3kb_20210510 from.
After installing dso3kb_20210510 it still shows up in the info screen as 20210416 (I guess an oversight when they rebuilt the code in a rush)
dso3kb_20210510  has significantly improved my  DSO2D10 with respect the the crashes  in normal waveform use Sine/Square etc in fact it hasn't crashed once.
However dso3kb_20210510  still has significant crash/lockup issues when using UART/i2c Serial Triggering/Decoding in RUN Mode.
Inasmuch as i you rapidly operate the Sec/Dev timebase control during Serial Trigger/Refresh cycle it locks up, so rotate Sec/Dev with care and you maybe ok.
So i have emailed  Hantek again and am looking forward to another software upgrade in the no to distant future i hope.

However, I don't think dso3kb_20210510  was well tested as it seems to have caused several other issues so upgrade to it with caution.
You can see on my previous posts some of the issues I have reported to Hantak.

Hope it works out for you imk

 




 

[SimonM]

However, I don't think dso3kb_20210510  was well tested as it seems to have caused several other issues so upgrade to it with caution.
You can see on my previous posts some of the issues I have reported to Hantek.

Hi Imk,

You can see that I only made one post before today and I'm still trying to figure out some things about the scope.

It has been 40 years between using a scope at university and now when I wanted one. For a while, at work, I used logic analyzers, but it has been a software-only world for me for the last 30+ years. For what I want now - using Raspberry Pi and Arduino the 10 version would have more than met my requirements but was out of stock so that's why I have the 15 version. It was also a gift so the additional small cost was covered by the giver!

The version of the software on mine was older than yours and I did consider leaving it ASIS but eventually decided that it made sense to use the latest published version. It may have been a mistake as I didn't have any problems and I still can't find issues with the current version. I have tried the timebase and voltage sensitivity changes but don't get any kind of lockup.

You mentioned a newer firmware version and I notice that this was initially put on the Hantek site and then withdrawn. I know from writing and supporting software that fixes are published and eventually "rolled" into a new release.  Since it can be difficult to build fixes for everyone there seems to be a tendency to roll up support updates for several issues and there may be problems resolved but also new undesirable "features" (bugs) that also get introduced.

If I had an issue that required an update and I could be sure that I could revert to a previous version then I would take an update to verify that something could be fixed but probably go back to a known version and wait for the official release. I would also wait a time to see if the new version is deemed a success by the community. It seems this later version was rushed out to please a few folks but also regressed a few things (I also don't want to be a long-term beta tester...). Perhaps you know that it is possible to go back to a previous version?

The FFT for analyzing harmonics looked interesting and I realize that the number of samples points is limited (compared to a dedication SA), so I was initially disappointed that I couldn't look at a square wave and set the "span" to show just a few of the odd harmonics. I was going to write it off until I realized that the calculation requires thoughtful selection of timebase e.g. garbage in = garbage out (user error). Now that I have a better understanding, all is well and the results are what you expect. I haven't noticed a delay from setting it up to seeing the result and I do like the immediate feedback of twiddling knobs rather than clicking software and simulating things with software. That's also why I wanted a "bench" scope and not a unit that needs to be connected to a PC. For me, that would just be too convoluted. The signal generator function is more than I might need and I don't already have one to experiment with.

Is there any difference with the B probes? I see the spec for PP-150B and PP-150 and they seem the same? They are also both 100 Mhz probes so I can't see any reason to use 150 in the name. The same thing for the other probes, as the naming doesn't match the -3dB response of the (theoretical) spec. To match a probe to a scope, isn't it necessary to use a much higher rated probe as the response is something like the square root of the sum of both probe and scope. I noticed that the response of a PP-150 doesn't fall off much to about 350 Mhz e.g. is probably better than you might think. In fact, I do wonder if there really is much difference with the more expensive probes (except, they keep more of your dollars).

One thing about a probe, when the clip is removed, should there be a probe point? I am probably doing something wrong because the probe tip is in the hook part and so the probe accessories like the spring and yellow covers etc. have no use, and the probe can't be used without the hook. Perhaps the PP-150B just means PP-150 (broken version). Perhaps my understanding falls a bit short and you can of course forget a lot in 40 years!

Simon

[imk]

Hello Simon,

So which version did you install the dso3kb_20210416 or dso3kb_20210510 my scope came with dso3kb_20210416 and was crashing all the time.

I notified Hantek and couple of days later they sent me a link to download dso3kb_20210510.
After installing it the situation has improved as and now only seems to crash when serial triggering and protocol decoding.
Although when serial triggering I changed the memory depth from 4k to 4m and it crashed.

It is interesting to note that after installing  dso3kb_20210510 it still shows in the utility menu that dso3kb_20210416 is installed.
However there is a 5k size on disk difference between the dso3kb_20210416  and dso3kb_20210510 plus it is more stable on my scope.

Which raises an interesting question, are there different hardware versions of this scope and there will there ever be a firmware that works well on all versions.

As for me and my scope, i am still wondering whether to keep it or get the siglent  SDS1202X-E and a separate waveform generator which was something i was really trying to avoid as i have limited space these days.
imk

[tttonyyy]

Simon I think the B is just for the "black" aesthetic to match the scope styling. There is a PP200B as well in the black style.
The probes are physically different - the compensation adjustment on the B ones is at the probe, on the non-B it is at the BNC end. And the ground clip is shrouded on the B. No idea if they perform differently though.

[DavidAlfa]

I found that anything over 40K limits to 250Msps.
Also, I'm starting to think that the 1Gsps is BS.
Reading a 160MHz signal, the result is the same whether CH2 is enabled or not...

[tttonyyy]

Good analysis Simon. It would make sense for there to be faster caching for short bursts, but then a reduced rate for extended memory access once the cache area is exceeded.
Interesting that the memory can be overclocked so much though (see the hacking thread) to the point where the larger storage sample rate could potentially be doubled.

[Marvinmg]

My DSO2D15 is a lemon and Hantek’s support sucks

In March I bought a DSO2D15 having read the posts on various forums which gave the consensus that the Hantek hardware was acceptable but the software was rather buggy.  On receiving the DSO and exploring is features various software bugs that locked up the machine were experienced but as Hantek were issuing firmware updates I expected they would eventually have fixes for major software problems.
Unfortunately I then begin to find that my unit exhibited a number of significant problems in its basic operation.
•   Traces exhibited phantom noise on signals. I don’t mean digitation noise of a minor division or so, but random spikes that can be up to 1 major division high on displayed waveforms, including those directly from its internal signal generator.
•   Poor triggering. The unit is unable to sync stably on just basic waveforms, even its calibrator and its internal signal generator.
•   Significant offset on channel traces after zeroing. The voltage measurements displayed are affected by these DC offsets. On attempting calibration to correct the problem the calibration procedure usually failed with varying error messages. Even if successful the offsets remained.

These problems mean that the scope cannot be relied on to stably or accurately display even basic signals.

After trying a number of the firmware up-grades without any success in resolving these problems I contacted Hantek support. In describing the problems, I mentioned that I had observed the waveforms from the internal generator and from external circuits with my analog scope and that the waveforms appeared clean and were able to stably trigger.
Hantek asked me to send them comparative videos of the DSO and the analog scope to show the problems described.  I sent the videos.  Now after 4 weeks I have received no response, even though I sent weekly follow up emails. In my last email I advised Hantek that if I did not receive a response I would post the problems with their instrument to the EEVBlog Forum for all to see. No reply was received.
It appears to me that these problems are either hardware design issues or a manufacture problem with my particular unit.

I would therefore suggest to those contemplating the purchase of a DSO2x1x to be aware that they could also receive a lemon and if so will get poor/no support from Hantek.
If anyone is interested in seeing the videos and screen captures of the problems, they are at https://drive.google.com/drive/folders/1MrwXf4mSIksYND4oyVKzrqQihpCTnqy2?usp=sharing

Sorry about the x-post but I originally posted to a less visited topic.

[QuitButton]

I too am returning the scope to Amazon. I've been emailing Hantek about the calibration problem for a few weeks and each time I get the same reply about letting the device warm up for half a hour before calibrating.

It just isn't getting though to them that there's a fault with these scopes that needs addressing.

Marvinmg  - what version of the firmware are you running? All the ones I've tried show "DC, AC RMS and DC RMS" on the DVM.

I also have a fault with captures that fill the acquire buffer. If I scroll to the end of the capture there's a massive amount of noise at the end of the buffer. Attached pic shows input from signal generator, CH1 is clean, CH2 is full of noise.

[imk]

MarvinMg

I noticed on one of your videos you had the trigger mode set to Auto, do you find it more reliable in Normal.
I am going to make a video of the Serial Trigger/Decode lockup problems i am having later this evening, i'll post again when done. .

imk

[imk]

As promised here is link to lockup video while adjusting the timebase sec/dev during Serial Trigger/Decode.
As in the video sometime it takes only a turn or two of the Timebase other times it takes a bit more effort to expose the problem.
When i originally received the scope about two weeks ago, adjusting almost any of the Rotatory Encoders would cause the scope to freeze.
So i contacted Hantek support and the sent to me  dso3kb_20210510.zip which has helped a lot.
Inasmuch as much as i can display normal waveform sine/square on both channel over a wide frequency range without issues

However as can be seen the scope freezes during serial trigger decodes for the two serial protocol I have tested  UART and i2C
Plus i have had lockup issues when adjusting the Acquire->Mem Depth to 4m
Also sometimes the SDA goes nuts and just displays Noise Spikes at high Mem Depth's

(Filmed Entirely On Location "My Man Cave" )

imk

PS I just did same test again and in first click on the Timebase Sec/Dev it locked up :-)
It is random inasmuch as it happens just when you catch the refresh at the wrong time, ouch!

[imk]

Sometimes when display serial protocol triggering the display goes noisy.
Sometimes the SDA of i2c get completely distorted and almost looks like it is displaying some other protocol

[imk]

Simon,
I2c is bit trick to setup, so us UART serial trigger decode
Write a simple Arduino app to send "Hello World" to the serial port at 9600 bps every second
and setup scope to Serial Trigger off that and problem is same one my scope.
Tricky bit to setup on the scope is the Data Byte to trigger off Look For The Two Little Red Dots, took me two hours to spot them, tired eyes :-(

[imk]

Simon,
Did you go through the calibrate process on your scope?
As far as serial trigger is concerned when you have your Arduino app sending.
Trigger off falling edge first (the start space)
When you have that working, move on to trigger of a data byte in the message, it is bit more trick to setup
I am out this morning to mid afternoon so will catch up with progress early evening.
Sent the two video links to hantek but no reply yet.
imk

[Sergey_Malyshev]

I noticed that after warming up and calibrating the device, version 3101 of the signal generator works with overvoltage.
And the instrument has stopped copying the image to USB.

[QuitButton]

I noticed that after warming up and calibrating the device, version 3101 of the signal generator works with overvoltage.
And the instrument has stopped copying the image to USB.

Is it the signal generator or the scope's voltage reading that's wrong?

[Sergey_Malyshev]

Shows exactly 5 v from the calibration output

[Marvinmg]

RE: My DSO2D15 is a lemon and Hantek’s support sucks

A few clarifications to questions I have been asked on the setup and software version of my problem scope.

Software 1.0.1.1.0 (20210416.00)
Hardware 000.000.000.000.000.000.000.001
Firmware 3000

I have not updated the software past the mid-April version expecting that Hantek would ask for further clarifications and did not want to introduce new variables.

I believe that I did my due diligence before purchase. I was prepared to put up with some software bugs but not for this lack of basic functionality. We use a number of earlier model Hanteks where I work and they are fit for purpose.

Wherever possible the tests were undertaken with the scope’s default setup settings and the recordings used the internal generator’s default 1KHz sine/square wave output.
I also checked with the output from a Tektronix ARB and saw the same problems.
 
I usually use Manual trigger settings on a scope but the Hantek defaults to Auto. Trying Manual makes no improvement though. The scope often would not trigger at all or freezes after selecting manual.

The error messages received on calibrate were 51126 and 50081. Hantek has not told me what these codes mean. Up to now I have been dealing with caiyijun@hantek.com so if anyone knows of someone at Hantek who is helpful I would appreciate an email address.

[DavidAlfa]

Mine also has the Lemontree 2090, came with SW 20201221 and had a lot of crashing too, it was so bad that I almost returned it.
Since I overclocked it, the crashes are very rare. Even with the same factory fw. So I guess the main issue is the CPU not being fast enough to react to the events.
I finger-probed the soc while running pi bechmark. The temperatures were warm, not burning hot. So it's ok.
Also, the CPU voltage is untouched (Although I will look into this, reaching 1GHz would be great  )

After a week of using it with no major issues at all (Except crappy decoders and defficient trigger detection in some Vdiv modes), yesterday I crashed the system because I forgot a " in a boot script, causing the system to hang in the middle of the boot process.
I flashed with platform tools, and didn't remember to apply the overclock script. It felt like a gameboy minning bitcoins!
After reinstalling it, it was much better. It'll never perform like a $1000 DSO, but at least it's better than factory.

I made a safe update script to apply overclock at boot time, check my GDrive folder!

- Unzip the file into the root of the usb drive
- The overclock folder should be in the root of the drive

Install
- Run system update and select "dso3kb_install_overclock.upk" file.
- The system will reboot automatically.

Uninstall
- Run system update and select "dso3kb_remove_overclock.upk" file.
- The system will reboot automatically.

Notes:
- The update consists on 2 files: S99overclock.sh (Runs last at system boot) and oc_manager (Executed as daemon by S99overclock).
- Before applying overclock, it will ensure the system clocks are unmodified.
- There's a delay of 15 seconds to let the FPGA init, so the keyboard works. To abort overclocking press F0 key within that time.
- If you modify any file inside overclock folder, run the install package again!

[DavidAlfa]

I found that anything over 40K limits to 250Msps.
Also, I'm starting to think that the 1Gsps is BS.
Reading a 160MHz signal, the result is the same whether CH2 is enabled or not...

I was looking at a signal with the timebase turned up (to 2ns a division) at an edge. To see the individual dots it helps to have a single shot trigger enabled otherwise it can start to look like vectors.

In the "acquire" screen you can select the memory depth. The 8M option disappears with two channels operating. That seems reasonable because there is only so much memory and so the depth is limited. With the other options, the depth doesn't differ, but then you are not using all the memory anyway.

In the 'display" memory, you can switch between "vector" and "dot". Since the vector mode joins the dots it can be difficult to know when sampling is done. With the dot mode, you will see each dot, and switching the 2nd channel off has several effects:

1. The number of dots doubles e.g. with a 2ns a division showing you will see an edge with dots increasing in Y and placed every 1/2 division.
2. Sampling says 1gs/s e.g. it agrees with what you see. With the second channel on the intermediate dots disappear and the sampling drops from 1 g/s to 500m/s.

When you increase the memory to 400k or higher then the sample rate drops back to 250 m/s or 125 m/s. This suggests that there are two types of memory e.g. a smaller and faster cache and slower memory. Again, that seems reasonable as something has to give when you have access to more memory.

Simon

You're right. The problems comes else from the resolution or the processing. It's so rough that it barely makes any difference.
I guess if the lowest V/div settings are not being amplified, directly feeding the ADC (using less bits).
Because it has more steps than my 5th floor without elevator! All the steps are done in the same y positions, so it's clearly a bit resolution thing.

Check the attached pic. All the steps are exactly at the same Y position. I counted a total 40 vertical steps for the 8 vertical divs.
It would be ok-ish if at least, when zooming out the voltage, you could see the whole signal.
But saturating the signal in 2mV mode and going back to 5mV, you get a square signal of 4 divs. That means the signal was clipped to 200mV.
200mV would be 10 vertical divs in 2mV mode, which would make a total of 50steps and just 5.6 bits resolution.
I think I'll return this crap!

[QuitButton]

It felt like a gameboy minning bitcoins!

Did overclocking help with Roll mode? Roll mode is horribly jerky and shows just how woefully underpowered the CPU is.

(Mine has been returned, I'm not convinced the problems will ever get properly fixed)