Rigol DHO800/900 Oscilloscope Bug Reports + Firmware

[Fungus]

RS232 decoder is very unstable and buggy.
I've checked RS232 decoder on 3 oscilloscopes on one case, where 2 chips communicate (Tx and Rx) on the same wire with very small delay between packets.

Agilent MSO-X3000 easily handles small delay, Rigol MSO5000 decodes Rx and Tx packets fine,
but Rigol HDO804 decodes only 1st packet (request), and completely ignores long second packet (response). Small delay completely ruins it's decoder.

Try turning on zoom mode. It does a full memory decode when you do that.

[maxspb69]

Do you even read questions before writing an answer?

[ebastler]

Do you even read questions before writing an answer?

Looking at the pictures would have been sufficient too.

[Ivan7enych]

The RS232 and other decoders works very stably. The problem is that setting the threshold level in the decoder parameters has an error. Switch the probe to 1:1 mode, set 1:1 probe ratio in the channel settings and make sure that everything works ok.

I know how to use oscilloscopes, threshold level is correct for all data on a screen (see picture). Of course I tried different threshold values in 0-5V range, this Rigol HDO 804 is simply unable to decode middle part of data with any settings, while my other oscilloscopes do that without issues.

I see the problem in small time delay (approximately 1bit length) between request and response data packets - this delay completely puzzles decoder.

[maxspb69]

It's great that you know how to use an oscilloscope! But the oscilloscope firmware contains a bug that was discussed several pages ago. The error is due to the incorrect display of the threshold level. Because of this bug, decoders do not work correctly. The bug does not appear in 1:1 probe ratio.
Which is what I told you about.

[2N3055]

The RS232 and other decoders works very stably. The problem is that setting the threshold level in the decoder parameters has an error. Switch the probe to 1:1 mode, set 1:1 probe ratio in the channel settings and make sure that everything works ok.

I know how to use oscilloscopes, threshold level is correct for all data on a screen (see picture). Of course I tried different threshold values in 0-5V range, this Rigol HDO 804 is simply unable to decode middle part of data with any settings, while my other oscilloscopes do that without issues.

I see the problem in small time delay (approximately 1bit length) between request and response data packets - this delay completely puzzles decoder.

To be honest, that is quite aggressive data sending. 1 bit pause is calling for errors.
At least 2-3 bits time would be more conservative and recommended.

With 1 bit, you can get synchronization errors, UART might start decoding in the middle of the packet and proceed to next half of packet.

I'm not talking about scope here but about your equipment.

If communication is happening close with short cables, might work OK.

Fact that those scopes can decode it right is because their decoders have more intelligence than simple UART hardware.

[ebastler]

To be honest, that is quite aggressive data sending. 1 bit pause is calling for errors.
At least 2-3 bits time would be more conservative and recommended.

With 1 bit, you can get synchronization errors, UART might start decoding in the middle of the packet and proceed to next half of packet.

I'm not talking about scope here but about your equipment.

Hmm, it looked like well more than a single bit time to me in the screenshots. Did I misinterpret the polarity?

And even a single stop bit should be fine for any decoder. After all, that's what a uni-directional RS-232 transmission uses between characters all the time. (Ignoring my old mechanical teletype here, which uses 1.5 stop bits for safe recovery between characters...)

[Fungus]

Do you even read questions before writing an answer?

Looking at the pictures would have been sufficient too.

There's no zoom mode in any of those pictures. When he said "some of it works" I thought it was the partial decode that it does when not zoomed.

What it actually is is that part of the signal doesn't go down to zero.

That's the threshold level bug for sure. Set probe ratio to 1:1 to make it work.

[Ivan7enych]

It's great that you know how to use an oscilloscope! But the oscilloscope firmware contains a bug that was discussed several pages ago. The error is due to the incorrect display of the threshold level. Because of this bug, decoders do not work correctly. The bug does not appear in 1:1 probe ratio.
Which is what I told you about.

Sorry, you're right.
That appears the same bug with threshold. In 1:10 mode decoder starts working with threshold 8V (actual 0.8v?). 1:1 has correct level and correct decoded data.

[2N3055]

To be honest, that is quite aggressive data sending. 1 bit pause is calling for errors.
At least 2-3 bits time would be more conservative and recommended.

With 1 bit, you can get synchronization errors, UART might start decoding in the middle of the packet and proceed to next half of packet.

I'm not talking about scope here but about your equipment.

Hmm, it looked like well more than a single bit time to me in the screenshots. Did I misinterpret the polarity?

And even a single stop bit should be fine for any decoder. After all, that's what a uni-directional RS-232 transmission uses between characters all the time. (Ignoring my old mechanical teletype here, which uses 1.5 stop bits for safe recovery between characters...)

Yeah in theory.. Short cables, low noise environment... but offtopic here, sorry.

[Aleksandr]

What are these hidden functions, especially for DDR?

[shapirus]

DDR: initial address & length. Google lens ftw.

[shapirus]

- "AFE zero" self calibration option spoils calibration results, but the initial state could be restored by pushing original cal files to the scope

I wonder what this "AFE zero" actually does. It does indeed spoil the offset calibration (I didn't test gain after it), and it happens regardless of whether the probes are disconnected or shorted, end result is about the same. But they must be using it at the factory in one way or another, it must be there for a reason. Perhaps.

[norbert.kiszka]

This can be useful (DHO924S):

[ebastler]

This can be useful (DHO924S):

Have you tried it? I understand that the higher resolutions will not give you more actual pixels for the curve display, but will just scale up the 1024*600 picture? Does this cause blur as an interpolation artefact?

[norbert.kiszka]

This can be useful (DHO924S):

Have you tried it? I understand that the higher resolutions will not give you more actual pixels for the curve display, but will just scale up the 1024*600 picture? Does this cause blur as an interpolation artefact?

Currently only one FHD display screen I have is in my laptop. But I have Eizo monotor 1600:1200 with DVI and somewhere I have HDMI->DVI adapter, but where? Also I have old TV with HDMI and even lower resolution - dont remember how low, because I didnt use it for years. I will try it later.

[norbert.kiszka]

BTW. I feel scammed a little bit. FFT sample rate is limited to 50MSa/s :/

[ebastler]

BTW. I feel scammed a little bit. FFT sample rate is limited to 50MSa/s :/

Fortunately that is not the case. The FFT is limited to 1 MPts of data, so if you choose a long record time of 20 ms (for good spectral resolution), the sampling rate will indeed be 1 MPts / 20 ms = 50 MPts/s. But if you switch to a faster time base for the data acquisition, and hence shorter sweep time, the sampling rate will be increased correspondingly.

The FFT limit of 1 MPts is stated clearly in the datasheet, by the way, hence no cheating on Rigol's part there.

[axantas]

This can be useful (DHO924S):

Have you tried it? I understand that the higher resolutions will not give you more actual pixels for the curve display, but will just scale up the 1024*600 picture? Does this cause blur as an interpolation artefact?

This is, what I get on an UHD monitor set to 1600x900. Other resolutions do not display correctly on this DELL thing. UHD is possible as well, but monitor shifts the picture to the left. No higher resolution in this case as well. Interesting: the curves tet more pixelated than the UI.

[ebastler]

UHD is possible as well, but monitor shifts the picture to the left. No higher resolution in this case as well. Interesting: the curves tet more pixelated than the UI.

Yes, that's what I thought. They apparently let Android render the UI at the proper screen resolution, but the trace display is scaled up after the fact from 1024*400, or whatever the net vertical area availale for curves may be.

[bobxyz]

DHO814 with 00.01.02.00.02 firmware (but this has been going on in all the previous versions too)

I can't seem to use a FAT32 formatted USB stick to transfer waveform pictures from the scope to my Windows 10 PC without getting a Windows message of:
  "There's a problem with this drive.  Scan the drive now and fix it."

Scanning finds and repairs the issue.  Turning the scope off before removing the USB stick makes no difference.  Using NTFS format, instead of FAT32, seems to work fine.

To reproduce:
 - FAT32 format the USB stick on Windows, do a safe removal.
 - insert the USB stick into the scope
 - press "Quick" to dump a waveform to the stick
 - count to 10 (not sure it makes a difference) and remove the stick
 - insert the stick into the Windows PC and watch the failure popup show up immediately

Is is just me and my PC setup, or do others have the same problem?

[tautech]

DHO814 with 00.01.02.00.02 firmware (but this has been going on in all the previous versions too)

I can't seem to use a FAT32 formatted USB stick to transfer waveform pictures from the scope to my Windows 10 PC without getting a Windows message of:
  "There's a problem with this drive.  Scan the drive now and fix it."

Scanning finds and repairs the issue.  Turning the scope off before removing the USB stick makes no difference.  Using NTFS format, instead of FAT32, seems to work fine.

To reproduce:
 - FAT32 format the USB stick on Windows, do a safe removal.
 - insert the USB stick into the scope
 - press "Quick" to dump a waveform to the stick
 - count to 10 (not sure it makes a difference) and remove the stick
 - insert the stick into the Windows PC and watch the failure popup show up immediately

Is is just me and my PC setup, or do others have the same problem?

Typical outcome when a device fails to add a timestamp to a saved file.

[norbert.kiszka]

Is is just me and my PC setup, or do others have the same problem?

Im using 256 GB pendrive with FAT and Linux on all my computers. No problems so far.

[mwb1100]

I can't seem to use a FAT32 formatted USB stick to transfer waveform pictures from the scope to my Windows 10 PC without getting a Windows message of:
  "There's a problem with this drive.  Scan the drive now and fix it."

I get this message all the time when moving media from a non-Windows system (linux, cameras, whatever) to Windows.  The likely cause of the message is that the USB stick was unplugged without being properly dismounted.  Apparently Linux sets a dirty bit when a FAT USB is mounted and only cleans it up if you do a proper unmount.  I don't know why NTFS seems to be resistant to this problem (I rarely use NTFS formatted USB sticks).  Maybe it's because NTFS is a journalled file system so it can always roll back to a known good state?

There's no reason to scan the drive for this "problem", however there are a couple caveats:

1. linux does cache a lot of disk writes and won't flush them to physical media until unmounted. I believe that for removable media it flushes writes whenever a file is closed.  But you still should take some care with this.

2. Windows will display that message for a variety of problems, not just this particular problem.  So it's not always a meaningless annoyance.

In practice, I can't remember when I've ever actually run into a problem ignoring the message.

[AceyTech]

This can be useful (DHO924S):

Have you tried it? I understand that the higher resolutions will not give you more actual pixels for the curve display, but will just scale up the 1024*600 picture? Does this cause blur as an interpolation artefact?

From Dave's early discoveries. (This should start where he answers the resolution question)
https://youtu.be/r_BYYgCqScE?si=OWU4W64nf2w_kgHw&t=7

Sorry for the off topic post.