Hantek 6022Bx support

[OliverHaag]

Moving the Hantek 6022Bx related work from #6 here now.

Current work regarding the support can be found in the following repos:

• https://github.com/olerem/openhantek/tree/6022be: @olerem (6022 support)
• https://github.com/nickless81/openhantek/tree/qt5_6022be: @nickless81 (6022 support with Qt5)
• https://github.com/giomasce/openhantek/tree/6022be @giomasce (6022 support with reverse engineered fw)

Also related: A 6022 libusb1.0 driver: https://github.com/rpm2003rpm/HT6022_Driver A cocoa (MacOSX) based GUI for the 6022 based on the driver: https://github.com/SergeOkon/HT6022_OSX

[davidgraeff]

Can everybody with a 6022Bx model try out the added support for those devices, would be much appreciated.

[daybyter]

Ok, I'm still trying to get rid of the error with the b4,b5 and 07 bulk commands. For now I just edited control.cpp and just outcommented all the lines like this->controlPending[CONTROLINDEX_SETOFFSET] = true; Did this with the setOffset, the setGain and setRelays lines. That got rid of the pipe error lines. Now I just see those lines like Received 20480 B of sampling data , but no luck to see any trace. Someone said, that the time is set wrong, so the trace disappears to the left? Tried to set samplerate etc again, but no trace so far on the screen... ;-(

Edit: could it be, that the problem is GL related? I'm testing in a virtualbox, where I could install qt 5 to my debian with no problem. Mesa is also installed, but I don't have no 2d hardware acceleration there (seems to be for Windows guests only). I tried to activate 3d acceleration with no effect. But I don't get any GL related errors from OpenHantek. Sometime the widgets are drawn at the wrong place, but the graticule looks fine and it's drawn using the same GL functions, so GL seems to work ok, as I understand it?

[davidgraeff]

The graticule is drawn via OGL, your installation should be fine. The included pull requests throws away the first 1000 samples, maybe that logic is broken with (or without) your changes?

[daybyter]

I never got a trace. Before I changed anything, too.

[daybyter]

Finally a trace! :)

I started from scratch with your latest sources and things looked much better! Biggest problem seems to be the debugging output, which slows the app down a lot, so it responds with a few seconds delay to any change of the settings. That makes it very hard to position the trigger precisely as an example. I tried to check a problem with a current project of mine (a eprom writer) and checked Vpp for fall time. But I could get a good trigger settings to have the Vpp nicely in the middle of the screen. Most of the time, the curve jumped all over the screen. Another issue is the length of the trace. It's kinda hard to find a setting, where the entire curve is sampled. Would be better to append newer samples to the end of the trace, I guess. I thought with the jhoenicke firmware, this should be feasable? Anyway...some success for today. More testing tomorrow.

Thanks a lot for your efforts!

[daybyter]

Just wanted to show you some of my current tests.

One of my current projects is a eprom writer with a falltime problem. I diagnosed it first with a rigol 1054z to have a reference, what the trace should look like:

http://imgur.com/a/vZ7DR

I had lots of problems with OpenHantek to get any usable triggering yesterday, so I started my old Win XP laptop with the RichardK software today just to check what could be done with the 6022be.

Screenshot of the trace:

http://imgur.com/a/5Cu3N

and I also shot a very short video, just so you can see, that the software trigger is really stable and usable:

https://www.youtube.com/watch?v=IvqDPA4Bftw&feature=youtu.be

It's just meant as a reference, what could be done with the 6022be.

I would say, it's not really as good as the rigol, but definitely usable to work on the problem.

Now I have to work on the debian VM with OpenHantek, because I had to upgrade from jessie to stretch to get the new cmake. Now I don't have any graphics after a reboot. Have to fix this, before I can test any further.

[daybyter]

Ok, more testing today...

With the newer QT and KDE, OpenHantek seems somewhat faster. More responsive to controls.

I measured again my circuit with the falltime problem, and this is the result:

http://imgur.com/a/CcFFu

:-) Pretty good!

But I had to set the trigger to single and restart the sampling several times, before I got this. When I set the triggering to normal, I don't get a stable trigger:

https://www.youtube.com/watch?v=tvWpFSt50rc&feature=youtu.be

I also have a problem to the set the trigger level precisely. The marker on the right side only jumps in steps of 2.5V, or so.

Anyway...great work so far! Thanks again for your efforts!

[kilmarnock]

Can everybody with a 6022Bx model try out the added support for those devices, would be much appreciated.

I have a 6022BL and it is not supported in the udev .rules file. openhantek reports "No hantek oscilloscope found" /usr/local/share/hantek/dso6022bl* is missing

[swkim01]

As to @jssilva25 's comment about 6022bl device id, I added 6022BL support code to my repository. But the test is up to you. :-) https://github.com/swkim01/openhantek

[davidgraeff]

@swkim01 @kilmarnock Would be awesome if it works for you to create a PR

[kilmarnock]

It does not work for 6022bl, see https://github.com/swkim01/openhantek/issues/7

[dipusone]

I've managed to make the @swkim01 version work using a firmware dumped directly from the scope, for any reason the one in the repo gives problem when flashed. I've forked the repo (yep a fork of a fork) and updated the firmware file https://github.com/dipusone/openhantek. If someone ( @kilmarnock ) can confirm the new firmware it is working i can make the PR.

[kilmarnock]

@dipusone The firmware looks good to me, openhantek displays real data on the test port. Thank you!

[alextrezvy]

I have complied latest revision from git. It started, but no signal from the device. What I did wrong? Ubuntu 14.04, Hantek 6022BL. I can see the device with 'lsusb' command, but I don't know about udev initialization correctness (of course, udev rules was copied from manual). UPD: I have the following output of 'lsusb -v': Bus 001 Device 005: ID 04b4:602a Cypress Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x04b4 Cypress Semiconductor Corp. idProduct 0x602a

[bitwisetech]

My new 6022BL oscilloscope work OK with Fedora26 with https://github.com/dipusone/openhantek fork-fork after the following changes: The device reports as VendorID: 04b4 DeviceID 062a After 'dnf install fxload' the program installs at /usr/sbin/fxload There's a comment in sigrok's udev rules file that the rule for the Hantek must apply before " 70 seat rules " ( for systemd systems )

Changed last two lines of 90-hantek.rules to: SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/602a/*", RUN+="/usr/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso6022bl-firmware.hex -s /usr/local/share/hantek/dso6022bl-loader.hex -D $env{DEVNAME}" ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="602a", MODE="0660", GROUP="plugdev"

Renamed 90-hantek.rules to 61-hantek.rules and copied into /etc/udev/rules.d

OpenHantek works CH1 with test signal, software triggering Thanks Greatly !

[alextrezvy]

@bitwisetech: Where did you get the files: 'dso6022bl-firmware.hex' and 'dso6022bl-loader.hex'?

[bitwisetech]

From the link referred to in the post's first line: https://github.com/dipusone/openhantek

[alextrezvy]

@bitwisetech thanx for the link, but it didn't help. I've tried both this and dipusone's forks. All of them says: 'No Hantek oscilloscope found'. My udev rules looks as: cat /etc/udev/rules.d/61-hantek.rules

Hantek DSO-6022BL

SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/602a/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso6022bl-firmware.hex -s /usr/local/share/hantek/dso6022bl-loader.hex -D $env{DEVNAME}" ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="602a", MODE="0660", GROUP="plugdev"

[bitwisetech]

Silly question, did you push the little button ? ( 5th element fan ) I did dmesg to confirm the VID/PID when the scope is connected and ran 'which fxload' to find that executable is in /usr/sbin , not in sbin so my udev rule is different from yours. I also have a link frm ~/.local/share/sigrok-firmware to the fx2 firmware but I think that's only for the Hantek in logic analyser mode.

[alextrezvy]

I've checked dmesg and now it printed me a wierd strings:

[10167.564015] usb 1-5: new high-speed USB device number 5 using ehci-pci
[10167.696318] usb 1-5: New USB device found, idVendor=04b4, idProduct=8613
[10167.696324] usb 1-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[10167.717453] usbtest 1-5:1.0: FX2 device
[10167.717459] usbtest 1-5:1.0: high-speed {control bulk-in bulk-out} tests (+alt)
[10167.717484] usbcore: registered new interface driver usbtest

It says 'idProduct=8613' while it was '602a'! WTF? And what little button do you mean?

UPD: I've tried to type the id '8613' into the rules. And now the red LED on the device starts to blink, and I've got the following message from dmesg:

[11254.124019] usb 1-5: new high-speed USB device number 14 using ehci-pci
[11254.256389] usb 1-5: New USB device found, idVendor=04b4, idProduct=8613
[11254.256392] usb 1-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[11254.256681] usbtest 1-5:1.0: FX2 device
[11254.256685] usbtest 1-5:1.0: high-speed {control bulk-in bulk-out} tests (+alt)
[11254.415743] usb 1-5: USB disconnect, device number 14
[11256.180015] usb 1-5: new high-speed USB device number 15 using ehci-pci
[11256.312768] usb 1-5: New USB device found, idVendor=04b5, idProduct=602a
[11256.312771] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[11256.312775] usb 1-5: Product: Hantek6022BL 
[11256.312777] usb 1-5: Manufacturer: ODM

Also, the dipusone's fork now says: 'Could not open device '001:015': Access denied (insufficient permissions)', which differs that fork from this one.

UPD: I got it! Now the diposone's fork show the signal and my rules look as (different ID's for different strings):

cat /etc/udev/rules.d/61-hantek.rules 
# Hantek DSO-6022BL
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/8613/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso6022bl-firmware.hex -s /usr/local/share/hantek/dso6022bl-loader.hex -D $env{DEVNAME}"
ATTRS{idVendor}=="04b5", ATTRS{idProduct}=="602a", MODE="0660", GROUP="plugdev"

Now the question is: how to run the device in logic analyzing mode? How to scroll the recorded plot to the left (to the past)? Also, is that possible to run the software on a laptop with 1024x600 resolution? Now it doesn't fit the screen.

[bitwisetech]

The little button is on the back of the unit next to the USB connector. My unit reports as 04B4:062A with the button in the 'H' (Hantek ? ) position and as 0925:3881 in the 'P' position. As I understand, you use it as a scope in the 'H' position and as a logic analyser in the 'P' position, for which I use sigrok . 04b4:8613 is the VID:PID for Cypress' FX2 USB development kit, I'm guessing that VID:PID pair reports at some point. I'm not enough conversant with udev rules to know if I should have left ENV{PRODUCT} with those values.

[blurrpp]

Hi i just downloaded and compiled openhantek. Works great for my hantek 6022BE but i completly can't record any data. Field "record length" is empty (no options available), i can save only short sample in CSV. is thare any bug or there is something wrong in my system ?