OWON VDS1022I Quick Teardown (versus the Hantek 6022be)

[ebclr]

Your version lost USB isolation  , that is not good

[Gyro]

Your version lost USB isolation  , that is not good

Not the end of the world, it can be retrofitted to the PCB if needed. The cost probably isn't much different to the price difference between the 'I' and 'non-I' but at least it can be done. See earlier posts in this thread.

The non-isolated version is really no different from a grounded scope. USB logic analyser, Hantek etc. It just needs care not to create a high current ground loop.

[ebclr]

I high recomend to do this I already burned one Picoscope, with some ground loops to mains via computer power supply

[CatWhisker]

Hi Gyro & Ultrawipf,

I pushed my quick & dirty guide here:

https://github.com/tinwhisker/Owen-VDS1022

Quick background:
I bought the scope, read some reviews that people wanted it on Mac/Linux, so got it running.

I came here and see you guys had started trying, so: Tada!

I'll be uploading an OS X 'app' package later, so you can just click-run the app.

Not tested in Linux, but I don't see a big issue for tweaks. (i'll do it later if this doesn't help.)


Dan.

[Gyro]

Hi CatWhisker,

Tada!

Congratulations and thank you. I'm impressed! 

I'm sure this will be helpful to a number of people, especially if it really is that easy to tweak it for Linux too.


It may be worth mentioning too that the VDS series support SCPI, I haven't looked into it in any detail, but it might be useful for automated measurement functions.

[Ultrawipf]

That sounds awesome and is exactly what i thought and hoped for.
I will probably also buy this scope and when it works on OS X with that script it should also run on linux, i will try that when i have the scope.
Hopefully the scope will get some more attention when it runs on linux.

[gsdn]

Hi Gyro & Ultrawipf,

I pushed my quick & dirty guide here:

https://github.com/tinwhisker/Owen-VDS1022

What a coincidence, I also just got it working on OSX past night (but went to sleep before posting anything).

Similar steps, although I simply removed libusbpp linking to get (an old version of) Libusbjava to build.

I'll be uploading an OS X 'app' package later, so you can just click-run the app.

That would be great

Not tested in Linux, but I don't see a big issue for tweaks. (i'll do it later if this doesn't help.)

Before trying on OSX, I did about the same steps (building the libs) on (Arch) Linux, but no luck. In fact, I tried on OSX primarily to confirm it would work out of Windows and it was a Linux specific issue I was hitting.

To me it seems the osciloscope has some strange behavior and the Linux kernel has issues dealing with it, so, for now, I don't think it's gonna be as easy as on OSX.

Great work!

[CatWhisker]

Hi Gyro & Ultrawipf,

I pushed my quick & dirty guide here:

https://github.com/tinwhisker/Owen-VDS1022

What a coincidence, I also just got it working on OSX past night (but went to sleep before posting anything).

Similar steps, although I simply removed libusbpp linking to get (an old version of) Libusbjava to build.

I'll be uploading an OS X 'app' package later, so you can just click-run the app.

That would be great

Not tested in Linux, but I don't see a big issue for tweaks. (i'll do it later if this doesn't help.)

Before trying on OSX, I did about the same steps (building the libs) on (Arch) Linux, but no luck. In fact, I tried on OSX primarily to confirm it would work out of Windows and it was a Linux specific issue I was hitting.

To me it seems the osciloscope has some strange behavior and the Linux kernel has issues dealing with it, so, for now, I don't think it's gonna be as easy as on OSX.

Great work!

Haha, like a bus - these will all be coming out the woodwork!

I've tidied up the OS X App and uploaded.
This "build" doesn't need to put files anywhere like the initial script did. libUSBJava has been tweaked to look locally instead.


I'll poke at Linux when I have some time.
Last time I poked with USB and 'scopes on Linux was at Pico years ago, so no doubt it's 'different' again...

[Ultrawipf]

Okay, i have the scope now and i am quite impressed how well it works even with usb 1.1
I quickly tried it on linux, but the software won't find the hardware.
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.

[CatWhisker]

Okay, i have the scope now and i am quite impressed how well it works even with usb 1.1
I quickly tried it on linux, but the software won't find the hardware.
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.

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.
It should have write access and a quick Python script succeeds, but this is just annoying!

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.

When running the app, you'll spot the terminal chatter when the device is plugged in, then fail with a timeout.

I'll have another crack at it another free day, but hopefully someone can give it some real effort.

[Ultrawipf]

While digging around in the code to add some shortcuts to move the trigger position i also found a "secret" menu that you can activate by pressing ctrl+l and click on "tune"
Can anyone translate to see what that might do?



*edit*
oh well, looks just like some kind of configuration editor and language selection.
But i still don't know what those three tabs do differently.
The voltage selections do change the range on the scope and the calibration also just starts the self calibration just like in the main menu.

[gsdn]

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)...

[JustMac]

I note that Saelig is having a clearance sale on these ATM. It is the non-I model unfortunately. 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'm a bit concerned about the 5kSa capture but for these $s ($84) I'll see what I see. 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 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. 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 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. 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. My thought was to use a cheap ARM SoC board (perhaps an RPi) to talk via USB to the scope. The pair are powered by the ubiquitous wallwart, which is general isolated from the mains. The link to the client software on the PC is then done via WiFi. This would mean some custom software on the ARM board to play  mailman between WiFi and USB. And some more mods to the client 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. I recall other posters saying it's already somewhat laggy. In return you get isolation and freedom from yet another USB cable dragging across the workbench.

Of course the whole scheme may be goofy but I figured I'd toss it out there and let people pull on it's wings.

[rch]

Apparently USB opto-isolators are a thing.  I didn't know that, but this is just an example from Google of a fairly reputable sounding one.

http://uk.farnell.com/olimex/usb-iso/usb-isolator-1000vdc-for-pc-laptop/dp/1795095?mckv=fvKfxZhD_dc|pcrid|78108470709|&gross_price=true&CATCI=pla-131293226229&CAAGID=20220744309&CMP=KNC-GUK-GEN-SHOPPING-OLIMEX&CAGPSPN=pla&gclid=CKiy19mhrdECFW4A0wodOisBqQ&DM_PersistentCookieCreated=true&CAWELAID=120173390000303585

[JustMac]

Yup, I've seen USB 2 isolated cables for about $50 (US). And Adafruit sells a isolator for USB 1.x for about $35, though it's a bit shy on current for this usage. (https://www.adafruit.com/product/2107) Linear Tech sells a USB 2 isolator IC, which Mouser and Digikey carry for about $30. You'd then have to come up with the PCB to mount it and associated connectors & cabling.

So there are solutions for people who want to isolate a non-I version w/o opening it up, it really depends on what speed it runs at (hence my question above).

My goofy idea above was birthed by looking for a "fair" entry level logic analyzer. I ran across a one-off project that used a Beaglebone Black (with it's PRUs and onboard RAM) to do a good job of capturing data but with real triggering and deep memory, something the $20 streamers can't do. Because it's another single board Linux machine, it could even run sigrok-client and with an added display and keyboard, be it's own little stand alone LA. No doubt better, in some regards, than the ones I started with decades ago.

Conceivably you could do a similar thing with my goofy proposal above to make it stand alone, but the added cost of a display and buttons and encoders, etc, etc would soon be enough that you could buy a better, budget, "real" benchtop DSO for just a bit more. YMMV. Just to isolate and make it wireless might run about $30 added (plus time to code), only slightly more $s than adding the 2 ICs mentioned in prior posts. When mine arrives I'll be better able to see if the idea has any merit.

[Gyro]

Apparently USB opto-isolators are a thing.  I didn't know that, but this is just an example from Google of a fairly reputable sounding one.

http://uk.farnell.com/olimex/usb-iso/usb-isolator-1000vdc-for-pc-laptop/dp/1795095?mckv=fvKfxZhD_dc|pcrid|78108470709|&gross_price=true&CATCI=pla-131293226229&CAAGID=20220744309&CMP=KNC-GUK-GEN-SHOPPING-OLIMEX&CAGPSPN=pla&gclid=CKiy19mhrdECFW4A0wodOisBqQ&DM_PersistentCookieCreated=true&CAWELAID=120173390000303585

Actually, isolators but not opto-isolators. They use on-chip (or at least in package) inductive coupling. They're pretty much all based on the Analog Devices ADUM4160...

http://www.analog.com/en/products/interface-isolation/isolation/standard-digital-isolators/adum4160.html

Note that these USB isolator products state USB2.0 compliance but when you look closer, their maximum supported speed is USB Full Speed (12Mbps) not USB2 High speed (480Mbps). This works with the VDS1022(I) because of its high level of front end processing and also things like USB audio DACs, but won't work with the Hantek, simple USB logic analysers etc. because their USB streaming needs USB High Speed to get enough throughput.

You also need to get enough power across the isolation barrier to power the device, either with an isolated DC-DC converter or external PSU. A lot of the off the shelf USB isolators are only good for 100mA.

I have seen one recent reference to a USB2 High Speed isolator but the links to the company and Silicon are dead.

[Gyro]

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. 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.

Yes it was resolved, they both use USB Full Speed (12Mbps) and so are compliant with both USB1.1 and USB2.0 (again at Full speed, not High). The AD USB isolator chip is 'software transparent' so they both use the same driver and on-board code.

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. 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) ?

Yes, there's a lot more going on - there's an on board ARM CPU and FPGA rather than just a Cypress 8051 based EZ-USB micro. All the triggering etc is handled on-board rather than having to be done by the PC S/W in real time so all it needs to pump across the interface is display data rather than raw samples.

Yes, you can retrofit the parts, I'm not sure about the current cost. ADUM4160s are relatively easy to source, the more difficult part is probably the TI isolated DC-DC converter IC. I haven't looked for one of those, but reading back a few pages, someone did do it successfully.

[JustMac]

Yes, there's a lot more going on - there's an on board ARM CPU and FPGA rather than just a Cypress 8051 based EZ-USB micro. All the triggering etc is handled on-board rather than having to be done by the PC S/W in real time so all it needs to pump across the interface is display data rather than raw samples.

Aahhh, so am I correct in stating that all you get at the PC end is some "picture" format file for each waveform displayed ? Which at best contains/depicts perhaps 1k samples (given the display box is 1024 max) ? Any and all panning, zooming, measurements, etc is done in the OWON box so, as the old saying goes, "what ya see is what ya get" ?

ETA : Much thanks to you and the others for this very informative thread !   

[gsdn]

I ask the above because I have a goofy idea on another way to isolate the scope. My thought was to use a cheap ARM SoC board (perhaps an RPi) to talk via USB to the scope. The pair are powered by the ubiquitous wallwart, which is general isolated from the mains. The link to the client software on the PC is then done via WiFi. This would mean some custom software on the ARM board to play  mailman between WiFi and USB. And some more mods to the client 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. I recall other posters saying it's already somewhat laggy. In return you get isolation and freedom from yet another USB cable dragging across the workbench.

Of course the whole scheme may be goofy but I figured I'd toss it out there and let people pull on it's wings.

It could work. But if you simply use it with a notebook only on its battery, unplugged from the wall, it's also effectively isolated, no? (though not wireless )

[JustMac]

But if you simply use it with a notebook only on its battery, unplugged from the wall, it's also effectively isolated, no? (though not wireless )

Yes that would isolate the scope and PC from earth ground. But c'mon now, where's the unneeded complexity in that !   

I got my VDS1022 delivered today. Thumbs up to Saelig, I put the order in on Fri and it came (free shipping) 5 days later. 

I wanted to put up a somewhat obvious chart of sampling rate vs horizontal time setting in case some people didn't realize that they're tied in a DSO. In particular with only 5k samples/chan of storage, there's only so long it can collect data before that memory is full. And so to "see" a longer display means a slower Sa/s rate. And that means less than the full bandwidth is available as those rates.

5ns/div   100MS/s
...
2us/div   100 MS/s
5us/div   50MS/s
10us/div  25MS/s
20us/div  12.5MS/s
50us/div  5MS/s
100us/div 2.5MS/s
200us/div 1.25MS/s
500us/div 0.5MS/s
1ms/div   250kS/s
2ms/div   125kS/s
5ms/div   50kS/s
10ms/div  25kS/s
20ms/div  12.5kS/s
50ms/div  5kS/s
................. trigger to auto mode, no single shot available
100ms/div 2.5kS/s
200ms/div 1.25kS/s
500ms/div 0.5kS/s
1s/div   250S/s
2s/div   125S/s
5s/div   50S/s
10s/div  25S/s
20s/div  12.5S/s ?
50s/div  5S/s
100s/div 2.5S/s  ?

I wonder how Owon splits those half samples ?   

I had a brief chance to sniff the USB link and what I've seen so far is (I think) that the program on the PC sends a set of 3 commands to the scope HW. Each of these gets a 5 byte response except for the last one. If the HW is not "ready" (buffer not full ?) then a "busy" response is sent. IF the HW is ready then there's a 5216 byte message. The 1'st hundred or so bytes seem to be some header of some sort, the remainder appears to be the sampled data.

In this case I had only a single channel on, digitizing the 1kHz test signal. The scope was autoset to some ?? V/div vertically, near zero offset and 50kSa/s. One period of that data looks like ;

3C 3D 3C 3C 3C 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3E 3D
00 01 01 00 00 00 00 00 00 00 00 00 FF FF FF 00 00 FF 00 00 FF 00 00 FF 00

I interpret those 50 bytes as 25 samples of 0 or -1, 25 samples of 61 (+/- 1). The numbers make sense if the scope sends a 2's complement number, -127 to +128 for it's 8 bit sample. The 50 samples make sense for a 1 msec period sampled at 50kSa/s (-> 50 Sa/ms). The 50% DC of the test waveform is obvious.

So sometime this weekend I'll vary the sample rate and turn on the other channel just to see what I can see via the sniffed USB. I'll post my results and thoughts here, if anyone is interested and the OP doesn't mind the "hijack" of his thread. And if I can how to get the multiport to output, I'll measure the waveforms/sec update rate vs horz time setting, which should be good for a laugh. From the USB timestamps for the above, it was ~ 14 ms between 2 full data packets or ~71 wvfrms/s.

[Gyro]

So sometime this weekend I'll vary the sample rate and turn on the other channel just to see what I can see via the sniffed USB. I'll post my results and thoughts here, if anyone is interested and the OP doesn't mind the "hijack" of his thread. And if I can how to get the multiport to output, I'll measure the waveforms/sec update rate vs horz time setting, which should be good for a laugh. From the USB timestamps for the above, it was ~ 14 ms between 2 full data packets or ~71 wvfrms/s.

Go ahead and hijack  , I don't think anyone has done any USB sniffing yet (one advantage is that the USB connection is slow enough to do it). With the Mac and Linux efforts going on too, all additional info is useful.

P.S. Another line of interest is the documented SCPI protocol interface.

http://www.owon.com.hk/service_down.asp?SortID_1=4&SortID_2=7&seek=&curpage=3

[common_ground]

Is the noise level on the 1022 much higher than the noise on 1022I oscilloscope ( if someone was able to check both ).
Thank you.

[Gyro]

I don't think this is a question that anyone will be able to answer., there are too many variables. The 1022 isn't inherently noisier than the USB isolated version (if you just short the inputs I think the residual noise would be the same). Any additional noise will come from ground loops. The noise induced by a ground loop will be dependent on the test setup, the computer, the length of USB and mains connections, how quiet the mains is etc. The VDS1022I will probably be quieter in some situations by some degree but it is not possible to quantify it so easily.

What the USB isolation mostly brings you is reduced chance of damage to your PC and equipment due to accidentally created ground currents, eg. accidentally shorting a probe ground clip to a high current supply rail (note that it doesn't mean that 'floating' the scope's ground at an elevated voltage is a good idea though).

[krum]

Hello everyone,
I am reading this forum for some time and it is a real pleasure, although probably 80% of the things I am reading, are very distant or not clear to me. I have a little to no electronic experience, but how you guys approach each challenge, is a pleasure to read. 

Because of this, topic I recently purchased an OWON VDS1022I oscilloscope. I intend to learn how to use it for measuring things around my oldtimer (which recently received a brain surgery and now features megasquirt).

I hope my cry for help is on the right place. Today I was testing the oscilloscope for the first time for about 30-40 minutes, then turned it off and after turning it on again, it won't set itself automatically (the big A letter on the top right corner).
The program opens the AutoSetting dialog, the oscilloscope clicks twice and then the AutoSetting dialog stays just forever. The oscilloscope light is green and every few seconds it blinks shortly red.

Has anyone experienced such issue? Would it be possible, that I am not doing anything correct? I already deinstalled and reinstalled everything on my laptop, and also tested the oscilloscope on another laptop.

Thanks in advance for any help you could provide

[Gyro]

Hi krum, welcome to the forum.

You say that the Autoset has stopped working.  Does manual setting of timebase and sensitivity range of the inputs still work correctly? Do you still get sensible traces if you adjust these settings manually? Do all ranges work, AC/DC coupling too.

If it works with manual settings then it sounds unlikely that there is a hardware fault. If you have tested on two different laptops then it probably rules out USB interface problems too (unless both laptops cannot supply enough power to drive the scope, that seems unlikely though). You are using the supplied cable rather than a longer one? If the scope is responding, it seems to rule out driver issues -the S/W would tell you if it couldn't see the scope anyway.

If you see traces in manual mode then I'm wondering if there is something about the signal(s) that is confusing the Auto setup (I don't know maybe large spikes or something). If there is a fault on one of the sensitivity ranges then I suppose that could confuse it too.

The other thing to check is that you are running the latest version of the PC software, which is not necessarily what is on the CD, depending how long the supplier had it in storage. I have vague memory of one of the past updates being to improve autoset functionality.

You can find the latest software on the OWON site: http://www.owon.com.hk/products_info.asp?ProID=175   It's the first thing Owon would tell you to do anyway.

If nothing helps, then it's possible that you have a faulty unit, i which case I would go back to the supplier. Owon might also be able to help based on its behaviour (light pattern etc).

I hope this helps.


P.S. It probably doesn't help right now, but it's a good thing to get into the habit of using the manual settings, based on what you are expecting the signal to be, rather than autoset. It gives to a better 'feel' for a signal not being what it should and you can probably set the scope more optimally by eye too.