Hantek 6254BD 250MHz 1GSa/s PC/USB DSO - Page 1
Forum section: electronics / testgear

author: doobs
author_rank: Newbie
timestamp: March 17, 2018, 03:43:46 am
content: HiI 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 fromhttp://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- 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 OpenHantekhttps://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 sigrokhttps://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 Hantek6022APIhttps://github.com/rpcope1/Hantek6022APIproject and that in turn apparently had its genesis through this eevblog forumhttps://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, LLCI 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.sysCode:Dso5200x861.sys: file format pei-i386architecture: i386, flags 0x0000013b:HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGEDstart address 0x00010334Sections:Idx Name Size VMA LMA File off Algn0 .text 000005f6 000102a0 000102a0 000002a0 2**2CONTENTS, ALLOC, LOAD, READONLY, CODE1 .data 00002590 000108a0 000108a0 000008a0 2**2CONTENTS, ALLOC, LOAD, DATA2 INIT 0000019c 00012e40 00012e40 00002e40 2**2CONTENTS, ALLOC, LOAD, CODE3 .rsrc 00000348 00012fe0 00012fe0 00002fe0 2**2CONTENTS, ALLOC, LOAD, READONLY, DATA4 .reloc 00000082 00013340 00013340 00003340 2**2CONTENTS, ALLOC, LOAD, READONLY, DATASYMBOL 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[ 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 endSo 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.sysCode:Hantek6000BX86.sys: file format pei-i386architecture: i386, flags 0x0000012f:HAS_RELOC, EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_LOCALS, D_PAGEDstart address 0x0001283eSections:Idx Name Size VMA LMA File off Algn0 .text 00002142 00010480 00010480 00000480 2**2CONTENTS, ALLOC, LOAD, READONLY, CODE1 .rdata 00000144 00012600 00012600 00002600 2**2CONTENTS, ALLOC, LOAD, READONLY, DATA2 .data 00000008 00012780 00012780 00002780 2**2CONTENTS, ALLOC, LOAD, DATA3 INIT 00000442 00012800 00012800 00002800 2**2CONTENTS, ALLOC, LOAD, CODE4 .rsrc 00000378 00012c80 00012c80 00002c80 2**2CONTENTS, ALLOC, LOAD, READONLY, DATA5 .reloc 000001b2 00013000 00013000 00003000 2**2CONTENTS, ALLOC, LOAD, READONLY, DATAHantek6000BX86.sys: not a dynamic objectSYMBOL TABLE:no symbolsDYNAMIC SYMBOL TABLE:no symbolsSo, 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:memcpysprintfInterlockedDecrementInterlockedIncrementIoFreeIrpIoInitializeIrpIoAllocateIrpKeInitializeSpinLockKfReleaseSpinLockKfAcquireSpinLockIoAttachDeviceToDeviceStackMmMapLockedPagesKeTickCountKeBugCheckExntoskrnl.exeHAL.DLLUSBD_GetUSBDIVersionUSBD_CreateConfigurationRequestExUSBD_ParseConfigurationDescriptorExUSBD.SYSwhereas 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_firmwareSo, 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 withCode:pkt time from to protocol length info10.000000host5.1.0USB36GET DESCRIPTOR Request DEVICE40.000000host5.1.0USB36GET DESCRIPTOR Request CONFIGURATION70.000000host5.1.0USB36GET DESCRIPTOR Request CONFIGURATION100.000000host5.1.0USB36SET CONFIGURATION Request234.2343755.1.6hostUSB539URB_BULK in824.3750005.1.0hostUSB1052URB_CONTROL inBasically, 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 Flashhttp://www.bios-chip24.com/MXIC-MX-25L4006E-M2I-12G-4Mbit-SPI-Serial-Flash-SOIC-8/enchip sitting to the east of the FPGA and between it and the USBXIhttp://www.hantek.com/en/NewsShow_51.htmlport. 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-Converterhttp://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].To the north of the FPGA is DAC902E - a Digital-to-Analogue Converterhttp://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 chiphttp://www.cypress.com/file/138911/downloadrunning 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 EEPROMhttp://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 theFX2LP.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-Ampshttp://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 bothCode:examples/example_linux_readeeprom.pyexamples/example_linux_readfirmware.pyThose 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.5http://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.

author: gf
author_rank: Super Contributor
timestamp: April 07, 2018, 09:20:44 am
content: I recently bought the "small brother" 6074BD (70MHz).QuoteI'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).QuoteWhat 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.QuoteThe 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

author: bugi
author_rank: Regular Contributor
timestamp: April 07, 2018, 06:02:20 pm
content: Quote from: doobs on March 17, 2018, 03:43:46 amYou'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.QuoteConsidering 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.

author: doobs
author_rank: Newbie
timestamp: April 24, 2018, 01:49:09 pm
content: 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 herehttps://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 againdoobs

author: gf
author_rank: Super Contributor
timestamp: April 24, 2018, 07:47:37 pm
content: QuoteHi,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

author: gf
author_rank: Super Contributor
timestamp: April 24, 2018, 08:52:35 pm
content: Adding my photos.gf

author: martinloren2
author_rank: Newbie
timestamp: January 24, 2019, 03:51:44 pm
content: Can you send me the firmware? Eventually you can export it with the android app Cypress FX2 Utils. support@martinloren.com

author: rgon
author_rank: Newbie
timestamp: March 22, 2019, 12:36:09 pm
content: 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 bethathard. 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.

author: gf
author_rank: Super Contributor
timestamp: March 23, 2019, 12:59:00 pm
content: 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).

author: bianchifan
author_rank: Regular Contributor
timestamp: March 23, 2019, 02:11:48 pm
content: Quote from: rgon on March 22, 2019, 12:36:09 pmMe too!Unfortunately I dod not own one up to now, I'm still thinking...Quote from: rgon on March 22, 2019, 12:36:09 pmMaybe this link:Android APK for Hantek 6004 seriescan help you..I found this Andropid app last November and I'm wondering that it seems still unknownI was too lazy to create a thread for it 'cause it's not my stuff..

author: gf
author_rank: Super Contributor
timestamp: March 23, 2019, 07:04:04 pm
content: Quote from: bianchifan on March 23, 2019, 02:11:48 pmIt 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.

author: bianchifan
author_rank: Regular Contributor
timestamp: March 24, 2019, 07:02:32 pm
content: Quote from: gf on March 23, 2019, 07:04:04 pmOK...just found it in an area I've never looked atThe 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...

author: rgon
author_rank: Newbie
timestamp: April 01, 2019, 01:30:14 pm
content: 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:import libusb1device_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:print('EEPROM Response', device_handle.controlRead(0xC0, 162, MEM_OFFSET, 0, 8, timeout=0))and to write:Code: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: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: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 substitutedWEIRD_BYTE_ARRAYby the first value the program sent.Code: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 theWEIRD_BYTE_ARRAYvalue. 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), theQTDSOdemo imports theHTHardDlllibrary, 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 dsoGetInBufferCode:mov rax, cs:__security_cookiecall __security_check_cookieIf you follow this reference, you'll see:Code:uintptr_t _security_cookie.data:000000018006E000 __security_cookie dq 2B992DDFA232hI'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.Quote from: gf on March 23, 2019, 12:59:00 pmThere's one last type of command that I seldom find:Code: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: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.Quote from: bianchifan on March 23, 2019, 02:11:48 pmWow, 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 insideht6000api.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_updateCode:mov rax, cs:g_channelsInfo_ptrThere you go, (some) channel info appears to be sent every time the buffer is polled.Quote from: gf on March 23, 2019, 07:04:04 pmThis 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 projectClearly, 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: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: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 userhackscopefrom 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.

author: gf
author_rank: Super Contributor
timestamp: April 01, 2019, 04:58:23 pm
content: Quote from: rgon on April 01, 2019, 01:30:14 pm__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

author: Microcheap
author_rank: Frequent Contributor
timestamp: April 07, 2019, 04:14:35 am
content: 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 herehttps://fil.email/Aknb5dl8

author: gf
author_rank: Super Contributor
timestamp: April 07, 2019, 09:59:02 am
content: Quote from: Microcheap on April 07, 2019, 04:14:35 amYes, 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.

author: Microcheap
author_rank: Frequent Contributor
timestamp: April 07, 2019, 03:11:56 pm
content: 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.

author: gf
author_rank: Super Contributor
timestamp: April 07, 2019, 04:11:31 pm
content: @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?

author: Microcheap
author_rank: Frequent Contributor
timestamp: April 07, 2019, 06:00:31 pm
content: It is the 24LC64 EEPROM chip (U807 on the board), if you flip the board you will find it underneath the Cypress uC.

author: martinloren2
author_rank: Newbie
timestamp: April 16, 2019, 10:51:28 am
content: Quote from: Microcheap on April 07, 2019, 04:14:35 amIs it the eeprom content? Can you send it to me? (support@martinloren.com) I may compare it with that one from 6074.

author: bianchifan
author_rank: Regular Contributor
timestamp: April 27, 2019, 09:42:24 am
content: 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.

author: Appocalypse_br
author_rank: Contributor
timestamp: September 28, 2019, 06:30:30 pm
content: Hi there i have a hantek usb 6104bc, seems to have bricked it just using it normally, now it don't power up don't show red light but inside have yellow led, when i plug it in yellow led turns on and off, Windows makes the usb sound but gets stuck in this part and don't go foward, if anyone have tutorial how to unbrick it, will be great thanks you all guys.

author: Neekeetos
author_rank: Contributor
timestamp: September 29, 2019, 01:25:58 pm
content: Quote from: Microcheap on April 07, 2019, 04:14:35 amI have the same idea. Just fit DAC904E, it's almost compatible. My unit is 6074BCQuote from: Microcheap on April 07, 2019, 04:14:35 amWhat is the exact procedure to read eeprom from the unit? I assume there is some way of doing this via usb & cypress sw.It seems that 6xx4bc bd and be units have similar schematics, i'll attach pcb photos so anybody can compare(done some soldering already). They are probably share the same firmware and only differ in eeprom contents. Fpga in my scope is sending some sine data stream to dac out of the box, but there is no clock to dac and pd signal is active.BTW, regarding fpga firmware, i found that JTAG pinout iseeprom is compatible to M25P40 in Impact , so readout( as well as flashing own bin) is possible.add: attached cypress eeprom

author: Appocalypse_br
author_rank: Contributor
timestamp: October 02, 2019, 06:01:54 pm
content: Yes its exactly that board can you sendme copy of your firmware? mine is corrupted won't work anymore.

author: Neekeetos
author_rank: Contributor
timestamp: October 02, 2019, 06:09:57 pm
content: Quote from: Appocalypse_br on October 02, 2019, 06:01:54 pmI only have FW for fpga, attached to this message. Not yet figured out how to read cy7c68013 eeprom.BTW: I managed to replace some npns and jfet on last channel, but i see almost no improvement on bw. Guess there is some filter fpga is applying on adc data depending on settings which should come from usb mcu.

author: Microcheap
author_rank: Frequent Contributor
timestamp: October 02, 2019, 09:32:03 pm
content: Quote from: Neekeetos on October 02, 2019, 06:09:57 pmThe cypress chip has no internal eeprom, the FW is stored in a eeprom chip 24LC64 (IC U807) on the other side of the board, and it is loaded to the MCU during power up.Which version of the HT6xx4 do you have? If you can damp yours EEPROM content and post it here it would be nice.There is no hardware difference among the models, the BW is limited in software.

author: Neekeetos
author_rank: Contributor
timestamp: October 03, 2019, 03:54:07 pm
content: Quote from: Microcheap on October 02, 2019, 09:32:03 pmAttached to my previous message, so you potentially could find out which my scope model is...Just wonder if anybody can upload the eeprom from 6254bd model

author: Microcheap
author_rank: Frequent Contributor
timestamp: October 03, 2019, 04:07:58 pm
content: Quote from: Neekeetos on October 03, 2019, 03:54:07 pmThat is what I asked. I have the eeprom from a 6074bc and I would like to compare it to the 6254bd model, maybe the BW configuration is in there as the hardware are the same.

author: Neekeetos
author_rank: Contributor
timestamp: October 03, 2019, 04:27:08 pm
content: Spent some time reversing pcb, so here are my recent findings regarding fpga pinout:Code:// ADC HMCAD1511CSn B2SDATA A2SCLK B3RESETn A3PD C3DP1A B5DN1A A5DP1B B6DN1B A6DP2A C7DN2A A7DP2B B8DN2B A8LCLKP C9LCLKN A9FCLKP B10FCLKN A10DP3A C11DN3A A11DP3B B12DN3B A12DP4A C13DN4A A13DP4B B14DN4B A14// DAC902CLK E16PD J14DB11 F15DB10 F16DB9 G14DB8 G16DB7 H15DB6 H16DB5 J16DB4 K15DB3 K16DB2 L16DB1 M15DB0 M16// ledsnLED_green B1nLED_red C1// out square 1kOUT1K E3// main fpga clock 24M coming from quartz oscillator near cypress.CLK24M_IN K14// ADF4360 ref clock in 10M , fpga outputs this....CLK10M_OUT E15// OFFSET PWM 1.9khz for channels 1-4OFFSET_CH1 T13OFFSET_CH2 T15OFFSET_CH3 R16OFFSET_CH4 T14// ADF4360/HC595 SPICLK/SRCLK B16DATA/SER D16RCLK C16LE B15MUXOUT E12// J7 socketJ7_0 K1J7_1 J1J7_2 F1J7_3 E1J7_4 E2J7_5 D1// CY7C68013ACY_NRST G3SLRD F3SLWR F4SLOE K2PKTEND G1FIFOADR1 H2FIFOADR0 H1FLAGC M4FLAGB N4FLAGA P4IFCLKF2INT0 L3Managed to run DAC , but the main part which is pll init and adc read is not yet done.

author: Appocalypse_br
author_rank: Contributor
timestamp: October 03, 2019, 07:18:21 pm
content: Hey many thanks for the firmware, i am little noob in these i2c field can any of you guys help me trough the process of backup and write the firmware in my unit, many thanks, if you have some link to tutorial video or make a quick one will be great.(mine is bricked itself no red light blink anymore)thanks a lot.Just found these hey great work!https://sigrok.org/wiki/Hantek_6022BEhttps://sigrok.org/wiki/Hantek_6254BD(seems same of 6xxxBC mine 6104bc is same)https://sigrok.org/wiki/Hantek_6052BE

author: Neekeetos
author_rank: Contributor
timestamp: October 12, 2019, 06:46:54 am
content: Slight update on HW initialization details. The PLL is initialized every time scope software starts and never changes. There is a lock output from ADF4360 (muxout) connected to fpga pin , but it is not used. Init sequence is as follows:Full init sequenceWord 1Word 2Word 3There is also a chain of hc595 registers sharing SPI CLK/SRCLK and DATA/SER pins with ADF4360, however RCLK is independent( so as LE on PLL). Each register connects to own oscilloscope channel sharing the same functions which are :QHLPF_ENABLEQF/QGATT2_RELAYQD/QEATT1_RELAYQCAC_DC_RELAYQBADC_DRIVER_ENABLESome example bus data:Word 1Word 2

author: eevblogfan1
author_rank: Newbie
timestamp: October 28, 2019, 02:57:49 pm
content: I managed to score a 6254BD for $80 on ebay and while I await it to arrive, and cross my fingers I didn't get bamboozled, I decided to research everything I could find about the device, and I found your forum and the hantek support forum in the process. In particular I noticed the below:Quote from: rgon on April 01, 2019, 01:30:14 pmAnd I also noticed a person on Hantek support forum had an issue with the usb device having the wrong idQuoteWhich is quite common, so it seems they finally got tired of emailing out that iic firmware to fix usb device issues and their employee Amy just attached it to ato their post in reply. You have to register to see attachments, but it can be done in less than a minute, I have also attached it to the end of this post. Perhaps it will help some people out here. The iic itself seems to be the same for 0x13FD bytes as the cy_eeprom_dso6074bc.zip firmware posted by neeketos, but neeketos seems to have additional data beyond that.Screenshot of forum post and partial file listingIf anybody would like to decode the iic file, one way would be to go to section 3.4.3 Serial EEPROM Present, First Byte is 0xC2 of themanual here. Although there might be better ways, perhaps sigrok has some utilities that automate the process, I don't really know to much about the project other than it seems they are fx2 gurus.Quote from: rgon on April 01, 2019, 01:30:14 pmWhile I am on the topic of rgon's post, did you ever publish anything or do any more investigation work?

author: Appocalypse_br
author_rank: Contributor
timestamp: October 30, 2019, 06:25:01 pm
content: Hi every one, mine 6104bc bricked it self in normal day to day use, so i desolder the 24lc64 and writed the 6074bc firmware dump provided in this forum. YAY! device is working now!BUT when i set in milivolts and the relay activates the signals of the channel gets mixed with the others, any clue why that is happening? i will try to program the original firmware back.Thanks to the users that are helping me.

author: Appocalypse_br
author_rank: Contributor
timestamp: October 31, 2019, 05:18:31 pm
content: Problem 1Before writting the original dump back in i tried the program posted above seems to write via EZ-USB.But when i click the EZ-USB shows the next screen, in that screen i can't click in any button, you guys have any clue why is that?Maybe because i have the eproom with data in it, the program do not works?Should i erase the data and try trought the EZ-USB to fix the milivolts problem?Problem 2Attached the pictures of the problem.1x Probe, 100mv div, DC, measure the 2vpp test point (AC no problem)(10x PROBE no problem)

author: Microcheap
author_rank: Frequent Contributor
timestamp: November 01, 2019, 02:40:54 am
content: I'm not sure if I understood your 2nd problem, but there was a bug in the software version 2.2.4 (the one you are using) that I helped Hantek to identify and that introduced an offset error in the oscilloscope's channels. You need to update the software to Ver2.2.5 or downgrade to version 2.1.36 and run the self-calibration again.https://www.eediscuss.com/forum.php?mod=redirect&goto=findpost&ptid=14725&pid=18097&fromuid=26055

author: Neekeetos
author_rank: Contributor
timestamp: November 02, 2019, 01:50:25 pm
content: Quote from: eevblogfan1 on October 28, 2019, 02:57:49 pmBet this data is calibration and nothing interesting. I tested your version of cypress fw, but i see no changes in features, no functional gen appeared and bw not improved. It seems to me that functional cap is done via different fpga fw for particular models of scope. But, great that there is no need in dedicated programmer for cypress, as it flashes itself via usb....Quote from: eevblogfan1 on October 28, 2019, 02:57:49 pmThe great need in this "anybody" who knows cypress well and can extract info on how fw works. This is due to my findings - fpga eeprom is connected directly to cypress pins , thus could be read and programmed!Pins are (PD* are cypress port pins ) :PD0 : flash_nCSPD1 : flash_CLKPD2 : flash_SIPD3 : flash_SOPD4 : flash_nWPThere are also 3 unsoldered jumpers nearby:PD5 : R197PD6 : R198PD7 : R199

author: Appocalypse_br
author_rank: Contributor
timestamp: November 04, 2019, 03:26:36 pm
content: Quote from: Microcheap on November 01, 2019, 02:40:54 amOk, but is not an offset problem, i have only proble 3 connected, no input signal in other channels, but as you can see the signal in channel 3 over shoot the screen and affect the other channels. Even in v2.2.5 screenshot down.

author: Microcheap
author_rank: Frequent Contributor
timestamp: November 05, 2019, 03:30:37 am
content: ...Ah, ok I managed to reproduce the problem. I first thought it could be coupled noise in the inputs but it looks like it just another bug in the software, it happens when using a x1 probe and the vertical scale is set to 100mV or smaller and the signal is >= 2Vpp so it gets out of the screen area.Not really an issue since that, for a 2Vpp signal, you will have to set the volt/div to a scale greater than 100mV to be able to see the waveform correctly anyway.

author: Appocalypse_br
author_rank: Contributor
timestamp: November 24, 2019, 08:04:33 pm
content: Yes thanks for the 2.2.5 info, but its a bug confirmed.

author: PointLess
author_rank: Newbie
timestamp: May 05, 2020, 10:23:29 am
content: Anyone ran into a problem that 6254 stopped displaying signal waveform in software and solved that? I've already tried restarting/reinstalling/etc, even other PC, still no luck...I use Windows 10 x64 1909 and latest 2.2.5 software, it shows 6254 connected, turning voltage knob makes relay clicking noises.Need help badly if anyone knows any suggestions.I got a eeprom programmer so reading/writing all 24/25/etc eeproms is not a problem.PS Problem solved. Looks like the 3.3v PWM dc-dc is a weak point in schematics, so changing it to a typical linear LDO 3.3v stabilizer like 1117-3.3 closes the case forever. I was really surprised why they used PWM instead of linear dc-dc because it makes little sense in minimizing noise over power supply lines for such sensitive equipment.

author: Hantek
author_rank: Newbie
timestamp: December 21, 2020, 01:44:45 am
content: i have an Hantek 6254BD 250MHz 1GSa/s PC/USB DSOcan anyone tell me what is the part number of a square tiny chip with 10 leads/legs U38, seats next to the 2r2 inductor on the right side of the usb port, the metal spring facing up.started to get overheated and soon it blew up.i cannot read the part number. and if you know what it is for please let me know.thank you

author: Microcheap
author_rank: Frequent Contributor
timestamp: December 21, 2020, 06:16:04 am
content: The U38 IC is a TPS63000 (marking code BPT). It's a buck-boost converter from TI. You can easily buy it from many sources, it's cheap.https://www.ti.com/lit/ds/symlink/tps63001.pdf

author: Hantek
author_rank: Newbie
timestamp: December 21, 2020, 10:16:51 pm
content: thank you very much.

author: danman
author_rank: Newbie
timestamp: January 12, 2022, 03:05:20 am
content: Quote from: rgon on April 01, 2019, 01:30:14 pmI've managed to load the FX2 firmware into ghidra and the above block seems to be resetting EP buffers and signalling something to PORTA (FPGA?).I'll keep investigating the code. My device is about to come on Friday.

author: danman
author_rank: Newbie
timestamp: January 18, 2022, 11:33:03 am
content: I have really basic opensource python version working here:https://github.com/danielkucera/pyhantekContributions are welcome!

author: mrfrenzy
author_rank: Newbie
timestamp: August 03, 2022, 11:01:42 am
content: This looks really promising!Do you have any roadmap on what is needed to make it usable?I might want to get a 6254 and try some contributions.

author: danman
author_rank: Newbie
timestamp: August 03, 2022, 11:21:38 am
content: I put it aside a little bit because I made the original software work under Wine:https://github.com/danielkucera/hantek-wine-driverThere is a lot of things to discover and implement in the python driver:- the whole configuration:- triggers- offsets- timebase- v/div- ...- calibrationetc, etc,...There are some hints in the provided SDK with windows .dll but it needs a lot of time and development.

author: mrfrenzy
author_rank: Newbie
timestamp: August 03, 2022, 11:39:05 am
content: Thankyou for your effort.I understand there is quite a lot to be done. I am basically looking for a software alternative that can be automated from the command line to auto start and save measurements from every trigger.I might get the 6254 and do this temporarily with AutoIT for this project, later if I get time I will try to contribute some testing of different configuration parameters.

author: daro19862
author_rank: Newbie
timestamp: March 12, 2024, 06:22:43 pm
content: HelloIs it possible to make the oscilloscope work with pulseview?

author: SiberK
author_rank: Newbie
timestamp: August 27, 2024, 08:06:07 am
content: Привет! Если это ещё актуально.Я тоже прикупил 6254BD, и мне тоже не очень понравилось штатное ПО.Решил поковырять SDK для него. Кое-что получается.Если кому-то интересно, обсудить можноздесь.Картинки и коротенькое видеоздесь.Исходникиипререлиз.

author: dedcaps1
author_rank: Newbie
timestamp: August 27, 2024, 12:28:30 pm
content: hidoes anyone know something about the Be automotive version?i have a very similar "signal" like this "without problem" picture:https://www.eevblog.com/forum/testgear/hantek-6254bd-250mhz-1gsas-pcusb-dso/msg2763860/#msg2763860but even that "signal" is somehow really fuzzy and it is kinda hard to see any crank/camshaft signal and yet alone somehow compare them etc... and is there any better software for it, because even the trigger function doesnt seem to work and only "pause/stop" gives that really fuzzy graph... or is it just some signal interference on the car, because i have only tested it on a kinda old car...i would basically expect the signal to be more clear and solid like this:https://www.eevblog.com/forum/testgear/hantek-6254bd-250mhz-1gsas-pcusb-dso/msg2734660/#msg2734660

author: radeko
author_rank: Newbie
timestamp: September 20, 2024, 10:00:08 pm
content: You can use Hscope App with Hantek 6xx4 Osciloscopes.It Works on Android. Can also work on android on raspbery pi.Hscope Automotive Module: supported up to 125KSa/s real-timehttps://www.martinloren.com/hantek-6xx4/

author: arda_bildik
author_rank: Newbie
timestamp: May 01, 2025, 02:44:24 pm
content: Hi guys I've read the thread from start and I thinka waveform gen upgrade from 6xx4BC to 6xx4BD seems possible. I am not much deep into fpga based electronics, have anyone of you got successful on trying to upgrade it? I have tried to upload newer firmware to the DSO but PC program doesnt enable the DDS menu on the interface.