Rigol DS1074Z Serial Decoding - Page 1
Forum section: electronics / testgear

author: echen1024
author_rank: Super Contributor
timestamp: February 08, 2014, 04:35:52 pm
content: So the one everyone is interested in. How does serial decoding stack up on the DS1074Z? For this price range, it's perfectly acceptable. If you are going to go into the 1500+ category though, an Agilent 2000X with the ASIC is much better.

author: cybermaus
author_rank: Frequent Contributor
timestamp: February 08, 2014, 04:58:32 pm
content: Ah, you used the knob-swap 'hack'.

author: echen1024
author_rank: Super Contributor
timestamp: February 08, 2014, 05:05:43 pm
content: I did, and I really like it!

author: taemun
author_rank: Regular Contributor
timestamp: February 09, 2014, 11:08:34 am
content: Nice description of the Rigol DS1000Z serial decoders.Just a small note: are you able to push the exposure down (ie quicker) on your video camera? The readability of the scope GUI is a little hampered because it's being blown out.

author: echen1024
author_rank: Super Contributor
timestamp: February 09, 2014, 06:21:18 pm
content: Quote from: taemun on February 09, 2014, 11:08:34 amIt's not a camcorder, rather a camera (Canon EOS 6D), so I cannot control these settings live while shooting. I will try next time though.

author: whowe
author_rank: Contributor
timestamp: February 10, 2014, 05:05:55 am
content: Can't see the video.It's really difficult to set a uncommon bit rate (like 70000bps) for serial decoding, even with the "knob-swap" cheat.By the way, since you have a 1074z, can you check this on yours please?https://www.eevblog.com/forum/testgear/strange-behavior-of-hw-counter-of-rigol-ds1074z/

author: cybermaus
author_rank: Frequent Contributor
timestamp: February 10, 2014, 07:17:52 am
content: Just so you are aware: I tried hooking up a USB standard HID keyboard, in the vague hope maybe it would take input from it: It doesn't!Not numerical, no cursors, no Enter, nothing. I guess the best way would be to hook it up through Ethernet and to always have a PC with the client nearby.

author: mrflibble
author_rank: Super Contributor
timestamp: February 10, 2014, 09:16:24 am
content: Quote from: cybermaus on February 10, 2014, 07:17:52 amThe result is not surprising, but worth a try. Would have been cute if it worked. On a somewhat related note, as far as I understand it the DS2000 series uses AD blackfin and the DS1000z series uses freescale i.MX28. Correct? Has anyone checked the firmware or flash content yet to see what kind of OS the DS1074Z etc are running? Might be some fun to be had if it's a rigoled up linux version with some RTOS patches.

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 11, 2014, 06:15:02 am
content: Quote from: echen1024 on February 08, 2014, 04:35:52 pmThanks for taking the time to do another video. I'd only suggest you may want to do a quick dry-run before turning the camera on, just to avoid thosemoments.I had a couple thoughts as i watched it, that I thought I'd share...You commented that the 1000Z was slow handling protocol decodes, because it did so in software. Unlike the Agilents and Tek's that do it in hardware. You're certainly correct about Agilent... they flaunt that advantage constantly, and it's a good one. However, I'm skeptical about the Tek claim. I know for sure their low-end models still do protocol decode in software, but I haven't been following their high-end models for quite some time. They may or may not, but I just took a look at their DPO4000-series, and if they do have hardware decode, they certainly managed to keep it a secret.Then, you also referenced the YouTube video that showed how slow the decoding was on the Rigol, vs. the Tek and Agilent. I guess if you think it makes sense to compare mangos vs. watermelons*, that was an informative video. OTOH, the Rigol was processing28 times as muchsample memory as the Tek, and almost 6x as much data as the Agilent + its hardware decode advantage. So the fact it was slower isn't particularly surprising, or enlightening. I debunked that pile of steaming manurehere.You yourself managed to perpetuate that with your demo. You're examining a 9600-baud serial data stream. So order-of-magnitude, the signal under test is ~100 us/bit cell. Now if I were sampling such a source, I may decide that 10 samples/bit were adequate, or maybe even 100. Especially so if my purpose was to decode it, rather than searching for ns-type glitches. Your choice was... 1 GSa/s (cranked to the max), or100,000 samples per bit cell! To be polite, that wasn't the best choice for the job.And unfortunately, you captured 24M points, because, well, you can.You stated you liked to set it that high because you needed the width (I assume to see a whole string). And yet your entire string rarely displayed more than 60 bits of data (often less, max ~110). Even though that huge 24M could capture a whopping24,000 characters!at a reasonable/generous 100 samples per bit cell.So you set up a demo where, to decode ONE character, the scope has to process 1M samples. Then decoding 11M samples into a string of 11 characters was slow. Shocking, really.Lastly, the whole decode messed up when you slid the trace horizontally on the screen. I found that more interesting than all the rest, and yet, I can't really make too much of it, since you failed to set the Triggering mode to RS232, and left it on RisingEdge.That'll screw up any decoder. So who knows?I think to some extent, when these demos are done casually, they tend to create a negative vibe for the device in question, because they cast them in a bad light. And undeservedly so. I don't think that was your intention, but if I were a newbie looking for a scope, the RS232 decode you showed would have been very disappointing to me.But your conclusion, "I don't think this is something I'd enjoy using on a day to day basis", pretty much put the nail in the coffin. "It screws up, and you can't really save it...". I think the conclusion that many would draw from that is that it's a toy, and not really useful at all.I would have liked to see what the 3 sub-panels for Decoder/Packet/Details looked like, once you had more than one character captured in your 24M samples. And you were on the right track. But you only showed those when there were no 'packets' to display. And then got hung up on the range beeping on the Decode panel, because your 11-char string was short and you twisted the knob too rapidly, and kept hitting the end.Hopefully, this will be taken as constructive criticism. Don't be discouraged. At 15 I was only building Heathkit meters and power supplies, and figuring out Thevenin equivalent circuits.And that was about a hundred years ago.But when you post a video like this, many will be unable to separate deficiencies in the device, from those in the operator. Keep that in mind.--* picture a wheelbarrow race, and the goal is to get the largest # of your items from point A to point B. And you're the guy hauling watermelons. Good luck with that.

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 11, 2014, 06:32:50 am
content: Quote from: echen1024I don't see any 4-channel Agilent 2000X models for $1,500? Or anywhere close.The cheapest I could find was the DSO-X2004A (70 MHz), at $1,900. And their 100 MHz model is over $2,200. (Your DS1074Z has been 'adjusted' to the 100 MHz DS1104Z model, and actually delivers ~160 MHz).So $585, vs. $2,200+? Really? I won't claim the ASIC doesn't help, and Agilents aren't better quality (because they are). But please re-run your RS232 test on the Agilent, and show us the 24M samples you've captured.The Rigol can beat the Agilent on sample depth, with 3-channels tied behind it's back.

author: mrflibble
author_rank: Super Contributor
timestamp: February 11, 2014, 06:56:57 am
content: A redo at 100 Msps and shorter memory depth might be interesting. Also,should you decide to do another video on this, maybe you could show how the segmented memory (if it has any) works in combination with the serial decoding.The scenario for that being, you type something, then wait loooong time, then type some more. It would be interesting to see if segmented memory is working there at all, and if so, how easy it is to navigate through the records.As already mentioned you may want to check the exposure, because the scope GUI is pretty blurry at times. For the rest, keep it up.

author: echen1024
author_rank: Super Contributor
timestamp: February 11, 2014, 03:18:01 pm
content: Quote from: mrflibble on February 11, 2014, 06:56:57 amAh hah! I realized the segmented memory after I publ1is1hed the video. I plan to do a segmented memory capture sometime. I will also tweak my camera settings. Thanks

author: Rigby
author_rank: Super Contributor
timestamp: February 11, 2014, 04:13:21 pm
content: I like this video. It's a bit slow, and you should consider a practice run off-camera or do multiple takes and edit out the mistakes and surprises. You want it to look like you know what's going on, even if you don't. There are lots of videos on YouTube, and I'm more likely to listen to someone who has a video that is at my speed and who knows what's going on.You should work out how exposure works on your camera so that there aren't any surprises when you want the screen to show.Don't rely on autofocus. The scope isn't moving to & from the screen rapidly, so there's no reason to use autofocus. Manually adjust it and don't touch it until you set up for the next shot. Don't move the camera during a shot and focus won't be an issue.We don't, as viewers, need to know when you're about to turn the camera off and we don't need a greeting when you come back. All we see is an edit. There's no goodbye for us, no time away, and no need for a hello, even though you may have been gone for days in between. Record the hello and goodbye clips after you're all done and you know what you've recorded, then put them at the front of the video and at the end.Overall, it's a good video, and there's room for improvement. As an engineer, optimization should be a priority for you anyway, and I expect your videos to become more and more polished pretty quickly. Nicely done.

author: echen1024
author_rank: Super Contributor
timestamp: February 12, 2014, 03:28:17 am
content: Quote from: Rigby on February 11, 2014, 04:13:21 pmThank you! I will put those adjustments into the next video, with the focus only on the screen, where everyone is interested.

author: nagyizee
author_rank: Newbie
timestamp: February 17, 2014, 01:00:39 pm
content: A question to those who used this scope for more serious protocol decoding:Has anybody succeeded to set the DataSrc to "Memory"?(  ->  -> [Decoding1 Configure] ->  )I am asking this because I have a 4Mbps SPI data flow with packets of ~250 bytes, and I would like to decode the whole packet in the Event Table in hexa format.The problem is that I can not change the  to work with the entire sample memory (it is grayed out) and it decodes maximum 70 bytes of data from the on screen trace, if I zoom out to fit more data on screen it will decode junk only.Note that triggering is stopped, sample memory set to 3M samples, signal is clear, can see good details if zoomed.Thanks

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 17, 2014, 01:48:25 pm
content: Quote from: nagyizee on February 17, 2014, 01:00:39 pmI'd be interested in the answer to this as well.My guess is that Rigol originally intended to provide this capability (it's certainly a very logical thing to want), otherwise it wouldn't be in the Src list. But never got around to implementing it in the firmware, and so grayed it out.Never being able to decode anything more than the 700 samples of data on-screenseverelyreduces the value of the decode function. I always "assumed" it could decode whatever you had captured.

author: nagyizee
author_rank: Newbie
timestamp: February 17, 2014, 03:52:23 pm
content: Yes, this confirms my theory that it was a better idea to hack the scope instead of giving money for an option which can not be used for a more serious work.

author: mrflibble
author_rank: Super Contributor
timestamp: February 17, 2014, 03:56:36 pm
content: Quote from: nagyizee on February 17, 2014, 03:52:23 pmNot that I wouldn't hack it when I had one, but I love your rationalization.

author: iDevice
author_rank: Regular Contributor
timestamp: February 17, 2014, 10:32:19 pm
content: I don't know on the 1000Z, but on a 4000 I can sample a very long sequence in memory and decode it in zoom mode.Actually, it's the only way to use the decoders as they stupidly don't work on segmented memory

author: jadew
author_rank: Frequent Contributor
timestamp: February 18, 2014, 01:03:51 am
content: Quote from: Mark_O on February 11, 2014, 06:15:02 amThat's an issue I noticed in my review as well. There seems to be a bug in the firmware because the wave gets corrupted which in return could trigger an error in the decoder.What's also interesting to note is the fact that the decoded data changes (after the wave got corrupted during the scroll), which can only mean that they are decoding the data again and again as you scroll, which could account for the shitty performance or at least the shitty visible performance. There's absolutely no need to re-decode the data if no new acquisition has been made.

author: echen1024
author_rank: Super Contributor
timestamp: February 18, 2014, 01:52:34 am
content: Quote from: iDevice on February 17, 2014, 10:32:19 pmThat's pretty annoying. It would be much more useful IMO.

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 18, 2014, 07:27:19 am
content: Quote from: jadew on February 18, 2014, 01:03:51 amThere is, if they're doing peephole decoding, which must be what they're doing. Every time you make any adjustment, they rescan the Display memory, and re-decode. That way, they never provide any real decode buffer, beyond the short stack they maintain for the Event List view. Which in itself may not even be any longer than what you can fit on one screen.I.e., you can zoom out to the point that you can't read any boxed data from the B1 or B2, but still read the byte stream in the Event List. However, even there, you'll never get more than 70 (say) bytes decoded, because 700 sample bits from the Display memory, with 10 bpb is only 70 (87, at 8 bpb). And at that level, some of the display bits will probably be "corrupted" (down-rendered improperly from multi-samples), so 25-35 'correct' bytes is likely the most one could ever expect in the Event List.

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 18, 2014, 07:34:13 am
content: Quote from: iDevice on February 17, 2014, 10:32:19 pmI asked Rigol Tech Support, and was told that they tested it on their 1000Z, and could not "reproduce the problem". I.e., it should work to decode segmented memory captures (on the 1000Z at least), as long as you're running the current software (00.02.01SP1). They suggested the person with the problem may have been running an older firmware.Of course, they could be confused (language barrier), and I have no 1000Z to test it myself. So perhaps it really doesn't work.EDIT: I will say though that there's no rational reason it would not work on segmented data, since the peephole decoders work on Display memory. They shouldn't carewherethat data came from: continuous capture, segment in a multi-acquisition, reference memory, wherever. They just decode a 700-byte chunk of samples.

author: mrflibble
author_rank: Super Contributor
timestamp: February 18, 2014, 12:06:35 pm
content: Quote from: echen1024 on February 18, 2014, 01:52:34 am@echen1024:Since you have a 1074Z ... did you confirm that indeed the decoding doesn't work on segmented memory? Because not supporting it would be really dumb... Not that it is a make or break feature, but it definitely is on the list of pro/cons that would determine buy this scope vs buy another scope.I also read Mark_O's post, but that "could not reproduce the problem" reply from Chinese support is exceedingly rich in entropy. As in, who the hell knows what that means...So the question remains: does serial (and other) decoding work on segmented memory on the DS1074Z. I tried finding something meaningful in TFM, but no such luck.

author: echen1024
author_rank: Super Contributor
timestamp: February 18, 2014, 01:30:31 pm
content: The scope is packed up for a school project, but that will be finished with Thursday, and I will try it out then.

author: mrflibble
author_rank: Super Contributor
timestamp: February 23, 2014, 02:14:35 am
content: Quote from: echen1024 on February 18, 2014, 01:30:31 pmAny chance to try it yet?

author: Rigby
author_rank: Super Contributor
timestamp: February 23, 2014, 02:51:34 am
content: Quote from: 3roomlab on February 23, 2014, 01:40:26 amFor protocol analysis, a device that is designed as a protocol analyzer first will nearly always outperform a device designed as an oscilloscope first.

author: echen1024
author_rank: Super Contributor
timestamp: February 23, 2014, 03:51:19 am
content: Quote from: Rigby on February 23, 2014, 02:51:34 amWell of course.