Unite all OpenHantek efforts

[davidgraeff]

• https://github.com/fabiobaltieri/openhantek: @fabiobaltieri (GUI)
• 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)
• https://github.com/dpavlin/openhantek: @dpavlin (Touch Interface, Min/Max voltage) (http://sourceforge.net/p/openhantek/discussion/1153137/thread/94c97670/)

[davidgraeff]

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

[olerem]

I have nothing against it. We can use your repo as base? The problem with original repo was not working communication (email nottification). Probably the author of openhantek can be notified about it, may be he will agree to move this project to github including issue tracking.

I need to admit that i'm not good at C++. So i won't be able to provide good reviewing for new patches.

[davidgraeff]

Hey Oleksij, the author, Oliver Haag, founded this github repository and is part of the team. Look at the original website http://openhantek.org/ :) Thanks for your support. It would be great if all efforts could be united to make the software compile again on modern systems and to support the very popular 6022 DSO.

[olerem]

Ah, ok. I see. I don't know about status of other projects. Did some one solved triggering issue for 6022? As far as i understand, 6022 can't provide FW based triggering. So it should be done by SW, which was not available in old version of OpenHantek.

[giomasce]

Hi.

It would be very nice to unite the available manpower on OpenHantek. Unfortunately my contribution ability is really little at the moment, due to many other commitments, but please keep me in the loop, as I hope to find more time later on.

BTW, I did not perform a complete reverse engineering of the firmware; I began doing it, but could not complete because of lack of time. I tried to fix in my repository as much as I could, so that others or the future me could resume as efficiently as possible from that. I also have copies of (some of) the relevant docs and datasheets, so feel free to ask about that (they can be find on the Internet, though).

I own a 6022BE that does not work properly at the moment. Some waveform can be seen, but it is clearly broken and trigger does not work at all.

Thanks, Giovanni.

[OliverHaag]

Hi all,

David had the idea to move over to github and I have some time at the moment to work a bit on it. I'm moving the (broken) website to a new jekyll based site here on github at the moment, but I never used it before so it may take a few more days till it goes online. But I've already quickly generated one using the github wizard thingy, that's better than nothing at least ;) Just for convenience: git.openhantek.org is forwarding directly to the repo too.

Sure that the trigger is pure SW or is just some post-filtering in SW required? At least my DSO-2090 got that much blind time between acquisitions that you would have to wait for ages to get the trigger event you wanted without any HW support... Since my DSO-2090 doesn't trigger too precise in terms of time I had thought about adding a software based horizontal post trigger alignment once. Adding post filtering is another thing I thought about to allow other triggers than falling and rising edge, but never started working on that. If something like this is required for the 6022 anyway it could also be helpful for the 2090 and others. But this turns off-topic, in case the 6022 requires this functionality feel free to open a new issue.

Thanks all, Oliver

[nickless81]

Hi Everyone.

I like the idea.

I been playing around with the code for some needs I have. I have a 6022BL which use the 6022be software for the Osciloscope and other program for the Logic Analizer.

I propuse a few changes.

Lets create libraries.

• USB Wrapper: An interface that use libusb-1.0, libusb0.1, WinUSB, etc etc. I like to make the software multiplatform (Windows, Linux, Mac, Android, iOS, etc)
• DSO Wrapper: An interface that comunicate with the DSO. Not all Hantek DSO have the same number of analog ports, some have 2, 4, 6. And also have several samples rates. The GUI application could ask which DSO is available (connected) and what are the specification (numbers of ports, samples rates, etc etc), and then creates dinamically some of the user interface (QtQuick/QML is a good option even for deploy over Android or iOS, tablets).

I like the idea of libraries because I am planning to create a Scilab Module (http://www.scilab.org/), to comunicate with the DSO, takes the results from it, store it and postprocessing the results (or even processing the data on the fly).

I am working on a project for the company where I work (it's an innoventures program I am participate), and I like to use as open source tools as possible. There is a chance that we got financial support for further develops and I want to get the Company involved as much as possible.

Oleksij Rempel, I having some issues to comunicate with my 6022BL, libusb-1.0 pipe error (-9). How did you partially reverse engineer the firmware? I want to continue with the reverse engineer to complate it and make possible to use my DSO.

Thanks and Best Regards from Costa Rica,

Jose Pablo,

On Thu, Oct 8, 2015 at 4:38 AM, Oliver Haag notifications@github.com wrote:

Hi all,

David had the idea to move over to github and I have some time at the moment to work a bit on it. I'm moving the (broken) website to a new jekyll based site here on github at the moment, but I never used it before so it may take a few more days till it goes online. But I've already quickly generated one using the github wizard thingy, that's better than nothing at least ;) Just for convenience: git.openhantek.org is forwarding directly to the repo too.

Sure that the trigger is pure SW or is just some post-filtering in SW required? At least my DSO-2090 got that much blind time between acquisitions that you would have to wait for ages to get the trigger event you wanted without any HW support... Since my DSO-2090 doesn't trigger too precise in terms of time I had thought about adding a software based horizontal post trigger alignment once. Adding post filtering is another thing I thought about to allow other triggers than falling and rising edge, but never started working on that. If something like this is required for the 6022 anyway it could also be helpful for the 2090 and others. But this turns off-topic, in case the 6022 requires this functionality feel free to open a new issue.

Thanks all, Oliver

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

Saludos.

Santiago 1:5 Y si alguno de vosotros tiene falta de sabiduría, pídala a Dios, el cual da a todos abundantemente y sin reproche, y le será dada.

[olerem]

@OliverHaag, i'm pretty sure, Windows SW do not send any commands if user trying to configure triggering. So, even if FW is able to do so, current Win SW using own SW method.

@nickless81, to get FW, you will need usb monitor (i used Wireshark) and disassembler. Then monitore the HW initialisation, capture USB stream and compare it with data located in WIndows binaries.

[olerem]

Beside i noticed that we are not able to get continues stream from the DSO, i mean some data can be lost. I don't recommend to use this device for some precise work. On other side, for hobby it is more then enough :)

[nickless81]

@olerem Thanks. I give it a try tonigth with virtualbox running a Virtual Machine with Windows, I think its much easier to filter the USB comunication base on the IdVendor and IdProduct that changed after the device is initialized.

[fabiobaltieri]

Hi :-)

Thanks for starting this... it's great to have an official repo on GitHub! My branch mostly contained some hacks around an external USB control board that I never published, so there's not much stuff that makes sense upstream, that said a couple of small patches I wrote may be useful. I've rebased my master to those and moved my hardcontrol stuff in a separate branch, feel free to have a look up to 6e3e04b6d4c5.

[nickless81]

Hey guys. I think we need to get an agreement of how we are going to join forces with this project and how we are going to develop. I got a few Ideas I need to put on paper (maybe draw a few diagram to explain myself better). I like to hear yours ideas about how to develop the application and define the scope and a milestone. I other words, draw a roadmap and start walking over the road.

Best Regards, JP.

[davidgraeff]

I'm on a branch where I did a few things already. Mostly the split of OpenHantek into:

• libHantekDSO (device communication, sampling and analysing). The name of the lib is not final, could also be libOpenHantek.
• OpenHantek (Gui)

libHantekDSO changes:

• I splitted up "types.h" into several classes. I really don't like the all-in-one-file concept. This is probably not in the final state. I had to shuffle around a lot of classes and files. Right now I have these files:
  • protocol.h/cpp + protocol_bulk.h + protocol_controlcommands.h: The structs, bits, enums that are essentially send over the wire for all currently supported DSOs. We should name this protocol somehow and rename the files to protocol[HantekV1].h etc.
  • dsoSettings.h, dsoSpecifications.h: Should be generic for supported and coming devices. Samplerate, voltage limits, channel/dso settings are stored in those structs.
  • usbCommunication.h/cpp: Only usb communication, no hantek product id, models etc as before.
  • hantekProducts.h: A DSODeviceDescription struct which encodes a model name, usb product/vendor, endpoints. This file contains also a "database" (array) of all supported products.
  • deviceBase* and hantekDevice class. Formerly known as DsoControl and Control. I extracted everything that could be generic to deviceBase* classes. The actuall hantekDevice class that implements the currently supported DSOs is 600 lines only (using protocol.h etc) and if it cannot be extended for coming devices, a new hantekDeviceV2 class can reuse alot of functionality. This also allows me to implement test classes like a DummySineWaveDevice on top of DeviceBase (not done so far).
• All usb communication stuff is done in a usbCommunication class (formerly known as device.h, this is actually a thin wrapper around libusb methods now). This allows us to support windows where only another usbCommunication.cpp file has to be provided now.
• A DeviceList class that keeps an eye on the bus and automatically create/destroy Device instances (hotplugging). This requires changes in the GUI.
• DataAnalyzer moved to this lib, too. This is actually the interface class to the GUI.

I'm using c++11, so replaced QThread, QMutex, QDebug, QList, QString, Qt Signals/Slots and made the library only depend on libusb and libfftw. I would like to have the policy of using Qt only for the GUI if possible.

Buildsystem

I'm sure this can also be done with qmake, but because I'm quiet familiar with cmake and actually only know how to archive certain tasks (like adding tests) for cmake, I changed the build system. Fine tuning for MacOSX installing is propably necessary and a regression compared to the state before.

[OliverHaag]

Nice to see some work done regarding this. Splitting up into libs is a good idea.

I've taken care to keep all device-specific stuff separate (And kept it in a separate directory to clearly separate it from the other code). What would be really nice is putting this into a separate libhantek or however you want to call it in a way that anyone who would like to support scopes by another manufacturer could just add another lib without changing OpenHantek itself. Those device-specific libs should be without Qt-dependencies (But there aren't many anyway afaik). Hotplugging should be kept in mind when doing this (Checked how that could be done some time ago, I just remember that it turned out to be platform dependent...). The DataAnalyzer is required for every device, so it shouldn't be together with the device-specific stuff imo. So I would put that into a separate postprocessing library. If you want to remove Qt-dependencies there feel free to do so ;)

Btw.: Regarding filenames and so on, I usually used camel case so best keep it this way and avoid underscores too keep the project clean. But splitting up types.h is a good idea, thought about that too since it's growing quite large already and is a bit larger due to the Doxygen documentation of the protocol in there anyway. edit: Ah nope just lowercase, but anyway - let's choose one way and avoid mixing ;)

Switching over to CMake is okay, just didn't do it since I wasn't that familiar with it.

[olerem]

On one side i will be happy to have at least one type of devices working on linux, but there are many more like power supplies and multimeters. Is it something for openhantek?

[nickless81]

I thinking of using an external XML file with the info about the device. VendorId/ProductId, control comunication type and control words. Even the firmware in a text mode that can be loaded and parsed without any recompilation. Made the solution as modular as possible.

Best Regards, JP

[cskau]

Since you're already talking about a lib, allow me to lobby for inclusion of SainSmart/Buudai USB oscilloscopes. As it turns out a couple folks have already managed to hack up OpenHantek to talk to the DDS120 and DDS140.[0] They've essentially just changed out some of the innards of control.cpp, device.cpp, and type.cpp.

For that purpose I think a lot of the changes outlined above make sense, though obviously this is becoming less and less "Hantek". The biggest change I'd like to see added to the list is less giant switches for every model under the sun. control.cpp is especially bad in that regard. I'd rather have many small files for each device, than one large tangle for all.

In any case I'll try see if I can get a repo up with SainSmart/Buudai support for my own DDS140.

Let me know if I can help out with anything.

[0] http://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/255/

[davidgraeff]

@cskau Did you make progress on supporting your DSO?

[cskau]

Thank you for checking in.

I've got a small tool based on code I salvaged from some of the other projects for dumping the raw sampling data. So it definitely works. However, I did observe sample gaps between frames, which I'm not sure if it's a device limitation or just bad code on my part. I'll have to do some more rigorous testing.

If I were to try push some of these changes, which branch should I be targeting at this point?

[davidgraeff]

@cskau Ideally provide a lib for accessing the raw data. In the mr_split_gui_backend branch there is a folder libusbDSO. If you like, you can implement the interface of deviceBase.h (which inherits deviceBaseSamples which inherits DeviceBaseSpecifications). Then all necessary functions to be compatible with openhantek would be available (like getChannelNumbers, getMinSamplerate and so on).

I have time on wednesday, at the moment i would like to get that branch done before I write a howto for a new device driver lib.

[uwehermann]

Hi guys,

just a quick heads-up: in sigrok we're now supporting the following devices:

• Hantek 6022BE
• Hantek 6022BL
• Sainsmart DDS120
• RockTech/Buudai BM102 (basically the same as DDS120)

All of those are supported via our sigrok-firmware-fx2lafw firmware (originally for logic analyzers; the analog scope support is a slightly adapted version of Jochen Hoenicke's firmware).

http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=blob;f=README;hb=HEAD#l90

I'll be adding Instrustar ISDS205* support soonish, I've opened an ISDS205A and ISDS205X recently and they're very similar to the above devices, supporting them shouldn't be too much work.

Adding support for the SainSmart DDS140 might also not be too hard, haven't looked at that in detail yet, though.

We're also supporting e.g. Hantek DSO-2090 and some other models via another driver in libsigrok (currently using the vendor firmware).

Anyway, just wanted to let you guys know, if you want to grab/use some firmware or PC-side code from sigrok feel free to do so, the licenses are compatible (both are GPLv3+).

There's also an opportunity to have a libsigrok-based backend in openhantek if you want to go that route; libsigrok is a shared library that contains all hardware access drivers for sigrok-supported devices (logic analysers, DMMs, scopes, and lots more). If you added support for libsigrok in openhantek you could support all currently sigrok-supported scopes (Hantek, Agilent, Tektronix, whatever) automagically, plus all those added to libsigrok in the future.

Feel free to drop by in the #sigrok IRC channel on FreeNode for a chat.

Cheers, Uwe.

[davidgraeff]

@uwehermann: Sigrok as a backend is actually what I considered as well. OpenHantek would be a total different application then though, because the user interface should be rewritten in Qt5/QML at that point, as the current C++ based GUI is somehow tailored towards the internal device structure.

[perivar]

Hi guys,

just a quick heads-up: in sigrok we're now supporting the following devices:

• Hantek 6022BE
• Hantek 6022BL
• Sainsmart DDS120
• RockTech/Buudai BM102 (basically the same as DDS120)

All of those are supported via our sigrok-firmware-fx2lafw firmware (originally for logic analyzers; the analog scope support is a slightly adapted version of Jochen Hoenicke's firmware).

http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=blob;f=README;hb=HEAD#l90

I'll be adding Instrustar ISDS205* support soonish, I've opened an ISDS205A and ISDS205X recently and they're very similar to the above devices, supporting them shouldn't be too much work.

Adding support for the SainSmart DDS140 might also not be too hard, haven't looked at that in detail yet, though.

We're also supporting e.g. Hantek DSO-2090 and some other models via another driver in libsigrok (currently using the vendor firmware).

Anyway, just wanted to let you guys know, if you want to grab/use some firmware or PC-side code from sigrok feel free to do so, the licenses are compatible (both are GPLv3+).

There's also an opportunity to have a libsigrok-based backend in openhantek if you want to go that route; libsigrok is a shared library that contains all hardware access drivers for sigrok-supported devices (logic analysers, DMMs, scopes, and lots more). If you added support for libsigrok in openhantek you could support all currently sigrok-supported scopes (Hantek, Agilent, Tektronix, whatever) automagically, plus all those added to libsigrok in the future.

Feel free to drop by in the #sigrok IRC channel on FreeNode for a chat.

Cheers, Uwe.

Hi Uwe, I also have a Instrustar ISDS205. Did you ever get one to work with OpenHantek? I would like to use this with Linux, and not only Windows.

Best Regards Per Ivar

[elbowz]

Hi @uwehermann,

I'm also interested to the Instrustar ISDS205* (B in my case). Your post speaking about this device is quite old, so I would like know if the support is abandoned or still in progress.

Thx in advance!

[defcon8]

+1 for Instrustar ISDS205X support!! Any update on the progress of the implementation?