Author Topic: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO  (Read 3243 times)

0 Members and 1 Guest are viewing this topic.

Offline doobs

  • Contributor
  • Posts: 7
  • Country: au
Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« on: March 17, 2018, 02:43:46 pm »
Hi

I am a bit of a newbie to all this, which will become abundantly clear ...

I recently bought the above scope for around $400AUD off ebay. The distributed software (freely downloadable from http://www.hantek.com/en/productdetail_2_10164.html) works nice enough under Windows XP. Under Windows 7 I could only get the drivers to function if I hit the F8 key at boot time and select the "Disable Driver Signature Enforcement" option, because the driver just aint signed right. I tried several other options to try and enable the driver anyway, such as running:

Code: [Select]
   bcdedit  -set loadoptions DISABLE_INTEGRITY_CHECKS
- but only the F8 boot option actually worked.

Anyway, although this thing comes with an integrated frequency generator I didn't look into that because what I really wanted it for was to measure magnitude and phase angle info for a whole spectrum of frequencies via X-Y plots, but the official software makes it incredibly laborious - having to centre and measure ellipse params by hand. The ellipses themselves are graphically quite blurry. I thought I could export some traces, fit an ellipse and automate it meself, but the software only seems to export 1 trace/channel to a file at a time, making the whole process incredibly tedious.

Being a Linux/Python fan, I soon found meself thinking, wouldn't it be great if I could just operate in Linux? I quickly found the OpenHantek https://github.com/OpenHantek/openhantekproject and several other forks of it on GitHub. Unfortunately they really only support the Hantek 6022 models. But that led me to the sigrok https://sigrok.org/ project where they seemed to have a goal to support as many different test equipment models as possible. When I dug a little deeper it turned out that their sigrok 6022 driver actually derived from the github Hantek6022API https://github.com/rpcope1/Hantek6022API project and that in turn apparently had its genesis through this eevblog forum https://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/!
So here I am...

Just plugging the device into the USB port(s - x2 - 1 just for extra power) and running  lsusb identifies the device as:
Code: [Select]
04b5:6cde ROHM LSI Systems USA, LLC
I naively thought that maybe just installing the  6022 _loader and _firmware driver files might at least get some basic communication going, but that was not so. I guessed that maybe the equivalent of the 6022 _loader and _firmware files needed to be extracted from the Hantek6000BX86.sys Windows driver. OpenHantek came with an openhantek-extractfw module which I attempted to run but without any success. I tried to run it also on an Hantek6022BLX861.sys driver, downloaded from the Hantek website, but that also didn't work. But it did seem to work with an older(?) Hantek Dso5200x861.sys driver file.

I had a look at the  Dso5200x861.sys driver file just with the  unix objdump program:
Code: [Select]
objdump -s -h  -f -F -t -T Dso5200x861.sys
Code: [Select]
Dso5200x861.sys:     file format pei-i386
architecture: i386, flags 0x0000013b:
HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x00010334

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000005f6  000102a0  000102a0  000002a0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00002590  000108a0  000108a0  000008a0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 INIT          0000019c  00012e40  00012e40  00002e40  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  3 .rsrc         00000348  00012fe0  00012fe0  00002fe0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .reloc        00000082  00013340  00013340  00003340  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
SYMBOL TABLE:
[  0](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[  1](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[  2](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[  3](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[  4](sec  4)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00003040 $R000000
[  5](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[  6](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[  7](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[  8](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00002fce .idata$6
[  9](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[snip]
[ 22](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 @comp.id
[ 23](sec -2)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 header
[ 24](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002a0 __imp_@IofCallDriver@8
[ 25](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002a4 __imp__KeSetEvent@12
[ 26](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002a8 __imp__KeWaitForSingleObject@20
[ 27](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002ac __imp__KeInitializeEvent@12
[ 28](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002b0 __imp_@IofCompleteRequest@8
[ 29](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002b4 __imp__IoDeleteDevice@4
[ 30](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002b8 __imp__IoDetachDevice@4
[ 31](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002bc __imp__IoAttachDeviceToDeviceStack@8
[ 32](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002c0 __imp__IoCreateDevice@28
[ 33](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002c4 __imp__IoBuildDeviceIoControlRequest@36
[ 34](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002c8 __imp_@InterlockedDecr
[ 35](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002cc __imp_@InterlockedIncrement@4
[ 36](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002d0 __imp__ExFreePool@4
[ 37](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002d4 __imp__ExAllocatePoolWithTag@12
[ 38](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000002d8 ^?NTOSKRNL_NULL_THUNK_DATA
[ 39](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000334 _DriverEntry@8
[ 40](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000360 _Ezusb_DefaultPnpHandler@8
[ 41](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000037e _OnRequestComplete@12
[ 42](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000394 _ForwardAndWait@8
[ 43](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000040e _CompleteRequest@12
[ 44](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000430 _Ezusb_DispatchPnp@8
[ 45](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x000004dc _Ezusb_Unload@4
[ 46](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x000004e0 _Ezusb_HandleRemoveDevice@8
[ 47](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000051e _Ezusb_HandleStartDevice@8
[ 48](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000054c _Ezusb_StartDevice@4
[ 49](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000058e _Ezusb_RemoveDevice@4
[ 50](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x000005ac _Ezusb_PnPAddDevice@8
[ 51](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000612 _Ezusb_CallUSBD@8
[ 52](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000682 _LockDevice@4
[ 53](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x000006c0 _UnlockDevice@4
[ 54](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x000006e6 _Ezusb_8051Reset@8
[ 55](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000794 _Ezusb_DownloadIntelHex@8
[ 56](sec  2)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000008a0 _firmware
[ 57](sec  2)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00002908 _loader
[ 58](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00002e40 __IMPORT_DESCRIPTOR_NTOSKRNL
[ 59](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00002e54 __NULL_IMPORT_DESCRIPTOR
[ 60](sec -2)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000033e0 end
So when the extractfw program does its work, it pulls out the _firmware and _loader  code for uploading to the USB device.

Running the same process on Hantek6000BX86.sys:
Code: [Select]
objdump -s -h  -f -F -t -T Hantek6000BX86.sys
Code: [Select]
Hantek6000BX86.sys:     file format pei-i386
architecture: i386, flags 0x0000012f:
HAS_RELOC, EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_LOCALS, D_PAGED
start address 0x0001283e

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00002142  00010480  00010480  00000480  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rdata        00000144  00012600  00012600  00002600  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000008  00012780  00012780  00002780  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 INIT          00000442  00012800  00012800  00002800  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  4 .rsrc         00000378  00012c80  00012c80  00002c80  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .reloc        000001b2  00013000  00013000  00003000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
Hantek6000BX86.sys: not a dynamic object
SYMBOL TABLE:
no symbols

DYNAMIC SYMBOL TABLE:
no symbols
So, no symbols at all, which would explain why openhantek-extractfw was struggling to find anything useful.

Running the linux program "strings" on Hantek6000BX86.sys  shows, amongst other things:
Code: [Select]
memcpy
sprintf
InterlockedDecrement
InterlockedIncrement
IoFreeIrp
IoInitializeIrp
IoAllocateIrp
KeInitializeSpinLock
KfReleaseSpinLock
KfAcquireSpinLock
IoAttachDeviceToDeviceStack
MmMapLockedPages
KeTickCount
KeBugCheckEx
ntoskrnl.exe
HAL.DLL
USBD_GetUSBDIVersion
USBD_CreateConfigurationRequestEx
USBD_ParseConfigurationDescriptorEx
USBD.SYS
whereas doing the same for Dso5200x861.sys reveals function calls like:
Code: [Select]
header
_loader
_Ezusb_DefaultPnpHandler@8
_Ezusb_DispatchPnp@8
_Ezusb_Unload@4
_Ezusb_HandleRemoveDevice@8
_Ezusb_HandleStartDevice@8
_Ezusb_StartDevice@4
_Ezusb_RemoveDevice@4
_Ezusb_PnPAddDevice@8
_Ezusb_CallUSBD@8
_Ezusb_8051Reset@8
_Ezusb_DownloadIntelHex@8
_firmware
So, apparently Dso5200x861.sys was built around the  Cypress EZ-USB library, whereas the newer drivers such as Hantek6000BX86.sys are built around the Microsoft USBD library. But the newer Hantek6000 software does install a CyUSB.dll library, so presumably USBD just provides some kind of common USB transport/interface layer?

At this point I guessed that maybe the Hantek software itself, might be uploading the _loader and _firmware driver packets when it actually connects to the device. So I thought to install a USB packet sniffer and just watch some of the traffic during the connection process. Under Windows XP I installed USBPcap -1.0.0.7 (I was completely unable to coax the more recent USBPcap 2.0  to work). Along with that I installed Wireshark-win32-1.12.13 , which also installs WinPcap. With this combination I was able to save the communication packets between the Hantek6000.exe software and the USB scope into a Wireshark .pcap file.  Just looking at the recording, it starts with
Code: [Select]
pkt   time              from        to    protocol length  info
1 0.000000 host 5.1.0 USB 36 GET DESCRIPTOR Request DEVICE
4 0.000000 host 5.1.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
7 0.000000 host 5.1.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
10 0.000000 host 5.1.0 USB 36 SET CONFIGURATION Request
23 4.234375 5.1.6 host USB 539 URB_BULK in
82 4.375000 5.1.0 host USB 1052 URB_CONTROL in
Basically, there are no large configuration packets coming from the host to the device and presumably the bulky waveform data is in the large packets going in the opposite direction. So it seems that no upload equivalent of  _loader or _firmware is actually taking place.


At this point I thought, bugger it, I'll just open it up and take a peek inside! But I shouldn't have done that.

To get inside, there are two large plastic feet that simply slide off each end of the box with a bit of sustained gentle pressure. 4 screws hold a face plate at each end. Undo those, wriggle a face-plate up and over a BNC connection and the main circuitboard just slides out.  Two photos are attached.

In the centre of the under side of the board is a tightly compressed metal spring that I believe grounds the board to the metal chassis of the case. On the upper side of the board, where the spring is soldered in, is an image of a thumb and forefinger, with a cross though them suggesting, DON'T TOUCH THE SPRING! In my naivety, I didn't notice and it actually took me some significant pushing and prodding to get the bloody thing to slide back into its case. Having done that, the bloody thing no longer works :-( There is an additional upright component (maybe a coil?) on the same side as the spring that I may have knocked adrift trying to squeeze it back into the case, but I don't believe I was that ham fisted.

Anyway, at this point it is stuffed! When I plug it in under Windows7 (yeah F8 option) and try to connect with the software I get Blue Screen Of Death, core dump, and the little green LED adjacent to channel 1 on the scope starts flashing an angry red! No BSOD under WindowsXP, but it just doesn't connect and when you try the software crashes.

Moving on and trying to salvage something from me predicament - sorry the photos are so  poor, but I have been able to identify a few of the major IC components visually. On the upper side, the most prominent feature is the large Xilinix Spartan-6 XC6SLX16 FPGA (labeled u13)https://www.xilinx.com/support/documentation/data_sheets/ds160.pdf. I believe this is configured by settings stored in an MXIC 25L4006E (u17) 4Mbit SPI Serial Flash http://www.bios-chip24.com/MXIC-MX-25L4006E-M2I-12G-4Mbit-SPI-Serial-Flash-SOIC-8/en chip sitting to the east of the FPGA and between it and the USBXI http://www.hantek.com/en/NewsShow_51.html port. Between the USBXI and USB ports is a paper-clip accessible "PRG" switch. To the west of the FPGA is an HMCAD1511 Analogue-to-Digital-Converter http://www.analog.com/en/products/analog-to-digital-converters/hmcad1511.html#product-overview. The specs for that say 1GSa/s is only for 1 channel and it reduces to 500MSa/s for 2 channels or 250MSa/s for 4 channel operation.

To the north of the ADC is (u1) ADF4360-7 - an Integrated Synthesiser and VCO [urlhttp://www.analog.com/media/en/technical-documentation/data-sheets/ADF4360-7.pdf][/url].
To the north of the FPGA is DAC902E - a Digital-to-Analogue Converter http://www.ti.com/lit/ds/symlink/dac902.pdf, all leading towards the "Gen Out" BNC connector on the case.

To the south of the FPGA is the (u16) Cypress CY7C68013A  EZ-USB FX2LP USB2.0 Micro-controller chip http://www.cypress.com/file/138911/download running the 8051 instruction set and with 16KBytes of onboard RAM. Adjacent to that, but underneath the board is a (u807) Microchip Technology Inc. 24LC64, 64Kbit EEPROM http://ww1.microchip.com/downloads/en/DeviceDoc/21189f.pdf, presumably permanently storing the firmware for the FX2LP. There is a 24MHz xtal oscillator to the south of the
FX2LP.

Also on  the under side of the board are 4x MC74HC595A (u25, u26, u27, u29) Serial Shift Registers(?)http://www.farnell.com/datasheets/2353736.pdf, one on each channel and  2x TLV274C (u14, u18)Op-Amps http://www.ti.com/lit/ds/symlink/tlv274.pdf.

So apparently, the firmware is stored on board and doesn't need to be uploaded via any UDEV rules. I guess it just plug and plays. Knowing that I tried to experiment with  Hantek6022API, just replacing the MODEL_ID = 0x6cde  in LibUsbScope.py. With that change I was able to run both
Code: [Select]
examples/example_linux_readeeprom.py
examples/example_linux_readfirmware.py
Those tests seem to work, though others do not. Saving the 8051 firmware for instance, it does disassemble into something seemingly coherent using the program dis51-0.5 http://plit.de/asem-51/dis51.html.

So this is currently where its at - an expensive paperweight. Hopefully my misadventure might serve as a warning to others of what not to do, but might also provide a better starting point for someone else that actually knows what they're doing, to actually engineer some proper Linux support for this device.

 

Offline gf

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #1 on: April 07, 2018, 07:20:44 pm »
I recently bought the "small brother" 6074BD (70MHz).

Quote
Anyway, at this point it is stuffed! When I plug it in under Windows7 (yeah F8 option) and try to connect with the software I get Blue Screen Of Death, core dump,...

I'm unfortunately facing BSOD too, when I connect the DSO after boot, and also upon reboot.

After some trial and error I managed to avoid the BSOD reproducibly when I power-off the PC completely, connect the DSO, then power-on and boot (using F8 of course) with the DSO connected. My feeling is that the boot takes longer than usually, showing just a black screen for a while, but eventually it comes up w/o crashing.

I also did uninstall und reinstall the driver a couple of times while I was trying to get it up and running again, and at least one time it seems that the installed driver was indeed garbled (maybe a consequence of one of the crashes).

Quote
...The ellipses themselves are graphically quite blurry...

What frequency magnitutes are you talking about? And which timebase setting do you use? According to my observation the ellipses get more and more jittery ("dents" in the elliptical shape) the smaller the time/div value is set. For >= 1us/div the "dents" in the shape almost disappear, so that only the noise is left which broadens the border. Note that undersampling periodic signals in X/Y mode does not harm (no need to satisfy Nyquist for this use case), as long as the sampling can pick up enough points along the border of the ellipse. So you don't necessarily need to stick to the ns/div ranges, just because you signal frequency is so high. Any jitter and noise in your signals does of course affect the "shape jitter" and noise of the ellipse as well.

Quote
Also on the under side of the board are 4x MC74HC595A (u25, u26, u27, u29) Serial Shift Registers

The parallel outputs of the 4 shift registers obviously control the 4 analog input stages (attenuator relays, AC/DC switch, etc.). I guess that they realize a SPI interface for controlling the analog input stages (note that the HMCAD1511 needs to be controlled via SPI as well, so it would make sense to control other components on the board via SPI either).

I also could not resist and did take a look inside (I also opened the shield of one of the analog input stages) and can contribute a couple of photos, too (I'll add them later - sorry, unfortunately no good quality either).

gf
 
The following users thanked this post: doobs

Offline bugi

  • Regular Contributor
  • *
  • Posts: 229
  • Country: fi
  • Hobbyist using the ultra slow and unsure method
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #2 on: April 08, 2018, 04:02:20 am »
At this point I thought, bugger it, I'll just open it up and take a peek inside! But I shouldn't have done that.
You're on EEVblog forums, the motto is pretty much towards always peeking inside, even before turning it on... Whether that is always smart is another thing.

Quote
... On the upper side of the board, where the spring is soldered in, is an image of a thumb and forefinger, with a cross though them suggesting, DON'T TOUCH THE SPRING! ...
Considering that there is that "garbage can with cross" symbol right next to it, I'd say those two symbols mean the standard "do not dispose in normal trash" (it is considered special waste, a bit different handling in different places) and "static sensitive device" (do not touch / poke without using anti-static work things like wrist-wrap etc.)  Touching that spring, apparently being connected to the circuit ground, should (note, _should_) be sort of safe... but static electricity can be a nasty troll.
 

Offline doobs

  • Contributor
  • Posts: 7
  • Country: au
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #3 on: April 24, 2018, 11:49:09 pm »
Hey gf,
many many thanks!
I had all but given up on it until I saw your post, but now, having it plugged in during the PC boot sequence has bought this sucker back to life!
It lives again! Thank you, thank you!

Regarding the ellipses, when I look at them at any timebase (frequency from 100Hz to 60MHz)  they invariably appear as lines about 5 pixels wide, drawn with some kind of hash pattern stipple, that continually flickers as the traces refresh. What I wanted was just some simple way to fit an ellipse and calculate the phase shift - without all the centering and measuring and manual calculating bs.  I did something similar for me TDS820 here https://sourceforge.net/projects/tekds820/



Regarding the shift registers, they were the chip identification I was least confident about, so its good to see it might have been correct!
Anyways,
thanks again
doobs
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #4 on: April 25, 2018, 05:47:37 am »
Quote
Regarding the ellipses, when I look at them at any timebase (frequency from 100Hz to 60MHz)  they invariably appear as lines about 5 pixels wide, drawn with some kind of hash pattern stipple, that continually flickers as the traces refresh.

Hi,

well, IMO it's not a line with a "stipple pattern", but the alleged stipple pattern is IMO just the set of the sampled (x,y) points, lying approximately on an elliptical locus, with small gaps in between, and with some dispersion in x and y direction due to noise (causing the apparent "thickness" of the "line"). I would not consider this amount of noise a problem, if your intention is anyway to fit a function with a low number of parameters (like an ellipse  ;)) to a big amount of captured data points (note, you can capture 32k samples when 2 channels are turned on - that's more than sufficient to average out most of the noise when fitting the data to a parametric function).

More worrying than the random noise I find the systematic deviation from an ideal elliptical shape, since this is an indication for a potential non-linearity. I'm not sure, though, whether this is necessarily a flaw of the scope, but it could be also caused by your signals not being perfectly sinusoidal.

gf
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #5 on: April 25, 2018, 06:52:35 am »
Adding my photos.
gf
 

Offline martinloren2

  • Contributor
  • Posts: 7
  • Country: cn
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #6 on: January 25, 2019, 02:51:44 am »
Can you send me the firmware? Eventually you can export it with the android app Cypress FX2 Utils. support@martinloren.com
 

Offline rgon

  • Newbie
  • Posts: 2
  • Country: es
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #7 on: March 22, 2019, 11:36:09 pm »
Red flashing is the normal behaviour for the scope when connected but not communicating to any program, so you might have a functioning scope but a crapped out Windows installation. When connected to it's software, it flashes green.

This device's drivers are a mess. Thanks god I'm running it in a VM and revert to a snapshot every time I open it. For whatever reason, it also couldn't boot after switching it's drivers.

Another thing to note is that the whole 6xx4BD range seems to share the same HW, since my 6204BD's board is also labeled DSO6xx4 v1.6. Mine identifies as 04b5:6cde as well.

I too have bricked my scope by trying to use non-standard software (modified OpenHantek to connect to connect to this device by naively changing the USB ID in a header file). So OpenHantek flashed the 6022's firmware onto my 6204's FX2LP chip, bricking it. Oops.

Fortunately, some Hantek developer sent me the firmware and a tool to install it and it's now fixed. But since firmware updating is no longer needed, and the whole 6xxx family seems to use the same protocol for communication, it shouldn't be that hard. But I may be wrong, since I haven't even started.

If anybody knows of a git repo or project that tries to reverse engineer this device's drivers, it'd be great to know. I'm sure I'm not the only one interested in better software support and contributing.

EDIT: the protocol has little to do with the 6022's. I've spent an afternoon trying to make sense of the packets with wireshark and even though getting it up and running seems easy, I've only been able to dump EEPROM contents using libusb by copying the messages the official software sends. The configuration interface also seems much different (seemingly using bulk data transfers back and forth instead of config messages). More research needs to be performed.
« Last Edit: March 23, 2019, 07:13:11 am by rgon »
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #8 on: March 23, 2019, 11:59:00 pm »
Yes, I have no doubts that all 6xx4BC and 6xx4BD certainly share the same hardware platform, with only small component population differences.

I'd be interested in alternative software for these instruments as well. I must admit, though, that don't have enough free time to do significant work in this area.

Regarding the USB protocol, I'm wondering wheter it is rather high-level (with commands like "set V/div", "set timebase", "set trigger"), or whether is is low-level (with commands like "send byte sequence x to SPI device #y on SPI bus #z"). The latter would imply that each controllable component on the board would need to be directly driven by the software, requiring rather detailed knowledge about the hardware architecture and FPGA implementation (possibly even for different PCB and FPGA code revisions).
 

Offline bianchifan

  • Regular Contributor
  • *
  • Posts: 65
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #9 on: March 24, 2019, 01:11:48 am »
I'd be interested in alternative software for these instruments as well.
Me too!

Unfortunately I dod not own one up to now, I'm still thinking...
If anybody knows of a git repo or project that tries to reverse engineer this device's drivers, it'd be great to know. I'm sure I'm not the only one interested in better software support and contributing.

Maybe this link: Android APK for Hantek 6004 series
can help you.. ;)
I found this Andropid app last November and I'm wondering that it seems still unknown  :-//
I was too lazy to create a thread for it 'cause it's not my stuff..
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #10 on: March 24, 2019, 06:04:04 am »
Maybe this link: Android APK for Hantek 6004 series
can help you.. ;)

It was announced here in the Forum.
Unfortunately it contains a binary-only library "ht6000api.aar" with unclear origin and copyright.
The "interesting" part is hidden in this library, while the open sourced components are just the GUI stuff.

« Last Edit: March 24, 2019, 06:08:36 am by gf »
 

Offline bianchifan

  • Regular Contributor
  • *
  • Posts: 65
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #11 on: March 25, 2019, 06:02:32 am »
It was announced here in the Forum.
OK...just found it in an area I've never looked at  :-//

The binary-only ht600api.aar is just a PKZIP file.
Uncompressed you find some directories mostly without content.
And yeah, there is some binary stuff, i.e. shared objects for several achitectures in "ini" dir.
The interesting things are found in classes.jar...
 

Offline rgon

  • Newbie
  • Posts: 2
  • Country: es
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #12 on: April 02, 2019, 12:30:14 am »
This is going to be a huge post... Sorry about that.

Okay, so I spent an afternoon trying to get a grip on how this device communicates with the software. My idea was to copy the USB commands that the software sent with wireshark and usbmon and replicate them using libusb to try and get some info. What I gathered was the following:

I wrote a small python script based on the files in Hantek60022API to test my findings.
Code: [Select]
import libusb1
device_handle = self.context.getByVendorIDAndProductID(
            0x04B4,
            self.MODEL_ID,
            skip_on_error=True,
            skip_on_access_error=True
        ).open()



As with the 6022, the software has direct access to the scope's EEPROM, and reads and writes to it during normal operation. This is why many people have reported that crashing software destroys their scope.
However, as previously stated, there's no need to upload any firmware to the EEPROM on boot.

The sequence to read from the EEPROM is:
Code: [Select]
print('EEPROM Response', device_handle.controlRead(0xC0, 162, MEM_OFFSET, 0, 8, timeout=0))
and to write:
Code: [Select]
bytes_written = device_handle.controlWrite(0xc0, 162, MEM_OFFSET, 0, BYTES_TO_WRITE, timeout=timeout)
However, this can corrupt the contents of the EEPROM and the device may not work anymore. So only test this if you already have a copy of some working firmware.

This allows us to extract the entire contents and flash whatever we want. Previously, when bricking my scope, I had to ask Hantek for a file (DSO6106BD20160601.iic), but I'm unable to redistribute it since I haven't got permission. They sent me a copy of Cypress's CyConsole (win only) to upload this, but with this info, we can dump the entire contents of the memory of a working scope ourselves, save it to a file and later upload it, thus replicating its functionality with ~10 lines of python code and the ability to run it in *NIX OSs. I'll post my tool when I get some more free time.
I've yet to see if the calibration values are 32 bytes sored in offset 0x08, as is the case in the 6022.



When active, the software sets and reads a couple of commands and then begins polling the scope's buffer.

There's a recurring loop that does the following:
Code: [Select]
controlWrite(0x40, 179, 0, 0, WEIRD_BYTE_ARRAY) always followed by controlRead(0xC0, 178, 0, 0, 10)
And then, the software asks for the data buffer:
Code: [Select]
device_handle.bulkRead(0x86, 10, timeout=100)

If polling when the LED is supposed to blink, the scope blinks green, and if the polling rate is fast enough (I've tested 10Hz), it only blinks this color, indicating a 'succesful' connection to the software.



My initial attempt, after repeating the commands the software sends when booted, was to create a loop that sent the 179, 178 and 0x86 commands and read the buffer. Here, I've substituted WEIRD_BYTE_ARRAY by the first value the program sent.
Code: [Select]
while(1):
            device_handle.controlWrite(0x40, 179, 0, 0, b'\x0f\x03\x03\x03\xd9\x10\x1d\x00\x90\xfe', timeout=timeout)
            print('Response', device_handle.controlRead(0xC0, 178, 0x00, 0, 10, timeout=0))
            try:
                data = device_handle.bulkRead(0x86, 10, timeout=100)
            except Exception as e:
                print('couldn\'t read')
            else:
                print('received', data)

            time.sleep(0.1)

What's interesting here is the WEIRD_BYTE_ARRAY value. This is a repeating (I think I've found 20-30 different values in an unknown order) value which initially made no sense to me. It isn't sequential, so clearly it isn't a frame number and doesn't seem to be any kind of setting.

Even though when capturing the commands my program sends they are equal to my previous capture of the Windows software, the scope doesn't return anything. I can't seem to get a single value out of it.



Okay, so here comes the interesting part. It's my suspicion that the software sends a sort of token before reading. If it corresponds to what the scope expects, it'll dump the buffer and won't otherwise. I ignore its purpose. It may be to authenticate to the device and prevent this sort of reverse engineering.

In the official Windows SDK (HT6004BX_Software.zip/SDK), the QTDSO demo imports the HTHardDll library, which is stored in some parent folder. I disassembled it using IDA-free and a ton of functions were listed. Logically, I peeked into the one responsible to read the scope's value (dsoGetInBuffer), and check out what I found:

in function dsoGetInBuffer
Code: [Select]
mov     rax, cs:__security_cookie
call    __security_check_cookie
If you follow this reference, you'll see:
Code: [Select]
uintptr_t _security_cookie
.data:000000018006E000 __security_cookie dq 2B992DDFA232h

I've got 0 clue about assembly and may be 100% wrong, but this seems to be the token that I see, and what prevents me from reading the DSO's buffer even when copying the commands the program sent previously verbatim. More research needs to be made in order to find how it works.




Regarding the USB protocol, I'm wondering whether it is rather high-level (with commands like "set V/div", "set timebase", "set trigger"), or whether is is low-level (with commands like "send byte sequence x to SPI device #y on SPI bus #z").

There's one last type of command that I seldom find:
Code: [Select]
device_handle.bulkWrite(0x02, b'\x04\x00\xd4\x70', timeout=0)
I don't know what these payload bytes mean yet. I've found different values and they also seem to be sent when not changing any setting.

In the 6022, the command:
Code: [Select]
device_handle.controlWrite(0x40, 224+chNumber, 0, 0, VOLTAGE_RANGE_ID)
sets the scope's voltage range. I haven't found this to be the case in my 6204BD.




Maybe this link: Android APK for Hantek 6004 series
can help you.. ;)
I found this Android app last November and I'm wondering that it seems still unknown  :-//
I was too lazy to create a thread for it 'cause it's not my stuff..
Wow, good find! Yeah, unfortunately the cool stuff is hidden in that ht6000api.aar file. I've decompiled the java files in: JD-GUI and, while all the names are unobfuscated and are quite easy to understand, everything useful seems to be inside ht6000api.aar/jni/x86-64/libhantek-native-lib.so. I've also opened it and it also seems to corroborate the polling-nature of the software. It shines some light on some aspects, however:
In function ht_measure_update
Code: [Select]
mov     rax, cs:g_channelsInfo_ptr

There you go, (some) channel info appears to be sent every time the buffer is polled.

It was announced here in the Forum.
Unfortunately it contains a binary-only library "ht6000api.aar" with unclear origin and copyright.
The "interesting" part is hidden in this library, while the open sourced components are just the GUI stuff.
This is a really weird project. Almost nobody knows about it, the source includes dependencies from unknown originsm the github user has no other projects and the EEVblog account seemed to be created for that only purpose. Again, I'm not going to complaint since I've also created my account to discuss this project :)

Clearly, the ht6000api resource file comes from Hantek themselves, and it contains quite interesting file:
In ht6000api.aar/assets/autowave
.amr files, which start with the ASCII chars:
Code: [Select]
H.T.K.-.D.S.O.-.A.M.
And are named like car diagnostics events. Are they recordings?
And also, in ht6000api.aar/assets/autowave/settings
.set which start with the hex values:
Code: [Select]
H.T.K.-.D.S.O.
They are very short, are mostly the same and contain mainly 0s. This could shed some light into this, since they clearly specify the scope's configuration. They may be directly written on the EEPROM of the device, and (if these settings are directly stored in this memory) we could deduce the offsets of each config. If the official Hantek software supports these automotive files, it'd great to see how they are sent via USB.

It'd be great if user hackscope from the Hantek60x4 android APP could chime in on this. Then again, the git repo was abandoned last December, so who knows.

When I get some more free time, I'll continue investigating and will keep you up to date (even if I spend another 2h organizing my findings and writing this post lol). With some luck, I'll clean up the mess of code I've written and will publish it.

This is my first time working with USB, attempting to do something useful with wireshark and reverse engineering anything, so mind that I may be wrong on tons of stuff. I'm a total noob on all of these fields and still have got tons to learn. Any input is much appreciated.

 
The following users thanked this post: gf

Offline gf

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #13 on: April 02, 2019, 03:58:23 am »
I've got 0 clue about assembly and may be 100% wrong, but this seems to be the token that I see, and what prevents me from reading the DSO's buffer even when copying the commands the program sent previously verbatim. More research needs to be made in order to find how it works.

__security_check_cookie is the stack protection mechanism of the Visual Studio compiler. The "cookie" is set at the entry point of a function and checked upon return, aborting the program if the return address was overwritten on the stack (e.g. due to buffer overrun). It is not really relevant for your considerations.

Last year - shortly after I got my 6074BD - I also did start digging into HTHard.dll with IDA, but then it fell asleep due to lack of free time. In the mean time my PC had a disk crash and I had to re-install it from the scratch on a new disk. I don't think it's possible to recover anything I've annotated so far in the disassmbly from the faulty disk :(
« Last Edit: April 02, 2019, 05:02:48 am by gf »
 

Offline Microcheap

  • Regular Contributor
  • *
  • Posts: 102
  • Country: 00
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #14 on: April 07, 2019, 02:14:35 pm »

Would someone kindly confirm what are the DAC (U31) and the the output opamp (U32) of the AWG in this scope, please? I couldn't see the markings from the posted pictures.
Hantek uses in other scopes DAC902E and EL5166, but I would like to confirm that. I have a 6074BE board that I want try to mod and add the AWG.

The PCB for 6x74BE, 6xx4BD and 6xx4BC looks exactly the same, the PC software and USB driver are also the same, I think the only difference is some detail in the FW stored in the eeprom chip (U807) that is loaded to the Cypress uC. If it's not to much to ask, it would be nice to have a copy of the eeprom content to compare with mine and see if these devices are easily hackable.

I left a copy of mine here https://fil.email/Aknb5dl8
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #15 on: April 07, 2019, 07:59:02 pm »
Hantek uses in other scopes DAC902E and EL5166,...

Yes, exactly these ones, in my 6074BD, too.

A potential issue with retrofitting the AWG is its calibration. The software does not offer a calibration procedure for the AWG, and it is not known where and how the calibration data (I guess it's just gain & offset) are stored.
« Last Edit: April 07, 2019, 09:18:44 pm by gf »
 

Offline Microcheap

  • Regular Contributor
  • *
  • Posts: 102
  • Country: 00
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #16 on: April 08, 2019, 01:11:56 am »
Thanks gf for the confirmation.

The calibration data for the input channels are stored in the EEPROM (I found that trying to fix that offset problem that you reported in the other forum) if you check the .bin file it starts after the serial number of the device (at around 0x15C0), so I would bet that the AWG data is somewhere there as well.
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #17 on: April 08, 2019, 02:11:31 am »
@Microcheap, just to be sure, do you mean same the EEPROM which stores the 8051 code for the Cypress FX2LP? Or a separate data EEPROM?
 

Offline Microcheap

  • Regular Contributor
  • *
  • Posts: 102
  • Country: 00
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #18 on: April 08, 2019, 04:00:31 am »

It is the 24LC64 EEPROM chip (U807 on the board), if you flip the board you will find it underneath the Cypress uC.
 

Offline martinloren2

  • Contributor
  • Posts: 7
  • Country: cn
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #19 on: April 16, 2019, 08:51:28 pm »
I left a copy of mine here https://fil.email/Aknb5dl8

Is it the eeprom content? Can you send it to me? (support@martinloren.com) I may compare it with that one from 6074.
 

Offline bianchifan

  • Regular Contributor
  • *
  • Posts: 65
  • Country: de
Re: Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
« Reply #20 on: April 27, 2019, 07:42:24 pm »
Some days ago my ordered 6074BC has arrived.
For I have no working Windows partition any more and do not like to put all that stuff in my WINE prefix I did a short test of the Android apk today.
What I can say..it works. But almost in automatic mode only.
I was able to select the channels and the timebase but I couldn't adjust the vertical sensitivity.


It would be very nice if we can make it run with OpenHantek.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf