Hantek 6022BE 20MHz USB DSO

[RichardK]

Latest Binary: http://jmp.sh/v/NptVTtzwQwZwLEnbZwFe

[Matchless]

RichardK I ran your latest binary to compare my unmodified Hantel 6022be noise level on the Hantek software and yours. I still find my channel 1 very clean with only the odd noise spike now and then on the OEM software. The exact same settings on your software gives corresponding noise levels on both channels.
I have attached two screen shots:

[RichardK]

No idea, I get the data the same way the stock software does...

[rpcope1]

Hi I joined this forum after reading this great thread. I have also bought the Hantek 6022be for all the reasons already mentioned.  The software RichardK is busy with just made it more promising. I still need to understand how to use this DSO properly, as this is all new to me.

I will try to post the noise shown on both my channels when connected to the internal square wave. It interesting to see that channel 2 is nearly clean compared to channel 1.
Both probes were set to X10.
Any comments please?

  Matchless,
Have you added any shielding internal to the oscilloscope? I followed some of RichardK's instructions (thanks again so much dude), and added a couple extra caps and some shielding to the DC/DC converter, this should reduce a lot of the noise you're seeing. I also ran a power spectrum on the base level noise coming out of the oscilloscope after the fact (if you look back a couple pages) and found that most of my noise now was 60 Hz noise, which just means the whole thing needs better shielding (the oscilloscope is plugged into a laptop, so I was pretty sure that probably isn't a noise source). I wouldn't be totally surprised a stock oscilloscope was more noisy on channel 1 than 2, maybe if nothing else because of channel 1's proximity to the DC/DC converter, which really according to it's spec sheet is a little to noisy to normally be used in a scope. Can you build a power spectrum from that signal (and crop out the 10 kHz and harmonics), and show us what the noise looks like? I can certainly say from experience if you add the shielding and caps RichardK graciously posted about you should be able to get the noise about as low as it's going to go for this device. Also, I can post the python script I use to generate power spectrums from the Hantek wave output files if that would help.


  RichardK,
I started to use your binary. Though I can tell it's still a work in progress, this looks so much better. Thanks for your hard work!

[Matchless]

rpcope1,
            This was exactly my intention to follow Richardk's guide. I have just received the DSO and checked the noise and to my surprise channel 2 had no significant noise at the same settings using the Hantek software. I suspected faulty equipment and changed out probes, nothing changed. Then ran it up on Richards software and then both channels showed similar noise levels except that the noise is inverted. Tried the Hantek software and channel 1 only is noisy measuring about 4mV as per the settings in the pictures I posted. This has me stumped.
My settings are; both probes connected to the ground tag on the front panel, both probes on x1, time/Div on 50uS, both channels on 20mV. Channel 1 has noise of about 4mV and channel 2 has an occasional positive going spike of about 4mS. Channel 1 also has an occasional positive going spike, but has continuous noise as in the picture negative going.

On RichardK's software both my channels have the same continuous noise but where channel 1 is negative going, it seems as if channel 2 is positive going.

I can switch to and fro between the programs and nothing changes. The hardware is always the same......?

If anyone else can check this or even post a picture of their screen at the same settings it may help. I was prepared for noise, but with the same result for both channels.

Much appreciated.

[RichardK]

I just did a similar measurement, the results were the same on the latest binary and stock software... It started out with less noise on CH1, but then a few minutes later the noise evened out between channels (both my version and stock software).

Considering my scope was near a window and it's 2F outside, I think it's safe to say it's thermally related and once the scope warmed up, both channels had pretty much the same noise.

Edit: The keen-eyed observer might notice something in the next build that Rick Law was asking for a few pages back

[Rick Law]

I just did a similar measurement, the results were the same on the latest binary and stock software... It started out with less noise on CH1, but then a few minutes later the noise evened out between channels (both my version and stock software).

Considering my scope was near a window and it's 2F outside, I think it's safe to say it's thermally related and once the scope warmed up, both channels had pretty much the same noise.

Edit: The keen-eyed observer might notice something in the next build that Rick Law was asking for a few pages back

I see it!  I see it!

Thanks Richard!

[Matchless]

RichardK thanks again for  this new improved version you are working on! Thanks for posting the screenshot of your noise, your Ch2 looks just like my Ch1 on the Hantek program version 1.0.3 and like both Ch1 & 2 on your binary

I can see a slight increase in noise on my Ch1 after switch on from cold (ambient temp here is 28 C today). After about 30 seconds no more increase in noise.

The interesting part with my 6022be running on the Hantek program with both probes grounded; only channel 1 is noisy, channel 2 is shows no significant noise at all, just a blip every 3 to 4 seconds.
When closing the Hantek program and opening your binary, both channels show the same noise except that they seem inverted in comparison.

My logical assumption is that this must be tied to the software in some way, as the hardware is not even changed in the slightest, I do not even switch off anything or disconnect anything. I just toggle between the two programs and the result stays the same very time. I am running both on Windows 8.

Could it be that my Channel 2 has some hardware anomaly that matches it to the software differently and thus producing an improved signal display quality erroneously or correctly?
If the two programs are doing exactly the same thing, why should there be two differing results? Channel 2 seems to be working properly, as is Channel 1 except for the noise difference.

All I recall doing since powering it up was to try and run the Calibration function and its just accepted it with no further indication at all.

Maybe I have found the holy grail! If this improvement or anomaly is  pinpointed maybe the noise problem on these could be a thing of the past! Just wishful thinking from my side!

Any inputs here will be appreciated.

[Rick Law]

...

The interesting part with my 6022be running on the Hantek program with both probes grounded; only channel 1 is noisy, channel 2 is shows no significant noise at all, just a blip every 3 to 4 seconds.
...

Any inputs here will be appreciated.

Hi, Matchless,

Let me add some clues to this puzzle.  I have similar problem except it swaps Ch occasionally.  Often, my Ch1 has much less noise to Ch2.  Not quite down to occasional blip, just Ch1 about 1/3 to 2/3 the constant noise of Ch2.  Then, occasionally, without probe swapping, without disconnection, I turned it back on to continue prior work (ie:it is connecting back to the same circuit at the same point.), the "noise channel" reverse and Ch2 is 1/3 cleaner than Ch1.

My guess is, it is software artifact but not real.  I think packets were dropped.  Something unknown affects which channel has lower priority (got processed second? got less package?) and the trace was smoothed out rather than it being less noise.

Rick

[limpid]

Hello, anyone know bandwidth and div/v relationship for DSO6022BE?

[RichardK]

Hello, anyone know bandwidth and div/v relationship for DSO6022BE?

These are the sample rates for corresponding Time Divisions:
Note: They are in the exact same order as the Time/DIV Drop-down list of the stock software.

Code: [Select]

//Time Division
enum THantekTimeDivision
{
 //1016 samples
 HTTimeDiv48MS_1NS=0, //960, 1, 1
 HTTimeDiv48MS_2NS=1, //960, 1, 1
 HTTimeDiv48MS_5NS=2, //960, 1, 1
 HTTimeDiv48MS_10NS=3, //960, 1, 1
 HTTimeDiv48MS_20NS=4, //960, 1, 1
 HTTimeDiv48MS_50NS=5, //960, 1, 1
 HTTimeDiv48MS_100NS=6, //960, 1, 1
 HTTimeDiv48MS_200NS=7, //960, 1, 1
 HTTimeDiv48MS_500NS=8, //960, 1, 1
 HTTimeDiv48MS_1US=9, //960, 1, 1
 HTTimeDiv48MS_2US=10, //960, 1, 1

 //130048 samples
 HTTimeDiv16MS_5US=11, //800, 1, 1
 HTTimeDiv8MS_10US=12, //800, 1, 1
 HTTimeDiv4MS_20US=13, //800. 1, 1
 HTTimeDiv1MS_50US=14, //500, 1, 1
 HTTimeDiv1MS_100US=15, //1000, 1, 1
 HTTimeDiv1MS_200US=16, //2000, 1, 1
 HTTimeDiv1MS_500US=17, //5000, 1, 1
 HTTimeDiv1MS_1MS=18, //10000, 1, 1
 HTTimeDiv1MS_2MS=19, //20000, 1, 1

 //523264 samples
 HTTimeDiv1MS_5MS=20, //50000, 1, 1
 HTTimeDiv1MS_10MS=21, //100000, 1, 1
 HTTimeDiv1MS_20MS=22, //200000, 1, 1

 //1047552 samples
 HTTimeDiv1MS_50MS=23, //500000, 1, 1
 HTTimeDiv1MS_100MS=24, //1000000, 1, 1
 HTTimeDiv500K_200MS=25,//1000000, 1, 1
 HTTimeDiv200K_500MS=26,//1000000, 1, 1
 HTTimeDiv100K_1S=27, //1000000, 1, 1
 HTTimeDiv100K_2S=28, //2000000, 1, 1
 HTTimeDiv100K_5S=29, //5000000, 1, 1
 HTTimeDiv100K_10S=30, //10000000,1,1
 HTTimeDiv100K_20S=31, //20000000,1,1
 HTTimeDiv100K_50S=32, //50000000,1,1
 HTTimeDiv100K_100S=33, //100000000,1,1
 HTTimeDiv100K_200S=34, //200000000,1,1
 HTTimeDiv100K_500S=35, //500000000,1,1
 HTTimeDiv100K_1000S=36,//1000000000,1,1
 HTTimeDiv100K_2000S=37,//2000000000,1,1
 HTTimeDiv100K_5000S=38,//-1,1,1
};

Not sure what you mean for Voltage Divisions in respect to bandwidth, all I can tell you is the vertical resolution is limited to 256 bytes (even though the SDK uses a short).

[Rick Law]

Hello, anyone know bandwidth and div/v relationship for DSO6022BE?

I listed them on another tread when someone else asked the exact same question:
------------------
At 50ms (1Mhz) it starts acquiring at full 1M samples (1,047,552 for each channel total 2x1047552)

At 20ms (1Mhz) it is at 523264 samples each Channel
At 10ms (1Mhz)= 523264
At 5ms (1Mhz)= 523264

At 1ms (1MHz) = 130048
At 100us (1Mhz) = 130048
At 20us (4Mhz) = 130048
At 10us (8Mhz) = 130048
At 5us (16Mhz) = 130048

At 2us (48Mhz) = 1016
Anything faster than 2us, it is still at 48MHz at 1016 samples each channel (2032 total)
------------------
Additional info since that post - only starting thinking about it recently when RichardK's program made it less painful to go slow division and find the trace (thanks, Richard):  The slowest is 100KHz.  At 1meg memory, you have max a bit over 10 seconds worth of data.  So, if you set your scope to 10sec/division, your trace will fill only a bit over 1 division and the rest of the trace-screen is blank.

[fery13013]

HI for everybody,

could you perhaps help me?
I have this equipment, used it with my desktop pc.It was fine.
Then I connected it to my other desktop, I checked the reference signal and it was not 1 kHz, but about 1,9 kHz ( T= 540 microsec).
Where is the problem?

[Rick Law]

HI for everybody,

could you perhaps help me?
I have this equipment, used it with my desktop pc.It was fine.
Then I connected it to my other desktop, I checked the reference signal and it was not 1 kHz, but about 1,9 kHz ( T= 540 microsec).
Where is the problem?

Repeat the whole thing first with your two PC's.  If you get the same result, try a third PC.  That will help determine what is faulty.

[fery13013]

I repeated it and I checked both of them with a second signal, with an exact frequent also. My second pc shows me a wrong frequent.  The question is why?

[limpid]

thanks, I ask them, they tell me below data, this is correct?

1.
V/div and bandwidth relationship for you reference as below?

Volt/div
   

Bandwidth

20mV, 50mV, 100mV
   

10MHz

200mV
   

12MHz

500mV, 1V, 2V, 5V
   

20MHz
 
2.
No attenuation, cut off voltage -+5V, attenuation 10X, -+50V.

Looks question1, it is not correct, how about with question2?

[Mark_O]

thanks, I ask them, they tell me below data, this is correct?

1.  V/div and bandwidth relationship for you reference as below:

Volt/div                             Bandwidth

20mV, 50mV, 100mV         10MHz

200mV                             12MHz

500mV, 1V, 2V, 5V            20MHz
 
2.  No attenuation, cut off voltage -+5V, attenuation 10X, -+50V.

Looks question1, it is not correct, how about with question2?

Why do you think that Answer 1 is not correct?  It's fairly normal for the effective BW to drop at higher sensitivity settings.

[Matchless]

Let me add some clues to this puzzle.  I have similar problem except it swaps Ch occasionally.  Often, my Ch1 has much less noise to Ch2.  Not quite down to occasional blip, just Ch1 about 1/3 to 2/3 the constant noise of Ch2.  Then, occasionally, without probe swapping, without disconnection, I turned it back on to continue prior work (ie:it is connecting back to the same circuit at the same point.), the "noise channel" reverse and Ch2 is 1/3 cleaner than Ch1.

My guess is, it is software artifact but not real.  I think packets were dropped.  Something unknown affects which channel has lower priority (got processed second? got less package?) and the trace was smoothed out rather than it being less noise.

Rick

Thanks Rick, I am just going to sit tight and follow this thread. With RichardK's improved software seeing the light, I expect a lot is going to happen here over time. Many thanks for your input. Maybe soon, I will have both channels properly noisy or a miracle and both channels without noise!

[Matchless]

The keen-eyed observer might notice something in the next build that Rick Law was asking for a few pages back

I actually also prefer both channels with separate controls as in the picture of your latest PR8 version! Will check it out as soon as you make it available!
Thanks again for doing all this!

[RichardK]

Latest Binary: http://jmp.sh/v/GxYh8cys9Rbbf3HAlLqG

[A_L_E_X]

Hantek released an update of the software (1.0.4), but i haven't noticed any changes to the GUI. They must have corrected some bugs.

[RichardK]

Hantek released an update of the software (1.0.4), but i haven't noticed any changes to the GUI. They must have corrected some bugs.

The HTDisplayDll.dll has been updated, HTMarch.dll has not changed... I'm comparing the two Display dll's disassembled right now to see what has changed and will test the new DLL with the latest binary.

[Rick Law]

Hantek released an update of the software (1.0.4), but i haven't noticed any changes to the GUI. They must have corrected some bugs.

The HTDisplayDll.dll has been updated, HTMarch.dll has not changed... I'm comparing the two Display dll's disassembled right now to see what has changed and will test the new DLL with the latest binary.

Alex, thanks for letting us know.

Richard, I will be loading your PR8 and test.  Thanks for your effort.

In prep for testing Richard's new release, I decided to first install Hantek's V104 so I can use it with the latest driver.  Running V104 for a brief time, these are my observations:

1. All the hardware drivers are date 1/13/2014, they are new with V104, as to whether anything is changed within, time will tell.

2. The software looks the same as v103.  But for the window's title, you would not know anything changed - most noticeable change with the UI is the splash screen's modified picture.

3. The software seem more responsive.  The trigger point on a trace seem to be more stable so jittering with the displayed trace seem less.  This is not a scientific measurement but merely by "feel".  Any improvement here is small - small enough that it could be just a low-noise day for me because I turned off something (whatever thing) that might have created lots of electrical noise.

4. RMS measurement on 103 will hang the program after a while, so far, I have not hung it yet but in that similar duration, typically, RMS would have jammed on v103.  A more extensive test will be needed before I suggest that it really had been fixed.

5. I had an unknown hung.  Not sure why. 

6. Worthy of upgrade?  Yes, it just feel more solid with the trigger.  I am not sure why because I am not sure how to quantify trigger stability yet.  The trace that used to wonder (due to changing trigger point) seem to be triggering better.

So, now that I have the new device drivers loaded, let me check out RichardK's stuff first.  RichardK's stuff is far more interesting and far more important to me than this update from Hantek so far...

Rick

[Rick Law]

RichardK,

Thanks, this new PR8 works pretty nice.  I went from 0.01Hz to 8Mhz with random stops every decade or so.  When randomly stopped, I make the channel different frequencies or change wave shape.  I explored various options at that random stop (such as changing line-to-dot interpolation, measurement cursor, so on.  Then I go back to Ch1&Ch2 at equal frequency and move up 10x with possibly another random stop before 10x.

I noticed a few issues - but only issue 1 is a bug.  The other issues are refinements:

Issue 1:

At certain settings, Ch2 will use Ch1's position.  Look at the attached video, you will see the Ch2 trace is on top of Ch1 for a brief time, then disappear, then come back.  But looking carefully: Ch2 trace actually returned to where it should be at the bottom part of the screen.  It will stay there for a flash then go back to where Ch1 is.  The hopping around is non-stop once you get it started.
https://www.youtube.com/watch?v=9l1oj9mdqfQ&feature=youtu.be#

Settings to get that issue going:
Ch1: 110KHz, triangle, +2.76v to -2.76v
Ch2: 110KHz, square, +2.00 to -2.00v
TimeScale 5uS/division
Trigger: Edge, Auto, Ch1, Rising

To Start:
The hopping around does not happen all the time.  To get it going, set it to 5uS then switch between FULL Screen and windowed partial screen, resize the screen, full screen again.  After a few tries, the hopping around will start.

To Stop:
Switch to 10uS and then back to 5uS a few times, the hopping will stop.  (Sometimes it will stop at first switching)

Also:
At 10uS, I can get the hopping going also.  At much slower speed, I can't get it to hop around.

Issue 2:

Using the scope's built-in 1KHz reference wave and with the AC coupling turned on, you see the AC-filtered wave jittering up and down a bit too much.  I think the noise is affecting the evaluated DC offset.  With the offset changing, the trace is moving up and down too much.

If I can suggest, perhaps the evaluated DC offset should be dampen a bit.  Perhaps keeping DC offset unchange unless/until the evaluated new DC offset is at least abs(X%) greater than current DC offset and minimum delta of at least 10mV.  That should make it rock solid if in fact the noise is the cause of the problem.

Issue 3:

I notice that once paused, changing the time-scale doesn't redraw the trace at the new time-scale.  Actually, I found and using time-scale changing to zoom in is easier for me.  If you think so as well, perhaps don't waste time on zooming.

Issue 4:

I miss the regular measurement window.  I can get the current peak/max/min regardless of where in the trace it would occur.  The interactive cursor measurement is very nice, I like it, but it can't do that job.

If I don't have the peak on the visible trace, I can't put the cursor there and I can't measure it.  Same for the unknown-position max and min.  If I can't put the cursor there (unknown-position), I can't measure it.

The standard measurement window does that.  Where ever it may be on the trace, I get the peak/min/max for that duration.

I hope we can keep the interactive cursor along with the old measurement window.

Lastly,

Thanks RichardK!  This is a good release with very nice improvement...   I think Hantek should contact you and give you some add'l info or help.  Or may be even a free sets of probe or something just to show a token of appreciation.

Rick

[RichardK]

Issue 1:

At certain settings, Ch2 will use Ch1's position.  Look at the attached video, you will see the Ch2 trace is on top of Ch1 for a brief time, then disappear, then come back.  But looking carefully: Ch2 trace actually returned to where it should be at the bottom part of the screen.  It will stay there for a flash then go back to where Ch1 is.  The hopping around is non-stop once you get it started.
https://www.youtube.com/watch?v=9l1oj9mdqfQ&feature=youtu.be#

Settings to get that issue going:
Ch1: 110KHz, triangle, +2.76v to -2.76v
Ch2: 110KHz, square, +2.00 to -2.00v
TimeScale 5uS/division
Trigger: Edge, Auto, Ch1, Rising

To Start:
The hopping around does not happen all the time.  To get it going, set it to 5uS then switch between FULL Screen and windowed partial screen, resize the screen, full screen again.  After a few tries, the hopping around will start.

To Stop:
Switch to 10uS and then back to 5uS a few times, the hopping will stop.  (Sometimes it will stop at first switching)

Also:
At 10uS, I can get the hopping going also.  At much slower speed, I can't get it to hop around.

I'm aware of this issue, not sure what's causing it yet, but I'll fix it eventually

Issue 2:

Using the scope's built-in 1KHz reference wave and with the AC coupling turned on, you see the AC-filtered wave jittering up and down a bit too much.  I think the noise is affecting the evaluated DC offset.  With the offset changing, the trace is moving up and down too much.

If I can suggest, perhaps the evaluated DC offset should be dampen a bit.  Perhaps keeping DC offset unchange unless/until the evaluated new DC offset is at least abs(X%) greater than current DC offset and minimum delta of at least 10mV.  That should make it rock solid if in fact the noise is the cause of the problem.

Also aware of this, I think it has to do with the AC coupling taking time to take effect and the wave being drawn before it's done.

Issue 3:

I notice that once paused, changing the time-scale doesn't redraw the trace at the new time-scale.  Actually, I found and using time-scale changing to zoom in is easier for me.  If you think so as well, perhaps don't waste time on zooming.

Probably due to incomplete nature of the code, but will look into it to verify it's not a bug.

Issue 4:

I miss the regular measurement window.  I can get the current peak/max/min regardless of where in the trace it would occur.  The interactive cursor measurement is very nice, I like it, but it can't do that job.

If I don't have the peak on the visible trace, I can't put the cursor there and I can't measure it.  Same for the unknown-position max and min.  If I can't put the cursor there (unknown-position), I can't measure it.

The standard measurement window does that.  Where ever it may be on the trace, I get the peak/min/max for that duration.

I hope we can keep the interactive cursor along with the old measurement window.

I plan on having measurement capabilities (similar to the stock feature) but have not implemented it yet, so eventually all of them will available.

Thanks for the feedback