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.