Hi,

I think you're using an older PulseView Windows installer and/or the wrong driver maybe.

The correct VID/PID for the device *before* firmware upload is 04b4:6022. You need to assign that to WinUSB via Zadig.

The correct VID/PID *after* firmware upload (which happens when you try to run PulseView or sigrok-cli for that device) is 1d50:608e.

Your screenshot shows 04b5:6022 (note the 5 there), which is not a VID/PID used by sigrok for this device, hence setting that to anything in Zadig will not help.

It looks like you've used hantekdso previously? Maybe if you have that installed and/or open it'll try to use the device and/or something might switch to those drivers? Not sure.

Either way, I think if you set both 04b4:6022 and 1d50:608e to WinUSB and use the latest PulseView installer it should work fine (it did for me, I just tried on an 6022BE on Windows 10 here).

Please let us know how it goes.

Hello,
I've done some additional digging and here's what I found. I used linux because it was easier for me tweak and recompile sigrok.


It seems that my device really is 04b5:6022. These are legitimate ids, as they can be found in the INF file of the Windows driver:

[Strings]
ClassName="Hantek6022BE"
ODM="ODM "
USB\VID_04B4&PID_6022.DeviceDesc="Hantek6022BE DRIVER 1"
USB\VID_04B5&PID_6022.DeviceDesc="Hantek6022BE DRIVER 2"
Hantek6022BE1.SvcDesc="Hantek6022BE DRIVER 1"
Hantek6022BE2.SvcDesc="Hantek6022BE DRIVER 2"

And it really shows my device in Device Manager as "Hantek6022BE DRIVER 2" (assuming WinUSB driver is not installed of course).

Under linux i played a little with https://github.com/rpcope1/Hantek6022API (for example using examples/example_linux_scopevis.py) which worked just fine, so that gave me a reason to try and dig inside libsigrok to see what's the difference.


libsigrok misses support for 04b5 so I tried to add it. I simply copy pasted the structure for 04b4 as 04b5 in hardware/hantek-6xxx/protocol.c:

static const struct hantek_6xxx_profile dev_profiles[] = {
	{
		0x04b4, 0x6022, 0x1d50, 0x608e, 0x0001,
		"Hantek", "6022BE", "fx2lafw-hantek-6022be.fw",
		dc_coupling, ARRAY_SIZE(dc_coupling), FALSE,
	},
	{
		0x04b5, 0x6022, 0x1d50, 0x608e, 0x0001,
		"Hantek", "6022BE", "fx2lafw-hantek-6022be.fw",
		dc_coupling, ARRAY_SIZE(dc_coupling), FALSE,
	},


This has somewhat worked, but not all the way:

>sigrok-cli -l 5 --driver hantek-6xxx --samples 100
...
sr: [00:00.008537] hantek-6xxx: Found a Hantek 6022BE.
sr: [00:00.008774] ezusb: uploading firmware to device on 1.5
sr: [00:00.038914] ezusb: setting CPU reset mode on...
sr: [00:00.039684] resource: Attempt to open '/home/cleric/.local/share/sigrok-firmware/fx2lafw-hantek-6022be.fw' failed: No such file or directory
sr: [00:00.039747] resource: Opened '/usr/local/share/sigrok-firmware/fx2lafw-hantek-6022be.fw'.
sr: [00:00.039824] ezusb: Uploading firmware 'fx2lafw-hantek-6022be.fw'.
sr: [00:00.040595] ezusb: Uploaded 4096 bytes.
sr: [00:00.041369] ezusb: Uploaded 4096 bytes.
sr: [00:00.042570] ezusb: Uploaded 4096 bytes.
sr: [00:00.044211] ezusb: Uploaded 4024 bytes.
sr: [00:00.044219] ezusb: Firmware upload done.
sr: [00:00.044221] ezusb: setting CPU reset mode off...
sr: [00:00.045218] hwdriver: Scan of 'hantek-6xxx' found 1 devices.
sr: [00:00.045263] hantek-6xxx: Waiting for device to reset.
sr: [00:00.445715] hantek-6xxx: Waited 400 ms.
sr: [00:00.546885] hantek-6xxx: Waited 501 ms.
...
sr: [00:03.075040] hantek-6xxx: Waited 3033 ms.
sr: [00:03.075074] hantek-6xxx: Unable to open device.
Failed to open device.



Now it detects the device and uploads the firmware but fails after that.

After some debugging I tracked down the reason. It is because of what you said: that the ids should be changed to 1d50:608e after firmware upload but that does not seem to happen and as a result sigrok does not find the device. So I did this:

{
		0x04b5, 0x6022, 0x04b5, 0x6022, 0x0001,
		"Hantek", "6022BE", "fx2lafw-hantek-6022be.fw",
		dc_coupling, ARRAY_SIZE(dc_coupling), FALSE,
	},

That is, I made sigrok expect the same 04b5:6022 ids after firmware upload and it worked!

sr: [00:00.350113] hantek-6xxx: Opened device on 1.5 (logical) / usb/1-2 (physical) interface 0.
sr: [00:00.350137] hantek-6xxx: Device came back after 0 ms.
sr: [00:00.350275] hwdriver: sr_config_set(): key 50001 (limit_samples) sdi 0xece800 cg NULL -> uint64 10
sr: [00:00.350421] session: Using thread-default main context.
sr: [00:00.350440] session: Starting.
sr: [00:00.350453] hantek-6xxx: Initializing
sr: [00:00.350463] hantek-6xxx: update samplerate 8
sr: [00:00.350474] hantek-6xxx: hantek_6xxx_write_control: 0xe2 0x8
sr: [00:00.352105] hantek-6xxx: update vdiv 2 2
sr: [00:00.352133] hantek-6xxx: hantek_6xxx_write_control: 0xe0 0x2
sr: [00:00.353105] hantek-6xxx: hantek_6xxx_write_control: 0xe1 0x2
sr: [00:00.354086] hantek-6xxx: coupling not supported
sr: [00:00.354111] std: hantek-6xxx: Starting acquisition.
sr: [00:00.354122] std: hantek-6xxx: Sending SR_DF_HEADER packet.
sr: [00:00.354143] session: Running transform module 'nop'.
sr: [00:00.354162] transform/nop: Received packet of type 10000, passing on unmodified.
sr: [00:00.354180] session: bus: Received SR_DF_HEADER packet.
cli: Received SR_DF_HEADER.
sr: [00:00.354373] hwdriver: sr_config_get(): key 30000 (samplerate) sdi 0xece800 cg NULL -> uint64 8000000
sr: [00:00.354439] hantek-6xxx: trigger
sr: [00:00.354450] hantek-6xxx: hantek_6xxx_write_control: 0xe3 0x1
sr: [00:00.360923] hantek-6xxx: Request channel data.
sr: [00:00.361506] hantek-6xxx: data_amount: 20 (rounded to power of 2: 512)
sr: [00:00.361550] hantek-6xxx: Request channel data.
sr: [00:00.361976] hantek-6xxx: receive_transfer(): calculated samplerate == 701ks/s
sr: [00:00.362020] hantek-6xxx: receive_transfer(): status LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED received 512 bytes.
sr: [00:00.362053] hantek-6xxx: Requested number of samples reached, stopping. 10 <= 256
sr: [00:00.362102] session: Running transform module 'nop'.
sr: [00:00.362130] transform/nop: Received packet of type 10007, passing on unmodified.
sr: [00:00.362157] session: bus: Received SR_DF_ANALOG packet (10 samples).
cli: Received SR_DF_ANALOG (10 samples).
CH1: 0.19 V
CH1: 0.19 V
CH1: 0.19 V
CH1: 0.19 V
CH1: 0.21 V
CH1: 0.19 V
CH1: 0.19 V
CH1: 0.19 V
CH1: 0.19 V
CH1: 0.21 V
sr: [00:00.362458] session: Running transform module 'nop'.
sr: [00:00.362490] transform/nop: Received packet of type 10007, passing on unmodified.
sr: [00:00.362517] session: bus: Received SR_DF_ANALOG packet (10 samples).
cli: Received SR_DF_ANALOG (10 samples).
CH2: -0.01 V
CH2: -0.01 V
CH2: -0.01 V
CH2: 0.01 V
CH2: -0.01 V
CH2: -0.01 V
CH2: -0.01 V
CH2: -0.01 V
CH2: 0.01 V
CH2: -0.01 V
sr: [00:00.362700] hantek-6xxx: Stopping acquisition.
sr: [00:00.362727] hantek-6xxx: hantek_6xxx_write_control: 0xe3 0x0
sr: [00:00.364504] std: hantek-6xxx: Sending SR_DF_END packet.
sr: [00:00.364534] session: Running transform module 'nop'.
sr: [00:00.364545] transform/nop: Received packet of type 10001, passing on unmodified.
sr: [00:00.364557] session: bus: Received SR_DF_END packet.
cli: Received SR_DF_END.
sr: [00:00.364591] usb: usb_source_finalize
sr: [00:00.364628] session: Stopped.
sr: [00:00.364683] hantek-6xxx: Closing device on 1.5 (logical) / usb/1-2 (physical) interface 0.



So this is a two part problem:
1/ support should be added for the (probably newer) 04b5 id.
2/ it should be investigated why the ids do not change. Here I must mention that I'm running Ubuntu in VirtualBox on a Windows host so I'm not sure if this interferes in some way. It is not clear to me at all what the mechanism of this id switching is. In dmesg I only have:
[ 3959.791011] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 3959.814257] usb 1-2: New USB device found, idVendor=04b5, idProduct=6022
[ 3959.814262] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3959.814265] usb 1-2: Product: HantekDSO6022BE 
[ 3959.814268] usb 1-2: Manufacturer: ODM

Should I expect the ids change to be logged in dmesg? Or this id change is something which is not related to the kernel at all, but is only libusb feature?

I hope this information helps.

Best~

Hi, I've finally reproduced this and you're correct indeed that the other VID/PID pair was missing in the libsigrok driver. That's fixed now in 2efb3cd70053098d4b7106b84c2d400eb0fb4370, thanks!

Additionally, you also need the use Zadig *twice* for this device, once before firmware upload (VID/PID 04b5:6022 usually) and once after firmware upload (the firmware is getting uploaded when you simply start PulseView, you can close it again immediately). The VID/PID after firmware upload will be 1d50:608e.

Once you've run Zadig twice, simply start PulseView and the device should be auto-detected (it'll be auto-selected as well potentially, or at least appear in the device drop-down box when you click on the little arrow).

I've added this info to this (and other) wiki pages:

https://sigrok.org/wiki/Hantek_6022BE#Firmware

*** Bug 1266 has been marked as a duplicate of this bug. ***