Credits

The initial import of this documentation comes from the work "tinhead" has done over on the www.mikrocontroller.net pages.

Introduction

The DSOs are identifiable only by the USB VID:PID 049f:505a (this VID is actually assigned to Compaq), and the bus and device address. When operating several DSO5xxxBs on a PC they cannot be distinguished by their serial number as Hantek sets the iSerial field in the USB descriptor to 0.

The CPU is the MIZI Research/Samsung S3C2410 SMDK. It contains the USB char driver (usb-char.c, Linux 2.4.18), and which uses the VID:PID 049f:505a. Although the DSO is based on a newer kernel (2.6.13), this driver was taken from the previous model Tekway DST1000 (not B!).

Apparently the DSO5xxxBM/BMV models, running Linux 2.6.30.4, use the "serial gadget" driver. Whether this is an improvement is currently not known.

Another effect of this driver is that the DSO briefly shows up at boot with another VID:PID on the USB bus. The bootloader (vivi) uses a SoC monitor, such as the Samsung S3C2440 SMDK (u2440mon), which when booting reports its own VID:PID on the USB port. While this may be very useful for hacking, backup or similar, changing the VID:PID causes BSODs on Win64 PCs.

Hantek's DSO protocol is layered directly on top of the USB bulk transfers. It is request/response oriented, meaning the USB host sends a request and receives a list of answers. The protocol can therefore be used in a single-threaded application using synchronous USB communication, even though Hantek's TTScope application uses separate transmit and receive threads.

Basic Structure

Marker0x43 or 0x53

Length

Command

Data bytes

Checksum

LSB

MSB

Marker0x43 or 0x53

Length

Command

Subcommand

Data bytes

Checksum

LSB

MSB

Marker0x43 or 0x53

Length

Command

Checksum

LSB

MSB

The message format is the same for requests and responses. Each message begins with a marker byte. There are two different markers:

0x53: normal message

0x43: debug message

This is followed by two bytes indicating the length of the message, LSB first, excluding the marker and length fields.

The word length is followed by the command byte. The reply to this command will have bit 7 set in the command byte. Therefore command bytes from PC to device are always smaller than 0x80, and the responses are always greater than or equal to 0x80.

The command byte is followed by command-specific data bytes. Some commands use the first data byte as a sub-command. The number of data bytes can be zero.

The data byte is followed by a primitive checksum byte. To calculate this checksum, add up all the bytes of the message. The LSB of this sum is used as the checksum.

0x53 Normal messages

Most 0x53 messages are used by the TTScope software.

0x00 Echo

All data bytes in the request are simply returned unchanged.

0x01 Read DSO settings

This gives a long record in which the current settings of the DSO are binary encoded.

To ensure that the SYSData structure is decoded correctly it is recommended to read the /protocol.inf file immediately after connecting (see Read file).

If the protocol.inf file on the DSO is not readable or available the reply will be empty, i.e. it will contain no data byte:

0x53

0x02

0x00

0x81

0xD6

0x02 Read sample data

Only the sample data of the two channels (CH1/CH2) can be retrieved. The REF, MATH and FFT data can not be accessed, which is probably why Hantek's TTScope software shows nonsense data under "PowerSpectrum" and "WaveTabulator".

The request:

0x53

0x04

0x00

0x02

0x01

0x00 for CH1 or 0x01 for CH2

Checksum

The DSO responds with at least 3 and at most 202 packets. The first packet (subcommand 0x00) describes the total length of the sample data. The second packet (subcommand 0x01) contains a channel number and the sample data itself. If the sample data is longer than 10000 bytes, further packets with subcommand 0x01 are sent.

This is an example of a small transfer from a DSO5xxxB set to 4ns/DIV and 4K buffer:

0x53

0x06

0x00

0x82

0x00

Sample data length (3 bytes)

Checksum

0x53

0x5c

0x02

0x82

0x01

CHn + 0x..0x.. (600 bytes of sample data)

Checksum

0x53

0x04

0x00

0x82

0x02

CHn (0x00 for CH1 or 0x01 for CH2)

Checksum

Here's an example with more data (150 packets with 10000 sample bytes per packet) from a DSO1202BV with 2ms/DIV and 2M buffer:

0x53

0x06

0x00

0x82

0x00

Sample data length (3 byte)

Checksumme

0x53

0x14

0x27

0x82

0x01

CHn + 0x..0x.. (10000 bytes of sample data)

Checksum

148 more packets with subcommand 0x01 and CHn sample data

0x53

0x14

0x27

0x82

0x01

CHn + 0x..0x.. (10000 bytes of sample data)

Checksum

0x53

0x04

0x00

0x82

0x02

CHn (0x00 for CH1 or 0x01 for CH2)

Checksum

If an errors occurs during transmission, a special packet is sent with subcommand 0x03. This can also be sent if the DSO is in STOP mode, in which case there is no data available.

0x53

0x04

0x00

0x82

0x03

CHn (0x00 for CH1 or 0x01 for CH2)

Checksum

Since the sample data contains no information about the current DSO settings (channel, volts/DIV, timebase), it is important to read the settings first. The following commands ensure a consistency data set:

0x12 Lock panel

0x01 Read DSO settings

0x12 Unlock panel

0x02 Read sample data

0x00 or 0x01 can be used as "idle" commands

If both channels need to be read, the samples can be read sequentially:

0x12 Lock panel

0x01 Read DSO settings

0x12 Unlock panel

0x02 Read CH1 sample data

0x02 Read CH2 sample data

0x00 or 0x01 can be used as "idle" commands

Originally (in the Tekway DST1000 with 2.5Kpoint memory) the panel was also locked during the sample data transmission. This is not recommended for the current DSOs, since the data volumes are much higher than in this original model.

The sample data are post-processed from the image memory. The values are 10 DIV vertical (-127 to 127) and 20 DIV horizontal.

0x10 Read file

This function can be used to read any file on the DSO, but is primarily intended to read the protocol.inf (see Read DSO settings) and keyprotocol.inf (see Keypress trigger) files.

The request must include the complete file path.

0x53

Length

0x10

0x00

File path

Checksum

LSB

MSB

The response uses two subcommands:

0x01: Data

0x02: Checksum of all data

If the contents of the file don't fit in one response packet, further packets with the subcommand 0x01 are sent. The packet with subcommand 0x02 marks the end of the file transfer, and contains a checksum of the entire file.

As far as we know the "start/stop DSO acquisition" function triggers the same action internally as pressing the "run stop" button on the control panel. However it appears to be somewhat buggy. Call this function before retrieving sample data from the DSO.

Lock control panel:

0x53

0x04

0x00

0x12

0x01

0x01

Checksum 0x6b

Unlock control panel:

0x53

0x04

0x00

0x12

0x01

0x00

Checksum 0x6a

When the control panel is locked a red key appears on the top status bar of the DSO's display, and the controls no longer respond.

The response contains the sent lock/unlock command:

0x53

0x04

0x00

0x92

0x01

0x01 or 0x00

Checksum

0x13 Keypress trigger

Lets you simulate the press of nearly any button on the DSO's control panel. The desired key is selected by two bytes of data:

0x53

0x04

0x00

0x13

0x..

0x..

Checksum

The first byte is the key code. The second byte is the number of key presses, according to Hantek. However values higher than one appear to result in only one keypress regardless, so there is no point is specifying anything other than 0x01 for this.

The following keycodes are available for the Hantek DSO5xxxB/BM/BMV, Tekway DST1xxxB and Voltcraft DSO-3062C bench scopes:

The reply to a key command contains a data byte that refers to the menu that was displayed in response to the keypress. The menu need not actually be displayed.

0x53

0x03

0x00

0x93

0x..

Checksum

0x14 Set system time

Lets you set the system time.

0x53

0x09

0x00

0x14

Data bytes (YYMDHMS)

Checksum

The data bytes:

Byte 1: Year (LSB)

Byte 2: Year (MSB)

Byte 3: Month (1...12)

Byte 4: Day (1...31)

Byte 5: Hour (0...23)

Byte 6: Minute (0...59)

Byte 7: Second (0...59)

The reply is a packet without data bytes:

0x53

0x02

0x00

0x94

Checksumme

0x20 Screenshot

After receiving this command, the DSO sends a screenshot image without size or color palette information. It is sent back in multiple reply messages, up to a total of 384000 bytes. This corresponds to the 800x480 resolution of the display, with a color depth of 8 bits.

The PC sends a request without data bytes:

0x53

0x02

0x00

0x20

0x75

The DSO responds with 37 packets of 10208 bytes, with subcommand 0x01. The 38th packet is a little shorter, containing only 6304 bytes. After this another packet is sent with subcommand 0x02, containing a primitive checksum.

0x53

0xE3

0x27

0xA0

0x01

0x.. 0x.. 0x.. .. .. .. (10208 bytes)

Checksum

...

0x53

0xA3

0x18

0xA0

0x01

0x.. 0x.. 0x.. .. .. .. (6304 bytes)

Checksum

0x53

0x04

0x00

0xA0

0x02

Image checksum (1 byte)

Checksum

These DSO protocol packets are split up into multiple USB packets, but your USB library should resolve this transparently.

The received image is in the format of a windows bitmap with 256 colors. The image is flipped vertically, i.e. the bottom line is sent first. The color palette is compiled into the dso.exe program on the DSO, and TTScope on the PC, and has a length of 1024 bytes.

In the handheld Hantek DSO1202B/BV, DSO1102B/BV and DSO1062B/BV the display has a 640x480 resolution. This results in a total 307200 bytes of data transmitted for the screenshot.

The PC sends a request without data bytes:

0x53

0x02

0x00

0x20

0x75

The DSO responds with 30 packets containing 10208 bytes, subcommand 0x01. The 31st packet contains only 960 bytes, and is again followed by a final packet containing a checksum for the screenshot data:

0x53

0xE3

0x27

0xA0

0x01

0x.. 0x.. 0x.. .. .. .. (10208 bytes)

Checksum

...

0x53

0xA3

0x18

0xA0

0x01

0x.. 0x.. 0x.. .. .. .. (960 bytes)

Checksum

0x53

0x04

0x00

0xA0

0x02

Image Checksum (1 byte)

Checksum

0x21 Read system time

Lets you read the device's system time.

The PC sends a request without data bytes:

0x53

0x02

0x00

0x21

0x76

The reply contains seven data bytes:

0x53

0x09

0x00

0xA1

Data bytes (YYMDHMS)

Checksum

The data bytes:

Byte 1: Year (LSB)

Byte 2: Year (MSB)

Byte 3: Month (1...12)

Byte 4: Day (1...31)

Byte 5: Hour (0...23)

Byte 6: Minute (0...59)

Byte 7: Second (0...59)

0x43 Debug messages

The 0x43 messages are not used by the TTScope software, but nevertheless expose interesting functionality. Hantek may be willing to answer some questions about these messages.

0x00 Read FPGA register

Lets you read one of more FPGA registers.

The request for a single register:

0x43

0x04

0x00

0x00

0x00

0x00 up to 0xFF (register number)

Checksum

The response contains the 4-byte register value:

0x43

0x06

0x00

0x80

0x.. 0x.. 0x.. 0x.. (register values)

Checksum

The request for multiple registers contains a starting register and the number of registers to fetch. The last register in this list (start register + number of registers) must not be higher than 0x4f.

0x43

0x05

0x00

0x00

0x01

0x.. (start register)

0x.. (number of registers)

Checksum

The response contain the register values, 4 bytes per register:

0x43

Length

0x80

X * 0x.. 0x.. 0x.. 0x.. (register values)

Checksum

LSB

MSB

Internally, this calls the firmware function PcUartReadFpgaReg.

Please note: this syntax is temporary, and may be incorrect.

0x01 Read FPGA FIFO contents

Lets you read directly from the FIFO memory. The request contains the buffer length in bytes:

0x43

0x08

0x00

0x01

0x.. 0x.. (buffer size)

Checksum

The response contains the FIFO contents:

0x43

Length

0x81

FIFO contents

Checksum

LSB

MSB

Please note: this syntax is temporary, and may be incorrect.

0x02 Read DSO firmware variables

The PC sends a request without data bytes:

0x43

0x02

0x00

0x02

0x47

The reply contains the DSO firmware variable values. These are stored on the DSO in the file
/param/sav/run1kb_yymmdd and are loaded at boot time. If the file chk1kb is not available at boot time, default values are used. These default values are also used when the "Default" button is pressed on the DSO. The stored setups also include these values.

The DSO variables themselves are not yet documented; but at least the following information is stored:

current UI (current menu, all user-selectable settings)

DSO serial number

Firmware version

PCB hardware revision

0x43

Length

0x82

DSO firmware values

Checksum

LSB

MSB

0x03 Read DSO self-calibration

The request contains no data bytes:

0x43

0x02

0x00

0x03

0x48

The response contains the self-calibration info read from the DSO's memory. This is stored on the DSO in the file /param/sav/chk1kb_yymmdd and is loaded at boot time. If this file is not available, default values are used.

0x43

Länge

0x83

chk1kb contents

Checksum

LSB

MSB

0x10 Read file

0x11 Virtual remote shell

Allows you to run shell commands. The command sent is stored on the DSO in a temporary file, which is then executed and the output is sent back in the reply packet. Instructions such as "cd / tmp" therefore do not make sense.

Commands that output over 10239 bytes cause the main "dso.exe" process to crash. If you have a shell on the DSO via the UART, you can run "/dso.exe" to restart it. Otherwise, powercycling the unit is necessary.