Rigol MSO2202A SD-DS2 Serial Decode Bugs - Page 1
Forum section: electronics / testgear

author: PeterHouse
author_rank: Contributor
timestamp: March 09, 2015, 11:42:54 pm
content: Using the most recent firmware available for the MSO2202A, version 00.03.03.SP1.I purchased the SD-DS2 Serial Decoding module.The serial decoding still does not function properly in a couple of ways although I can get to slightly work.1. The menus shown for SPI decode are incorrect and do not match the online documentation for the SD-DS2 (although the online does not show this module for this specific model). The menus seem to be for I2C showing SDA and SCLK signals and there are no options for SPI signals CS, MISO or MOSI as shown on this document:SD-DS2 Product Information2. The included pictures show 2 signal capture screens and 2 signal display screens with decoding turned on. All displays show the same SPI startup sequence for a product I am creating.The first capture, "Not Working Capture 200ms.png", is set to 200ms/division and after changing the display to the 200us/div setting and turning on the decode channels, you can see the decoding is incorrect in "Not Working Display 200us.png".The second capture, "Works Capture 100ms.png", is set to 100ms/div and after changing the display to 200us/div and turning on the decode channels, you can see the decoding is mostly correct except the decoding is not time aligned very well and shows up ahead of the actual signal by almost half a byte in "Works Display 200us.png".These problems make the SD-DS2 decoding unusable since it is unreliable – If the decoding algorithm detects an error keeping it from working it should at least display an error and not display data which is incorrect.I have been working with Rigol on this issue since I purchased and received the 'Scope in August of 2014.

author: don
author_rank: Regular Contributor
timestamp: March 10, 2015, 02:14:30 pm
content: I tried a DS4000 and if I recall correctly I2C decode only worked at 100ms/div or faster. This was regardless of memory /depth and sample rate. That was a big disappointment for a scope with 140M memory. I wonder if decode breaking at time bases slower than 100ms/div is common on rigol.

author: PeterHouse
author_rank: Contributor
timestamp: March 10, 2015, 02:44:04 pm
content: If it is common, which I believe it is, it certainly limits the usefulness of the 'scopes functionality.The first product I am working on sends small SPI bursts once per second and I need to analyze a series of bursts which requires a longer capture time than 100ms per div.For this product I ended up purchasing a Beagle I2C/SPI analyzer which did the job easily. I expect the 'scope should do a similar job.

author: PeterHouse
author_rank: Contributor
timestamp: May 09, 2016, 01:58:54 pm
content: The Saga Continues.Due to a personal issue and Rigols' lack of speed (a couple of months to receive a response), this issue has taken a while to finally resolve conclusively.I finally received a message from my third Rigol engineer, Jason Chonko, stating: "I can say that our scopes will only decode displayed data. If the information required to decode the bit stream is not on the display, that can cause issues with the decode."Unfortunately, this makes the Serial Decode option about worthless. since if you have more than about 20 bytes on the screen, the display cannot show the decoded data as it gets too scrunched up to view. As soon as you scroll, and the first byte goes off the left side of the screen, the entire decode becomes unreliable since it is no longer synced to the start bit of the first byte.Outside of the stated limitation, the serial decode only works on a narrow range of sweep speeds and shows data which is unreliable at other times making this "feature" more of a liability.I love the scope other than this single issue.It's too bad it's not open source so someone could fix this correctly and make it really functional. The engineers at Rigol do not seem to have a good understanding of serial protocols and what is takes to work with them.

author: Fungus
author_rank: Super Contributor
timestamp: May 09, 2016, 02:19:29 pm
content: Quote from: PeterHouse on May 09, 2016, 01:58:54 pmI'm sure they understand them just fine.Many (most?) functions on Rigol 'scopes only work with whatever data is shown on screen.I have a feeling this is a hardware limitation - the main CPU doesn't have direct access to the main memory buffer (or something like that).

author: PeterHouse
author_rank: Contributor
timestamp: May 09, 2016, 03:07:20 pm
content: The big issues here are:1. They charged $250 for this "feature" with no real description of any limitations and these limitations seem to be regardless of protocol.2. The "feature" displays bad data with no indication the data is unreliable.3. They kept getting me to "upgrade the firmware and see if this fixes your issue". The tech support guys did not take the time to realize the problem is a limitation of the "feature" and another firmware upgrade was a complete waste of time for me and for them.I will not give up my scope and it sits here next to my older Agilent which is short on features but is very reliable as to what it shows on the display.

author: rf-loop
author_rank: Super Contributor
timestamp: May 10, 2016, 04:18:36 pm
content: Quote from: PeterHouse on May 09, 2016, 01:58:54 pmWhy you do not capture all in main window (why need care if main window is so crunched) and then open details in zoom window and scroll this window to position what you want look? Is it not possible in Rigol?

author: PeterHouse
author_rank: Contributor
timestamp: May 10, 2016, 04:24:30 pm
content: Unfortunately, it does not work that way. As soon as the beginning byte is off the display, the decode goes flaky.