Hantek 6022BE 20MHz USB DSO

[evgenymagata]

Hello,

first of all, thanks to the people involved with the Open6022BE Software. I got a question though: Since i only have Mac and Linux computers, i am forced to run the Software in a Windows XP Installation in a VirtualBox VM on my Mac.

Generally, the Software works great. Unfortunately for some reason VM seems to limit the options of the DSO significantly: in the horizontal DIV i can only select time ranges between 10us and 2ms or the program crashes immediately. This happens to both the original Hantek and the Open6022be software. Does anyone have an idea how i could resolve this problem?

Cheers,
e.

[djcristi]

you cannot solve it, usb emulation in virtual machine adds latency, and since the DSO operation is real-time, it cannot work.
i also have macbook air with OS x , and it would be great if software existed for this OS.

[Chriss0422]

Hello everybody,


My english is not really good so forgive me. I'm new on this forum.
First of all, I would like to congrats RichardK for his very very beautiful work.
RichardK, if you still read this forum, thanks a lot ! I hope to see you again programming this beautiful software.
It's been a few week I use this software and I have notice some bugs, maybe users can confirm them.

1. I'am in France, so when I click on "Save" button I have systematically an error "1.0 is not a floating point value"
This appears due to the dot separator used in "Image export setting" tab combobox (for Horizontal and Vertical zoom). I suppose the default Windows separator is used and in France it's dot and not comma. This is my hypothesis. It's a blocking point, I can't use the function "save" due to this.

2. When I use Vertical Cursor to measure the time durtion of a signal, the return value is not the same when I change the Time/DIV in order to Zoom In or Zoom Out. I mean, after Zoom out for example, when I readjust the cursor on my signal, the Time duration return is not the same.

3. Sometimes, when I use the scrolling waveform function at the top of the screen, the "T" goes crazy. See attached file.

4. In the case I use normal trigger for acquiring a signal then I click on "Stop" to analyze it.
When I change the time/DIV setting in order to zoom in or out, it's not working. There is no signal redraw.
With single shot trigger, it's works.


Do you have these same behaviour in your side ?

I have collected many other bugs if somebody is interrested in them... Maybe RichardK ? :-)

Sorry again for my poor english language.

Regards,
Christophe

[roderick]

hantek just released a newer version of software v1.0.5 , download link

i will also download Open6022 to see which is better...

Was anyone able to download the software?  It looks like hantek.com is now redirected to some other commercial site.

[SeanB]

hantek just released a newer version of software v1.0.5 , download link

i will also download Open6022 to see which is better...

Was anyone able to download the software?  It looks like hantek.com is now redirected to some other commercial site.

Worked for me. you must be a Comcrap customer.

[rpcope1]

Hello,

first of all, thanks to the people involved with the Open6022BE Software. I got a question though: Since i only have Mac and Linux computers, i am forced to run the Software in a Windows XP Installation in a VirtualBox VM on my Mac.

Generally, the Software works great. Unfortunately for some reason VM seems to limit the options of the DSO significantly: in the horizontal DIV i can only select time ranges between 10us and 2ms or the program crashes immediately. This happens to both the original Hantek and the Open6022be software. Does anyone have an idea how i could resolve this problem?

Cheers,
e.

I had worked on this little cheap-o scope a while back, and got the weird inclination to sit down and reverse engineer it this weekend, so I wrote some Linux (and probably also Mac OSX) bindings for Python (via libusb) if you were looking to use this on a non-Windows machine: https://github.com/rpcope1/Hantek6022API

[daybyter]

I'm trying to run your code in a virtualbox vm, but no luck to far. Kernel shows the scope as an unknown usb device with the correct id, but it seems the python code cannot find the device.

Has anyone managed to run this in a vm?

[rpcope1]

I'm trying to run your code in a virtualbox vm, but no luck to far. Kernel shows the scope as an unknown usb device with the correct id, but it seems the python code cannot find the device.

Has anyone managed to run this in a vm?

I have not tried running it in a Linux VM,  but I could try later. Can you post a screenshot and/or open a ticket on Github? Any error output in general dumped from the console? The code is still a little rough, how good are your Python skills?

As a more general update, it turns out the firmware Hantek shipped this device with has got some bugs and is otherwise kind of  so I'm in the middle of disassembling the 8051 firmware with jhoenicke, and trying to squeeze what little bit of real performance can be had out of the device. I am targetting being able to do 15ish MHz single channel and 10 MHz dual channel _with actual triggering_ by shipping all of the data immediately asynchronously back to the host and letting the host figure out the trigger in parallel with data collection. I'm also going to try and get the Python library rewritten in C and make it compatible with all three major OSes (since libusb should be present everywhere). The board also is provisioned for an external trigger, which appears to be connected to a GPIO on the FX2LP, which may prove fruitful. The end goal is to be able to write some open source firmware for this scope and at least provide the means (via a library) to have this device function in some sort of meaningful way, like  having a working trigger (even if it has to be done host side). I have not decided how much effort I am going to put into rolling a GUI for the library, but it will eventually be more than enough for someone reasonable versed in Python to roll their own. Though this thing is sort of underwhelming in comparison to even my Rigol 1102E, it might be an interesting tool for the Raspberry Pi audience to be able to debug their low speed Arduino and what not via their Pi for under $100 (provided a few hardware hacks and some generous software magic is applied).

[daybyter]

Phew...python skills....I sorta know how it works, but I don't really like it. I'm more a java guy. Your C rewrite might be easier to read for me.

You think, you can get that many data across USB with a constant data rate? Might be some mouse movement come in between, or so...?

[baruch]

As a more general update, it turns out the firmware Hantek shipped this device with has got some bugs and is otherwise kind of  so I'm in the middle of disassembling the 8051 firmware with jhoenicke, and trying to squeeze what little bit of real performance can be had out of the device. I am targetting being able to do 25ish MHz single channel and 15 MHz dual channel _with actual triggering_ by shipping all of the data immediately asynchronously back to the host and letting the host figure out the trigger in parallel with data collection.

An open source firmware would be very cool.

Do you have information/pointers on the firmware code and packaging?
I would love to at least follow the project even if I might not have time to actually hack on this (my 6022BE device is enroute so no real hacking besides disassembly for me for now).

I recently wrote firmware for an existing power supply (B3603) and it was kinda fun to do that.

[2010kira2010]

Hello everybody!

Please!!!!!

Who can copy the firmware eeprom?

[momus]

Rpcope, your research on this scope seems -very- promising.
Your python api seems to be easy to use, I thought I wouldn't have a clue what your examples are doing, but it's quite readable.
I will maybe try to tinker with it.

Creating a good GUI on top of this could be a huge step forward.
If you even manage to open the door to a real hardware triggering, I think I'll build a shrine for you...

[rpcope1]

Phew...python skills....I sorta know how it works, but I don't really like it. I'm more a java guy. Your C rewrite might be easier to read for me.

You think, you can get that many data across USB with a constant data rate? Might be some mouse movement come in between, or so...?

Yeah, there's gonna be some tricky code in there for the time being because we're getting close the limits of performance on CPython (and threading is unfortunately sort of nerfed in CPython anyways which makes life even harder). I am going to try and roll a new oscilloscope program, so you might just watch out for that; I am debating how much if any needs to be done in C (really need a high speed ring buffer).

As far as how much data can be moved, the big thing is you have to make absolutely sure the device is on a bus by itself. You can do this by running lsusb on Linux (not sure what the equivalent for Mac or Windows is), and checking to make sure no other devices on the same bus. As far as moving data, USB 2.0 kind of caps out 30 MB/s so that really sets an upper limit. With the help of Jochen Hoenicke, we've already changed the firmware and driver in a few critical ways that make it significantly more performant than what is available stock. First, Jochen has removed dead code from the firmware, and added an option to only pull data from one channel (by default it always pulls both); this allows you to expend all your USB bandwidth getting more samples for a single channel. Jochen has also added more sampling modes; the default maximum was 48 MSa/s which isn't realizable with USB 2.0 and produces super dirty signals. Jochen has added a new 30 MSa/s mode, which in my testing is way cleaner, and I have been able to stream at 30 MSa/s with less than 2% data loss. On the driver side, I pulled a lot of the stupid Hantek behavior out; the original Hantek driver will try to clear the FIFO on every read, which means you always will lose data, and waste USB bandwidth. The stock driver also did everything synchronously and did not queue up bulk transfers, leading to more data loss and poorer use of bandwidth. I've got an async implementation that makes these changes, and I can get really looking traces at reasonably high speed (30 MSa/s); ideally with a better C implementation or some clever use of multiprocessing, I will be able to realize this performance in an application.

What does this mean? You'll probably not get the advertised "20 MHz" performance exactly, but you'll probably get 5-7+ MHz single channel (or better, with good interpolation), and probably 3-5+ MHz dual channel, and hopefully get good consistent triggering. A lot of this is going to involve lots of interesting software magic.

The board also appears to have traces and holes for an external trigger, I am still examining what it will take to get this integrated into the firmware.

[rpcope1]

As a more general update, it turns out the firmware Hantek shipped this device with has got some bugs and is otherwise kind of  so I'm in the middle of disassembling the 8051 firmware with jhoenicke, and trying to squeeze what little bit of real performance can be had out of the device. I am targetting being able to do 25ish MHz single channel and 15 MHz dual channel _with actual triggering_ by shipping all of the data immediately asynchronously back to the host and letting the host figure out the trigger in parallel with data collection.

An open source firmware would be very cool.

Do you have information/pointers on the firmware code and packaging?
I would love to at least follow the project even if I might not have time to actually hack on this (my 6022BE device is enroute so no real hacking besides disassembly for me for now).

I recently wrote firmware for an existing power supply (B3603) and it was kinda fun to do that.

So firmware isn't so bad on this device. If you look at my repo, it's got the hex code for the stock firmware; the device has no sizeable non-volatile storage to speak of, so the original Windows driver sends the firmware over USB every time the device is plugged in. I was able to capture the data by running Windows in a VM and running a trace on the USB port in wireshark. The MCU that controls the device in the scope is a CY7C68013A (FX2LP), which is really ubiqitous. It sports a lot of GPIO, an 8051 processor and a 4K FIFO that buffers the data. The ADC is an AD9288, which is also as common as dirt. If you're interested in the firmware, i hope you like assembly  . Cypress kind of suggests you use Kiel but I am using mcu8051ide, and there are lots of open source 8051 tools including disassemblers out there; the instruction set on the device is also pretty sane. Pretty much everything use in the scope is well documented, and I can provide further details if you have questions.

[rpcope1]

Hello everybody!

Please!!!!!

Who can copy the firmware eeprom?

No need to copy the EEPROM, it's probably the most useless chip on the board. It doesn't hold any firmware, it just "stores" calibration values that the stock driver uses (and I do not). All of the firmware is transferred by the host everytime the device is plugged in and held in memory; you have to flash firmware every time you power the device up. If you look at my Python API, methods are provided to both read and write the EEPROM if that's your thing.

Rpcope, your research on this scope seems -very- promising.
Your python api seems to be easy to use, I thought I wouldn't have a clue what your examples are doing, but it's quite readable.
I will maybe try to tinker with it.

Creating a good GUI on top of this could be a huge step forward.
If you even manage to open the door to a real hardware triggering, I think I'll build a shrine for you...

I had started to hack together a GUI using matplotlib, but I'm fighting with the fact getting parallelism in CPython is not easy; just consistently reading and trigger is probably enough to saturate a CPython process. I am hoping to work to make the documentation better on CPython also; I'd like to get this to the point where someone with basic Python skills can still use this device in a meaningful way. Real hardware triggering might (or might not) be possible, I just need to slog through the 8051 assembly now. It's also possible that we might be able add significantly better software triggering than the stock software (see my above post).

As an aside, honestly this device is probably more palatable if you think about it as a DAQ with few ports, decent speed and marginal precision; to anyone who is reading this if you're thinking about buying this as your primary scope, trust me, save up and buy a Rigol.

[baruch]

So firmware isn't so bad on this device. If you look at my repo, it's got the hex code for the stock firmware; the device has no sizeable non-volatile storage to speak of, so the original Windows driver sends the firmware over USB every time the device is plugged in. I was able to capture the data by running Windows in a VM and running a trace on the USB port in wireshark. The MCU that controls the device in the scope is a CY7C68013A (FX2LP), which is really ubiqitous. It sports a lot of GPIO, an 8051 processor and a 4K FIFO that buffers the data. The ADC is an AD9288, which is also as common as dirt. If you're interested in the firmware, i hope you like assembly  . Cypress kind of suggests you use Kiel but I am using mcu8051ide, and there are lots of open source 8051 tools including disassemblers out there; the instruction set on the device is also pretty sane. Pretty much everything use in the scope is well documented, and I can provide further details if you have questions.

After I posed the former message I found your repository, I still don't have the device to really play with it but started to look at the assembly. I'm adept enough at reading assembly but never really tried writing it beyond adapting sdcc peephole rules for optimization.

You are currently patching an existing firmware, I personally would have gone for understanding the pinouts and interface points and writing a new firmware and then you can do the writing in C to reduce programmer effort.

I would also avoid writing a whole new scope software, there are already several for the 6022BE, the RichardK one and others as well. I personally would prefer to just write a driver for sigrok and let another project handle the GUI.

[rpcope1]

So firmware isn't so bad on this device. If you look at my repo, it's got the hex code for the stock firmware; the device has no sizeable non-volatile storage to speak of, so the original Windows driver sends the firmware over USB every time the device is plugged in. I was able to capture the data by running Windows in a VM and running a trace on the USB port in wireshark. The MCU that controls the device in the scope is a CY7C68013A (FX2LP), which is really ubiqitous. It sports a lot of GPIO, an 8051 processor and a 4K FIFO that buffers the data. The ADC is an AD9288, which is also as common as dirt. If you're interested in the firmware, i hope you like assembly  . Cypress kind of suggests you use Kiel but I am using mcu8051ide, and there are lots of open source 8051 tools including disassemblers out there; the instruction set on the device is also pretty sane. Pretty much everything use in the scope is well documented, and I can provide further details if you have questions.

After I posed the former message I found your repository, I still don't have the device to really play with it but started to look at the assembly. I'm adept enough at reading assembly but never really tried writing it beyond adapting sdcc peephole rules for optimization.

You are currently patching an existing firmware, I personally would have gone for understanding the pinouts and interface points and writing a new firmware and then you can do the writing in C to reduce programmer effort.

I would also avoid writing a whole new scope software, there are already several for the 6022BE, the RichardK one and others as well. I personally would prefer to just write a driver for sigrok and let another project handle the GUI.

There were two issues with using the RichardK software moving forward: it's built for Windows (all I have is a Windows XP VM, every PC I have is Linux/BSD, so having something Linux specific is important), and it utilizes the Hantek driver (as I understand) which operates rather differently than what I'm doing (the biggest thing being you'd need to add threads for async, which may or may not be problematic). I will see what it would take to port it, though; what would be more interesting is porting the drivers to sigrok. I need to look at how they do things, and will when I get time. I agree, it's probably better to consolidate efforts on the front-end stuff. As far as patching the existing code, I agree that green field development would be a good way to go, but Jochen has been making those patches, and I won't argue with his awesome work there.

Really the ultimate goal for this repo is to provide a nice Linux/POSIX (and hopefully Windows) API to the device, and any front-end, if any, comes second; I agree though, once I get a better feel for what's possible, I think we can move towards building drivers for things like Sigrok and OpenHantek, so that people can get use out of the device and leverage others well tested front-end code.

[baruch]

Sounds great!

Here a few things I've been looking at to get a sense of the FX2LP and how the scope could work and sources to copy ideas and possibly code from:

• fx2lafw - http://sigrok.org/wiki/Fx2lafw - Sigrok FX2LP firmware for a logic analyzer
• OsciPrime - http://www.osciprime.com/index.php?p=specs - a slow scope implemented with FX2LP, open source firmware
• UUUSB - http://lea.hamradio.si/~s57uuu/uuusb/ - A data acquision with great explanation for using FX2LP FIFOs, also links to software

[2010kira2010]

rpcope1

I damaged EEPROM.
In the EEPROM stored vid/pid device.
8byte

Presumably: C0 B4 04 22 60 00 00 00

[6022owner]

I posted a related topic to:

  https://www.eevblog.com/forum/testgear/how-to-save-hantek-6022be-sciope-data-to-wav/

about how to save the scope data to a .WAV. Please respond in the other thread.

[Seekonk]

I'm finding this to be my go to scope.  Most of my needs are out there in the genba.  Nice to have something portable to save an image and document time/voltage.  Do wish it had some indicator that would flash when A/D reached the upper voltage limit. 

[hoenicke]

rpcope1

I damaged EEPROM.
In the EEPROM stored vid/pid device.
8byte

Presumably: C0 B4 04 22 60 00 00 00

Yes, exactly:

Code: [Select]

>python example_linux_readeeprom.py
c0b4042260000000...


[momus]

I think I found something quite valuable today :
https://github.com/rpm2003rpm/HT6022_Driver

It looks like that guy did more or less the same kind of reverse engineering as rpcope and hoenicke. Didn't mod the firmware though
(Is it even possible that they didn't notice this project ?)

It works straight out of the box on linux ($ make && ./a.out), and it's written in C. (Which is great for me because I was getting headaches learning python's dynamic typing )
It uses the stock firmware, but it should be as simple as a copy/paste to make it upload the modded one instead.

It's lacking some comments, and a few variables names are a bit mysterious, but it works, (without being root).
If we implement a rolling buffer, and have the gui in another thread, would we still need isochronious usb transfer ?

I guess forking this project would definitively be better than a complete C rewrite...

[hoenicke]

I think I found something quite valuable today :
https://github.com/rpm2003rpm/HT6022_Driver

It looks like that guy did more or less the same kind of reverse engineering as rpcope and hoenicke. Didn't mod the firmware though
(Is it even possible that they didn't notice this project ?)

Thanks for the link, I didn't find this project when I searched for Linux support a month ago.

It works straight out of the box on linux ($ make && ./a.out), and it's written in C. (Which is great for me because I was getting headaches learning python's dynamic typing )
It uses the stock firmware, but it should be as simple as a copy/paste to make it upload the modded one instead.

Accessing the scope is really not that difficult, once you understand libusb1.  Python makes it easier to prototype something, but I see no reason why one shouldn't be able to port this to C.

The procedure to setup the scope is as follows:

• Find the USB device (04b4:6022  or 04b5:6022 when firmware present)
• If firmware is not present, send it via 0xa0 control messages.  Then restart at 1.
• Set number of channels (new feature of my firmware), sampling frequency, scale for ch1 and ch2 via 0xe0-0xe5 control messages.
• Start sampling (0xe4 control message with data 1)
• Read samples via bulk or isochronous (new feature) transfer.
• Optional for new firmware: stop sampling (0xe4 message with data 0).

If you want to continuously sample over a long time, you should use the asynchronous libusb1 API.   This is probably the most difficult technical part.

It's lacking some comments, and a few variables names are a bit mysterious, but it works, (without being root).
If we implement a rolling buffer, and have the gui in another thread, would we still need isochronious usb transfer ?

Isochronous usb gives gapless sampling for up to 24 MB/s  (24 MHz one channel or 12 MHz two channels).  With bulk transfers there is no guarantee.  You get a mostly gapless sample if you sample at up to 30 MHz into a single block, but every extra message sent over the USB port or every delay in the usb driver of more than 40 µs may corrupt your samples.

Features like triggering, calibration, etc. have to be done in software at a higher level.  The driver will just read the raw samples continuously from the device.

[Hernexto]

1. I'am in France, so when I click on "Save" button I have systematically an error "1.0 is not a floating point value"
This appears due to the dot separator used in "Image export setting" tab combobox (for Horizontal and Vertical zoom). I suppose the default Windows separator is used and in France it's dot and not comma. This is my hypothesis. It's a blocking point, I can't use the function "save" due to this.

Same for me Chriss, with Spanish language... same behaviour.
As the save function is something I only use rarely I just change on the "Control Panel" - "Local settings", "Decimal separator" from comma to dot. This way Works!
If you use it frequently maybe some Windows powershell script could switch it easier.
Or a REGEDIT change: http://blog.coretech.dk/mip/changing-the-regional-related-small-stuff-dot-vs-comma/

Just my 2 pence!

BTW... I'm very happy to see the source code! I have seen other projects die without it.

short questions...
- does the math (-) trigger works?
- does the save function (with both channels) really saves both channels?
ok...  TODO.txt on source code:  3. Exporting waves to file (binary or txt) with more than one source selected only exports first selection!
- new question, can you load two previously saved waves or just one as it seems?