Rigol DHO800/900 Oscilloscope Bug Reports + Firmware

[Mechatrommer]

FW is 01.02.00.02.. i'm trying to feed 0.5Vpp 5MHz sine (RigolDS1.png) to get long memory 10Mpts capture @ 31.25MSps Peak Detect mode (RigolDS2.png)... hit "Single" trigger button (RigolDS3.png)... when triggered, dso will stop capturing.. dial back to 100ns/div, what a fucked up capture (RigolDS4.png). the workaround, need to do it in Normal mode, not Peak detect (RigolDS5.png), WTF?

edited: this is not a bug, this is a trap for young player... this is supposed to be this way
https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5454092/#msg5454092

[shapirus]

Apparently it just fails to interpolate the samples at this sampling rate. Or, rather, it just uses linear interpolation, hence the jagged edges. With Normal acquisition it needs it to be at least 5 times the signal frequency so that the zoomed in result stays barely acceptable (anything lower, and it becomes heavily aliased), and any mode other than Normal requires an even higher sampling rate to signal frequency ratio.

It's a shame it doesn't have Dot display mode, it could be helpful in this scenario, at least to have a better understanding of what's going on.

[Mechatrommer]

Apparently it just fails to interpolate the samples at this sampling rate.

looking at samples distance (sharp edge to edge the same between RigolDS4.png and RigolDS5.png) its not interpolation issue, its a fucked up averaging (if anything oversampled Peak detect) or sometype bit overflow or simply misplaced y value or whatever. i noticed this when downloading data to PC, i thought my PC app got bug, but it turned out from dso.

[shapirus]

looking at samples distance (sharp edge to edge the same between RigolDS4.png and RigolDS5.png) its not interpolation issue, its a fucked up averaging (if anything oversampled Peak detect) or sometype bit overflow or simply misplaced y value or whatever. i noticed this when downloading data to PC, i thought my PC app got bug, but it turned out from dso.

Well, the samples are spaced exactly as they are supposed to be at this sampling rate: 32 ns per sample:
(in this case a 10 MHz input signal was captured)




It's an aliasing issue all right, zoom out and you can clearly see it:




The same can be reproduced in Normal acquisition mode, it just needs the sampling rate to be even lower to manifest itself.

Here's a 10 MHz signal captured at 6.25 Msa/s in Normal mode:




I think Peak (or Average for that matter) acquisition just needs more samples per second to work properly compared to Normal. The issues related to the insufficient sampling rate simply manifest themselves earlier in acquisition modes other than Normal.

And it's clearly using linear interpolation, regardless of the acquisition mode, when acquisition is stopped and the captured buffer is zoomed in.

[shapirus]

But yeah, Peak mode is doing some weird stuff. Probably that's just the way the algorithm works.

Here's a 10 MHz signal captured at 165.25 Msa/s (6 ns per sample), Peak acquisition mode:




The original waveform can be guessed, but hey, what are those jagged peaks (spaced exactly 6 ns apart!), which are by the way seen only on the rising slope? Clearly they are some artifacts of Peak mode.

Sounds like it requires the sampling rate to be way higher than the signal frequency, or maybe it's not suitable for zooming in at all. After all, it needs to capture multiple waveforms to do the math and detect the peaks. Probably there are more hints in the manual that can give insights on how it actually works and why this happens.

[Mechatrommer]

It's an aliasing issue all right, zoom out and you can clearly see it:

you are comparing apple to orange... you are testing very close to nyquist limit (only 3 samples per cycle) and sinc interpolation is OFF during stopped mode is adding spice to the injury. i carefully did any test to avoid such limit. my case 5MHz @ 31.25MSps (6 points per cycle) is not aliasing issue.

But yeah, Peak mode is doing some weird stuff.

ditto!

Probably that's just the way the algorithm works.

no, thats not how the algorithm works.

The original waveform can be guessed, but hey, what are those jagged peaks (spaced exactly 6 ns apart!), which are by the way seen only on the rising slope? Clearly they are some artifacts of Peak mode.

i did captures much earlier with jagged wave, i thought its the noise in background, but now it become suspect of flawed algorithm.. attached is my capture downloaded to PC much earlier.. granted signal noise is about 10mVpp (about right in display) but my noise is occuring every 500KHz (smps switching), looking closely, the jagged wave is 15MHz (half sampling rate), not my noise!..

[gf]

Peak mode is not expected to result in "reconstructible" samples (according to the Shannon-Nyquist sampling theorem).

It has a completely different aim: Don't miss narrow spikes (narrower than the sampling interval) even if you capture at a low sample rate. In order to achieve this aim, it is usually supposed to record two values per sample, (a) maximum value and (b) minimum value of the signal within the sampling interval.

Don't use peak mode if the signal is bandwidth limited to < fs/2 and if you want to be able reconstruct the continuous signal from the samples.

[Mechatrommer]

that probably explained that... but iirc i didnt notice such issue on DS1054Z, maybe i'll try again on DS1054Z to verify that theory...

[gf]

This naturally raises the question of how to visualize it? I could imagine:

1) display only the minimum
2) display only the maximum
3) display the average between minimum and maximum
4) display a vertical error bar at each sample which celarly shows the min...max range
etc.

Personally, I'd prefer (4).
The screenshots look to me like the points of the trace alternate between min and max values (but I could be wrong).

[Mechatrommer]

In order to achieve this aim, it is usually supposed to record two values per sample, (a) maximum value and (b) minimum value of the signal within the sampling interval.

its confirmed the same in DS1054Z, i just didnt aware, i took Normal Acq for granted.. so its not a bug, its a trap for young player i guess i should set to Normal Acq for my purpose posted earlier. (i edited my post above)

[Mechatrommer]

another bug... not sure if its already been reported... dso doesnt save and load all previous setting correctly upon power cycle. CH vertical scale can be reloaded correctly, but memory depth and CH visibility etc, reverted back to whatever dso think is default.

RigolDS0.png: i set only CH4 visible, 10Mpts memory length
RigolDS1.png: after switch OFF and ON again, CH1 becomes visible and memory length goes back down to 1Mpts.

[Fungus]

another bug... not sure if its already been reported... dso doesnt save and load all previous setting correctly upon power cycle.

Yes, it has.

[Slavius]

I am transferring the found bugs or flaws in the firmware of the Rigol DHO800-900 oscilloscope to this topic.

1) The first Bug is that there is a certain phase shift at a frequency of 70 MHz, between two channels (20 degrees or about 800 picoseconds), namely in the following combinations:

a) 1 + 2 (synchronization on 1 or 2 channels)


b) 1 + 3 (synchronization on 1 or 3 channel)


c) 1 + 4 (synchronization on 1 or 4 channel)


d) 2 + 3 (synchronization on 2 or 3 channel)
e) 2 + 4 (synchronization on 2 or 4 channel)
f) 3 + 4 (synchronization on 3 or 4 channel)

When channels are turned on in such combinations, there is no phase shift, or within acceptable limits = 1 degrees or about 50 picoseconds:
a) 2 + 3 (synchronization on 1 or 4 channels)
b) 2 + 4 (synchronization on 1 or 3 channel)
c) 3 + 4 (synchronization on 1 or 2 channels)
d) 2 + 3 + 4 (synchronization on 1 or 2 or 3 or 4 channels)
e) 1 + 2 + 3 (synchronization on 1 or 2 or 3 or 4 channels)


f) 1 + 2 + 3 + 4 (synchronization on 1 or 2 or 3 or 4 channels)


Any types of calibration do not give anything, I tried different combinations in the extended “SelfCal” menu item, except for the “ADC Phase” calibration item, since this is the second bug, which is described below.

2) The second Bug is that the "ADC Phase" calibration ends with the error "Unknown error occurred while calibrating"




I think that this is precisely the calibration with which the phase shift of the channels is calibrated.

Does anyone know how to calibrate "ADC Phase"?
Please share your information as I haven't found anything yet...
3) The third Bug or simply a low-quality trigger of the “Edge” type is that when you turn on the Coupling trigger function - “AC”, the sine wave (from 10 to 70 MHz) becomes unstable and trembles (jitter) in the horizontal plane within 3 nanoseconds, and the "Holdoff" setting doesn't help. Perhaps the OWON DGE2070 Generator is to blame, I would like you to check this on your oscilloscopes too.


p.s.
Measurements were carried out using:
- The Rigol DHO804 oscilloscope itself (with unlocked options 50 Mgpt and a frequency of 100 MHz) latest firmware v00.01.02.00.02
Warmed up within an hour. Calibrated with different combinations, no difference.
- Original probes from the PVP3150 kit (at 150 MHz) in position X10.
- The OWON DGE2070 generator is configured for output frequency = sine 70 MHz and output voltage = 3.5 Vpp. Connected via the supplied coaxial cable bayonet - crocodiles.
- The oscilloscope probes (I connected two together and three and four, they only affect the signal range) are connected to the coaxial cable with crocodile clips at one point parallel to the signal terminal and parallel to the ground terminal.