Rigol DHO804 Test and Compare Thread

[Martin72]

plus extended, surprisingly detailed controls for XY mode, right?

No,
This "Mode" is available in the "Add window" menu under XY - but not in the horizontal menu, where you can only switch XY on or off.
Somewhat stupidly done, if Fungus hadn't shown this, I still wouldn't have known.
Either way, the rigol is ahead of the siglent scopes, because you can't do anything there, you don't even have the split screen with XY and the two channels.
Siglent should change that.

[Martin72]

That's interesting, at least I hadn't noticed that until just now:
In the web server, the screen has a different resolution, 1280x800, as you can see in the two pictures from my previous post.
A direct screenshot saved on a usb stick has the resolution of the installed screen.

[iMo]

I've just been messing around playing youtube videos into the 'scope in XY mode:

How do you modulate (switch on/off, etc) the beam?

[Fungus]

... plus extended, surprisingly detailed controls for XY mode, right?

They're not easy to find.

[Fungus]

I've just been messing around playing youtube videos into the 'scope in XY mode:

How do you modulate (switch on/off, etc) the beam?

I didn't. I just got a wire with a stereo jack plug on the end and played the audio of the Youtube video into my 'scope.

[ebastler]

That's interesting, at least I hadn't noticed that until just now:
In the web server, the screen has a different resolution, 1280x800, as you can see in the two pictures from my previous post.
A direct screenshot saved on a usb stick has the resolution of the installed screen.

But the 1280x800 pictures don't look great -- more blurry fonts and some jagged edges. Looks like they don't get the benefit of proper rendering from scratch (as the scope allegedly does on the external HDMI screen), but are upscaled 1024*600 images?

Edit: Or is it just my browser handling the pictures differently? I have plenty of screen resolution on the computer, so it's not the PC being forced to rescale. How do the 1280*800 captures look to others?

[dmulligan]

Are there any other secret passageways which get unlocked in "Test Mode"?

There are some HDMI settings IIRC.

[Fungus]

Are there any other secret passageways which get unlocked in "Test Mode"?

There are some HDMI settings IIRC.

Yes, that, too... you can set HDMI resolution manually in debug mode.

Normally it reads the monitor's native definition and uses that. I'm not sure why you're want to use other resolutions but I guess that's why it's a "debug" feature.

But the 1280x800 pictures don't look great -- more blurry fonts and some jagged edges.

Yep, I reported that as a bug. 1280x800 is 1000/4000 series screen resolution.

It should be an easy fix, the resolution is hard-coded in the HTML of the web page that it serves up.


(I wonder if I can find/edit that file with ADB  )

Edit: It's buried in "webcontrol.apk" and I don't know how to modify .apk files.

[DaneLaw]

Maybe a DHO owner can specifically confirm or refute this theory by looking at suitable test signals?

This is about the best I could get:

Weird - as it does not look like it has much detail in those inner-modulated signals,- what amount of EXIF metadata do screen dumps from Rigol-scopes contain.?

I wondered if it was the high amount of grading levels, that made the step-grading less pronounced on the DHO800/900 series, and why you see a faster transition to dark on scopes with a low amount of grading levels., like fx scopes with 64-levels - but usually, you can decipher that, if you step a few feet back, and look to see if there are details (depth) in that uniform inner-mass, just with very fine grading/transition from all the grading levels, but that doesn't look to be the case on your example.

On the Micsig it also got pretty high grading levels to the point that it at times can look uniform, but it does carry depth, even signals that at first glance look'ed uniform.
Both in CCT-mode, and in native channel-colors. (256)

- Ch3 with a few grading steps (SG FY6900) picture 5 & 6 are with CCT. (temp)

[KedasProbe]

I compared the signal generator accuracy, set to 10MHz (DHO914S)
Compared to Leo Bodnar mini GPSDO via DG4102 Counter and scope phase change.

Start up about 40Hz too high dropping fast
After about 6 minutes it hits 10MHz exactly
After 10 minutes it's 6 Hz too low
Long time: 16-17Hz too low

It is possible to fine tune the generator setting to hit 10Mhz but doesn't stay there very long. (screenshot)

[Martin72]

Tried it out earlier with the batronix board spi 4-channel(Mosi, Miso, CS,CLK), works very well with the 804.
What is absolutely annoying is this "waveform freeze"...
If you stop the scope, you can't recognize the waveform because it is superimposed.
Freeze off is the solution and it will stay with me permanently.

[Fungus]

What is absolutely annoying is this "waveform freeze"...
If you stop the scope, you can't recognize the waveform because it is superimposed.

Just to be crystal clear for users of other brands: It's a user option.

Freeze off is the solution and it will stay with me permanently.

It depends what you're looking at.

If it's data packets then it's bad. Analog signals? Not so much.

[2N3055]

What is absolutely annoying is this "waveform freeze"...
If you stop the scope, you can't recognize the waveform because it is superimposed.

Just to be crystal clear for users of other brands: It's a user option.

Freeze off is the solution and it will stay with me permanently.

It depends what you're looking at.

If it's data packets then it's bad. Analog signals? Not so much.

It is good that you can shut it off.
It is equally useless for digital and analog signals.

Unless used with persistence. Which is why that option should be in persistence settings.
And should be coupled with persistence, and if persistence is off it should be automatically off.

That is logical, consistent and how it should have been done.
And to make it worse, it is not something that is problem with scope hardware.
Just a poor choice of function grouping and lack of understanding how it should be done.

It is obvious that it was added as an afterthought, probably someone complained and instead of realizing WHY it was wrong and fixing the problem in concept itself, they made a checkbox fix and just planted it somewhere. It is, unfortunately, a consequence of modern software development  practice, of shipping "approximation" of product and counting on fixing it later.
Then a fix is made 1 year later by someone who was not in primary team, and is pretty much given directive "just fix this and close the ticket"...

So you get this "it can do it but you need to know this trick.." kind of result.

But as I said as long as it achieve the task, no matter how illogical it is, I guess it is going to be OK..

But so far, they didn't show any institutional advances to their software process. Brand new platform, same development process so far.

[TurboTom]

The "Freeze" function can be useful if an intensity graded display of an (analog) signal is desired for duocumentation. The legacy instruments had this always enabled, still it didn't bother (me) at all: If one wants the "frozen" trace, press "Stop/Run", if a single scan is desired, press "Single". No function switching required...

[Martin72]

I have now started to display and save the signals from the demo board step by step on the 804.
Then another scope, another one.
And to upload the data sets for comparison.
But first the 804 and then the decoder signals from the board.
This worked quite well, but it is a bit annoying that you can only get back to the decoder menu via the menu button at the bottom left - unless you have activated the table, from there you can go directly to the menu.
A bit confusing and illogical.
RS232, I²C and SPI no problems, but the "parallel decoding" function leaves me somewhat perplexed.
The demoboard provides 8bit in parallel, so I thought, ok, then I'll just decode 4 bit, whatever.
But that didn't work, it was worth a try.
I didn't quite understand the point of the parallel bus decoder.
If you go to the menu, you can first define whether you have a clock and if so, on which channel.
Then which channel the bus is on - Hm?
I'm not a bus expert, but parallel decoding on a single channel sounds strange.
However, you can select one of the four channels under "bus", but there is also "user".
If you select this, you can assign a bit to each channel and specify the bit width (maximum 4, logically).
Otherwise not...

[nctnico]

What is absolutely annoying is this "waveform freeze"...
If you stop the scope, you can't recognize the waveform because it is superimposed.

Just to be crystal clear for users of other brands: It's a user option.

Freeze off is the solution and it will stay with me permanently.

It depends what you're looking at.

If it's data packets then it's bad. Analog signals? Not so much.

It is good that you can shut it off.
It is equally useless for digital and analog signals.

Unless used with persistence. Which is why that option should be in persistence settings.
And should be coupled with persistence, and if persistence is off it should be automatically off.

That is logical, consistent and how it should have been done.
And to make it worse, it is not something that is problem with scope hardware.
Just a poor choice of function grouping and lack of understanding how it should be done.

Let me stop you right there... This is one of the typical situations where a feature is handy or gets in the way. Tektronix DSOs (at least the older ones) operate in this way and that is where Rigol likely copied it from. It can be handy when dealing with slow signals so you can see the difference between the old and the new signal without needing slow or infinite persistence. On the Tektronix scopes you can press one of the channel buttons to make the previous acquisition dissapear.

[ebastler]

I have now started to display and save the signals from the demo board step by step on the 804.

Thanks for these! 

Fungus had found a few days ago that, if one wants the scope to also "look back" beyond the time window visible on-screen, one has to decode from Zoom mode. (In order to decode messages which are not fully shown on screen, but started earlier.) https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5152266/#msg5152266

Reassuringly, your I2C_tab.png screenshot suggests that the decoder always works from deeper memory, not from the screen buffer like in the DS1054Z. It might only look at the time interval visible on-screen, but it can still decode data which are not resolved on the screen. That's good!

[Martin72]

Ah, I think I understand what that means, because until now I thought, ok, it always shows what you can see.
E.g. seven data packets visible, seven data packets are displayed in the table.
But I seem to remember that it wasn't like that with the 1054Z... crap, I already had it in the bag yesterday and then didn't feel like taking it home with me.

[ebastler]

In the situation shown in the I2C_tab.png screenshot, the DS1054Z would not be able to decode anything. As soon as the individual bits are no longer resolvable on-screen, they can't be decoded either.

[Martin72]

Ah, ok.
So a screen-only decoding would not be able to do something like the following picture?
But only when it can be seen in full resolution (second picture), I think I have understood it now.
But only when it can be seen in full resolution (second picture), I think I have understood it now.
The third image shows the same word, but with an additional table.
It's a pity that the value is no longer displayed on the screen, it seems to be compressed when you have a window next to it.

[nctnico]

I have now started to display and save the signals from the demo board step by step on the 804.
Then another scope, another one.

Just wondering: how is the 7" screen in terms of operator comfort?

And does the DHO804 decode full memory or only the part of the signal shown on screen?

[ebastler]

Ah, ok.
So a screen-only decoding would not be able to do something like the following picture?
But only when it can be seen in full resolution (second picture), I think I have understood it now.

Yep, that's right. No way to decode something like your first screenshot on the DS1054Z; you have to zoom in until you can resolve the bits like in the second screenshot. Good to see that the DHO800 does it properly.

I wonder whether (and very much hope that!) there is similar progress in the "measurements" department. Again, the DS1054Z does these from the screen data: As soon as the relevant details are no longer resolved on screen, measurements show wrong values or indicate that they are unable to measure anything ('*****'). Does the DHO800 handle this better?

[ebastler]

And does the DHO804 decode full memory or only the part of the signal shown on screen?

As mentioned earlier (referencing Fungus' findings), it seems to be "ful memory" when you are in Zoom mode, while it's only the part shown on the screen (but with the full resolution from memory!) in normal view.

[nctnico]

And does the DHO804 decode full memory or only the part of the signal shown on screen?

As mentioned earlier (referencing Fungus' findings), it seems to be "ful memory" when you are in Zoom mode, while it's only the part shown on the screen (but with the full resolution from memory!) in normal view.

So basically it decodes only what is on screen which is not full memory.

[Martin72]

How can you determine for sure whether it is from the complete memory?
This is a fundamental question.