The Hantek 6022BE Digital Storage Oscilloscope

For the course on embedded systems we need an oscilloscope to be able to see certain signals created by micro-controller code. These signals are have a signal level of either 5V or 3.3V and are rather slow. These means that a rather limited but cheap scope is good enough for us.
The Hantek 6022BE has a sampling rate of 48 MHz or a bandwidth of some 20 MHz. To make things really cheap it uses an USB interface and the display capabilities of a PC to display scope traces and a graphical user interface (GUI) of the PC to control timebase, signal sensitivity and trigger level. Don’t expect features you will get on a 10 kUS$ Textronix scope, you will quickly hit the limitations of the 6022BE, however it should meet the requirements imposed by the course exercises.




The Hantek 6022BE has 2 DC coupled input channels, a calibration signal generator emitting a square signal and it is delivered with 2 80 MHz probes and a USB cable to connect it to the PC. In addition to this you get a mini CD with Windows software implementing a GUI based control program and a software development kit which allows to implement your own code.
The scope is based on a Cypress CY7C68013A chip, which is essentially a 8051 μ Controller with built in RAM, I2C and USB interface. An external I2C EPROM is used to store USB Vendor and Product ID as well as a few calibration parameters.
When the scope is plugged into the Windows PC a driver is started downloading firmware into the Cypress RAM making it ready for operation. The code is stored in RAM and must therefore re-loaded each time the scope is powered. Once the firmware is loaded the Vendor ID is changed making the scope looks like a different device.

This is how the Windows application looks like:

Channel B is connected to the calibration signal which tells us that this is a 1 kHz square wave.
The horizontal time base can be selected between 1,2,5,10,20,50,100,200,500 ns/division up to
1,2,5 s/division. Of course 1 ns/division is pretty useless on 20 MHz scope.

The vertical sensitivity can be selected from 20 mV to 5V per division.

You can trigger the scope in

• auto mode
• normal mode
• or single shot

and you can trigger on channel A or B and select the trigger slope. The trigger is done purely in software: First data is taken on the scope, then transferred via USB to the PC where the triggering is computed in software.

The scope can run in normal y(t) mode showing the time dependence of the signal or in X/Y mode, where the X axis corresponds to the signal read on the second channel. There are some mathematical functions that can be executed on the signals:

• channel A + channel B
• channel A - channel B
• channel A * channel B
• channel A / channel B
• FFT (Fast Fourier Transform) showing the frequency content of the signal

The signal trace can be exported to an ASCII file and re-imported.

Running the Hantek 6022BE under Linux

Just like in the Windows case we must first first load the scope with its firmware. There are different ways to do this:
use udev rules to load the firmware using the fxload program
make the application program load the firmware if it is not loaded yet

When is scope is plugged in without the firmware being loaded it announces itself as a Cypress Semiconductor device with Vendor ID 0x04b4.

This changes to ROHM LSI Systems (a company that probably has nothing to do with this scope) because the Vendor ID has changed to 0x4b5.

When browsing the WEB for information of the Hantek 6022BE under Linux, this is what I found:
Openhantek by Oliver Haag. This is a git repository with software for Hantek scopes. Unfortunately it only supports more expensive scopes from Hantek. Several people have started to implement drivers for the 6022BE but have not come very far (hantek602be support in openhantek). However you will find code there porting the originally QT-4 based openhantek code to Qt-5.
Then there is a driver implementation (hantek driver) which consists of a functions to download the firmware and to set sensitivity and time base and a main program to demonstrate these functions. This also is rather incomplete.
Then there is hantek6022api which is a library of Python code. This however also contains firmware code for the Cypress chip and the author (J. Hoenicke) of this 8051 code has done very interesting reverse engineering figuring out what the USB commands to the scope are and how to use them.
The 8051 code is given as source code as well as disassembled original code from Hantek. It also supplies a program that allows the user to read out the RAM and EPROM contents.
On my dual boot PC I loaded the original Hantek firmware into the scope, then rebooted into Linux and used the example_linux_readfirmware.py included in hantek6022api to extract this code. After disassembly with dis51 I was able to compare the code with the one included as stock firmware in hantek602api to confirm that they are identical.
Cypress, the producer of the CY7C68013A chip provides a the cyusb library and a GUI program showing how to program the chip. This has not much to do with the scope but shows how to download and upload code, reset the CPU, read or write the EEPROM etc.
Finally there is the sigrok repository of software for different types of measurement instruments and the Hantek 6022BE is one of the supported devices (oufff,for once we are lucky). This uses the firmware code of J. Hoenicke. Unfortunately sigrok uses again different Vendor ID and Product ID after loading the firmware. Since we have the source code, I was able to modify this. sigrok also contains a simple GUI application (pulseview) to visualize the traces read from the scope.

The above screen dump shows the trace read from the Hantek6022be when the probe is connected to the calibration pulse generator.

Some specs

Depending on the sampling rate the number of samples that can be read changes with the more samples the slower you sample. Here is a table showing the buffer size to be read back:

Bringing up openhantek

There are quite a few versions of openhantek floating around on the WEB. The latest one seems to be this one. It contains several branches with mr_split_gui_backend being the most interesting one.

The mr_split_gui_backend branch of openhantek separates out the GUI into qml files and I therefore first try to only bring the GUI onto the screen forgetting about the functionality, which is implemented in C++ code. The qmlscene utility allows to do exactly this.

Using qmlscene I see that the menu bar does not come up. The error is this:

appmenu-qt: handleReparent 138 The given QWindow has no QMenuBar assigned

It turns out that this is a bug on my Ubuntu system which can be avoided by setting UBUNTU_MENUPROXY to the empty string.

Not only is the GUI separated from the rest of the code but also hardware access is split into a number of libraries, one for each type of device. We therefore have

• libDemoDevice: this one generates a sine wave with which the program can be tested and therefore does not need any hardware

• libOpenHantek2xxx-5xxx: this is the access code for the more expensive Hantek scopes

• libOpenHantek60xx: this is the library of access code we are interested in. It is based on hantek driver mentioned earlier.

In addition to these libraries there are two more:

• libusbDSO containing the access routines to USB which are common to all scopes (except of the demoDevice of course)

• libPostprocessingDSO which contains code for post process the traces including FFTs.

Graeff’s version of openhantek is based on cmake, which unfortunately I don’t know well enough. To get started I converted back to qmake and created a qtcreator project with all openhantek code. Neither Graeff’s original project nor my qtcreator project did compile out of the box but needed several corrections to get it working. Another problem with Graeff's mr_split_gui_backend branch is that he references the qtquickplot library, which is however missing on the repository. I found it here. There were still some minor incompatibility problems (the library wants floats as data input while openhantek2 provides doubles) but these can easily be solved.

When I finally get the everything compiled and linked I see this when running openhantek for the first time:

Of course it is normal that it does not find any Hantek scope as long as noting is connected to the PC. I first want to get the demoDevice working and when selecting it, this is what I see (after quite a bit of further debugging):

After some modifications of the GUI, some additions etc. the mr_split_gui_backend shows essentially the same GUI as the original openhantek version except that the opengl widget for display of the traces is replaced by the qtquickplot widget. Unfortunately also the sliders for the trigger level, offset adjustment and cursors are missing.

For comparison, this is how the original GUI looks like:

Basic components of OpenHantek

As explained above, the new openhantek program (called openhantek2 in git) is missing a lot the the GUI elements needed to run the scope. On the other hand it nicely separates the scope functionality putting it into libraries.

It has the additional advantage that the demo device, which simply generates a sine wave (with some noise added) and a triangular signal, can be used for all GUI testing such that the hardware is not needed for most of the work.

The original openhantek program on the other hand has all necessary GUI elements. I therefore decided to try combining both, using the libraries from the new program and the GUI from the old one. The screen dump above shows the demo device with the old GUI.

Mapping the traces to the plots

Vertical mapping

The grids of the openhantek scope are 8 units high (-4 - +4) and 10 units wide (-5 - +5). The scope trace must be mapped to these dimensions. Since the scope hardware has got an 8 bit ADC values 0..250 must be mapped to -4..+4. In addition we must take into account the hardware gain that can be set on the scope. The following table shows the available hardware gains on the first column, the gain settings in V/div in the second one, the max voltages that can be displayed in the plot and the last column shows the multiplication factor needed to map the values from the scope to the screen.

Gain Setting [V]	V/div	Total size on plot [V]	Multiplication Factor
1	10 mV	0.08	12.5
1	20 mV	0.16	6.25
1	50 mV	0.4	5
1	100 mV	0.8	1.25
1	200 mV	1.6	0.625
2	0.5 V	4	0.5
5	1 V	8	0.625
10	2 V	16	0.625
10	5 V	40	0.25

Example: Let’ say we have a 1 V signal we want to display. Then the scope HW gain will be set to 5V producing values of 128 corresponding to 0V to 128+32=160. In this case the maximum Voltage that can be displayed (without plying with the signal offset) is 4V corresponding to the scope voltage of 4V <> 205 (128 + (32*4)*0.625.

The vertical multiplication factor is multFactor = gain setting / total size on plot.
From the table we can see that for 5V/div only ¼ of the ADC resolution is reached while for 100mV/division and below the signal will be saturated.

Horizontal mapping

Horizontally we have to take into account

• the timebase selected

• the sampling rate

• the record size needed to display the full trace

Timebase per div	Total horizontal Size	Sampling Rate	Record Size	Down Sampling Factor
1s	10 s	100 kHz	1 MS -> 10 kS	100
500 ms	5 s	100 kHz	500 kS -> 10 kS	50
200 ms	2 s	100 kHz	200 kS -> 10 kS	20
100 ms	1 s	100 kHz	100 kS -> 10 kS	10
50 ms	500 ms	100 kHz	50 kS -> 10 kS	5
20 ms	200 ms	100 lHz	20 kS	1
10 ms	100 ms	200 kHz	10 kS	1
5 ms	50 ms	200 kHz	10 kS	1
2 ms	20 ms	1 MHz	20 kS	1
1 ms	10 ms	1 MHz	10 kS	1
500 us	5 ms	1 MHz	5 kS	1
200 us	2 ms	1 MHz	2 kS	1
100 us	1 ms	1 MHz	1 kS	1
50 us	500 us	1 MHz	500 S	1
20 us	200 us	4 MHz	800 S	1
10 us	100 us	8 MHz	800 S	1
5 us	50 us	16 MHz	800 S	1
2 us	20 us	48 MHz	1016 S (hardware max)	1

As can be seen from the table the record length for a big timebase becomes very big because the min sampling rate is 100 kHz. In order to keep the record length within reasonable limits we must down-sample for 50 ms / div and longer.

When mapping the trace data (y = 0..255, x=0..recordLength) to the openGL plot widget (y=-4 .. +4, x=-5 .. +5) the display follows as expected.

The screen dump below shows the demo device when the timebase has been switched to 500us/div instead of 1 ms/div and the gain has been set to 0.5V/div instead of 1V/div.

-- Uli Raich - 2017-01-24

Comments