Implement your own protocol decoding module on Rigol scope - Page 1
Forum section: electronics / testgear

author: pascal_sweden
author_rank: Super Contributor
timestamp: January 16, 2014, 12:06:54 pm
content: Is it possible to implement your own protocol decoding module on Rigol scope?I have seen that some people are working on open source project for Rigol scope, but this seems for the DS1000 series, and not specifically related to protocol decoding.Would be cool if you can implement your own protocol decoding module for the Rigol DS2000/DS4000 series.I am thinking about some vending protocols, e.g. MDB (Multi-Drop Bus protocol), DEX (Direct EXchange protocol), Executive, etc.Seems like a nice challenge!Note that the decoding module should work on 2 Channels in parallel, to double check e.g. the timing between the Master and the Slave on the MDB bus.Are there any commercial Rigol decoding options that use 2 Input channels on the scope? Or is all decoding always done on 1 channel?Sometimes you need 2 channels.

author: neslekkim
author_rank: Super Contributor
timestamp: January 16, 2014, 01:06:02 pm
content: wouldnt it be better to do this on an logic analyzer that is made for this?, for instance an Saleae Logic?

author: marmad
author_rank: Super Contributor
timestamp: January 16, 2014, 03:18:41 pm
content: Quote from: pascal_sweden on January 16, 2014, 12:06:54 pmNo - not in real-time. You can't get the samples out of the scope fast enough. You can, of course, do protocol decoding on the captured samples later - but not while the DSO is running.

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 17, 2014, 12:17:03 am
content: Quote from: pascal_sweden on January 16, 2014, 12:06:54 pmSure. The built-in decoder for I2Crequires2 channels (SDA and SCL). It won't run on one. And SPI needs 2 channels (out of 4), to decode half the comm link. CAN can use 2 channels as well (the differential signals CAN_H and CAN_L), or just decode from a single channel (with less noise immunity).Serial decoding is actually rarely done (properly), on a single channel.

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 17, 2014, 12:23:34 am
content: Quote from: marmad on January 16, 2014, 03:18:41 pmI was wondering if there was a (slower) speed where you could actually do this in real time? I.e., I don't recall all the details, but I remember you described the comms from the DS2000 as being double-buffered, where the scope had a secondary buffer it dumped data into for transfers, and the actual transfers were asynchronous. So you initiated them, and they ran at a high speed while data was available, and you monitored the status to know when it was complete. IIRC, the transfers themselves ran somewhere on the order of 400 kB/sec(?), though I may have that wrong.Would it be possible to continuously initiate those transfers, back-to-back, for data at a slow enough sample rate?

author: pascal_sweden
author_rank: Super Contributor
timestamp: January 17, 2014, 08:10:58 am
content: But I wanted to implement it in the GUI of the Scope, not sending it out to a computer.Would it then be possible to do it in real-time?Any link to open source project for Rigol where they do their own implementation for a new decode option in the Rigol GUI?

author: neslekkim
author_rank: Super Contributor
timestamp: January 17, 2014, 08:13:17 am
content: check this, it's for the ds1052e, maybe one day one could make opensource code for the whole scope?http://rigol.codenaschen.de/index.php/Main_Page

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 17, 2014, 08:33:32 am
content: Quote from: neslekkim on January 17, 2014, 08:13:17 amCheck what?

author: neslekkim
author_rank: Super Contributor
timestamp: January 17, 2014, 08:42:24 am
content: Quote from: Mark_O on January 17, 2014, 08:33:32 amSomething ate the url

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 17, 2014, 11:48:54 am
content: Quote from: pascal_sweden on January 17, 2014, 08:10:58 amYes, of course. At least as real-time as Rigol is currently doing it. I had no idea you were proficient in Blackfin programming. That's a fairly esoteric skill.QuoteYou're dreaming. The only "open source" project for any Rigol that I'm aware of is the one that neslekkim linked to (for the 1052E). That one was started over 2 years ago, still has no source code disassembled, and has nothing for any protocol decoding.But please feel free to start one! I anxiously await your contribution. I'd like to see CAN on the 1000Z.

author: marmad
author_rank: Super Contributor
timestamp: January 17, 2014, 01:50:12 pm
content: Quote from: pascal_sweden on January 17, 2014, 08:10:58 amQuote from: Mark_O on January 17, 2014, 12:23:34 amWow, a lot of dreaming going on here!It doesn't seem to cross anyone's mind that this is NOT what DSOs are designed to do in any way. The computer interfaces they have (if any) are for remote control and POST-processing of data. If you want to write protocol decoders, do it for a logic analyzer - lots of possibilities there - and that's what they're designed for.@Mark_O:I think those numbers you're referring to are from when the DS2000 is stopped and transferring sample memory, but they're nothing like that when the DSO is running (and using it's sample memory). During that time, you can accessdisplaymemory at the maximum polling rate of ~60 wfrm/s (for a single channel) - but the amount of new waveforms you get out of that ~60 (as opposed to just the same copy of display memory as before) is something like 12-15 waveforms a second. Not quite enough for real-time decoding, eh?ADDENDUM:At >=5ms/div, the number of wfrm/s you can grab from the DS2000 starts to get close to the update rate on the DSO screen - but the DSO can do that with 14M. So, for example, @5ms/div, that's 5ns between samples for the DSO - and 100us between samples for the PC. So maybe it's slightly possible to decode something with a baud rate < 10k - if you can manage to time-correlate your waveforms from the DSO... but, IMO, the effort would be much better spent somewhere else

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 17, 2014, 09:21:37 pm
content: Quote from: marmad on January 17, 2014, 01:50:12 pmOh, that definitely crossed my mind.And I wouldn't have even asked at all, knowing that acquisition and data transfer are normally alternating, synchronous processes (not overlappable). However, your earlier comments about how the DS2000 runs differently than the 1000Z (different SCPI commands available for initiating a transfer, then polling for status) and that the DS2000 has a (unique?) secondary data transfer buffer for offloading data, got me wondering if acquisition and transfers might be overlappable.[and in sweden_pascal's case, he didn't want to offload the data at all... just process it on-board.]QuoteSure, but if Rigol has added new capabilities not normally seen, who knows what might be possible, unless you explore it?QuoteThanks for all the analysis. I don't disagree.

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 17, 2014, 09:27:23 pm
content: Quote from: marmad on January 17, 2014, 01:50:12 pmI missed this one. That may well be true on the DS2000 (and other newer Rigol series). But Werner found on the older DS1000C/CD/E/D series that SCPI sample transfer rates ran ~3x faster in Run mode than in Stop mode (over on the RCGroups forum, about 4 years ago). An anomaly I don't believe we ever found an explanation for.

author: marmad
author_rank: Super Contributor
timestamp: January 17, 2014, 09:43:36 pm
content: Quote from: Mark_O on January 17, 2014, 09:21:37 pmThe DS2000 and DS1000Z have slightly different command sequences for transferringsamplememory - i.e. the massive amounts of memory (depending on the sample length) that are accessible when they're stopped. The same commands (and the same commands from the DS1000 series before them) for transferring the 1400 bytes (1200 for the Z / 600 for the DS1) of display memory while the DSO is running.Quote from: Mark_O on January 17, 2014, 09:27:23 pmThe buffering/SCPI interface is a mess on the DS1000 series. I had the DSO for a couple weeks and my software was causing disturbances in the refresh of the display by pulling measurement data out of the scope too quickly (the video of the flickering and software used to cause it is in another thread I started here). Rigol claimed that they would fix it in the next FW release - but I didn't want to wait indefinitely (and I didn't like the tiny display anyway), so I returned it.

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 17, 2014, 11:21:21 pm
content: Quote from: marmad on January 17, 2014, 09:43:36 pmYes, and what would be the purpose of creating that level of incompatibility, within their own product lineup?QuoteA wise man.

author: pascal_sweden
author_rank: Super Contributor
timestamp: October 25, 2014, 10:33:06 pm
content: Quote from: pascal_sweden on January 17, 2014, 08:10:58 amSo nobody has ever done this before, to add his own new protocol decoding module to the Rigol scope itself? It would be nice if they open this up through some kind of API, in the sigrok style.It would open up a new market, where people could develop a new decoder module and sell it commercially through Rigol or its distributors

author: Mark_O
author_rank: Frequent Contributor
timestamp: October 26, 2014, 01:46:41 am
content: Quote from: pascal_sweden on October 25, 2014, 10:33:06 pmNo, they never have.QuoteYou really have no clue at all of what would be involved to do what you're suggesting. And how little it would benefit Rigol.[another Notify shut off.]

author: pascal_sweden
author_rank: Super Contributor
timestamp: October 26, 2014, 03:51:10 pm
content: If sigrok can do it, it can be done.Most likely they have an internal SDK for this at Rigol, that provides similar features as the sigrok framework.Benefit to Rigol: wider decoder support leading to increased popularity on scopes, indirect marketing, etc.They could even sell this as a separate product: Rigol SDK for building your own decoder module.Some people already had the ambition to build their own applications for the Rigol DS1052E scope:http://rigolwiki.codenaschen.de/index.php/Main_PageOn that project website they have suggested a protocol analyzer as future work.So these people also have no clue of what they are doing you are saying??

author: marmad
author_rank: Super Contributor
timestamp: October 26, 2014, 05:50:58 pm
content: Quote from: pascal_sweden on October 26, 2014, 03:51:10 pmYou mean it might help them sell those warehouses full of their new scopes that nobody wants to buy?QuoteYou haven't been paying attention to the information you read here. Rigol is one of the MOST secretive companies around (still grinding and rebadging ICs); there is no way they are going to give away/sell that - period. Perhaps in the distant future if people stop buying their DSOs - but I wouldn't hold your breath.