I just picked up the Multicomp Pro MP720016 (rebranded vds1022) at Newark.com for $56 US. I don't need one, but thought it would be fun to play with and the price was right. The isolated model was more than twice as much so I didn't spring for it.
-snip
That's a good price!
They're probably chasing market price and availability with the CPU clone, they've been hit by Chipagedon several times on the FPGA, I see it is a Gowin in that one. The S/W has had to support an increasing list of FPGA images. The front-end and ADC look as they should, even retaining the video sync decoder. I don't know what the wire jumper is, it looks power rail related.
Converting to the Isolated version actually wouldn't be a big deal. U37 is an ADuM3160, you would need to remove (and clean up after) the four 0R resistors under the footprint. The isolated DC-DC footprint has changed. The original used a TI DCP020505 5V - 5V 2W part but the footprint has changed to what looks lile a more comodity through hole part*. It would be easy to attach something suitable onto the through hole footprint, maybe go for 2.5W for a bit of leeway. Apart from that, the larger 0R resistors linking the two ground planes and +5V (R105 and R115) would need to be removed to complete the isolation. Maybe someone with a late model isolated Owon or Multicomp version could identify the DC-DC for you.
Edit: * Maybe a Chinese Mornsun / Tesla B0505S (-2W or -3W) variant from a quick search.
In [1]: from vds1022 import *
In [2]: dev = VDS1022(debug=0)
Traceback (most recent call last):
File "C:\Users\tjm_f\AppData\Local\Temp\ipykernel_6696\630509923.py", line 1, in <module>
dev = VDS1022(debug=0)
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\vds1022\vds1022.py", line 1403, in __init__
raise USBError("USB device %4X:%4X not found or locked by another application." % (
USBError: [Errno None] USB device 5345:1234 not found or locked by another application.
In [3]: import usb.core
In [4]: import usb.util
In [5]: dd = usb.core.find(idVendor=0x5345, idProduct=0x1234)
In [6]: dd.set_configuration()
Traceback (most recent call last):
File "C:\Users\tjm_f\AppData\Local\Temp\ipykernel_6696\2171008298.py", line 1, in <module>
dd.set_configuration()
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\usb\core.py", line 915, in set_configuration
self._ctx.managed_set_configuration(self, configuration)
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\usb\core.py", line 113, in wrapper
return f(self, *args, **kwargs)
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\usb\core.py", line 158, in managed_set_configuration
self.managed_open()
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\usb\core.py", line 113, in wrapper
return f(self, *args, **kwargs)
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\usb\core.py", line 131, in managed_open
self.handle = self.backend.open_device(self.dev)
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\usb\backend\libusb1.py", line 804, in open_device
return _DeviceHandle(dev)
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\usb\backend\libusb1.py", line 652, in __init__
_check(_lib.libusb_open(self.devid, byref(self.handle)))
File "C:\Users\tjm_f\Anaconda3\lib\site-packages\usb\backend\libusb1.py", line 604, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
USBError: [Errno 13] Access denied (insufficient permissions)
In [7]: print(dd)
DEVICE ID 5345:1234 on Bus 001 Address 009 =================
bLength : 0x12 (18 bytes)
bDescriptorType : 0x1 Device
bcdUSB : 0x200 USB 2.0
bDeviceClass : 0x0 Specified at interface
bDeviceSubClass : 0x0
bDeviceProtocol : 0x0
bMaxPacketSize0 : 0x40 (64 bytes)
idVendor : 0x5345
idProduct : 0x1234
bcdDevice : 0x100 Device 1.0
iManufacturer : 0x1 Error Accessing String
iProduct : 0x2 Error Accessing String
iSerialNumber : 0x3 Error Accessing String
bNumConfigurations : 0x1
CONFIGURATION 1: 100 mA ==================================
bLength : 0x9 (9 bytes)
bDescriptorType : 0x2 Configuration
wTotalLength : 0x29 (41 bytes)
bNumInterfaces : 0x1
bConfigurationValue : 0x1
iConfiguration : 0x0
bmAttributes : 0x80 Bus Powered
bMaxPower : 0x32 (100 mA)
INTERFACE 0: Physical ==================================
bLength : 0x9 (9 bytes)
bDescriptorType : 0x4 Interface
bInterfaceNumber : 0x0
bAlternateSetting : 0x0
bNumEndpoints : 0x2
bInterfaceClass : 0x5 Physical
bInterfaceSubClass : 0x0
bInterfaceProtocol : 0x0
iInterface : 0x0
ENDPOINT 0x81: Bulk IN ===============================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x81 IN
bmAttributes : 0x2 Bulk
wMaxPacketSize : 0x40 (64 bytes)
bInterval : 0x20
ENDPOINT 0x1: Bulk OUT ===============================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x1 OUT
bmAttributes : 0x2 Bulk
wMaxPacketSize : 0x40 (64 bytes)
bInterval : 0x20
Hello,
I am trying to learn how to control my MP720016 from python 3 (using Spyder under Windows 10) and am having problems even connecting to it properly. My computer and programming knowledge/skills are pretty poor, so are almost certainly the cause! Any suggestions folks have would be greatly appreciated.
...
# play with sockets for owon vds1022
# everyting hardcoded for now
import socket
import matplotlib.pyplot as plt
import numpy as np
dg = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
dg.connect( (socket.gethostname(),5188))
def sendMessage(mes):
dg.sendto(mes.encode(encoding='utf-8'),(socket.gethostname(),5188))
tmp = dg.recv(200000)
return tmp
def printReply(temp):
print(temp.decode('utf-8'))
# get ID, just for fun
tmp = sendMessage('*IDN?')
printReply(tmp)
# setup channel 1. hardcoded for now
tmp = sendMessage(':TIMebase:SCALe 500ns')
printReply(tmp)
tmp = sendMessage(':CHANnel1:COUPling AC')
printReply(tmp)
tmp = sendMessage(':CHANnel1:PROBe X1')
printReply(tmp)
tmp = sendMessage(':CHANnel1:SCALe 0.1')
printReply(tmp)
# setup trigger
tmp = sendMessage(':TRIGger:TYPE SINGle')
printReply(tmp)
tmp = sendMessage(':TRIGger:MODE AUTO')
printReply(tmp)
tmp = sendMessage(':TRIGger:SINGle EDGE')
printReply(tmp)
tmp = sendMessage(':TRIGger:SINGle:EDGE:SOURce CH1')
printReply(tmp)
tmp = sendMessage(':TRIGger:SINGle:EDGE:SLOPe RISE')
printReply(tmp)
tmp = sendMessage(':TRIGger:SINGle:EDGE:LEVel 0')
printReply(tmp)
# get channel 1 data. Not sure why the first
# call only returns 4 bytes, second returns 1000 bytes, and
# all subsequent give 1004. Everything still hardcoded
dat = sendMessage('*ADC? CH1')
dat = sendMessage('*ADC? CH1')
dat = sendMessage('*ADC? CH1')
# convert data to volts. Note ther are
# nominally 25 counts per division.
rawdat = dat[4:]
volt = np.arange(len(rawdat), dtype=float)
for ii in range(len(rawdat)):
tmpdat = np.double(rawdat[ii])
if tmpdat>125: # voltage is negative
tmpdat = tmpdat -256 # corrected. using 255 is wrong...
volt[ii] = tmpdat * 0.1 / 25.0
t = np.arange(len(rawdat))/100.0e6
plt.plot(t, volt)
dg.close()
In [11]: printReply(sendMessage('*IDN?'))
owon,VDS1022,MP7200162133088,V3.0.0
I am not sure what the 'V3.0.0' refers to.
Channel isolation 50Hz : 100 : 1, 10MHz : 40 : 1
QuoteChannel isolation 50Hz : 100 : 1, 10MHz : 40 : 1
Maybe a bit of Chinese language confusion. This would more commonly be called a 'crosstalk' spec. These are shown on most scope specs (and stereo audio equipment come to that). It is a measure of the rejection of a signal on one channel being visible at an attenuated level on the other trace. This is determined by internal construction - PCB layout, the physical spacing and isolation of sensitive front-end stages, screening cans etc.
It is labeled VDS1022_V2.1, with a date code 2021.07.12, so is slightly older than the board posted by ajlenze. It has a weird hand-soldered wire on the top-side of the board - not sure what that is about.
I have been playing with SCPI control of my MP720016 (rebadged vds1022) using sockets in python, and have found something odd with the sampling that I am hoping someone else already understands.
The short story is that I am only receiving 4k samples when I am expecting 5k. Testing with signals of known frequencies has convinced me that it is resampling the data to 80% of the nominal ADC sample rate.
The first thing that popped out at me when I saw these measurements was just how low the crosstalk is below 100 MHz. Not bad!
Given the shallow slope of the curve and the measurement uncertainties, I don't think we can get a good estimate of the -3 dB point from this curve, but the response above the nominal 25 MHz bandwidth is interesting.
The first thing that popped out at me when I saw these measurements was just how low the crosstalk is below 100 MHz. Not bad!
Given the shallow slope of the curve and the measurement uncertainties, I don't think we can get a good estimate of the -3 dB point from this curve, but the response above the nominal 25 MHz bandwidth is interesting.
Why these difficulties with measurements, if the frequency band for this device has been known for a long time.Anything above 32-34 MHz turns this oscilloscope into a simple indicator?
https://www.eevblog.com/forum/testgear/owon-vds1022i-quick-teardown-(versus-the-hantek-6022be)/msg2771522/#msg2771522