Got the scope back for a bit ... Discovered a couple of humdingers with serial decodes:
- 1) The serial decoders only display results with a limited set of samples in the trace - from reading the settings it's meant to be 2x the display resolution (Which should allow up to 600 bits, ~60 characters, to be decoded on display.) but in reality, from the visual point of transition, it looks more like 1/4 of display resolution - allowing a max of something like seven 10-bit characters. I'm not impressed at all! Poor effort there Rigol.
- 2) The serial decoders auto-disabled when the timebase is set low enough to cause scanning display mode. That's really bad. I thought it was bad that the rolling display mode has no triggering but this also means all slow timebases exclude many of the scopes features!
And to top it off, along with many other similar behaving settings, the setting also doesn't re-enable when moving back to faster timebase.
The workaround, for this particular one, is to do the needed capture at slower timebase then stop acquisition. Then you can zoom in to the trace using the timebase dial. Once past the equivalent of 200ms/div timebase, even though timebase is not relevant when stopped like this, the decoders can be turned on again.
Okay, more rendering problems that can fool the unprepared. And I'm certainly not sure I've got a complete handle on this yet ...
High Res acquisition mode had me a little perplexed right from the start. It doesn't look as clean as I expected. I could also see High Res mode aliasing an awful lot earlier than Normal acquisition mode. This is a tell-tail indicator of what is wrong. High Res mode should combine multiple consecutive samples instead of Averaging mode's combining of multiple consecutive sweeps. The trick is to do this as a rolling window or with decimating feedback on a sample by sample basis, aka digital filters. The trade-off is High Res inherently lowers the low-pass cutoff.
First up, the rendering at screen resolution seems to be done at something like four sample points per pixel, ie: Not using all in-range sample points. This is very cheap, it creates it's own aliasing and throws away a lot of the look of the higher precision. Even Peak mode has this behaviour, albeit to a lesser extent. Rendering of Normal mode is same as Peak. Bad Rigol!
The acquisition of the trace may actually be done correctly but, just like the zig-zag peak-to-peak rendering method, Rigol messed it at the final stage of displaying the results. See attachment - showing a full length trace as a meandering thin line while the zoomed in view shows it's actually a full height 50 Hz trace.
As a bonus, there's something wrong with Channel 4 selection. There is no relay clicking sound when toggling Ch4 on/off. As if it's always on. Solved, I had channel 4 set for triggering. Oops.
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
There is also no effect on the Sin(x)/x setting either, this setting is forced on when a single channel is on but defaults to off with multiples channels sampling. That is, except for Ch4. I can have Ch4 on with any other single channel and the Sin(x)/x setting stays forced on. As if it doesn't exist. I still don't understand Sin(x)/x but this one is now consistent at least. It actually seems to need three channels on before allowing a setting.