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.

[awakephd]

I trust your impartiality and I would ask for your rating in 2 ways:
1. Suitability as a first scope. Is the UI too complex and does the OS provide suitable protection for the scope newbie managing aliasing ?
2. For the experienced DSO user.

I don't want to anticipate this because I want to post it in "my" thread, but here it is in brief:
To 1: The user interface of this rigol in particular is a bonus for beginners, you can always fall into the aliasing trap with any scope.
Regarding 2: Experienced users would not buy this scope as their main measuring device, but rather as a second one, the small form factor and the USB supply are an invitation to do so.

Martin, I realize this is an old post - I have just now read through this complete thread, but came back to what you said above. Can you point me to "your post" where you expound on your conclusions? And have these conclusions changed any since you posted this?

[csuhi17]

I think I just managed to brick my 924s.
The point is that out of curiosity I played with the "search" function, if I remember correctly I simply closed it with the x and turned off the scope.

I would turn it on this morning, but it froze at the boot label.
Black background, RIGOL inscription, Run/Stop, channel "1" and "2" buttons light up.
After switching on, you could hear the relays clicking, and the display also darkened a bit while boot, as usual.

I haven't found any hard reset option for this yet.
The fat32 flash drive did not help, there is no help button here.
Does anyone have any ideas on how to fix it?

p.s. never "load last settings" again

[lunix]

I am not exactly sure what you're seeing.  But I thought I had bricked mine (DHO924S) at one time, as it wouldn't start the scope app in Android.  I unplugged everything, and left it overnight (about 10-12 hours). Then it worked again.  I will say, I have never seen such a buggy piece of test equipment.

[lunix]

What are all the indicators at the top of the screen, and why can't I get my Trigger level indicator to work unless Chan 1 is DC-Coupled?

Note the RED, and the empty white inverted triangles at the top of the waveform screen.  What are they?  (I can find nothing about these in the manual)

[csuhi17]

I am not exactly sure what you're seeing. 

I've been seeing this on the display for almost an hour.
Then I'll wait with him to see if it revives you.

Hooray, it worked      , just had to wait a few hours.
This is a bit funny, I think I'll make a couple of backup file images from the memory card. Just in case.

[shapirus]

I think I just managed to brick my 924s.
The point is that out of curiosity I played with the "search" function, if I remember correctly I simply closed it with the x and turned off the scope.

I had something similar once. I think I used zoom function with a large captured buffer, probably something in addition to that. After a restart, it would apparently want to load that last used state (maybe waited for a trigger to happen to fill in that buffer?), and that took ages. But eventually it booted.

[csuhi17]

It could have been something similar with me, I checked how long I could record two channels with it, and left it in the slowest time base.
After I managed to turn this on, I noticed it.
But now for some reason I can't produce the bug.
He might need something else

I didn't manage to push the buttons, it didn't respond to anything, I could only wait.
he came to his senses in about 3-4 hours.

The bugs presented by Slavius are also produced for me, 924s is the latest firmware

[Mechatrommer]

After a restart, it would apparently want to load that last used state (maybe waited for a trigger to happen to fill in that buffer?), and that took ages. But eventually it booted.

that means, last setting is stored somewhere not in sd card. but where? we need to find a way to zero those memory..

[shapirus]

After a restart, it would apparently want to load that last used state (maybe waited for a trigger to happen to fill in that buffer?), and that took ages. But eventually it booted.

that means, last setting is stored somewhere not in sd card. but where? we need to find a way to zero those memory..

How do you come to that conclusion? That still might be so, but I didn't say that I re-flashed the SD card in that instance, so the settings might still be saved on it.

There is some SPI flash chip that stores some information, but I believe it gets overwritten with data stored on the SD card on every boot (there are respective commands in the boot scripts).

[Mechatrommer]

After a restart, it would apparently want to load that last used state (maybe waited for a trigger to happen to fill in that buffer?), and that took ages. But eventually it booted.

that means, last setting is stored somewhere not in sd card. but where? we need to find a way to zero those memory..

How do you come to that conclusion? That still might be so, but I didn't say that I re-flashed the SD card in that instance, so the settings might still be saved on it.

that means, putting back original fw image file in sd card will fix dso bricked issue?

[shapirus]

that means, putting back original fw image file in sd card will fix dso bricked issue?

Potentially. It has yet to be tested.

[Fungus]

After a restart, it would apparently want to load that last used state (maybe waited for a trigger to happen to fill in that buffer?), and that took ages. But eventually it booted.

that means, last setting is stored somewhere not in sd card. but where? we need to find a way to zero those memory..

In the SRAM chip. I assme they don't want to wear the flash out by writing to it after every single twist of a knob.