(Linux) simple script to compile OpenHantek6022

[zen67]

! /bin/sh

cmake .. /home/zen/build make -j7 strip openhantek/OpenHantek rm -f packages/* fakeroot make package

mv /home/zen/build/_CPack_Packages/Linux/DEB/*.deb /home/zen/build/

...... P.S. Read https://github.com/OpenHantek/OpenHantek6022/blob/master/docs/build.md#linux

Rename /home/zen with your HOME

[Ho-Ro]

d2d2caa provides two more general setup and build scripts

[zen67]

Тhat's great! I guess that will make people happy. Can you help me with compiling a build for Windows (there I encountered the problem cmake -> lib.exe), with this roughly modified modelDSO6022.cpp? With that, I would like to test the transfer of the device this way. modelDSO6022.cpp.zip

[Ho-Ro]

Can you help me with compiling a build for Windows (there I encountered the problem cmake -> lib.exe), with this roughly modified modelDSO6022.cpp?

I do not have any Windows system, but please check the appveyor log, it issues these commands:

git clone -q --branch=master https://github.com/OpenHantek/OpenHantek6022.git C:\projects\openhantek6022
git checkout -qf d2d2caa430fb8ed27a3519b94110b0fbef68353f
set qtpath64="C:\Qt\5.11\msvc2015_64"
set arch64=x64
set dir64=build_x64
md build_x64
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64
cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_PREFIX_PATH=%qtpath64% -DCMAKE_BUILD_TYPE=Release -Bbuild_x64 -H.
...
cmake --build build_x64 --config Release --target package

But I do not understand your change

     specification.fixedSampleRates = {
         // samplerate, sampleId, downsampling
-        {100, 102, 200},  // very slow! 200x downsampling from 20 kS/s
-        {200, 104, 200},  // very slow! 200x downsampling from 40 kS/s
-        {500, 110, 200},  // very slow! 200x downsampling from 100 kS/s
-        {1e3, 120, 200},  // slow! 200x downsampling from 200 kS/s
-        {2e3, 140, 200},  // slow! 200x downsampling from 400 kS/s
-        {5e3, 1, 200},    // slow! 200x downsampling from 1 MS/s
-        {10e3, 1, 100},   // 100x downsampling from 1, 2, 5, 10 MS/s
-        {20e3, 2, 100},   //
-        {50e3, 5, 100},   //
-        {100e3, 10, 100}, //
-        {200e3, 10, 50},  // 50x, 20x 10x, 5x, 2x downsampling from 10 MS/s
-        {500e3, 10, 20},  //
+        
+        {1e6, 1, 100},   // 100x downsampling from 1, 2, 5, 10 MS/s
+        {1e6, 2, 100},   //
+        {1e6, 5, 100},   //
+        {1e6, 10, 100}, //
+        {1e6, 10, 50},  // 50x, 20x 10x, 5x, 2x downsampling from 10 MS/s
+        {1e6, 10, 20},  //
         {1e6, 10, 10},    //
         {2e6, 10, 5},     //
         {5e6, 10, 2},     //

How to read the setting: e.g. the line + {1e6, 1, 100}, means: select 1 MS/s rough data rate (the middle "1") and downsample x100 (average over 100 samples) that should lead to 1e6 S/s which does not make any sense.

[zen67]

It doesn't make sense, that's right. I just cut everything to 1MS / s Today I tried to see what the transfer from the device to the computer is. After 1MB/s. (depending on timebase) the transfer is within 2MB/s (single channel) i.e. I guess ADuM4160/3160 could be used to some extent if there is an external power supply. To measure the transfer, I use a Windows based software, and for that reason I need a test/trimmed build. Last night I tried to compile with QtCreator - cmake starts but configuration process ended with error. The problem is that I am more of a photographer and audio fan than a programmer :)

P.S. Thanks for the hint. I build Windows build by appveyor.

[Ho-Ro]

configuration process ended with error

What was the error message? Do you have the correct build environment installed?

I build Windows build by appveyor.

What happens if you type the (appveyor) commands that I wrote above step by step?

I guess ADuM4160/3160 could be used to some extent

The firmware in the scope transfers available data as soon as one block is complete, but only in USB high speed mode (480 Mbps) - regardless of the transferred amount/sample rate. That means fast data transfer with short or long idle periods in between:

30 MS/s: [DATA] [DATA] [DATA] [DATA] ...
1MS/s:   [DATA]                              [DATA]                              [DATA] ...

You need a high speed capable device. Please read this spec, it says:

Electric Specifications In order to realize the 480 Mbps bus operation for USB 2.0, a change in electrical specifications was necessary, but without sacrificing compatibility with USB 1.x. Furthermore, a change in protocol was required to allow 12/1.5 Mbps transfers to coexist with 480 Mbps transfers. The new specification also resolves issues that were evident in USB 1.x. 480 Mbps transfer could not be achieved with 3.3 V, so small-amplitude signals are used instead. 3.3V Differential (12/1.5Mbps) -> 400mV Differential (480Mbps)

[zen67]

In fact, I did nothing but start building (completely automatically) the project (appveyor). Since I never worked this way, while studying it, things happened with 2 clicks only.

Regarding the USB insulator. This is a simple experiment with a ready-made (Chinese) USB isolator. After all, if it is obtained to some extent, can be considered in the direction of adapting software with and without an insulator. For me, in this case, it is more important to eliminate high-frequency noise from the idiotic hardware design, which is obviously generated in the device itself (to a large extent), and not introduced by USB power supply (GND; Vcc - already checked).

Best regards and stay healthy!

[zen67]

No support for non-Linux related issues unless a volunteer steps in!

I can test.

[Ho-Ro]

Ok, thank you - so could you please check this Windows driver from EEVblog. I do not use Windows since years, I have only an old virtual W7 on one of my laptops where I can check the gui, but only for demo mode without any USB / HW access.

[zen67]

I do not observe any noticeable problems, as things are identical to the driver I use (attached below). If You point me to something specific, it would be better, I think.

openhantek_driver.zip

There is a problem with the calibration and / or something else when samplerate is 30MS/s or above (I have attached a clip). As the samplerate increases from 24 to 30MS/s, X shifts upward (visible in the clip).

https://dox.abv.bg/download?id=3aa7009e0a#

[Ho-Ro]

If You point me to something specific, it would be better, I think.

Reason for my question is that I got some responses that the Win install via Zadig is not the normal Windows way to do. So if I provide the Hantek_6022B.cat and the Hantek_6022B.inf would an average Windows user be able to doubleclick the Hantek_6022B.inf and he/she is done?

As the samplerate increases from 24 to 30MS/s, X shifts upward

Did you calibrate with my python tool? Or do you use the factory calibration already available in the I2C EEPROM? Otherwise 2 mV offset is not too bad, because in the 20/50/100 mV/div range the LSB is about 4 mV. Some more info about the calibration values can be found there and there.

The reason that the offset jumps a little bit lies in the different ADC timing that is clocked from IFCLK @30MS/s (and @48MS/s), but at lower sample rates the slower clock comes from CTL2 (6022BE) or CTL0 (6022BL) in sync with the GPIF DATA bit (OPCODE.1).

CLK     ⎺⎺⎽⎽⎺⎺⎽⎽⎺⎺⎽⎽⎺⎺⎽⎽⎺⎺⎽⎽⎺⎺⎽⎽⎺⎺⎽⎽⎺⎺⎽⎽
CTLx    ⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺     -> ENCA/ENCB 
DATA    ⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽      (one sample -> FIFO)

[zen67]

I think the script option is appropriate. The script is more user friendly (I think). Otherwise, user must go to the original Hantek procedure through the device manager, update driver, etc. There is a difference in the size of the two drivers, but I haven't looked at them. Perhaps, it should be noted that with a freshly installed driver, it is necessary to start OpenHantek, close it and restart it to install both devices (if OpenHantek does not detect the device immediately at startup).

I got some responses that the Win install via Zadig is not the normal... I also had a Zadig problem. I don't think this is quite a user friendly way and probably shouldn't be recommended.

Did you calibrate with my python tool? Yes I did. But on Linux. I copied * .conf to Windows and there are no problems. There were various errors under Windows all the time, and even when I uploaded all the modules, it still didn't work and I got pissed off.

Is it possible to come up with a way to make the calibration Windows procedure easier (as you did with the Linux compilation scripts)? Maybe if you put it all together to the point where you only need to run the python script? I guess a lot of people can't handle it now.

The reason that the offset jumps a little bit lies in the different ADC timing that is clocked from IFCLK @30MS/s (and @48MS/s), but at lower sample rates the slower clock comes from CTL2 (6022BE) or CTL0 (6022BL) in sync with the GPIF DATA bit (OPCODE.1).

I.e. this is a hardware problem?

[Ho-Ro]

TOPIC 1

I think the script option is appropriate.

Do you mean the EEVblog solution from 2018 with Hantek.cat, Hantek.inf and Install.cmd. How about the EEVblog solution from 2020 with only Hantek_6022B.cat and Hantek_6022B.inf, what is the difference between both variants? The 1st one uses the cmd file to sign the driver, the 2nd is already signed, what else?

So just the easy question: Would it be sufficient to provide the 2nd newer version (only Hantek_6022B.cat and Hantek_6022B.inf), the user doubleclicks the *.inf and he/she is done? (did I already tell that I avoid/ignore Windows for engineering and software development since years?)

TOPIC 2

I copied * .conf to Windows and there are no problems.

Then it is clear, because the config file doesn't distinguish between low and high speed, nor doesn't it provide sub-bit resolution. But if you calibrate with -e or --eeprom option (store calibration values in eeprom) under Linux it will use these values also under Windows - but the conf file (if it exists) takes priority, so do not use it if you want higher accuracy. I have deliberately made the conf file simple so that it can also be created manually if there is no possibility to use the calibrate.py script.

I.e. this is a hardware problem?

Yes, probably caused by the brain-dead ADC design already mentioned (the far out of spec common mode voltage), also the factory setup values in EEPROM provide separate offset correction for slow and for high speed.

[zen67]

1. Do you mean the EEVblog solution from 2018 with Hantek.cat, Hantek.inf and Install.cmd

Yes, that's what I mean. I don't think it matters which driver is used. It is important that it is easy to install. In this case, you can install the .inf file only if left click -> install. It is not possible to install it (.inf) with a double click. In this case, I think in terms of a user, not a developer (which I am not: D) For me, it doesn't matter how the driver is installed, but there are people who are used double-clicking and Windows.

2. Understood. Isn't it possible then that the * .conf file is the necessary complexity so that it does not rely on memory? (I doubt anyone does it by hand, and accuracy is sacrificed anyway.) As far as I know, we do not have non-volatile memory available in the device (or am I wrong?). Or dump the memory (after calibration) and save again at startup.

Yes, probably caused by the brain-dead ADC design

I understand them to some extent. This is a cost effective approach to this type of device. They compensate for the hardware shortcomings with software. It is unbelievable that even shielding is not put on, it is so squeezed in terms of hardware cost.

[Ho-Ro]

As far as I know, we do not have non-volatile memory available in the device (or am I wrong?).

Sorry to say, but you're wrong. There is an 256-byte EEPROM 24LC02B (the small 8 pin chip) that is necessary to hold the Hantek USB vendor and product id VID/PID e.g. 0x4b4/6022 (otherwise the scope would announce the default Cypress EzUSB FX2 combination 04b4/8613).

The firmware documentation gives more info about the EEPROM, its content and how to use it. If you buy the scope the EEPROM contains already factory offset-calibration values as mentioned in my post above.

P.S.:

For me, it doesn't matter how the driver is installed, but there are people who are used double-clicking and Windows.

People who decide to use an oscilloscope have some technical background. So right click->install should not be out of their horizon. I will package the newer (signed) driver for an unstable test version later this weekend.

[zen67]

Okay. If there is something that is for testing under Windows, I will be happy to help.

[zen67]

I recompiled the last build. Cannot install driver. I tried both ways. Could you compile to check if i have a problem? I have attached screenshots for the first and second way respectively (which is longer as operations). edit: First method works fine, with fresh downloaded driver from eevblog.com. Method 1

Method 2

[Ho-Ro]

That's a nasty result of the the automatic crlf->lf change done by git (as an unix tool), so the *.inf doesn't match its checksum anymore. Now fixed by a .gitattributes file an a remove and recommit, the file at github has now a size of 812 byte (same as the original). You could just try the cat/inf file from the latest appveyor artifacts.

[zen67]

Everything is fine now.

[Ho-Ro]

Thx!