Good morning
I looked at SDK of 6022BL SDK. As indicated by Roderick the first step is to call dsoChooseDevice after dsoOpenDevice:
Result = dsoOpenDevice(m_nDevIndex)
If Result = 1 Then
Result = dsoChooseDevice(m_nDevIndex, 0)
Result = dsoSetTimeDIV(m_nDevIndex, m_nTimeDIV)
End If
However, it seems that this is not the only modification. As I said don't have a 6022BL so I'm not sure, but using the HTMarch.dll from BL SDK also the call to the other functions seems different. For example:
HTMarch.dll (6022BE)
HTMARCH_API short WIN_API dsoReadHardData(
unsigned short DeviceIndex,
short* pCH1Data,
short* pCH2Data,
unsigned long nReadLen,
short* pCalLevel,
int nCH1VoltDIV,
int nCH2VoltDIV,
short nTrigSweep,
short nTrigSrc,
short nTrigLevel,
short nSlope,
int nTimeDIV,
short nHTrigPos,
unsigned long nDisLen,
unsigned long * nTrigPoint,
short nInsertMode);
HTMarch.dll (6022BL)
HTMARCH_API short WIN_API dsoReadHardData_LA(unsigned short DeviceIndex, short* pData1, short* pData2,
unsigned long nReadLen,
int nTimeDIV,
);
I don't found (in BL SDK) the dsoReadHardData that I use in BE.
Also the dsoSetTimeDIV seems different
from 6022BL
HTMARCH_API short WIN_API dsoSetTimeDIV(unsigned short DeviceIndex,int nTimeDIV);
nTimeDIV
indicates current sampling rate index value, following is the value.
0 : 48MSa/s
1: 16MSa/s
2: 8MSa/s
3: 4MSa/s
4: 1MSa/s
5: 500KSa/s
6: 200KSa/s
7: 100KSa/s
from 6022BE
HTMARCH_API short WIN_API dsoSetTimeDIV(unsigned short DeviceIndex,int nTimeDIV);
nTimeDIV
indicates current sampling rate index value, following is the value.
0 ~ 10 : 48MSa/s
11: 16MSa/s
12: 8MSa/s
13: 4MSa/s
14 ~ 24: 1MSa/s
25: 500KSa/s
26: 200KSa/s
27: 100KSa/s
In any case if you said that the only modification will be to add the call to dsoChooseDevice, I can try a simple test and send to you the new files. Let me know.
Fabio
Hi
I've added the Lissajous figure to PCSCOPE (version 1.7)
See attached figure
Fabio
Good morning
I looked at SDK of 6022BL SDK. As indicated by Roderick the first step is to call dsoChooseDevice after dsoOpenDevice:
Result = dsoOpenDevice(m_nDevIndex)
If Result = 1 Then
Result = dsoChooseDevice(m_nDevIndex, 0)
Result = dsoSetTimeDIV(m_nDevIndex, m_nTimeDIV)
End If
Just a note, I think it should be dsoChooseDevice(m_nDevIndex, 1) to choose the oscilloscope...
However, it seems that this is not the only modification. As I said don't have a 6022BL so I'm not sure, but using the HTMarch.dll from BL SDK also the call to the other functions seems different.
I don't found (in BL SDK) the dsoReadHardData that I use in BE.
I don't have a 6022BL either, unfortunately. But after expanding the BL SDK package, in this file
...\HT6022BL_SDK\SDK_6022BL\Header\HTMarch.h
I see the same parameter list as for the 6022BE. Possibly the documentation is wrong? I have noticed a number of errors in previous Hantek documentation.
Also the dsoSetTimeDIV seems different
Yes, the manual does have different values. It would seem very foolish for Hantek to completely change the values in their DLL (they would have to work to do that). So I have several theories, none of which can be proven without actual 6022BL hardware.
- Possibly the documentation is wrong, again.
- Maybe the legacy values for TimeDiv() still work, and they just changed the meaning of the values from 0 to 7.
In any case if you said that the only modification will be to add the call to dsoChooseDevice, I can try a simple test and send to you the new files. Let me know.
Fabio
This is a good question for Chriss0422, who tested a version of BasicScope by simply replacing the HTMarch.dll file with the one included with the 6022BL. I don't know how extensive his testing was, other than to see if the program starts up, but I would also be interested in whether the Time scale settings still work.
GENERAL CALL: Does anyone else have a 6022BL? We can really use your help in testing our software.
Hello Roderick and Fabio,
As I said to roderick, i'm not avalaible during one week but after that I'll be able to test all the things you want.
Regards.
The latest
BasicScope should support both 6022BE and 6022BL, automatically detected. But I have no way of testing it. While Christophe is away, can someone else try it?
There seems to be no real difference between the BE and BL version if only the scope is concerned. The Open6022BE software from RichardK works with the Hantek 6022BL if just the HTMarch.dll in the Open6022BE package is replaced with the (unchanged) version from the original Hantek 6022BL package. It even works for branded versions of the Hantek 6022 (my scope is such a 'clone': http://www.conrad.com/ce/en/product/122465 )
...
Yes, RichardK took the bold step of writing his own replacement functions for some of the Hantek calls. This was not a trivial step at all - he basically duplicated portions of the driver, and is issuing IOCTL's in a worker thread.
BasicScope takes a less radical approach, but I think it may actually work without needing to copy over the HTMarch.dll that came with the user's device. I would be very interested in whether it works with the VOLTCRAFT oscilloscope. Might I ask you to try it?
Hello.
I would like to ask you for help. I'm kinda in hurry with a project and my
Hantek 6022BE just died. It's not reading signal and it first blinks 5 times red, and then 1 time green. I don't really have time to read all responses here so I was hoping someone could help me. I couldn't find anything about this on the internet. What should I do? How can I fix it and what's the error?
Thank you all very much!
Hello.
I would like to ask you for help. I'm kinda in hurry with a project and my Hantek 6022BE just died. It's not reading signal and it first blinks 5 times red, and then 1 time green. I don't really have time to read all responses here so I was hoping someone could help me. I couldn't find anything about this on the internet. What should I do? How can I fix it and what's the error?
Thank you all very much!
You would be better and probably get more direct and helpful replies by starting a new post for your fault ; this post is more a techincal review of the 6022E.
Also give a little more info of what you are / were measuring, and some pics of what you mean by the red and green blinks ?
Hi,
Since end of last year I have a Hantek 6022be and I would like to run it from Linux. I saw that quite a few attempts have been made but the only more or less finished project seems to be sigrok, which has a driver for this scope. I will have to try this!
I also saw Hantek6022API which gives quite some insight into the inner workings of the device.
I wanted to know if the firmware has changed since the last year or so (Hantek6022API was last changed 8 months ago). To figure this out I started the scope on the windows side of my dual boot PC, rebooted into Linux and read out the scope memory using example_linux_readfirmware.py from Hantek6022API. Then I disassembled the code with dis51 and compared the result with the code you find in Hantek6022API. They are identical.
Then I tried to find the firmware in the windows driver (.sys) file and succeeded. Next will be to write a little program to extract the firmware similar to openhantek-extractfw (from openhantek) adapted to the 6022be. After that I hope to have a closer look into openhantek to see if the work started on the 6022be cannot be completed.
Also want to use the 6022be under Linux. Atm I'm trying to convert the Qt qml example to connect to the actual scope. Uploading the firmware seems to work, but I don't get any data from the scope at the moment. I am using the hantek firmware, but I want to use the jh firmware also optionally.
Sounds like we can collaborate!
Yesterday I tried pulseview in the sigrok repository and managed to get a trace from the scope. This should help to figure out what we have to do to read traces. I can also change vertical settings (from 20V to 2V) and the timebase. In addition you can set the number of samples you want to read. A problem with sigrok is that they use a different vendor ID after firmware download than Hantek. I would prefer to have the same of all (sigrok, openhantek ...) and load the firmware when the scope is connected through udev rules such that any of the applications can use it.
I started to write a small C test program with which I can try all the different features the scope provides without any fancy graphics etc. This is only to learn how to access the scope.
One thing I clearly did not understand yet is how Hantek handles triggering. Do you have any idea?
The scope doesn't do any triggering at all. The PC has to do the triggering (I am working on a trigger class atm). Problem with the hantek firmware is, that it cannot sample and transfer data at the same time. So it samples and then transfers data to the PC. If the trigger condition happens during the data transfer, the scope (or the PC) will miss it.
Sigrok uses a different ID, because they use a different firmware, I think. I guess it is the firmware by Jochen Hoenicke.
https://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/825/I added code to my app, so I can load this firmware alternatively. There is a firmware class, provides info on available sample rates etc.
Since I am in the middle of this QML transition, my code is a bit of a mess at the moment. I am adding the code from version 1 now step by step to the QML demo app.
Can mail you some sources, of you want to take a look, though.
Yes, I know they use Hoenicke's firmware. However, I prefer to load the firmware (whatever version) when plugging the device trough udev rules. After that I have the same device for any of the applications I might want to use.
Of course I am interested to look into your code. Can you upload it e.g. to Google drive such that I can get access to it?
My intention was to look into openhantek now and see if I can get something to work there.
If you need higher bandwith (even at the cost of a less reliable triggering) the original firmware might be better. So I think an app should offer the option of loading a selected firmware?
I don't have a google drive account, sorry.
roderick & Fabio1963, good show!
Glad to see the progress made to date!
roderick & Fabio1963, good show!
...
And a nod to Chriss0422 for his help in testing.
Looks like I have overwritten some code in the EEPROM: My Hantek now tells me it has Vendor ID 04b4 but
Product ID 8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit
Any idea how to correct this?
Can anybody tell me what the correct EEPROM content should be?
Thanks
Sorry, I guess I was panicking yesterday when I saw that the EEPROM had been overwritten. In the meantime I found a means to reset the vendor and product ID in the eeprom to what it was before and the scope works fine again. I also found that, when I got the scope first, I already had made a backup copy of the original eeprom contents.
So... I am fine and can continue my work on trying to get the scope to work on Linux.
For the moment I try to write little routines calling all the different functions of the scope in order to better understand how the thing works. ... and amd I not only killing eeprom contents, I also make some progress.
I'm trying to port the python sources to C++ and combine this with the QML oscilloscope demo of the newer qt version. Still very early and not working yet. But maybe someone wants to take a look and has some ideas or wants to contribute.
I use qtcreator in a VM, because these newer version don't seem to b available as deb packages.
Hello!
I'm sorry to highjack the thread, but please excuse me.
I've got a 6052BE scope and I've found that one of the lower bits of channel #2 is always stuck at 0, so I'd like to replace the ADC.
So, has anyone found the model of the ADC used in 6052BE?
Thanks!
Since almost 2 months I am working on openhantek for the 6022be. I think I now slowly understand how the whole thing is put together. I use D. Graeff's version, which has 2 branches: the original openGL interface and a new qml interface. In the new version David also separated the GUI from the hardware access and implemented a dummy device, generating a sine wave, for testing. Since the qml version is missing quite some of the needed GUI elements (essentially the sliders for offset, trigger level and cursors, I decided to try a mixture of the two versions: I separate out hardware access but keep the old openGL interface.
The demo device starts to work and I also saw a trace from the real scope, just before the program crashes again. I will continue my trials and keep you posted
Seems like you are trying to implement something very similar to my code?
I started with the QML demo app from the latest Qt versions, though.
Not sure! I picked up openhantek from David Graeff which comes in 2 branches: One in which he uses qml for the GUI and he separates the hardware dependent code into separate libraries. The other branch is essentially the old openhantek with the openGL widget for displaying the traces. Since the qml code is very incomplete (missing sliders) I made a mixture of both attempts: separating the hardware stuff but keeping the old GUI. This means quite a lot of changes to the code and I sort of kicked out the non 6022be code because I cannot test it anyway. However I try to make the whole thing as configurable as possible such that this code can be brought back easily.
In the meantime I made some nice progress and I have my first scope traces (see attachment). This means that I am probably on the right track. I can change the time base and the gain and the whole thing follows nicely. I did not do any changes in samplerate and gain settings on the hardware yet. Also triggering is not implemented yet even though I have small test routines which already do all this (setting sample rate, gain and also triggering). These must be integrated into the code.
Before the openhantek comes up it checks for connected scopes. If it finds any it can also download the firmware. If none are connected you can run the demo device for testing. Otherwise you connect to the real hardware and use the specifiactions of the scope to adapt the GUI.
More, as soon as more things are working.