OWON VDS1022I Quick Teardown (versus the Hantek 6022be)

[Gyro]

Ah, yes, something mentioned Anthocyanina, and many times previously in the thread, you should definitely try running florentbr's software as an alternative to the supplied Owon s/w. It has many enhancements and shortcuts that make a big difference... https://github.com/florentbr/OWON-VDS1022 Be sure to scroll down the the Requirements section - you need a Java runtime environment installed too.

Another thought is that you could try running the VDS1022 in Spectrum Analyser mode / window. This will allow you to display all of the frequency peaks in the SMPS output noise (ie. look at the output rail in the frequency domain as well as the time domain).

[sx57]

thanks mate i have already tried the florentbr mod but i couldn't change sampling rate.do you think if i learn python i can use the florentbr's python api to change sampling rate?
I used fft if you mean that, one strange thing is that on florentbr version it shows nothing and on the official ver it only works on db but not vrms .any thoughts?

[Gyro]

No, Florent's s/w doesn't allow you to change the sampling rate independent of timebase, it uses the same (most appropriate?) rates as the Owon s/w. Sorry, I'm no expert on python scripts. Maybe you could post a question on his github page. The FFT works fine for me in his s/w, are you sure you have it turned on in the Math (fx) menu entry? I can't think of anything else.

[sx57]

ok mate thanks yes it is on.

[jasonRF]

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.

I have attached a few photos of the board. 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 also have measured the footprint for the through-hole DC-DC converter in case folks are interested, but I am probably not going to upgrade this thing.

Anyway, I have only spent a couple of hours with the scope and it seems to work as advertised.   At least with 1 kHz sinusoids it meets the voltage accuracy spec.  Now I just need to learn SCPI programming, or at least how to use florentbr's API. 

jason

[markone]

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

Gigadevice STM32 clone Inside !

It's time that I wonder if those MCUs are actually illegal or not, probably best choice for rogue states under embargo.

[Gyro]

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.

[jasonRF]

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.

It does look like that part would fit - but it might be close in the height tolerance.  The footprint is actually large enough that it could probably be installed on its side with the leads bent 90 degrees.  I do think I would be more likely to just get an external isolator and perhaps upgrade the converter if needed.   Using one of the cheap USB power meters it looks like mine never draws more than about 300 mA, so the 2W versions should probably be fine. 

Yeah - the price was great, which is the only reason I picked one up just to play with.  I already have a couple of Picoscopes that cover my needs.   Newark also has good prices for their re-branded vds2062/vds3102 ($144/$166 US); too bad they have no features (only 2k FFT, no filtering options, no high-res, no serial decoding, no streaming mode, ...).   

jason

[Gyro]

Yes, from the footprint silkscreen it looks as if the DC-DC is intended to be fitted flat - the pins are on one (that) edge of the package anyway so maybe there is a pre-bent option in volume. The problem with external isolators is finding one with sufficient power rating, most are 1W at most.

Agreed, the VDS1022 is the only one that really matches its price point, and the only one with galvanic isolation available (unless ethernet connected on the higher end ones).


P.S. The reason I hedged on the wattage is that mine is an early one with a switcher rather than the big linear reg (U25?), so it has a lower consumption than some others have reported.

[jasonRF]

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. 

Here is an example Python session that fails using florentbr's API with an error indicating the device isn't present or locked by another application, followed by a few commands showing that the device is connected but that I don't have permissions to use it.  I get the same results whether or not the scope software is up and running, and when it is, whether or not I have opened the SCPI Console.  Likewise, if I do not attempt to use the API but first just try the usb commands I get the same permission error.   After trying all of these variations, I re-tried them when running python as administrator (in case that was the permission error), and it did not make a difference. 

Code: [Select]

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



I have also included a screenshot of the device manager, in case that gives some extra info. 

Thanks!

Jason

[jasonRF]

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

I think (but am not at all sure) that the issue is that the way I was using libusb in python, it was not happy that the Owon software needs to be up and running so Python does not have exclusive ownership.  I take that back.  I am probably misunderstanding something simple and fundamental, since I never was able to get florentbr's API to work.  As I wrote before, my computer/software knowledge and skills are sucky. 

Anyway, I found that using sockets is a pretty easy way to send SCPI commands to the scope.  Of course, the Owon software (or florentbr's improved version) needs to be running, and the scpi console opened up with a successful setting of port 5188. 

Here is code I used to setup the scope to capture a 1 MHz, 564 mV peak-peak sine-wave I generated with a tinySA.  I hard-coded everything for now, just to get it working.

Code: [Select]

# 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()

I have attached plots from both florentbr's version of the software, as well as from this Python script.  So I finally feel like I am up and running, after many hours of banging my head against the wall!  But at least I feel like I learned a lot (have never used sockets or libusb before).

Next up is to control both the scope and a simple arduino/AD9833 function generator to automate Bode plots...

Jason

EDIT: I thought I would share that the device ID gives both the Owon and Multicomp Pro model numbers, along with the serial number that is on the bottom of the physical device.   

Code: [Select]

In [11]: printReply(sendMessage('*IDN?'))
owon,VDS1022,MP7200162133088,V3.0.0
I am not sure what the 'V3.0.0' refers to. 

[tatel]

Hello, thank you all for the information in this thread. I want to ask you a couple of questions.

a) This spec has mistakenly led me to think that the channels were isolated from each other. I guess I did well to check all the information on this oscilloscope before pulling the trigger. I checked the first 10 pages of this thread, now I know this is not the case. So thanks again. I'm wondering what it means:

Channel isolation 50Hz : 100 : 1, 10MHz : 40 : 1

b) Work with the SMPSU. I am aware of the (debated) convenience of using an isolation transformer to float the DUT. And I know the recommendation is to use a differential probe. I'm leaning towards a MicSig DP750-100. However, while reviewing the Testec TT-SI 7002 differential probe, I saw a warning about it "Connect only to a grounded measuring device!". Could you confirm/deny that a differential probe can be used with VDS1022i?

https://www.testec.de/en/products/product-categories/differential-probes/

[Gyro]

Hi,

Yes, as you have found out from the thread, the VDS1022I provides USB isolation, for the purpose of protecting the computer USB port from accidental high current injection and breaking ground loops to reduce noise. It is not intended for elevating the ground clips to a high voltage. As you have found, both channel BNC shells (and the case) are all common.  You can get special purpose scopes with galvanic isolation between individual channels but their price is far greater than the entry level Owon. They will also show isolation voltage limits and appropriate CAT ratings clearly on the front panel.

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


Yes, a high voltage differential probe (or two, if you are using both channels simultaneously to monitor different parts of the circuit) is the safest way to go (at a cost). Differential probes do rely on a defined ground reference for signal integrity (although I think think they would be unlikely to cause a shock risk if floated due to their high common mode imput impedance). The simplest way would be to ground one of the BNC shells (the third 'multi' one for instance) or the ground tag on the 1kHz probe cal output. Isolation transformers are controversial (as you say), they do allow you to bring high potential points of a circuit (live chassis for instance) to ground, but at the expense of getting bitten by other parts of the circuit and defeating RCD type mains shock protection. The general rule for working on high voltage circuitry like SMPSs is know where your grounds are.

If you are wanting to monitor a single differential signal (that is within the voltage limits of the scope probes) one way is to use the 'poor man's' differential setup, where you use both probes. Remove or carefully insulate their ground clips (depending on probes), set the scope to 'Add' and one channel to 'Invert', and ensure that both V/div settings are the same. and use both probe tips. This configuration uses both scope channels as a differential amplifier. The resulting trace will be noisier than a true differential probe but may well get the job done. In this case too, you should ground the scope to prevent it from floating to the mid-point voltage of the two probe inputs (albeit at high impedance).

Finally, if working on higher voltage circuits, it would be wise to invest in some dedicated x10 (or even x100) probes instead of the common switchable x1 /x10 probes, or physically block the switch. It is all too easy to accidentally flip them to X1, damaging the scope input and potentially posing a shock hazard. It's good practice to always use x10, the only exception being low frequency very low level signals where you are trying to squeeze the last drop of sensitivity - again it's too easy to forget to switch them back. Beware of Chinese probe voltage specs and observe the de-rating curve - voltage capability drops off with increasing frequency (that applies to all scope probes). Scopes and probes, unless specialist high voltage models, are typcally CAT I rated.

I hope this helps.

[tatel]

Yep, it does help. Thank you, man

[jasonRF]

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

I have not done a systematic characterization of the crosstalk on my vds1022, but it seems the performance is much better than that spec.  For example, attached is a screenshot showing a 4Vpp 10MHz signal in channel 1, and I cannot see a 10 MHz signal on channel 2 regardless of which vertical scale I select. 

I have seen this exact same spec on a number of different Owon scopes, both benchtop and USB.  Perhaps they re-use the same front-end designs which may result in the same spec, but they may just pick numbers that any reasonable design can easily meet. 

Jason

[Gyro]

Agreed, I've never seen any significant crosstalk. The spec does seem pleasingly pessimistic.

[xmris]

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. 

Got mine last month from CPC Farnell UK, 2021.11.01 v2.3, mine does not have that mod, different PCB traces as you see.

[jasonRF]

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.  My guess is that inside the box it is resampling to the lower rate since it is sufficient for display on a screen, and that it is sending that resampled data when I request it over SCPI.  Perhaps it doesn't even keep the original samples in memory, so this may be the best in can do? 

The behavior when expecting less than 5k samples is easier to understand.  When I am expecting exactly 1k, 2k, or 4k samples (at 500ns/div, 1us/div and 2us/div ), it indeed provides the exact samples I am expecting.  And when I am expecting fewer than 1k samples, it is clearly upsampling in order to send 1k samples,

Has anyone else found this kind of behavior?  Also, do you get the same result using florentbr's API?  I still haven't gotten it to work, since I get permission errors all the time.  I am sure I am using it wrong...

Thanks,

Jason

[jasonRF]

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. 

Attached are a few plots to show what these resampled signals look like.  The one at 100 MS/s ideally should have 4k samples, so no resampling is going on.  The signal looks fine.  The remaining plots are all cases where it has done the resampling from 5k to 4k samples.  The signal looks worse with fewer samples per cycle.  It is weird that there is asymmetric behavior for positive and negative slopes.  To me it almost looks like it is shuffling the order of the samples when the slope is negative...

Do folks see this using florentbr's API?

By the way, I see the same behavior for several signal generators, so it has nothing to do with that.  These plots were made using a BK Precision 4013DDS as the source. 

Jason

edit: sorry for the weird order of the plots.  I cannot figure out how to make plots show up in a desired order with this interface.  I am technologically challenged!

edit2: I just pulled the scope apart and was able to verify that the clock signals to the ADC really are at 100 MHz, so they are not cheating that way. 

edit3: I sent this to Owon to see what they say.  Perhaps there is a firmware update or something that will fix this. 

[jasonRF]

Attached are some measurements of the scope frequency response; the example here is for the 5 mV/div vertical scale with an input of about 16 mV RMS (45 mVpp).  I used a tinySA as the source, which has an output spec of +/- 2dB over 100kHz-350MHz, so these are not high precision measurements.  The setup is:
tinySA->sma cable->sma to bnc adapter->50-Ohm feed-through->scope channel 1 input

I used a python script to automate this, using SCPI for the scope and the simple serial interface that the tinySA supports.  The scope was in the 2us/div setting for these measurements, so sends 4000 raw ADC samples captured at 100MS/s, without any of the resampling or related artifacts I showed in the prior post.  For each frequency I estimated the voltages two ways, 1) using the scope's built-in RMS voltage measurements, and 2) using Fourier analysis on the 4000 raw ADC samples. 

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.  In particular, it looks like at around 100 MHz that there is still ~10 dB of margin for easily seeing this 45 mVpp signal, indicating that with a good x10 probe this scope may be capable of seeing a 150-200 mVpp ~100 MHz signal (aliased down, of course) in the 50 mV/div setting.  A practical reason why I might care is that I like to do discrete audio electronic design, and it is possible to get parasitic oscillations in emitter-followers at these high frequencies (the Art of Electronics X-chapters shows a 2n3904 with 3Vpp oscillation at 90MHz).  This scope is not a very good tool for seeing these things, but it isn't completely blind either. 

This was mostly just me having fun learning to control the scope over scpi, but thought other folks might be interested in seeing the output. 
Jason

 

[indman]

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

[jasonRF]

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

Yes, I know that the bandwidth has been tested over and over by multiple people.  I should have referenced that in my post.   All I was trying to say in that quote is that people shouldn’t grab the -3dB intercept on my plot and think it is an accurate estimate; my signal source has too much amplitude uncertainty (and I did not calibrate it in any way).

Edit: to be more specific, if the tinySA amplitude really had +/- 2dB of error in this measurement, then the curve indicates the 3-dB bandwidth might be between about 25MHz and 60MHz.

Perhaps I am the only one interested in seeing a frequency sweep, even this crude one, but it won’t be the first time someone posts something that very few people care about. 

Jason

[DAIRVINE]

Gyro, right at the first post mentioned oversampling.

Google "oversampling adc for higher resolution"
By oversampling and decimating we should be able to slighly improve the resolution. With various assumptions, but still.
Even simply taking the 5k buffer, average 16 samples we should get to 10 bit.
Ideally this would be done in the FPGA. I assume schematic/firmware/FPGA source is unavailable?

As a PC workaround for a repetitive signal we could take multiple buffers at different (overlapping?) trigger delay times, align and combine them and build a much bigger sample buffer and then as another step improve the resolution.
Is 12 bit by averaging 256 samples or even 14 bit by averaging 4096 samples possible? We may need to calibrate the ADC levels.
Of course this only works on slowly changing signals.

[DAIRVINE]

How can I monitor battery charge/discharge over 24 hours?
Or if not can anyone provide pointers on how modify software?
I know this could be considered logging, but I could do it when I had a picoscope, and I assume the Hantek 6022be could do it. But what I have is a VDS1022i.
This is related to my previous post about improving resolution.
For example capture a frame every second, average and decimate to get nominal 14 bit resolution. Store samples in a buffer that could be scanned like the cheap logic analysers or picoscope.
Ideally as a built in function.
I understand that there are limitations like voltages drifing, ADC  non linearity etc. But I can probably improve voltage stability. The ability to calibrate the ADC might be helpful. For example by charging up a 1000uF  and letting it discharge through scope probe for a known slow signal. Possibly with a negative bias.

[Gyro]

For measuring battery voltage over a 24 hour period, a scope really isn't the tool for the job. As you say, there will inevitably be thermal drift and linearity issues, and while oversampling can increase apparent ADC resolution, trying to extract 14 bits out of an 8 bit ADC is way too optimistic. Pico are pretty good at this and they only manage a couple of extra bits in high resolution mode. I am lucky enough to own one of their old ADC216 native 16 bit low sample rate scopes and would never swap it for a newer one with resolution enhancement. Even that scope has a +/- 1% accuracy spec and thermal drift - fine for high resolution audio measurements but not so good for data logging.

Presumably you have already looked at florentbr's s/w. There are certainly possibilities for sample extraction there, but personally I would be looking at a datalogger rather than a scope. A cheap arduino or Pi Pico will give you a 12 bit native ADC resolution and would be much easier platforms for you to play around with oversampling etc. You could also very easily add on an external SPI high resolution ADC - even an LT 20 bit one, and have full control of reference stability etc. Just my opinion, but that's the direction I would follow for very slow, high resolution measurements.


Edit: Thinking back, you could probably use Scullcom's (6 1/2 digit) Arduino based mV meter project as a basis (massive overkill but fun!) and add logging via the USB virtual seral port...