Products > Test Equipment
Hantek 6254BD 250MHz 1GSa/s PC/USB DSO
doobs:
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: --- bcdedit -set loadoptions DISABLE_INTEGRITY_CHECKS
--- End code ---
- 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: ---04b5:6cde ROHM LSI Systems USA, LLC
--- End code ---
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: ---objdump -s -h -f -F -t -T Dso5200x861.sys
--- End code ---
--- Code: ---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
--- End code ---
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: ---objdump -s -h -f -F -t -T Hantek6000BX86.sys
--- End code ---
--- Code: ---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
--- End code ---
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: ---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
--- End code ---
whereas doing the same for Dso5200x861.sys reveals function calls like:
--- Code: ---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
--- End code ---
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: ---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
--- End code ---
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: ---examples/example_linux_readeeprom.py
examples/example_linux_readfirmware.py
--- End code ---
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.
gf:
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,...
--- End quote ---
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...
--- End quote ---
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
--- End quote ---
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
bugi:
--- Quote from: doobs on March 17, 2018, 03:43:46 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.
--- End quote ---
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! ...
--- End quote ---
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.
doobs:
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
gf:
--- 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.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
Go to full version