Hantek 6022Bx support - Githubissues

OliverHaag commented 8 years ago

Moving the Hantek 6022Bx related work from #6 here now.

Current work regarding the support can be found in the following repos:

https://github.com/olerem/openhantek/tree/6022be: @olerem (6022 support)
https://github.com/nickless81/openhantek/tree/qt5_6022be: @nickless81 (6022 support with Qt5)
https://github.com/giomasce/openhantek/tree/6022be @giomasce (6022 support with reverse engineered fw)

Also related: A 6022 libusb1.0 driver: https://github.com/rpm2003rpm/HT6022_Driver A cocoa (MacOSX) based GUI for the 6022 based on the driver: https://github.com/SergeOkon/HT6022_OSX

OliverHaag commented 8 years ago

@olerem, did you do any acquisitions after changing the trigger event? I think I've seen that some commands aren't sent if the acquisition is stopped so I prefer to leave the scope running and switch the settings then - and filter out what I need because quite a lot is sent in run mode of course. I've usually used USBsnoop since wireshark didn't show me everything back then - maybe that changed.

I'm pretty sure that you'll loose a lot of data, especially with higher samplerates. It's that way for every digital oscilloscope unless you're in roll mode, which is only available for lower samplerates. That's why I can't really believe that it's SW only triggering ;)

edit: The HT6022_OSX software seems to do it software only, so probably it's really that way which is quite creepy...

davidgraeff commented 8 years ago

libusb uses DMA for transferring it's data into main memory and if we store data in a fifo, we can almost simultaneously analyse incoming values. If SIMD on X86 (and Neon/whatsever on ARM) instructions are used, the actuall throughput should be quite high on modern systems. I'm not familiar with software triggers and the 6022 incoming data format yet, more reading is necessary. Is there any pitfall I've overlooked?

nickless81 commented 8 years ago

I been testing both firmware (Olerem and rpm2003rpm/HT6022_Driver). In both cases failed because of this error: Sending control command b4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sending control command b4 failed: Pipe error Error Code -9 Sending control command b5: 00 04 08 02 20 40 10 01 00 00 00 00 00 00 00 00 00 Sending control command b5 failed: Pipe error Error Code -9

I think I will need to reverse engineer the firmware for the 6022BL because is lightly different from the firmware of the 66022BE.

olerem commented 8 years ago

@OliverHaag, i used wireshark on linux side with windows in virtualbox or kvm. I didn't had good expiriance with plain windows usb sniffing. About triggering. I compared different usb dumps with different actions provided by Windows DSO GUI, like i said before, i'm sure there was send no command to configure triggering. The test case was made with fallowing steps:

start acquisitions; do nothing
start acquisitions; change trigger
compare usb dumps.

giomasce commented 8 years ago

I agree, I have never seen any USB command to configure HW triggering. Moreover, I have read some specs about the chipset inside and it is pretty clear to me that there is nothing able to perform triggering. The USB chipset just configures ADC and timing, but does not even have the power to read data received by ADC. The Cypress chip has support to receive data from the ADC and fill directly the USB buffer with it, and that is what happens. Firmware does not process data at all (it would be by far too slow to do that). The triggering has to be performed on software, with of course all the problems given by the huge blind spots between two different acquisitions (after all, it costs 60$...).

OliverHaag commented 8 years ago

Okay, seems clear and for 60 $ it's possible that they just left out the triggering hardware, I thought that it's more expensive ;)

So what's the current state of the 6022 support branches? Is everything except triggering working? Not completely sure where the software triggering should be implemented. I guess the best would be to let Control::getSamples handle this, since it's already doing conversion anyway and let it return 0 in case the trigger event wasn't found (Or is too near to the start/end of the acquisition got from the scope to get the necessary pre/post samples to fill the screen). To avoid bloating getSamples too much the trigger event search stuff should be placed in a separate class...

giomasce commented 8 years ago

I do not know the code well enough to judge about implementation details. However, I think that there might be other problems. In particular, I think I remember of having seen this strange behavior: when testing, for example, with a simple sine wave, OpenHantek presented a "broken" sine wave, meaning that at some point the phase immediately changed. I suspect this depended on independent packets (this with irrelated phases) getting incorrectly concatenated. This should of course never happen: there should be no hypotheses on correlation of different acquisitions. I could not determine whether the problem was in OpenHantek, the firmware or the relation between the two, but I suspect at lest part of the guilt was with OpenHantek. I will try to replicate when I have time, but this will hardly happen too soon.

OliverHaag commented 8 years ago

The buffer we get is a ring buffer and for the DSO2xxx and 5xxx we also get the starting position in that buffer coded in a strange way (But decoding for it is working fine already, done in Control::calculateTriggerPoint). But I guess it's doing the wrong thing (or doing something while it shouldn't do anything) for the 6022. Have a look at bufferPosition found here: https://github.com/OpenHantek/openhantek/blob/master/openhantek/src/hantek/control.cpp#L354 I would first just try to change that to 0 and see whats happening...

nickless81 commented 8 years ago

I got the wireshark data from the driver to the Hantek6022BL of the firmware loading. It is legal to uploaded into a repository on github? I asking before getting trouble. Thanks

nickless81 commented 8 years ago

I got NEWS!!!!!!!!!!!!!! I successfully reverse engineered the Firmware of the Hantek6022BL, and its a little bigger than the firmware of the Hantek6022BE. I downloaded the firmware in Linux and tested the device on windows (Over VirtualBox). I will continue to reversing the command the program on Windows send to the DSO in normal mode)

I forked the original repository here: https://github.com/nickless81/HT6022_Driver/tree/6022BL

nickless81 commented 8 years ago

I try to use OpenHantek to comunicate with the Hantek6022BL based on the Hantek6022BE implementation I forked. This is the results: Debugging starts Sending control command b4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sending control command b4 failed: Pipe error Sending control command b5: 00 04 08 02 20 40 10 01 00 00 00 00 00 00 00 00 00 Sending control command b5 failed: Pipe error Sending control command e0: 05 Sending control command e1: 05 Sending control command e2: 01 Sending control command e3: 01 Capture state changed to 2 Getting sample data failed: Operation timed out Starting to capture Sending control command b4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sending control command b4 failed: Pipe error Sending control command b5: 00 04 08 02 20 40 10 01 00 00 00 00 00 00 00 00 00 Sending control command b5 failed: Pipe error 0x1590720 void QWindowPrivate::setTopLevelScreen(QScreen*, bool) ( QScreen(0x6aa490) ): Attempt to set a screen on a child window. Received 20480 B of sampling data

I think I got long lone journey ahead.

Regards, JP.

davidgraeff commented 8 years ago

I do own a 6022BL and I didn't get the Pipe error message. Try another usb port, avoid usb hubs. What does the kernel tell you? (journalctl -f -k or dmesg)

nickless81 commented 8 years ago

@davidgraeff Which version on USB port do you connect the DSO? I got 2.0 and 3.0. I got problems with the 3.0 and Windows over virtualbox.

Thanks and Best Regards,

dmkkmd commented 8 years ago

I've spend the last few days to write a (chaotic) libusb driver for the 6022BL before I found out that there is already one created by you. So I got the firmware transmission to the DSO working (the red light is blinking). But how can I use the software for the 6022BE? At first I tried it without modifications, but the DSO was not recognized. I tried changing the deviceId of the 6022BE to the DeviceId of the 6022BL in devices.cpp, but now I get the following pipe errors over and over: Sending control command b4 failed: Pipe error Sending control command b5 failed: Pipe error I am not experienced in cpp programming. Is there any version of openHantek with out-of-the-box support for the 6022BL? In addition to that I would be interested if you got your knowledge about the protocol only from reverse engineering or is there any official documentation.

Regards

st2000 commented 8 years ago

@OliverHaag thanks for summarizing support for the Hantek 6602BE oscilloscope. Before I saw this open issue I copied this repository's code and substituted @olerem 's 6602BE code found in openhantek/src/hantek/. But @olerem 's code looked out of date. Therefore I merged code from this repository w/ @olerem 's 6602BE code. The result produces many broken pipe messages in the console where the application was started (as stated in other messages here) & the trace tends to disappear when a mouse drags across the scope's window.

(Correction / Update: The trace doesn't disappear. Hard to believe, but if the time is set to the uS range, then mouse activity w/in the scope's window resets the time to Seconds. This squeezes the trace to the left until it can not bee seen. If time is set in the mS or nS range this apparently does not happen. A real mind bender of a bug.)

If this code is of use (that is, if I have not started out w/obsolete code & have not repeated other's efforts) please let me know. I'll will then try to make the merged code available.

If what I have is no good for either reason ... then what is the most promising path?

giomasce commented 8 years ago

@OliverHaag Just changing bufferPosition to 0 did not fix the bug. Maybe I will try to understand a bit better that piece of code. In the meantime, this is an idea of what the problem is: test

You can see that the second peak is shorter than the others, probably because there is a ring discontinuity over there. The position of the discontinuity on the screen appears to be constant, even when restarting the application, at least within what I can see with just the eye.

giomasce commented 8 years ago

Update: the discontinuity appears to always happen at sample 1024 and is not introduced by OpenHantek: it is in the data returned by the DSO. The initial 1024 samples do not glue correctly even at the end of the buffer, so I guess they should just be discarded. I'll try to observe the Windows client in order to understand what they do with these samples.

jan-kleks commented 8 years ago

I've tried to read through your comments, but I'm still not sure. Is Hantek 6022BE currently working with OpenHantek or should I wait for some more progress due to bugs?

davidgraeff commented 8 years ago

@jan-kleks Hantek 6022BE is not supported by the master branch right now. @giomasce Thanks for your observation. Could you share your code so far?

giomasce commented 8 years ago

@davidgraeff I am using the code here: https://github.com/giomasce/openhantek/commits/6022be. I haven't had time to compare what I obtain with OpenHantek with what I obtain with the Windows original program. There is a strange thing happening: the Windows program appears to show more sampes than it actually receives from the DSO. Maybe I will have more time to check this more carefully later this weekend.

tr0043t commented 8 years ago

I was just asked to research linux support for the BE and BL, and of course ended up here. I've looked through the notes above already, but could someone provide a concise description of the current status of the project for both BE/BL oscilloscope functions and for BL data analyzer functions? I note the discussion of the apparent lack of hardware triggering, and am also curious about how well this might be worked around. Any info on current state of the project and practical goals would be greatly appreciated. Thanks!

giomasce commented 8 years ago

@laurenweinstein1 For BL, I am not aware of any kind of support. For BE you can have something close to a signal shown on the screen (for example using the my branch mentioned in my last comment, in which however all real work was done by @olerem). It is not ready for an end user, particularly the trigger does not work and there are discontinuities as I wrote above.

Not having an hardware trigger, the BE basically gives you random windows on the signal (except for that discontinuity problem, but let us assume it is solved). So the only thing I can think of is to simulate triggering on these windows, which should work if the signal is triggered frequently enough compared with the length of the acquisition window (which in turn is proportional to the inverse of the sampling frequency). But all of this is just theory, in practice trigger simply does not work and apparently nobody has time to work on that at the moment.

tr0043t commented 8 years ago

OK, I understand. Thanks!

L

On Mon, Feb 15, 2016 at 2:03 AM, Giovanni Mascellani < notifications@github.com> wrote:

@laurenweinstein1 https://github.com/laurenweinstein1 For BL, I am not aware of any kind of support. For BE you can have something close to a signal shown on the screen (for example using the my branch mentioned in my last comment, in which however all real work was done by @olerem https://github.com/olerem). It is not ready for an end user, particularly the trigger does not work and there are discontinuities as I wrote above.

Not having an hardware trigger, the BE basically gives you random windows on the signal (except for that discontinuity problem, but let us assume it is solved). So the only thing I can think of is to simulate triggering on these windows, which should work if the signal is triggered frequently enough compared with the length of the acquisition window (which in turn is proportional to the inverse of the sampling frequency). But all of this is just theory, in practice trigger simply does not work and apparently nobody has time to work on that at the moment.

— Reply to this email directly or view it on GitHub https://github.com/OpenHantek/openhantek/issues/7#issuecomment-184141153 .

tr0043t commented 8 years ago

I assume this path has been considered before and rejected, however ... I see that the standard Hantek Win software GUI for the BE/BL appears to run OK under Wine. Has consideration been given to finding a mechanism to use that GUI using Wine and via a linux-based driver? Thanks.

olerem commented 8 years ago

If driver will need software based trigger emulation, then we don't need Wine workaround at all.

giomasce commented 8 years ago

To me the Win software does not even work in VirtualBox (it works a bit, actually, but then often causes blue screen). My feeling is that, given how the protocol is simple, adapting the free software is much easier than writing a Wine driver for the buggy original software. However, as long as nobody has time to work on the project, nothing is going to happen... (no rants for anybody: I am in the numbers of those without time!)

gcarmix commented 8 years ago

I don't know if it can help, but I'm trying to use my 6022BL with OpenHantek and I found that with the giomasce code I finally get some waveform on the screen even if with wrong timebase. For the firmware I extracted it by sniffing the bus. I'm a C/C++ programmer too, let's go on with this project, 6022BE/BL is a good stuff for that price :)

tr0043t commented 8 years ago

I just got my BL working with PulseView, by the way.

On 03/03 14:15, gcarmix wrote:

I don't know if it can help, but I'm trying to use my 6022BL with OpenHantek and I found that with the giomasce code I finally get some waveform on the screen even if with wrong timebase. For the firmware I extracted it by sniffing the bus. I'm a C/C++ programmer too, let's go on with this project, 6022BE/BL is a good stuff for that price :)

Reply to this email directly or view it on GitHub: https://github.com/OpenHantek/openhantek/issues/7#issuecomment-191990958--Lauren-- Lauren Weinstein (lauren@vortex.com): http://www.vortex.com/lauren Founder:

Network Neutrality Squad: http://www.nnsquad.org

PRIVACY Forum: http://www.vortex.com/privacy-info Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info Member: ACM Committee on Computers and Public Policy Lauren's Blog: http://lauren.vortex.com Google+: http://google.com/+LaurenWeinstein Twitter: http://twitter.com/laurenweinstein Tel: +1 (818) 225-2800 / Skype: vortex.com I have consulted to Google, but I am not currently doing so -- my opinions expressed here are mine alone.

davidgraeff commented 8 years ago

@gcarmix I also got a waveform. I looked at the code and it is not mergeable at this state, because it disables some codepaths for others DSOs. The problem really is that this DSO with its software triggering is fundamentally different than the other supported devices.

I'll add all "safe" parts of the code at least. But in the long run the splitted libraries of the other branch should be used.

@laurenweinstein1 You are an awesome person but I guess there are a lot of capable guys here in the chat and no one has a signature as long as yours ;)

tr0043t commented 8 years ago

It's gotten longer and longer (my signature) over the years as I've needed to be very transparent about which organizations I'm affiliated with or have been affiliated with, otherwise I get complaints. Largely a result of hanging around the Net pretty much since its beginning, I guess. Long "paper" trail.

--Lauren--

On Fri, Mar 4, 2016 at 1:38 AM, David Gräff notifications@github.com wrote:

@gcarmix https://github.com/gcarmix I also got a waveform. I looked at the code and it is not mergeable at this state, because it disables some codepaths for others DSOs. The problem really is that this DSO with its software triggering is fundamentally different than the other supported devices.

I'll add all "safe" parts of the code at least. But in the long run the splitted libraries of the other branch should be used.

@laurenweinstein1 https://github.com/laurenweinstein1 You are an awesome person but I believe there are a lot of capable guys here in the chat and no one has a signature as long as yours ;)

— Reply to this email directly or view it on GitHub https://github.com/OpenHantek/openhantek/issues/7#issuecomment-192208220 .

jssilva25 commented 8 years ago

I also own a 6022BL and I'm very interested to make it work with openhantek. I have a few remarks, wonder if it helps:

I have a correct trace on a W7 virtualbox but it does not trigger. @giomasce: it doesn't crash though.
Before loading the firmware, the id is 04b4:602a Cypress Semiconductor Corp., as for 6022BL. However, after loading the firmware, the id is the same as for 6022BE, 04b5:6022 ROHM LSI Systems USA, LLC, which suggests that the supporting code could be the same, with the exception of the udev rule loading the firmware. Am I right?
@gcarmix: with giomasce code I get two spurious square waveforms without probes connected. Frequency is 100.30KHz, vertical amplitude acts weirdly and don't trigger.

giomasce commented 8 years ago

I doubt that from the two models having the same ID you can infer they need the same driver. The machine is rather cheaply engineered and I would not bet they payed attention to this kind of things.

jssilva25 commented 8 years ago

Hello,

On 06/05/16 18:27, Giovanni Mascellani wrote:

I doubt that from the two models having the same ID you can infer they need the same driver. The machine is rather cheaply engineered and I would not bet they payed attention to this kind of things.

Right, thank you.

As I really would like to make this work, I'm still taking other actions. The other option is trying to sell this scope and buy a 2090.

Edit: forgot to say that extractfw doesn't work: BFD: /media/joao/mydata/packages/Windows/Hantek6022BL/Driver/Hantek6022BLX861.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .text BFD: /media/joao/mydata/packages/Windows/Hantek6022BL/Driver/Hantek6022BLX861.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .rdata BFD: /media/joao/mydata/packages/Windows/Hantek6022BL/Driver/Hantek6022BLX861.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .data Section .data found (starting at 0x0c00, 10176 bytes) Symbol _firmware found (offset 0xfffffffffffff400, 0 bytes) Symbol _loader found (offset 0xfffffffffffff400, 10176 bytes) Can't get firmware contents: Bad value

So, I used dhex to compared the three driver files, for X86, IA64 and AMD64, and found that there's an identical area of exactly 8192 bytes, and no more than that, on the 3 files, starting at 0x0bfc in Hantek6022BLX861.sys downloaded from the Hantek site: http://www.hantek.com/down.aspx?url=http%3a%2f%2fwww.hantek.com%2fProduct%2fHantek6000%2fHT6022BL_Driver.zip

I then extracted the 8192 byte to a binary file with dd. Is this the driver binary image?

If so, can I convert it to hex format and load it with your loader? At which address?

After writing this I'll be converting your hex driver to binary and try to make an informal comparison to the image I have, any helpful comments?

olerem commented 8 years ago

@jssilva25 i used wireshark to monitore usb traffic. Captured the boot sequence and compared the data on the usb with the the content of binaries. Then i adopted the firmware extraction tool from openhantek to use specific offset instead of linker information.

jssilva25 commented 8 years ago

@olerem Thank you for your help. I can try that although, after eventually succeeding, I suspect there's a lot more trouble ahead. As I still have some time left, I'm tempted to return the 6022BL and eventually buy a 2090, although I'll loose the freight cost and the logic analizer section.

jssilva25 commented 8 years ago

Hello, I'm back again with some new developments.

So, I didn't return the 6022BL because I find it a challenge and because it works very nice and usefuly as an 8 channel logic analyser using the Saleae Logic software.

Back to the scope theme, I used wireshark to sniff the traffic to the scope on the firmware upload phase and I can confirm that the first tenths of bytes are coincident with @nickless81 driver at nickless81/openhantek/tree/qt5_6022bl.

The rules at fw/90-hantek.rules are wrong, at least for my device, as the last line should be 04b5:602a instead of 04b5:6022 which is the second id for the 6022be, not my 6022bl.

So, I built his tree and for that I had to struggle with a undefined `Hantek::Control::stringCommand(QString)' which I conquered by uncommenting an #ifdef DEBUG at control.h that defines the thing. I hope this isn't the cause of the problems I'm having, read below.

After building, installing and launching the app, I felt well rewarded that the device was found and there were two traces, responding to amplitude and time-base settings, but not triggering.

Also, as a side-effect of changing any setting, the time-base returns to 10 seconds, hiding the trace completely, which I can recover by resetting the TB.

All in all, I guess we are not far, can't some developer find some extra time, obviously nor taking it from his (her) children :), please? I, and I'm sure a lot more people, would be immensely grateful.

Rgds, jss

stefannilsson commented 7 years ago

Hello guys! And thank you for doing a great job!

Do you have any updates regarding the Pipe error issues? Something I can do to help, in capture traces, etc?

Running macOS Sierra and compiled from today's source.

**$ sudo /usr/local/OpenHantek** 
Version 
QObject::connect: No such slot OpenHantekMainWindow::sendCommand()
QObject: Cannot create children for a parent that is in a different thread.
(Parent is Hantek::Control(0x7f80d2773140), parent's thread is QThread(0x7f80d2401330), current thread is Hantek::Control(0x7f80d2773140)
22:13:18.016: Sending bulk command: 07 00 09 00 00 00 00 00
Sending bulk command 07 failed: Pipe error
22:13:18.017: Sending control command b4: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00
Sending control command b4 failed: Pipe error
22:13:18.017: Sending control command b5: 00 04 08 fd 20 40 ef 01 00 00 00 00 00 00 00 00 00
Sending control command b5 failed: Pipe error
22:13:18.017: Sending control command e0: 05
22:13:18.017: Sending control command e1: 05
22:13:18.018: Sending control command e2: 01
22:13:18.019: Sending control command e3: 01
22:13:18.019: Capture state changed to 2
22:13:18.031: Received 20480 B of sampling data
QWidgetWindow(0x7f80d3f458d0, name="QToolBarClassWindow") ( QScreen(0x7f80d241f9b0, name="DELL P2414H") ): Attempt to set a screen on a child window.
22:13:18.041: Sending bulk command: 07 00 09 00 00 00 00 00
Sending bulk command 07 failed: Pipe error
22:13:18.042: Sending control command b4: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00
Sending control command b4 failed: Pipe error
22:13:18.042: Sending control command b5: 00 04 08 fd 20 40 ef 01 00 00 00 00 00 00 00 00 00
Sending control command b5 failed: Pipe error
22:13:18.062: Received 20480 B of sampling data
QWidgetWindow(0x7f80d3d608a0, name="QToolBarClassWindow") ( QScreen(0x7f80d241f9b0, name="DELL P2414H") ): Attempt to set a screen on a child window.
22:13:18.073: Sending bulk command: 07 00 09 00 00 00 00 00
Sending bulk command 07 failed: Pipe error
22:13:18.074: Sending control command b4: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00
Sending control command b4 failed: Pipe error
22:13:18.074: Sending control command b5: 00 04 08 fd 20 40 ef 01 00 00 00 00 00 00 00 00 00
Sending control command b5 failed: Pipe error

giomasce commented 7 years ago

Hi @stefannilsson, unfortunately the development here is rather stalled. Nobody appears to have time for this now. I do not think I'm able to help with your problem. Sorry!

kyberkiller commented 7 years ago

So there is no way to get Hantek 6022BE working with OpenHantek? Am I missing something, or does this still apply?

How to start the development on this?

giomasce commented 7 years ago

@kyberkiller I am not aware of anyone having worked on 6022BE support lately. So I presume the situation is still the one described in my comments above (i.e., you can see something, but it is basically useless for real work). What one would have to do, basically, is to understand better the details of the protocol used by the 6022BE (which is not complicated, but there are some missing details) and fix the implementation of OpenHantek.

kyberkiller commented 7 years ago

Thnx, giomasce.

Can someone explain things a bit to get me and maybe some others going on.

I bought the cheapest Hantek 6022BE available, and it seems that it is not taken too seriously here to support.

1) Why is the firmware of scope uploaded to scope? There is firmware out of box.

2) I understand the roal of uploader to respond to plugging-in to do the upload of firmware.

3) What is the purpose of the driver here, and compared to question 2?

I downloaded https://github.com/nickless81/HT6022_Driver.git I ran "make" the driver, got a.out. Now what do I do with this? I see some comments in code that denote to uploading as well.

3) Why is the project maintained in different places - very messy, has the team actually split up?

4) Where do I get reverse engineering data - or where have the function names and protocols come from? Rev eng is something I have not done. I don't see any intermediate results on that, is that a trivial, or does everyone need to start from the very beginning?

5) Hantek SDK role? By a quick glimpse I understood it is something for Windows with which you can hook up to Win program to get it controlled and get data out of it. Is this correct or can this SDK somehow be used to understand what is taking place in the communication of firmware and the application?

Thanks in Advance,

giomasce commented 7 years ago

The 6022BE has no permanent storage for firmware. You have to upload each every time.The upside is that we have it and it is easy to patch it if someone finds it can be improved.
Good!
That is just an independent project, that is not however linked to any actual tool to visualize and understand data (like OpenHantek is). I would consider it mostly a testing/experimenting tool, that might definitely be valuable for learning how 6022BE works. As every other driver for 6022BE, it has to upload a firmware to work.
I would say that no team has ever formed. Some random people just tried to implement some support for 6022BE in OpenHantek, but nobody has ever had time to complete it.
The protocol is very simple and almost completely rev enged. If you look at the driver you liked it should not be hard to get a grasp of it. I also have a few handwritten notes at home that I can share if you want to work on this (I am on a trip now, so you will have to wait a few days). What basically needs to be sorted out in OpenHantek is why you see the effect described in https://github.com/OpenHantek/openhantek/issues/7#issuecomment-146873843 and my later comments. Then the whole code should be refactored and fixed, because at the moment it is just a dirty patch over the original OpenHantek code.
I have no idea on that. If it works like the Windows program works, it is a total crap. However, I do not develop on Windows.

olerem commented 7 years ago

This device should already work with sigrok. https://sigrok.org/wiki/Hantek_6022BE

I personally would prefer to continue with this project. -- Regards, Oleksij

kyberkiller commented 7 years ago

Giomasce, thnx for your effort on this.

I just sold my 6022BE 15 mins ago, and I believe I will get Hantek DSO-2090, to get a USB oscilloscope running (in Ubuntu).. I assume that's the one most certainly working with OpenHantek, right?

So, my perspective might change a bit, but yes, I'm at least interested in joining to do something.

After a quick look on the sigrok - it seems to be totally another perspective to OpenHantek oscilloscope software.

EDITED: Sigrok seems an interesting platform. I need to take a closer look.

swkim01 commented 7 years ago

I added some functions for 6022be to the following repository. https://github.com/swkim01/openhantek

You can adjust samplerate and use software triggering for 6022BE.

Support 48, 24, 16, 8, 4, 2, 1 M and 500, 200, 100 k Hz samplerates with modded firmware by jhoenicke.
Support software trigger by detecting rising or falling edge of signal. Use software trigger item on the trigger menu. For trigger level, adjust left arrow on the right-side of the graph.
Note that I dropped first 1000 samples due to unstable/unusual reading.

Finally, some more improvements and the integration to this repository is needed.

jan-kleks commented 7 years ago

BTW, is the source code of BasicScope of any use to the OpenHantek project?

There is also a lot of interesting discussion regarding alternative 6022Bx software here: http://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/

swkim01 commented 7 years ago

@jan-kleks Oh, I didn't know about BasicScope. I implemented it by myself. The software triggering uses a simple algorithm, actually a bit unstable. Thank you for the discussion link.

daybyter commented 7 years ago

Could it be, that the 6022be doesn't support the b4, b5 and 07 commands, so the app should never send them?

See my posting here:

http://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/msg1187931/#msg1187931

davidgraeff commented 7 years ago

@swkim01 I would very much welcome a pull request for the 6022Bx models

daybyter commented 7 years ago

Add this, too

https://github.com/KimBP

(Although I cannot test it at the moment because of the broken pipe issue.)

OpenHantek / openhantek

Hantek 6022Bx support #7