Rigol scopes serial decoding.

[H.O]

There's a lot of fuss about how stupid the Rigol engineers are due to the way they've implemented the serial decode on their scopes and how utterly useless it is. I've certainly complained about it too but the issues I had were actual bugs (ie decoding not working in segemented memory) and this has been fixed for quite some time on the DS4000 with FW 02.02 SP5 which is the scope I've got.

I'm sure they may have implemented it differently on different model so please be aware that it's a DS4000 the following tests have been conducted on. If you have experience with another model and want to comment in this thread, please don't just say "my Rigol" but make sure you include which model it is YOU are talking about.

Right, the main complaint people seem to have is that it only decodes what's on the screen and how utterly stupid and useless that is. Personally I don't know, you can only see what's on the screen anyway and why you'd want to look at hundreds or thousands of bytes on an oscilloscope screen is beyond me. But anyway, to test this I set the timebase to 100ms/div and sent a 735byte long string at 38400baud, at this timebase and baudrate the data easily fits on the screen and DS4000 does decode it. You can't see what it says but it does decode it:



To proove that it does indees decode it lets look at the event table, here scrolled right down to the bottom, 735bytes. I'll admit I haven't looked at each and every byte of the string but I haven't seen it do wrong - doesn't mean it never misses just that I didn't see it during the hour I played with this.



In the following screenshot you can see that we can zoom into the start of the string. Keypoint here is to STOP the scope, if you don't it'll mess up!



Now, what happens when we move the start of the string off the screen? Previosuly I've seen it mess up but that may very well have been due to not stopping the scope prior to "moving around" because now it continues to decode and display what's on the screen. Why do you care if the scope decodes what's not on the screen?



And here it is right up towards the end of the data, still decoding and displaying correctly. I'll admit, when panning around it takes a while (a few 100ms perhaps) for the decoder bubbles to "sync up" to actual waveform but it does seem to work just fine.



And here's a final screenshot (this is from another capture but it doesn't really matter) that shows it working in zoomed timebase mode:



So, what am I trying to say? Well, I'm saying that Rigols implementation of the decoders certainly isn't the fastest and I know there's no advanced search and navigation stuff that's available on higher end scopes but I don't understand what seems to be the main complaint about the decoders only working with what's on the screen. I Think that's a perfectly acceptable compromise.

Again, this may differ on other models so if you're commenting please make sure to say which model and which firmware version you're using.

EDIT: Replaced the screenshot with event table, initially it was the wrong one.
EDIT2: Which messed up the rest of it. So edited again.
EDIT3: Thread moved to correct category.

[rstofer]

I'll try this some time on my 1054Z.  In the meantime, I wonder if you would get a different result if you decoded a long string of SPI.  For RS232, syncing up to the start bit of each individual character is pretty easy and an event is only a few bits long.  A long SPI string would have the CS' going to zero to start the frame occurring a long time back.

[H.O]

Just tried it with SPI, same 735byte long string, it seems to work just fine:



If you look closely at the decoder bubbles there's one place where there seems to be missing a character (the "w" at the end of "how") but this is just because the letter doesn't fit inside the bubble. If you expand it further the data is there and is decoded. Event table is the same as on RS232.

[georges80]

I use the 1054Z for SPI decode. The packets we have are small enough to capture a transaction zoomed out and then we zoom into the area of interest to examine the individual bytes.

It works, but compared to a my home Agilent 2000x the 1054z is like trying to run through cold honey... The 1054z can be very slow to scroll and have the decoder 'catch up', it can also have issues decoding depending on SPI alignment. It's livable for occasional debugging, but I'd hate to rely on it for everyday work.

My summary would be that the results and performance are proportional (not necessarily linearly) when compared (to the cost) with something like the Agilent scopes with hardware decoders.

cheers,
george.

[H.O]

My summary would be that the results and performance are proportional (not necessarily linearly) when compared (to the cost) with something like the Agilent scopes with hardware decoders.

Absoultely! The speed at which even the DS4k decodes is rather slow and I can imagine (but I don't know) the DS1054Z is slower due to less processing power (again, I'm only speculating). For "live" viewing I think I could reliably get 4-5 updates per second (that's the decoder, not the actual trace) and that was under the "best" conditions. But then again there's no real use in it being faster than you're able to see/read anyway. The trace update rate is MUCH faster than the decoder so you're still able to see that the data is changing, it's just the decoder doesn't keep up.

If you want to grab several, tightly spaced, packets and decode them you do that with the segmented memory. It works since the data is processed at display time instead of at acquisition time. (After they fixed it, that is (again on the DS4k, don't know about the 1054Z)

The Agilent/Keysights are blazingly fast with their hardare decoders but they have a (relatively) limited amount of memory. If you set the Keysight 2000x to 100ms/div the fastest it can sample with its 1M of memory is obviously 1Msps. That should still be enough sample to reliably decode 115200 but probably not SPI at 400kHz. The DS4000 on the other hand samples 50 times faster at the same timebase and it's got 40% more "time on the screen".

But then again, who's actually using an oscilloscope to capture and analyze packets of thosands and thousands of bytes? I don't know but since the "decode what's on the screen only" is constantly being brought up as being either a bug or the stupidest implementation ever in "the Rigol" there's got to be a lot of interest in being able to do so. I think I've shown that you can - if you actually want to.

[nctnico]

Try to decode a long I2C, CAN or SPI message with a scope which only decodes what is on screen. Then you'll realise how utterly useless such decoding is. Recently Marmad posted some screendumps which show precisely where the problem is.

[H.O]

Try to decode a long I2C, CAN or SPI message with a scope which only decodes what is on screen.

I thought that was exactly what I did above, RS232 and SPI, 735 bytes long message. Where did I do wrong? Wasn't it long enough, was I just lucky or did I just not set the scope up properly in order to make it fail?

What's utterly useless about what is showed above?

Do you have a link to Marmads thread?

[metrologist]

Marmad is online, so perhaps he is crafting a reply. I think this is it, but not yet sure what is the point of interest:

https://www.eevblog.com/forum/testgear/siglent's-new-product-sds2000x-series/msg994681/#msg994681

[metrologist]

Oops, I think I copied the wrong thread link... maybe this is the reference?

The biggest limitation of the Rigol DS1054Z compared to its bigger DS2000 cousin is bandwidth and sampling rate.

Have you used both DSOs? The DS2000 is about tenfold faster than the DS1000Z (it has a whole separate FPGA for doing post-processing). As someone that has owned the DS2000 for 4 years and then used the DS1000Z for several months, I found it almost unbearable to use for anything other than the simplest waveform viewing. Turn on virtually any extra functions (especially when 4-channels are running) and the response of the DSO drops to a smail's crawl... it's terrible. Unless you need 4-channels almost exclusively (and most people don't: the majority of oscilloscopes produced have been 2 channels), I'd rather own a fast, 2-channel DSO that actually does all of the things it's supposed to do - and does them well
(EDIT: except FFT - Rigoi's uniformly suck at that).

I can give you some examples of what I mean. Rigol's DS1054Z is loaded with features.. and while the main timebase function of the scope generally performs well.. the serial decoding is implemented poorly. Instead of decoding the actual signal the decoder only decodes from the screen's frame buffer. So if the signal isn't the best and your scale isn't adjusted for maximum resolution you will get decoding errors. That's just one example.

Ok, now I'm fairly certain you've never used the DS2000. Yet another big difference you didn't mention (aside from speed): the DS2000's decoding works really well (I use it all the time). It's fast and it decodes the entire memory, not just display memory. It also decodes while in segmented memory, which brings me to another huge difference between the two DSOs: segmented memory. The DS1000Z's implementation is a useless joke (it's basically the same crappy implementation as the old DS1000E series). The DS2000, OTOH, has real segmented memory capture with timestamps and analysis. They are worlds apart.

Almost anyone that has used a DS2000 would then find it (as I did) almost painful to use a DS1000Z. They are not "cousins" - the DS2000 is an adult; the DS1000Z is a child.

From here:
https://www.eevblog.com/forum/testgear/understanding-entry-level-scopes-(limitations-uses)/msg1000443/#msg1000443

[hendorog]

I'm picking this one:
https://www.eevblog.com/forum/testgear/siglent's-new-product-sds2000x-series/msg994743/#msg994743

which seems to show precisely where the problem is for the Owon, and that the Rigol DS2k doesn't have a problem... 

[metrologist]

Bah, that screen didn't load for me the first time, and then I got caught up in reading lots of Marmad's posts. That's the one though.

[nctnico]

Try to decode a long I2C, CAN or SPI message with a scope which only decodes what is on screen.

I thought that was exactly what I did above, RS232 and SPI, 735 bytes long message. Where did I do wrong? Wasn't it long enough, was I just lucky or did I just not set the scope up properly in order to make it fail?

What's utterly useless about what is showed above?

You start by stating you don't see the problem with only decoding what is on screen. That is what I was responding to.

[H.O]

You start by stating you don't see the problem with only decoding what is on screen. That is what I was responding to.

But people constantly claims that "the Rigol" is decoding only what's on the screen. If that IS what mine is doing THEN I don't see the problem with it. If it's not decoding only what's on the screen then it's about time we start to differentiate one "Rigol" from another and not jump to conclusions that just because one model has a certain problem or limitation they all do. No, I'm not pointing any fingers at anyone specific.

I've shown a little bit of what the DS4k can do. That's the scope I own and use. I can't speak of any other Rigol model (or any of the Owons or Insteks or Siglents or whatever) but the idea of the thread was to show that the "genereal perception" of what "the Rigol" can do with its decoders may not be correct in all instances. Marmads screenshots from the other thread seems to indicate that the DS2000 doesn't have an issue either but I'll leave that up to those who actually owns one to say.

*I* don't know how Rigol have implemented the decoders in their firmware, what memory they're working from and so on. But "everybody" is saying "the Rigol" is utterly useless because they're working from the screen buffer. My point is that if they ARE working from the screen buffer then I think they're doing just fine. If they're NOT working from the screen buffer then we need to stop saying they are and differentiate those models that are from those that aren't (if they're different).

This is NOT meant as a Rigol fans vs Rigol haters thread.

[Muxr]

So I was [wrongly] under the impression that DS2k from Rigol used the video frame buffer for decoding. I will do some testing on this to confirm this weekend. But it looks like it is doing it from sample memory.

This image seems to prove it:

Which is the proper way to do it. Obviously it would be nicer if it did the full memory but this is still nice.

My original fear was that it did it from the the video frame buffer in which case it would be susceptible to erroneous readings, but that doesn't seem to be the case (not sure abou the DS1054z? though).

To be honest I haven't used the serial decode much on this scope, I usually use my LA for that (and DS2000 isn't my main scope).. but will do some testing this weekend to confirm these findings.