hantek just released a newer version of software v1.0.5 , download link
i will also download Open6022 to see which is better...
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.
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'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?
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.
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...?
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.
Hello everybody!
Please!!!!!
Who can copy the firmware eeprom?
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...
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.
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
I damaged EEPROM.
In the EEPROM stored vid/pid device.
8byte
Presumably: C0 B4 04 22 60 00 00 00
>python example_linux_readeeprom.py
c0b4042260000000...
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 ?
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.