Rigol scopes serial decoding. - Page 1
Forum section: electronics / testgear

author: H.O
author_rank: Frequent Contributor
timestamp: August 08, 2016, 01:58:20 pm
content: 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.

author: rstofer
author_rank: Super Contributor
timestamp: August 08, 2016, 02:05:53 pm
content: 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.

author: H.O
author_rank: Frequent Contributor
timestamp: August 08, 2016, 03:20:33 pm
content: 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.

author: georges80
author_rank: Frequent Contributor
timestamp: August 08, 2016, 03:26:16 pm
content: 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.

author: H.O
author_rank: Frequent Contributor
timestamp: August 08, 2016, 04:57:08 pm
content: QuoteAbsoultely! 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 08, 2016, 06:28:53 pm
content: 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.

author: H.O
author_rank: Frequent Contributor
timestamp: August 08, 2016, 06:44:33 pm
content: QuoteI 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?

author: metrologist
author_rank: Super Contributor
timestamp: August 08, 2016, 07:07:20 pm
content: 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

author: metrologist
author_rank: Super Contributor
timestamp: August 08, 2016, 07:10:51 pm
content: Oops, I think I copied the wrong thread link... maybe this is the reference?Quote from: marmad on August 08, 2016, 06:56:50 pmFrom here:https://www.eevblog.com/forum/testgear/understanding-entry-level-scopes-(limitations-uses)/msg1000443/#msg1000443

author: hendorog
author_rank: Super Contributor
timestamp: August 08, 2016, 07:20:48 pm
content: I'm picking this one:https://www.eevblog.com/forum/testgear/siglent's-new-product-sds2000x-series/msg994743/#msg994743which seems to show precisely where the problem is for the Owon, and that the Rigol DS2k doesn't have a problem...

author: metrologist
author_rank: Super Contributor
timestamp: August 08, 2016, 07:22:11 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 08, 2016, 07:57:16 pm
content: Quote from: H.O on August 08, 2016, 06:44:33 pmYou start by stating you don't see the problem with only decoding what is on screen. That is what I was responding to.

author: H.O
author_rank: Frequent Contributor
timestamp: August 08, 2016, 08:29:19 pm
content: QuoteBut 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.

author: Muxr
author_rank: Super Contributor
timestamp: August 08, 2016, 08:31:03 pm
content: So I was  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.