#Owon vds1022 software#
I'm sure a real software person (not I) could do it in an hour ! And if the speeds are really 1.1, the additional lag may be unnoticeable.
#Owon vds1022 mods#
And some more mods to the client software. This would mean some custom software on the ARM board to play mailman between WiFi and USB.
#Owon vds1022 Pc#
The link to the client software on the PC is then done via WiFi. The pair are powered by the ubiquitous wallwart, which is general isolated from the mains. My thought was to use a cheap ARM SoC board (perhaps an RPi) to talk via USB to the scope.
That the captured waveform is spit across the USB link as a file ? Even in continuous (vs single shot) mode ? Does anyone know or am I misfiring a neuron (again) ? I ask the above because I have a goofy idea on another way to isolate the scope. I also sorta recall a comment (perhaps not in this thread) that all the OWON PC scopes push their data to the PC differently from others, and that's why they don't make for good data streamers. Did that ever get resolved ? Are they all USB 1.1 hardware, just that the non-I is missing a couple of ICs ? I believe that sticking to 1.1 speed it's about $20 (US) to make the upgrade. I recall that early on in this thread there was some discussion on the USB hardware installed, 1.1 vs 2.0, in the I vs non-I variants. I've just got to come up with $16 (or more if I bother with the EEVblog discount) of other (needed ) stuff to get the free shipping. I'm a bit concerned about the 5kSa capture but for these $s ($84) I'll see what I see. I've decided that I'm tired of borrowing a Tek from work and one of these is probably enough for 95% of my needs (for the other 5%, I'm back to borrowing from work). I note that Saelig is having a clearance sale on these ATM. 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). it seems this device has some weird USB behavior. I have no idea what made it work once (or twice) in FreeBSD, but it did. 4) same 64bit FreeBSD 11 system running on actual hardware: same results as 3). 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". 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). ") early in the device initialization progress. 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.
0 kommentar(er)
