-
After this error message, ADB searches for TCP port 5037.
Unfortunately, ADB can no longer find it...
On the PC, it is displayed in the taskbar under USB devices as "MTP".
I'll try again tomorrow.
I probably shouldn't have given up!
Kurt, I think the problem lies on your PC. Do you have another android device to test it with you PC, if not Try run adb from linux or MAC or something else. I had the same problem on my PC when running Windows 11, it stop working and I couldn't find the reason why, so I just boot linux and adb work as it should. it looks like that the MTP protocol take the USB port and stops adb.
I've done some testing.
What I've noticed is that when I run `getprop sys.usb.config....`, it always returns `mtp.adb`
on restart!
It doesn't matter whether I enter `Setprop sys.usb.config mtp` or `none` beforehand.
Something has changed for me too!
After unplugging the USB stick and Wi-Fi adapter.
...but then it hangs at "adb shell".
So far, I've only tested Windows 10 and 11!
-
Same behavior here. I noticed that the memory depth is 4Kpt on the Hantek, but it's 1M on the DOV for the same test. If you change the depth on the DOV to 1K the VRMS is more accurate (see attachment 1). However, this causes some aliasing due to under sampling (see attachment 2). I think there is also some under sampling in your Hantek screenshot but not as severe.
The Hantek's DVM doesn't seem to be linked to the horizontal settings or memory.
I think that's a good thing. It's like a second measurement system.
With the DOV, the automatic RMS measurement and the DVM RMS show the same values.
Look, whether it's 100ms/div or 2ns/div, it makes no difference to the Hantek's DVM.
-
So far, I've only tested Windows 10 and 11!
I'd give Linux a try. -
After this error message, ADB searches for TCP port 5037.
Unfortunately, ADB can no longer find it...
On the PC, it is displayed in the taskbar under USB devices as "MTP".
I'll try again tomorrow.
I probably shouldn't have given up!
Kurt, I think the problem lies on your PC. Do you have another android device to test it with you PC, if not Try run adb from linux or MAC or something else. I had the same problem on my PC when running Windows 11, it stop working and I couldn't find the reason why, so I just boot linux and adb work as it should. it looks like that the MTP protocol take the USB port and stops adb.
I've done some testing.
What I've noticed is that when I run `getprop sys.usb.config....`, it always returns `mtp.adb`
on restart!
It doesn't matter whether I enter `Setprop sys.usb.config mtp` or `none` beforehand.
Something has changed for me too!
After unplugging the USB stick and Wi-Fi adapter.
...but then it hangs at "adb shell".
So far, I've only tested Windows 10 and 11!
Try the following steps:
1) remove USB from scope
2) restart your scope
3) on scope run terminal emulator
4) write setprop sys.usb.config mtp, adb
5) connect usb on scope
6) on PC run adb shell
if step 6 returned no device the the problem is on your PC
-
It's still stuck at the "adb Shell".
I need to take another look at the commands... -
I did it.
Updated to ads822a and firmware version 18....
It wasn't Windows!
MTP played a role. -
The Hantek's DVM doesn't seem to be linked to the horizontal settings or memory.
I think that's a good thing. It's like a second measurement system.
With the DOV, the automatic RMS measurement and the DVM RMS show the same values.
Look, whether it's 100ms/div or 2ns/div, it makes no difference to the Hantek's DVM.
They may be using separate hardware on the Hantek, which is good. On the ADS/DOV the DMM seems to be just a skin. -
I would have already done that.
I'll try resetting it to "None" and then start again... swap the cables... then we'll see... Thanks
Did you activate 'debug mode' on the oscilloscope? -
I would have already done that.
I'll try resetting it to "None" and then start again... swap the cables... then we'll see... Thanks
Did you activate 'debug mode' on the oscilloscope?
Hi
The biggest mistake is stopping midway through.
From me.
It's best if you look at the first command. It should only say "mtp".
Then you can continue...
If not, then write to me again.
-
I would have already done that.
I'll try resetting it to "None" and then start again... swap the cables... then we'll see... Thanks
Did you activate 'debug mode' on the oscilloscope?
Hi
The biggest mistake is stopping midway through.
From me.
It's best if you look at the first command. It should only say "mtp".
Then you can continue...
If not, then write to me again.
I did the process successfully some days ago.
I have looked the process again and the debug mode activation is made through the command setprop. -
I would have already done that.
I'll try resetting it to "None" and then start again... swap the cables... then we'll see... Thanks
Did you activate 'debug mode' on the oscilloscope?
Hi
The biggest mistake is stopping midway through.
From me.
It's best if you look at the first command. It should only say "mtp".
Then you can continue...
If not, then write to me again.
I did the process successfully some days ago.
I have looked the process again and the debug mode activation is made through the command setprop.
Then everything's fine.
It worked for me too. -
Same behavior here. I noticed that the memory depth is 4Kpt on the Hantek, but it's 1M on the DOV for the same test. If you change the depth on the DOV to 1K the VRMS is more accurate (see attachment 1). However, this causes some aliasing due to under sampling (see attachment 2). I think there is also some under sampling in your Hantek screenshot but not as severe.
I experimented some more. The RMS reading seems to start deteriorating at 10ms/div and exponentially degrade at 20ms/div. At 5ms/div and faster horizontal settings the readings seem accurate. The attached screenshots use 10M depth to force a higher sample rate and avoid the aliasing completely. I'm also using Hi Res and the 20MHz filter for less noise.
Attachments a - c: At 5ms/div everything looks OK. However, when I stop the scope and change to 10ms, and then to 20ms, the VRMS and StDev readings start going higher. The Vpp reading is still OK. The CycRms only works at 5ms/div. Since the data points are the same, I would have expected the readings to stay steady.
This made me wonder what would happen if I started out at 20ms/div, and after stopping the scope changed to 10ms/div, then 5ms/div.
Attachments d - f: At 20ms/div and 10ms/div we see the same problems. At 5ms/div, even though this are the same data points captured at 20ms/div, all the readings look OK. Even the CycRms came to life. Since the data points are the same, I would have again expected the readings to stay steady.
For the Measures, this scope has two Horizontal Range modes, Screen or Cursor. For attachments a - f I used Screen. Since at 5ms/div the screen has 90ms worth of data points, and this produces accurate readings, I wondered if limiting the Horizonal Range to 90ms or less using the Cursor mode would have an effect on the 20ms/div and 10ms/dv readings.
Attachments g - i: I don't see a significant difference. Seems that limiting the data points by switching the Measure range to "Cursor Mode" does not provide a workaround for the slow-timebase calculation bug on this scope. In fact, based on these results, I can't tell if the scope's firmware changed the way it calculates the measures. To answer that question, I'll try to set the cursors to a fraction of cycle and post the results next time.
-
Attachments g - i: I don't see a significant difference. Seems that limiting the data points by switching the Measure range to "Cursor Mode" does not provide a workaround for the slow-timebase calculation bug on this scope. In fact, based on these results, I can't tell if the scope's firmware changed the way it calculates the measures. To answer that question, I'll try to set the cursors to a fraction of cycle and post the results next time.
Here I set the horizontal range to a fraction of a cycle. If the cursor delimited range is ignored, I wouldn't expect much change. But surprise! There is significant change, except for the DVM, which evidently always uses the Screen range.
One thing that's not evident in the screenshots is the effect of the horizontal position. By slowly rotating the knob, you can see all the readings (except CycRms) change substantially, as different segments of the cycle become the target of the calculation.
-
If I may, I’d like to return to the hardware modifications Martin showed here:
The feedback capacitor should be chosen proportional to the load capacitance at the output. For "normal" capacitance values, e.g., up to 22 µF, 470 nF are more than enough. However, we also looked at other cases where the load capacitance was increased up to 220 µF. In that situation, it’s advisable to increase the feedback capacitor as well. But it can’t really be much bigger than 4.7 µF, because with 0603 package size you’re getting close to the limits of current technology. These capacitors aren’t exactly the easiest to get either...
https://www.eevblog.com/forum/testgear/voltcraft-dov-series/msg6335724/#msg6335724
I thank him for that visual summary.
However, shouldn't there be a 4.7µF capacitor instead of a 470nF one at position R2437?
SL75 writes about this here, for example:
https://www.eevblog.com/forum/testgear/voltcraft-dov-series/msg6318140/#msg6318140
Or was it ultimately decided that 470nF is sufficient? -
If I may, I’d like to return to the hardware modifications Martin showed here:
The feedback capacitor should be chosen proportional to the load capacitance at the output. For "normal" capacitance values, e.g., up to 22 µF, 470 nF are more than enough. However, we also looked at other cases where the load capacitance was increased up to 220 µF. In that situation, it’s advisable to increase the feedback capacitor as well. But it can’t really be much bigger than 4.7 µF, because with 0603 package size you’re getting close to the limits of current technology. These capacitors aren’t exactly the easiest to get either...
https://www.eevblog.com/forum/testgear/voltcraft-dov-series/msg6335724/#msg6335724
I thank him for that visual summary.
However, shouldn't there be a 4.7µF capacitor instead of a 470nF one at position R2437?
SL75 writes about this here, for example:
https://www.eevblog.com/forum/testgear/voltcraft-dov-series/msg6318140/#msg6318140
Or was it ultimately decided that 470nF is sufficient?
Load capacitance is 4 x 22uF (every channel 22uF), so in summary 88uF.
What capacitance value would you recommend for this case? -
I had no trouble using the 470 nF capacitor in the buffer to drive the 4x22 microfarad capacitors; in fact, it’s actually 6x22, because I used it to buffer all the 2.5 V circuits in the front end (two 22 microfarad capacitors are mounted on the other side of the board).
-
But it can’t really be much bigger than 4.7 µF, because with 0603 package size you’re getting close to the limits of current technology. These capacitors aren’t exactly the easiest to get either...
Well, I ordered some 0603 capacitors from Aliexpress.
I went with the smallest set (only 16 different values), but I think it's a very good selection up to 22μF.
-
But it can’t really be much bigger than 4.7 µF, because with 0603 package size you’re getting close to the limits of current technology. These capacitors aren’t exactly the easiest to get either...
Well, I ordered some 0603 capacitors from Aliexpress.
I went with the smallest set (only 16 different values), but I think it's a very good selection up to 22μF.
I'm a penny pincher.
All used parts soldered together...
-
But it can’t really be much bigger than 4.7 µF, because with 0603 package size you’re getting close to the limits of current technology. These capacitors aren’t exactly the easiest to get either...
Well, I ordered some 0603 capacitors from Aliexpress.
I went with the smallest set (only 16 different values), but I think it's a very good selection up to 22μF.
I'm a penny pincher.
All used parts soldered together...
Me too.
A brand-new 0603 capacitor cost me 1.1 ct. Desoldering it is more expensive.
-
But it can’t really be much bigger than 4.7 µF, because with 0603 package size you’re getting close to the limits of current technology. These capacitors aren’t exactly the easiest to get either...
Well, I ordered some 0603 capacitors from Aliexpress.
I went with the smallest set (only 16 different values), but I think it's a very good selection up to 22μF.
I'm a penny pincher.
All used parts soldered together...
Me too.
A brand-new 0603 capacitor cost me 1.1 ct. Desoldering it is more expensive.
I didn't have to wait, and I've never ordered just one item before.
We already have to pay €3.60 per item, regardless of its value!
New customs fees!
-
Dear Martin and all the other experts who have worked on this oscilloscope,
I would like to hear your opinion on two points.
1. The 70 MHz models (DOV70, 2- and 4-channel versions) are now sold out and impossible to find. They were discussed at length in this thread—you probably know more about them than the manufacturer does.
However, "Conrad" has recently lowered the price of the 100 MHz, 4-channel model (the DOV1004) to just over €300. It is reasonable to assume that this model shares the same flaws as the DOV704, and that as the older stock runs out, they are gradually putting the next models on special offer.
2. Now, however, a version calibrated in a DAkkS-accredited laboratory has appeared in the catalog, with a very near delivery date.
The price difference is significant: the DOV1004 costs over €1,000.
I am not referring to the cost of calibration itself—which can obviously be very high—but I wonder:
Does it make sense to apply this to an oscilloscope with so many fundamental issues? Problems ranging from hum and thermal drift to a cooling system that is clearly too cheap.
Is it the same device? or is it a new series where all the most annoying "bugs" have been fixed?
Is it possible that, to date, there is no information available other than this thread?
Has no one bought other models in the last months? Will people buy the DOV1004 now that it costs just over €300?
Regards, Filippo -
Hi Filippo,
Re 1:
Since the hardware is likely the same, there is a good chance that it is from the same batch as the DOV700 series we purchased, and therefore the same errors can be found in it as well.
Re 2:
As you correctly pointed out, a DAkkS calibration is very expensive and is only of interest to companies that are required to provide proof of such an accredited calibration.
However, they certainly won’t buy a scope like that, so there probably never was an order that would have revealed the errors.
Or rather, the calibration lab wouldn’t really care either, since it depends on the ranges being calibrated.QuoteWill people buy the DOV1004 now that it costs just over €300?
I wouldn't do it.
The 1004 is just a version certified for 100 MHz; the rest is the same, so what I wrote before also applies to this model.
Back when you could get the DOV702 or 704 for €149 or €187, modify the hardware, and finally flash the original firmware onto it, I’d definitely consider it on par with a Rigol DHO800—close, but certainly not better.
At €300, it would be too expensive, and that's the reduced price.
In the case of the DOV1002/4, I would therefore wait and see if Conrad might offer it at an even lower price to clear out its inventory.
-
However, "Conrad" has recently lowered the price of the 100 MHz, 4-channel model (the DOV1004) to just over €300.
But at Conrad italia, it still costs €545.00
https://www.conrad.it/it/p/voltcraft-dov1004-oscilloscopio-digitale-100-mhz-4-canali-1-25-gsa-s-50-mpts-12-bit-memoria-digitale-dso-1-pz-3350784.html
In Italy, I would buy from Batter Fly s.r.l. in Bologna (Rigol, Siglent).
https://www.batterfly.com/shop/de/rigol-dho804
https://www.batterfly.com/shop/de/siglent-sds804x-hd -
Conrads still has over 400 units of the dov1004...
Wait and see, or better yet, buy Rigol or Siglent! -
Hi!
Managed to find the previous firmware version - V1.0.1.8.1
Tried it out; at first glance, all the bugs are still there
But I haven't dug deep yet...
https://drive.google.com/drive/folders/11sV8otCtuEjS0IZY882vEMAyfc3Pkj3Z?usp=sharing