Rigol DHO800/900 Oscilloscope Bug Reports + Firmware

[EEVblog]

As requested, this a thread for posting of and discussion of bugs on the Rigol DHO800/900 Oscilloscope, and firmware updates.
No other discussion please, there are other threads for that:
General discussion: https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/

[Martin72]

Thank you Dave.

Here the mentioned posts:

https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5087923/#msg5087923

https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5088133/#msg5088133

It's hard to move and analyze signal.
Or is my scope broken?

Would be good if someone else can test it, with any luck my DHO will arrive this week.

[Serg65536]

This bug is reproducible, and I'm preparing the new video.
1 Set timebase 500ms/div
2 Move the trigger to the start of capture < 10%
3 Do a single capture of some signal
4 Explore the signal, move around, decrease timebase to the limit
5 Return to 1s/div timebase, turn On the Vernier, fine tune timebase, and waveform should dissapear.
(I'm not sure what steps are necessary and what could be omitted).
Old bug report:

[Serg65536]

Here is the new catch of the waveform disappear bug

[Serg65536]

The easy way to reproduce the bug. Rigol DHO804 DHO800 oscilloscope waveform disappear in stop mode:

Press Default, set roll mode OFF, change trigger level to some reasonable level, 500 ms/div, 200 mV/div, do SINGLE waveform capture.
When capture is done, change horizontal to 1 s/div, enable Vernier (press horizontal nob), change horizontal to 1.2, 1.3 s/div.

[Serg65536]

Waveform distortion in stop mode bug. Rigol DHO804 DHO800 oscilloscope
Capture any fast signal with a large memory, stop acquisition, increase the timebase until the artifacts are displayed.

https://youtu.be/WK8EEvo7V-Y

[Serg65536]

The scope has no way to set RTC (and no RTC battery). So the time mark should not be on the screenshots.

[gslick]

The scope has no way to set RTC (and no RTC battery). So the time mark should not be on the screenshots.

Dave has reported that if it is connected to a network it will set the time. I assume it has an NTP client.

https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5074246/#msg5074246

The timezone appears to be hardcoded to Asia/Shanghai. The bug would be that there doesn't appear to be any interface to change the timezone.

[persist.sys.timezone]: [Asia/Shanghai]

https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046544/#msg5046544

[dreamcat4]

yes, but surely it's also valid for the user to want to be able to switch off the date/time code entirely? (since once printed onto as a bitmap image it cannot be removed). for example what if the image file itself still gets written to the disk with correct timestamp - then it is not always strictly needed to be printed directly onto the image?

[gslick]

yes, but surely it's also valid for the user to want to be able to switch off the date/time code entirely? (since once printed onto as a bitmap image it cannot be removed). for example what if the image file itself still gets written to the disk with correct timestamp - then it is not always strictly needed to be printed directly onto the image?

Bugs / Feature Requests:

• Provide an interface to set the local timezone in non-volatile storage.
  
• Never watermark screen captures with the date/time if the date/time has not been set via the network and is not valid.
  
• Provide an interface to turn off the date/time watermark even if the date/time has been set via the network and is valid. Edit: Option to turn off the date/time watermark already exists.
  

[Dacian]

• Provide an interface to turn off the date/time watermark even if the date/time has been set via the network and is valid.
  

There is an option for that.
Here is a screenshot that does not contain the date and time. But I agree it should be off by default.


I can confirm the bug when acquisition is stooped and vertical zoom with vernier is done but I was not able to reproduce the 188.1khz bug so not sure what happens there as that looks fairly strange almost like some hardware defect where memory is corrupted.[/list]

[Fungus]

Here is a screenshot

Cute colors. 

And the multi-windowed display looks really useful,  I can't wait to try that feature.

(where's my 'scope at...?    )

[gslick]

• Provide an interface to turn off the date/time watermark even if the date/time has been set via the network and is valid.
  

There is an option for that.

Maybe this would have been easy to discover if I had one of these to poke around with. I should have RTFM the manual myself anyway.

[mwb1100]

Bugs / Feature Requests:

• Provide an interface to set the local timezone in non-volatile storage.
  
• Never watermark screen captures with the date/time if the date/time has not been set via the network and is not valid.
  
• Provide an interface to turn off the date/time watermark even if the date/time has been set via the network and is valid.
  

Can the date/time be set manually?  No mention in the DHO900 manual, but the DHO1000 manual does have it.  And my understanding is that the DHO900 firmware is very similar to the DHO1000 - why would they remove UI to set the date/time?  From the DHO1000 manual:

Display Date and Time

Click or tap the Show Time on/off switch to turn on/off showing the date and time on the screen. The date is displayed in "yyyy/mm/dd" format, and the time is displayed in "hh:mm:ss" format in the Notification Area at the lower-right corner of the screen. You can set the system date and time so that saved images are marked with the data and time information.

• Date: Click or tap the "Date" input field, then the date setting menu is displayed. The three dials in the menu represent year, month, and day. Set a proper date, then click or tap OK to confirm the date modification. Otherwise, click or tap or any area outside this menu to cancel date modification and exit the menu.

• Time: Click or tap the "Time" input field, then the time setting menu is displayed. The two dials in the menu represent hour and minute. Select the proper hour and minute to set the time. After setup, click or tap OK to confirm the setting.

[gslick]

Can the date/time be set manually?  No mention in the DHO900 manual, but the DHO1000 manual does have it.  And my understanding is that the DHO900 firmware is very similar to the DHO1000 - why would they remove UI to set the date/time?  From the DHO1000 manual:

The DHO1000 has a CR1220 battery next to the Rockchip RK808-D, which has a battery backed RTC.

https://www.flickr.com/photos/eevblog/52452909615/in/album-72177720303155042/

The DHO800/DHO900 do not have a battery to maintain an RTC when powered off. Would you really want to go through the UI to manually set the time every time you power on a DHO800/DHO900? I suppose it wouldn't hurt to leave that UI in, but doubt most people would ever bother using it.

[EEVblog]

The DHO800/DHO900 do not have a battery to maintain an RTC when powered off. Would you really want to go through the UI to manually set the time every time you power on a DHO800/DHO900? I suppose it wouldn't hurt to leave that UI in, but doubt most people would ever bother using it.

If you have ethernet connected then it sets the date and time automatically (Chinese time zone).
But yes, the big time stamp on the screen shot is annoying.

[ddv2005]

Hello,

Today I got DHO924 and tried to decode RS232 output from several esp32 boards. From the one board decoder works fine but from another board do not decode at all. After sometime I found that on the second board signal voltages are 3.3-0.4V but on the first one are 3.3v-0.01V. Then I put -0.4V bias on the probe and it start decode RS232 on the second board. But decoder threshold set to 2.2V and I believe that decoder should work without bias because voltage cross the threshold.

[TurboTom]

What if you enable "Copy Trig" option -- this should set the decoder threshold to the trigger setting.

[2N3055]

What if you enable "Copy Trig" option -- this should set the decoder threshold to the trigger setting.

Tom,
He set threshold to 2.2 V but if signal goes negative it stopped decoding..

[TurboTom]

What if you enable "Copy Trig" option -- this should set the decoder threshold to the trigger setting.

Tom,
He set threshold to 2.2 V but if signal goes negative it stopped decoding..

I understood his reports differently: if the Low signal didn't get close enough to zero, it stopped decoding. My suggestion was just meant to figure out if the manual decoding threshold entry might possibly not work properly (not transfered to an internal variable), and the "copy trig" may have a different effect. It appears to be a bug, anyway.

[Fungus]

Does the threshold work in general?

eg. Does it stop decoding you move it above the top of the signal or make it negative on the working signal.

Edit: Can you drag the threshold voltage up and down with your finger on these? Micsigs can... 

[Fungus]

My suggestion was just meant to figure out if the manual decoding threshold entry might possibly not work properly (not transfered to an internal variable)

Threshold might only be used to decide "high".

"low" might be defined by a fixed value which is close to zero. Yeah, I know it ought to be "not high" but you always have to leave a dead space between the two so it might not be. That's why we make Schmitt triggers in hardware.

Maybe somebody could look at the source code of the RS232 decoder in the APK and see.

(Yes, I know it's not the real source code but it's very close...)

[2N3055]

My suggestion was just meant to figure out if the manual decoding threshold entry might possibly not work properly (not transfered to an internal variable)

Threshold might only be used to decide "high".

"low" might be defined by a fixed value which is close to zero. Yeah, I know it ought to be "not high" but you always have to leave a dead space between the two so it might not be. That's why we make Schmitt triggers in hardware.

Maybe somebody could look at the source code of the RS232 decoder in the APK and see.

(Yes, I know it's not the real source code but it's very close...)

Threshold is threshold.. Above is logical 1, below is logical 0. Everything else is bug. On all decoders there is slight hysteresis in algorithm and that is all. On good decoders you can set hysteresis but usually that is not needed, you would need that only with very noisy signal.

[dreamcat4]

so if that is it, then any such threshold is not in hardware but instead rather like an adjustable software debounce? is that really correct behaviour? because i suppose it can be ok when the input is from an analog channels here. that can be done in scope software without such debounce. yet if the input channels are digital inputs from the la. then this is not the case.

[nctnico]

Disagree with single point threshold. I2C for example has a large noise margin by design. And the same goes for any digital signal; the receiver always has an amount of hysteresis by design. A long time ago I had to debug an I2C bus running at 1kHz with pretty soft edges. The Agilent 7104A couldn't properly decode because the hysteresis was too small. Ideally decoding should use a reasonable amount of hysteresis to make it work most reliable.