EEVblog #1146 - New Low Cost Rigol MSO5000 Oscilloscope

[Fungus]

Dave also showed quite a few problems with serial decoding in a video the other day.

I assume that's one of the things the firmware people are still working on so don't count your chickens until the fat lady sings. 

OTOH: The manual says the event table only shows what's in the area on screen so I'm not expecting full memory decode. I'm more interested in whether it still decodes properly when you zoom out a bit, eg. does it still decode when a byte of serial data is reduced to a couple of pixels on screen? If not, at what point does it start to fail?

(nb. I'm talking about the event table, not the bytes overlaid horizontally on the signal)

[mrpackethead]

I have a logic16 from salae, and its just awesome, comes with heaps of decode protocols, and it does the job *really* well, and its easy to transfer data to a PC for more in depth comparison and manipulation..      Just not sure i need another instrument to do that, and one that does it poorly.     Much more interested in the other features of it.

[Martin72]

The manual says the event table only shows what's in the area on screen so I'm not expecting full memory decode

True.

Manual:

Note: When the source channel of MISO or MOSI is set to "OFF",
information of the data line is not displayed in the data table.

You can turn off both channels ( we use spi without cs) on the WS3024 or SDS1104, as long as the table is on, data will be displayed on this.

Note:
 When you adjust the horizontal time base, the waveform displayed
on the screen will also change, and the total number of lines
containing the decoding information in the event table will also be
changed.

OK, thats the result of my second photo - took a look in the manual after work at home...
I wouldn´t expect that on a scope which can display math functions without the channel on..
Monday the tests will be continued and I will also test spi again for:

I'm more interested in whether it still decodes properly when you zoom out a bit, eg. does it still decode when a byte of serial data is reduced to a couple of pixels on screen? If not, at what point does it start to fail?

[2N3055]

It doesn't decode from screen buffer. I decodes form memory and in hardware at that.
But that statement is being confusingly used here.

Like 0xdeadbeef said, some scopes can be setup to show much less on screen but to sample to the full extent of sample memory. So your screen shows 1 ms of  data, but scope went on and actually was sampling for 100 ms. And you can decode all of it, and when stopped, you can browse data, zoom in and out and all.

Some scopes sample only interval that is is needed for one screen scan. So will be able to show you and decode only screen time worth of data. In which case, if you need more, you don't force memory to sample "after" the screen, but change time base to "see" all the data of interest. Scope will try to keep sample rate as high as possible, so it will expand how much samples it will take. If you have enough memory you can "squish" 100 packets on the screen to the point that you cannot recognize them visually. But they are there in sample memory in full detail,  it will decode them all, and you can then select zoom function and magnify portion of the capture.

To me that is more intuitive "scope like" behaviour.
On the other hand, for data analysis, you think in terms of sample rate and number of samples (which more like Lecroy philosophy, understandable considering their legacy)

I suggest that we stop using phrase "decode from screen" because it's confusing. It's either "decodes from data decimated for screen buffer"(which is bad)  or "this scope decodes only time interval shown on screen", in which case you need to set timebase to put on screen whole extent of data you are interested in.

[tautech]

I wouldn´t expect that on a scope which can display math functions without the channel on..

ON or hidden, it's a feature to be able to hide a trace when it's only needed for trigger or Math purposes.

[nctnico]

Then again, even with HW based decoding it's somewhat inevitable that decoding 20MPoints will take longer than 100kPoints.
Anyway, I guess people who expect the whole memory to be sampled and decoded without any speed impact didn't really get the whole DSO thing.

Sorry but that is nonsense. Even the older Agilent DSO7000 series decode all what is inside the memory. The newer R&S RTM3004 can also decode over 400Mpts (divided over multiple segments) and it doesn't slow down at all while doing that. A scope should be able to decode everything which is inside the memory otherwise the event table (and browsing through it) is useless. You'll lose track of what is what as soon as you are zooming in on a signal (like Martin72 shows). If you ever tried to work with a scope which only decodes what is on screen you'll start pulling your hair quickly. It is utterly inefficient especially with protocols which typically have longer messages like SPI, I2C and CAN.

[0xdeadbeef]

Sorry but that is nonsense.

We'll see about that.

Even the older Agilent DSO7000 series decode all what is inside the memory.

We have two Agilent DSO7000 (from early 200x or so) in the department and they can't even measure (things like frequency, DC) anything else than what is displayed on the screen (when zooming in after a single trigger) which makes them useless for me. So I'd be honestly surprised if they could decode anything offscreen. Then again, there are no options installed there and I wouldn't even bother as I hate these things anyway because of their crippling limitations.

The newer R&S RTM3004 can also decode over 400Mpts (divided over multiple segments) and it doesn't slow down at all while doing that. A scope should be able to decode everything which is inside the memory otherwise the event table (and browsing through it) is useless.

Again, do the math, sampling (and decoding) the full memory would slow down the refresh rate dramatically. Using segmented memory is actually reducing the sample depth per capture, so this is obviously something completely different than filling the whole memory at each trigger point. Note that most scopes behave differently for normal trigger mode, single trigger and special triggers like for segmented memory.

You'll lose track of what is what as soon as you are zooming in on a signal (like Martin72 shows). If you ever tried to work with a scope which only decodes what is on screen you'll start pulling your hair quickly. It is utterly inefficient especially with protocols which typically have longer messages like SPI, I2C and CAN.

If we're talking about zooming in after a single trigger, then we are on one page. Every proper scope should be able to do a measurement on the whole memory that was sampled (even though some Agilents can't).
However, as far as I can tell, this is not what we can see on the screenshots as the sample memory displayed exactly fits the screen in both cases.

Anyway, I'd never voluntarily decode serial protocols with a scope if I don't have to. I use the scope mainly to investigate when I get noise or bit errors and suspect it's a bus collision or whatever. So personally, I wouldn't care so much if only the onscreen message is decoded - as long as I can keep the whole area of interest on the screen.

[nctnico]

Things are not so bad as you might think. I did some extensive testing (including decoding) on various oscilloscopes (*). The big advantage of using an oscilloscope is that it will show you whether the signals are correct in the analog domain. In many cases the cause of a problem in a serial bus has to do with the shape of the waveform. I've seen people being stuck for over 2 weeks because they didn't bother to look at the signals in the analog domain. Just using a logic analyser and lots of head scratching. After hooking up the analog channels the problem was identified in 5 minutes.

*
https://www.eevblog.com/forum/testgear/micsig-to1104-(similar-to-rigol-1104z)/msg1196293/#msg1196293
https://www.eevblog.com/forum/testgear/gw-instek-gds2204e-(200mhz-4-channel-dso)-review/msg855862/#msg855862
https://www.eevblog.com/forum/testgear/rohde-schwarz-rtm3000-review/msg1604185/#msg1604185

edit: deep memory (lots of segments) allows to capture a lot of data and likely to capture a rare event in one measurement (collect data and then analyse). It can take a lot of extra time to do measurements over and over again to capture a rare event.

[Martin72]

We use the spi decoding for debugging/testing, e.g. to make sure the analog environment of our circuits is correct ( supervision/regulation circuits for voltage/current).
And sure, it is for say 90% enough of how the rigol scopes handles the decoding, that´s the reason we got 4 1054Z here.
And after years of using them we find a "bug", if we want to display another signal parallel to the decoding, it sucks up with decoding.
The WS3024 don´t, the SDS1104 too.
This in mind I was curious about the new rigol 5000 - And actually a little bit disappointed in this point.
Although it seems to have a good value for money in general - But further tests are required.
"Big" Display, 500000 Waveforms/s, 8Gs/s, lots of triggerfunctions, lots of math functions..I couldn´t see this on other scopes for the price.
But it seems, it´s another "asian style thing":
We put lot of stuff in, cause we could - and nothing works really 100% fine.
R&S RTB2000 series for example got less stuff - but what they got, it works.

[iMo]

.."Big" Display, 500000 Waveforms/s, 8Gs/s, lots of triggerfunctions, lots of math functions..I couldn´t see this on other scopes for the price.
But it seems, it´s another "asian style thing"

A high time to start an open source o'scope project. HW platform is there. All you need is 2-3 datasheets

[Martin72]

There is already a firmware update since october for the 7000 avaible, curious  as I am, I download it and read the release notes:

     - Auto supports unlocking by passwords
     - Math and Decode support displaying status and type
     - Add HELP menu item in "Utility->System"
     - Add probe ratios: 10000X,20000X,50000X
     - Fixed the problem of wave frozen
     - Fixed the exception of Fast acquisition
     - Fixed the setup saving and loading
     - Fixed the wave exporting and importing
     - Fixed the problem of Measure
     - Fixed the problem of Option uninstalling

No hires-mode, but 10000X Ratio, that´s of course much more important….

[julianhigginson]

oh no!

So, is anyone with one of these able to grab a decent stream of SPI traffic, zoomed out on the screen, and still have it make real sense of the data?

That's one thing I was worried about with serial decoding functionality - that it would "work" like the 1000z's serial decode. That level of serial decode capability would be an example of a dealbreaker for the scope, in my opinion.

[julianhigginson]

I have a logic16 from salae, and its just awesome, comes with heaps of decode protocols, and it does the job *really* well, and its easy to transfer data to a PC for more in depth comparison and manipulation..      Just not sure i need another instrument to do that, and one that does it poorly.     Much more interested in the other features of it.

I tried using a logic 8 earlier this year for checking the drivers I was writing for an SPI ADC and DAC.. both of which ran sample data over the SPI port, too

the software looked slick, but I had big problems because of the fundamentally slow sample rate. Logic 8 can do just 50MS/s when you have 4 channels up! And I was running the SPI pretty fast. OK, so I think, maybe I can try to use the SPI clock to drive the acquisition, at least get a proper sample of the contents of the data channels that way? nope, saleae doesn't do that. 

Also getting it to try and frame in anything other than 8 bits seemed impossible. which made things pretty annoying when I wanted to search for specific 24 bit commands in the decode panel amongst streams of data... and I could only search for single byte values.

I ended up doing a bit of the on-wire data verification by hand, on my scope... which is why I'd like good serial decode on my next scope. :-)

Yes, logic pro 8 would have been a lot more appropriate for my application, because it can sample at 5x the speed... but still, the software seemed a bit limited for something as reliably variable as SPI.

[rsjsouza]

And that's why proper logic analyzers cost real money... Saleae has several drawbacks limited by its hardware.

To me decoding on an oscilloscope is quite convenient, but when you start asking for "infinite" buffers or advanced triggers on such platform, you really need to start considering a proper LA or a very advanced USB oscilloscope (before MrWolf comes after me ).

As other resident experts have said before me, debug the analog domain with analog tools and then move to the digital domain with digital tools.

[Fungus]

Also getting it to try and frame in anything other than 8 bits seemed impossible. which made things pretty annoying when I wanted to search for specific 24 bit commands in the decode panel amongst streams of data... and I could only search for single byte values.

Do you think that seraching for "specific 24 bit commands amongst streams of data" is ever going to be easy/convenient on a device with buttons and twisty knobs?

Wouldn't a mouse/keyboard and large screen make it a lot easier?

[Martin72]

Thinking about a "firmware update wishlist"....


- Hi-Res mode with steps between 0.5 and 3 bits
- Free choosable cutoff frequency by the digital filters (and not depended on the timebase), otherwise they make no sense at the moment
- Decoding with the ability to hide the channels without loosing the data values in the event table
- Turn off the event table by pressing "off" ONLY
- A mode like "disable hardware accelaration mode" like on the WS3024 to display a pwm signal "stable" ( couldn´t describe it better and as I wrote times before, the SDS1104 can do it too)


And to who can I give the wishlist, except Santa.....
Make it any sense to write to rigol....

[nctnico]

Also getting it to try and frame in anything other than 8 bits seemed impossible. which made things pretty annoying when I wanted to search for specific 24 bit commands in the decode panel amongst streams of data... and I could only search for single byte values.

Do you think that seraching for "specific 24 bit commands amongst streams of data" is ever going to be easy/convenient on a device with buttons and twisty knobs?

Wouldn't a mouse/keyboard and large screen make it a lot easier?

Not if you want to see live data. You can always export the messages to a CSV file for off-line analysis. The other way around... not so much. Being able to do everything on one device is just easy and efficient (if it works well).

[julianhigginson]

Do you think that seraching for "specific 24 bit commands amongst streams of data" is ever going to be easy/convenient on a device with buttons and twisty knobs?

Wouldn't a mouse/keyboard and large screen make it a lot easier?

I think with a touch screen, I should be a able to get an on screen keyboard, and use pinch/zoom actions to select data ranges very easily. :-) that's one reason why I liked the idea of this new 5k series scope.

Also, with the saleae I had a mouse and keyboard.. Didn't help much there....

[Martin72]

Make it any sense to write to rigol....

I wrote it to rigol.eu, perhaps I get an answer.

[Martin72]

Today I did some measurements on a dc/ac Inverter 400Hz.
The FFT is quite fast and the peak search function is a nice feature.
But....
Maybe I found a bug:
I know the Signal is exactly 400Hz, the hardware counter shows 400Hz - But the peaksearch table did not:




410Hz ?
Where did it come from….

[Qw3rtzuiop]

Your RBW is too high. Try to lower it.

[Martin72]

Ah, okay, thank You, didn´t respected this.

[TK]

Your RBW is too high. Try to lower it.

RBW says 20Hz... is it high?

[Qw3rtzuiop]

It is too high if you want to measure a peak and care about a deviation of 10 Hz. In general it depends on your requirements.

On most scopes you can increase the RBW by increasing the recorded length -> increase the time base

[TK]

You are right, I did not see the 10Hz deviation.