I quickly tried it on linux, but the software won't find the hardware.
Without the actual message I can't be sure, but IIRC I saw such a message be thrown due to another problem (missing libraries, permissions... I can't remember).
Probably i need to manually create some device rules, but i have not much experience with that and how to force it to use libusb.
That (I'm guessing you mean the equivalent of the windows step of associating the device with the libusb-win32 driver) is not needed, just adequate permissions and the properly working libs.
Been faffing in Linux all day.
I'm at the point where the app will recognise the device, but fails (times out) at sending config.
This is the point I got too, before testing in the Mac. If you look at dmesg output, there should be a few "USBDEVFS_CONTROL failed" messages.
It should have write access and a quick Python script succeeds, but this is just annoying!
What does your Python script do?
Some notes:
- lsusb may list the unit with another Owon device - this is purely a text string, not an existing driver. It seems Owon use one Id across most devices!
- A rule appears not to make a useful difference for testing (I'm Sudo'ing everything for now), but for a 'public' guide, is probably going to be useful.
- I removed the lsusbjava.so (wrong ELF format), and apt'd the libusbjava.
The provided libusbJava.so is built for 32bit systems, are you using a 64bit system?
So far, apart from the Mac, in which we already know it works, I've tried:
1) a 64bit Linux (Arch) system with a recent kernel:
timeout errors ("USBDEVFS_CONTROL failed ...") early in the device initialization progress.2) a 32bit Linux (Centos) with an old (2.6) kernel running inside Virtualbox with the USB device passed through to the guest:
same as 1).3) a 64bit FreeBSD 11 running inside Virtualbox with the USB device passed through to the guest:
didn't work, then worked 1 or 2 times, then never again; even not working, it gets further in the device initialization progress than Linux, the last message shown in the terminal, before stalling, is "+6250 bytes MCU:getFrame 14".4) same 64bit FreeBSD 11 system running on actual hardware:
same results as 3).I have no idea what made it work once (or twice) in FreeBSD, but it did. it seems this device has some weird USB behavior... after trying to use it in FreeBSD/Linux, it locks the boot process of my notebook (which proceeds promptly after unplugging the device), booting with it plugged in sometimes also prevents Linux from recognizing my wireless keyboard/mouse usb receiver (which also proceeds to work promptly after unplugging it)...