-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unite all OpenHantek efforts #6
Comments
A 6022 libusb1.0 driver: |
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. |
Hey Oleksij, the author, Oliver Haag, founded this github repository and is part of the team. Look at the original website http://openhantek.org/ :) |
Ah, ok. I see. |
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. |
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 ;) 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... Thanks all, Oliver |
Hi Everyone. I like the idea. I been playing around with the code for some needs I have. I propuse a few changes. Lets create libraries. I like the idea of libraries because I am planning to create a Scilab I am working on a project for the company where I work (it's an Oleksij Rempel, I having some issues to comunicate with my 6022BL, Thanks and Best Regards from Costa Rica, Jose Pablo, On Thu, Oct 8, 2015 at 4:38 AM, Oliver Haag notifications@github.com
Saludos. Santiago 1:5 Y si alguno de vosotros tiene falta de sabiduría, pídala a |
@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. |
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 :) |
@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. |
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 6e3e04b. |
Hey guys. Best Regards, |
I'm on a branch where I did a few things already. Mostly the split of OpenHantek into:
libHantekDSO changes:
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. BuildsystemI'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. |
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...). 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. Switching over to CMake is okay, just didn't do it since I wasn't that familiar with it. |
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? |
I thinking of using an external XML file with the info about the device. Best Regards, |
Since you're already talking about a lib, allow me to lobby for inclusion of SainSmart/Buudai USB oscilloscopes. For that purpose I think a lot of the changes outlined above make sense, though obviously this is becoming less and less "Hantek". 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/ |
@cskau Did you make progress on supporting your DSO? |
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. If I were to try push some of these changes, which branch should I be targeting at this point? |
@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). 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. |
Hi guys, just a quick heads-up: in sigrok we're now supporting the following devices:
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. |
@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. |
Hi Uwe, Best Regards |
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! |
+1 for Instrustar ISDS205X support!! Any update on the progress of the implementation? |
(http://sourceforge.net/p/openhantek/discussion/1153137/thread/94c97670/)
The text was updated successfully, but these errors were encountered: