Rigol MSO2072A First Impression - by a Rigol Fan (with THANKS! TO hendorog)

[Electro Fan]

UPDATE:  I was getting close to being very concerned with the move from the DS2072 to the MSO2072A, but after some EXCELLENT guidance from hendorog (many thanks to hendorog), I am very enthusiastic about the move.  You can follow my down in the dumps to Cloud 9 impression here....

---

I have been a user of the Rigol DS2072 for about 2 years.  I thought it was a very good scope and decided to try the MSO2072A.  Maybe I don't quite understand how to use the MSO2072A or maybe I should have more carefully read the feedback here on the MSO2072A.

Here are my findings so far - feel free to correct me if I've misunderstood something.

The MSO2072A is represented as having fairly deep memory.  Having said that I read various reports that said the memory couldn't be used with decoding digital signals.  No problem, I don't need a ton of memory.  Not sure how much I need, but not a lot.

What I have found is that the only digital channel signals that can be decoded are those that are on the screen. And if you scroll off the screen you will lose even the one screen of decoded data.

This is different than the analog channel decoding.  For example, on the analog channels you can turn the Time Div knob to 100ms per Div, capture a relatively larger amount of data, and then turn the Time Div knob to 1ms per Div which allows you to see more detail, and with the horizontal scroll knob you can look at data that was off the screen.

With the digital channels it appears that you can just about get one run of the alphabet (26 characters) - and that would be upper or lower case, not both, much less numbers and special characters.

I'm hoping I am missing something here - it just doesn't seem that a scope referred to as a MSO should be limited to strictly viewing digital channel decoded characters (or even just the waveforms?) limited to one screen width - with no ability to scroll to a larger set of data (and waveforms?). 

Below you can see how a-z fits and that's it (due to no scrolling).  If you set the scope so you can see the signal at the Byte level with clock level detail you will get fewer characters.  If you select the smaller setting in the LA you just get miniature waveforms but it doesn't help with the limitation of on screen decoding only.  Obviously, there is a limit to what is visually discernible on one screen width.  This is not the issue.  The issue is whether you should be able to see more decoded data and signal waveforms by scrolling beyond one screen width.

The second biggest issue I have with the MSO2072A is that it does not seem to remember the last settings for the LA (this is with the option for viewing the last settings selected); when you turn the scope off you will have to redo a number of the LA settings to get back to where you left off.

Overall, it seems like Rigol has the ability to make proper features but it feels like they just quit working on the product before they were done.

Please tell me I'm missing something obvious. 

[Electro Fan]

Come on.... must be some other MSO2072A users out there....

Does the MSO2072A have the ability to retain and display more than one screen of digital signal waveforms and decoded data?

If so, how?

Thanks!

[nbritton]

The LA digital channels have 14 Mpts standard with an upgrade option to 28 Mpts. The MSO2000 and MSO4000 share the same LA parts and circuity. I haven't played with the LA feature on my MSO4014 yet, my DS6000 demo board arrived this week, I should have time to play with it tomorrow.

[Electro Fan]

Memory specs are interesting.... being able to get more than one screen of digital channel waveforms and decodes to remain in some type of memory so you could scroll beyond the one screen would be more interesting... please let us know what you find. Thx

[hendorog]

I have a DS4014 - not an MSO, but perhaps you are missing the record function?
You need to setup triggering to trigger on each packet. Then you should be able to record each packet in its own 'segment' of the memory.
Then scroll through the results with the playback function and the jog wheel.
My scope only shows the results of decoding the screen in the list, but it is quick and easy to scroll through the results.

[Electro Fan]

I have a DS4014 - not an MSO, but perhaps you are missing the record function?
You need to setup triggering to trigger on each packet. Then you should be able to record each packet in its own 'segment' of the memory.
Then scroll through the results with the playback function and the jog wheel.
My scope only shows the results of decoding the screen in the list, but it is quick and easy to scroll through the results.

hendorog 

Winner, Winner, Eggplant Parmigiana Dinner   

That is it!

You can turn on record, and send a packet of data, or a bunch of packets - short, long, doesn't matter, and just as you say, it will put each packet in it's own segment.  Then after completing the sending you can hit the playback button and easily see each packet - including both the waveforms and the data decodes.  You can forward and reverse to each numbered packet.  And within a packet playback you can scroll off the screen in either direction, change the Time/Div, look around, not have anything disappear. 

MAJOR good solution!

I am now a happy camper with the MSO2072A.

If you happen to have some ideas on how to implement a "search strategy" so you could look for certain data decodes or waveform patterns that would be great to know also. 

(For some reason I don't understand yet, using the analog channels with the decoders doesn't require the record function to enable multi-screenwidth viewing - any info on what causes the differences between the analog channels and digital channels would be interesting to know.)

Thanks Again 

EF

[Electro Fan]

You can record digital channels without the decoder on and then in playback you can simply view/review the waveform, or you can turn the decoder on (even though you recorded without the decoder) and get the decodes to appear during playback. 

[hendorog]

I am now a happy camper with the MSO2072A.

If you happen to have some ideas on how to implement a "search strategy" so you could look for certain data decodes or waveform patterns that would be great to know also. 

(For some reason I don't understand yet, using the analog channels with the decoders doesn't require the record function to enable multi-screenwidth viewing - any info on what causes the differences between the analog channels and digital channels would be interesting to know.)

Thanks Again 

No problem EF I'm glad it worked out Thanks for the virtual dinner 

The deep memory search is limited. Here are some options which might help :
1. Use protocol triggering features (bitmasks/patterns) to only trigger on the packets you want to see.
2. Use the waveform mask/analysis feature in the scope to search for particular waveforms.
3. Build a custom waveform mask on a PC, copy it onto the scope and use the analysis mask feature.

#3 has been documented here on eevblog by someone IIRC. From memory the mask is a CSV file which you edit in Excel/Openoffice.

[nbritton]

3. Build a custom waveform mask on a PC, copy it onto the scope and use the analysis mask feature.

#3 has been documented here on eevblog by someone IIRC. From memory the mask is a CSV file which you edit in Excel/Openoffice.

[Electro Fan]

I think the "someone" who made that video is Marmad - he is kind of like the Columbus of the Rigol DS2000. 

Thanks again for all the help.

- In playing further with the MSO2072A I think the saying "it's never as good or as bad as it seems" applies.  The MSO2072A definitely had and probably still has lots of functionality hiding inside waiting to be discovered and figured out.  At the same time, it seems like the ability to capture, view, review, search, and generally navigate around could be made more functional/versatile, intuitive, and just plain easier.  I'm hoping that other users here weigh-in on the operation of the LA/MSO functionality and that Rigol keeps at it.  I believe Rigol has the ability to make an excellent MSO - they might just need more/better feedback from users.  Having said that, Rigol probably can't respond to every request but the more clear the need for certain functionality the more likely I believe they will be to respond with new firmware and new products.

[Electro Fan]

hendorog - just checking to see how many characters (Bytes) you can record and subsequently display in one packet?  What is the maximum?  Thanks

(I think the record function helps to capture lots of frames, and it allows you to scroll around on and off the display without having the waveforms and decoded data disappear, but I'm having second thoughts/concerns about whether waveforms and data that didn't fit on the first screen during the recording session are actually getting recorded....)

[hendorog]

hendorog - just checking to see how many characters (Bytes) you can record and subsequently display in one packet?  What is the maximum?  Thanks

(I think the record function helps to capture lots of frames, and it allows you to scroll around on and off the display without having the waveforms and decoded data disappear, but I'm having second thoughts/concerns about whether waveforms and data that didn't fit on the first screen during the recording session are actually getting recorded....)

I think you are correct at least from the perspective of the analog channels - the packet needs to fit on the screen at some point for it to be decoded. That makes sense as (ignoring 'zoom mode') the screen shows what is being digitised. You can see that changing the timebase changes the sampling rate and the number of memory points (in Auto). The 'unused' memory in some timebases doesn't get used AFAICT.
So if you get a big packet that doesn't fit on the screen, it won't all be captured and decoded.

[Electro Fan]

hendorog - just checking to see how many characters (Bytes) you can record and subsequently display in one packet?  What is the maximum?  Thanks

(I think the record function helps to capture lots of frames, and it allows you to scroll around on and off the display without having the waveforms and decoded data disappear, but I'm having second thoughts/concerns about whether waveforms and data that didn't fit on the first screen during the recording session are actually getting recorded....)

I think you are correct at least from the perspective of the analog channels - the packet needs to fit on the screen at some point for it to be decoded. That makes sense as (ignoring 'zoom mode') the screen shows what is being digitised. You can see that changing the timebase changes the sampling rate and the number of memory points (in Auto). The 'unused' memory in some timebases doesn't get used AFAICT.
So if you get a big packet that doesn't fit on the screen, it won't all be captured and decoded.

Whether using the decoder or turning it off, I can't get more than 30 characters (Bytes) worth of waveform in a frame to record and playback at any setting with the digital channels.... am I doing something wrong?

So far the benefits of the record and playback are 1) you can capture more than one frame, and 2) when reviewing a frame if something scrolls off the screen it will scroll back without disappearing - but the 30 Byte limit per frame for decodes and waveforms seems like kind of small capacity.

[H.O]

(I think the record function helps to capture lots of frames, and it allows you to scroll around on and off the display without having the waveforms and decoded data disappear, but I'm having second thoughts/concerns about whether waveforms and data that didn't fit on the first screen during the recording session are actually getting recorded....)

Of course it doesn't record what might be outside of the screen. You need to set your timebase up so that the longest packet you expect to capture will fit on the screen timewise. You probably want to move the horisontal trigger position from the center of the screen towards the left hand side so you don't waste half the screen (and therefor memory) with pretrigger data. When you play back/review the recorded frames and you have a slow timebase (a lot of data) you can "zoom in" to allow the decoder to display but (at least with the analog channels) the decoder can lose track if a startbit of RS232 byte gets moved outside the screen so look out for that.

With that said, I've also got a DS4000 (no MSO) but I suspect it's "the same" in this regard.

[Electro Fan]

(I think the record function helps to capture lots of frames, and it allows you to scroll around on and off the display without having the waveforms and decoded data disappear, but I'm having second thoughts/concerns about whether waveforms and data that didn't fit on the first screen during the recording session are actually getting recorded....)

Of course it doesn't record what might be outside of the screen. You need to set your timebase up so that the longest packet you expect to capture will fit on the screen timewise. You probably want to move the horisontal trigger position from the center of the screen towards the left hand side so you don't waste half the screen (and therefor memory) with pretrigger data. When you play back/review the recorded frames and you have a slow timebase (a lot of data) you can "zoom in" to allow the decoder to display but (at least with the analog channels) the decoder can lose track if a startbit of RS232 byte gets moved outside the screen so look out for that.

With that said, I've also got a DS4000 (no MSO) but I suspect it's "the same" in this regard.

Thanks, what you describe with speeding up the timebase and moving the trigger as far left as possible to maximize the viewing experience is what I have stumbled on to with trial and error - but so far the best I can get no matter what timebase is used is less than 40 ASCII characters of data and the associated waveforms - doesn't matter how much you slow down the timediv during playback (slowing the timediv helps see the detail but it doesn't increase the capacity, and speeding up the timediv on the front of the process only helps to a modest extent).  Just seems like with all the memory in the scope it should be able to do (much) better.  If it could handle larger data sets and had some useful search function it would be a very, very good scope for the price.  It's still not bad, but it could be much better.  (fwiw, I've found the decoder can lose track on the digital channels but I've found RS232 on the analog channels to be pretty dependable)

- on the digital channels (with I2C) the decoder will turn off if you turn the timdiv from 100ms to 200ms before you do a capture; 100ms is the best you can get

[H.O]

Hello,

I understand that you can only fit 40 (or whatever) bytes/characters on the screen at once and I may be missing your point but I'll try one more time:

When you're capturing data you need to set the timebase as slow as is needed to fit an entire package. I mean at 100ms per div you can fit 1.4 seconds of data on the screen. If your packets are longer than THAT a scope probably isn't the correct tool for the job. If you're doing 100 (!) byte packets of RS232 at 19200baud that's ~52ms. Setting the trigger position 1 div from the left side and the timebase to 5ms per div would be a good starting point. You'll then have 11 effective divisions with a total of 55ms worth of post trigger data.

Then when you play back the captured frames you can "zoom into" the packets by decreasing (speeding up) the timebase and use the horizontal position knob to "pan around" inside the captured the data. The decoder will decode and display and what's on the screen at any given time but again, if the start of a byte falls of the screen it can make mistakes so one needs to be a little bit careful.

Again, this is how it works with the DS4k. I don't know if it's any different with the MSO and the logic channels but I wouldn't think so.....

[hendorog]

There are a couple of things I can think of:
The decoders lose track at slow timebases, earlier than they should. That limits the use of memory somewhat. The Digital channels are worse than the analog channels.
(Based on a post in another thread showing the performance of his MSO. I found my DS was quite a bit better. I'm assuming they were using digital channels)

Check the memory depth being used is sufficient to digitise the packets. Perhaps you have set the memory depth manually and that is the problem?

[Electro Fan]

I appreciate the help.

Here are some more test results.  Comments, questions, suggestions all welcome.

I set the scope for ASCII decoding at 2400 baud.  From a computer serial port I sent a long text file (12 pages, 40,344 character Bytes including spaces).

For this test I used analog Channel 1.  Acquire was set to 140k points.  TimeDiv was set for 100ms.  Trigger was far to the left.

The scope recorded until reaching frame 120.  Turns out that was enough frames to record the entire text file.

When reviewing the recording I set the scope to 10ms per Div – this enabled each ASCII character to display nicely by itself in one green decoder box.

Frame 1 showed the beginning of the text, Frame 120 showed the end of the text.  Each frame has about 330 characters (120 x 330 = 39,600 vs. 40,344 so my frame counts are approximate; I only examined a few of the frames for specific Byte counts.)  Each frame lasted about 1.35 seconds.  1.35 x 120 frames = 162 seconds.  40,344 Bytes x 9 bits (including a start bit) = 363,096 / 2400 baud (bps) = 151 seconds which is in the ball park of 162 seconds.     

Every frame reviewed retained the waveforms and the decoded data even though 9/10ths of each frame resided off the screen.  At 10ms per Div and 14 Divs you of course can see 140ms on the display which means 10 screens worth of scrolling with the small knob for 1.4 seconds worth of data - there is no doubt that a few changes to the hardware and software could make navigation more enjoyable.  And if Rigol added search features this scope could be extra nice.

In summary, it looks like the memory has the capacity to handle a data set of this size and is simply breaking (segmenting?) the data into pieces that fit within the scope’s file structure.

I will try the digital channels next with the same text file; my guess is that it might behave different, but we’ll see…..  In the meantime, these results are giving me some added understanding of how the scope works and how it is operated.  Thanks for walking and talking me through this stuff.

EF


Update:  I tried the same text file on a digital channel:  Good news and better news

The good news is that while I expected (given my earlier tests with I2C on a digital channel) that this test would not work as well as the analog channel test - this test had good results.  In fact, it gave the same results in terms of recording capacity as the analog channel test above - the entire ~40k Bytes file recorded within the same 120 frames.

The better news is that the decodes on the digital channel appeared to have less errors than the decodes on the analog channel (fewer decode boxes that were unable to display the ASCII Byte).  This is not too surprising given the nature of digital vs. analog, but it's nice to see.

I am now starting to think that the limited decoder recording capacity I saw earlier was due either to something in my probing setup, or possibly it was some limitation of the Arduino Uno or the IDE sketch, or maybe I2C is tougher to record/decode than RS232.  Not sure which yet, but I think it's all a step in the right direction for the Rigol MSO2072A.

EF

[hendorog]

I don't think that your scenario there is good for a scope based protocol decoder.

The decoder combined with segmented memory would normally be used to capture relatively short packets of data. The segmented memory allows the scope to ignore the dead time between packets. e.g. sending commands from a PC to a micro.

Contrast that with your test, which is a continuous stream of bytes from a text file.

Because you are using the segmented memory there is some blind time between segments. I'm not sure how long this time is, but no doubt some characters will be missed.

A better test would be to try sending many very small files (a few bytes each) to the com port. For all intents and purposes that would look very similar to sending commands from the PC to a microcontroller.

[Electro Fan]

I don't think that your scenario there is good for a scope based protocol decoder.

The decoder combined with segmented memory would normally be used to capture relatively short packets of data. The segmented memory allows the scope to ignore the dead time between packets. e.g. sending commands from a PC to a micro.

Contrast that with your test, which is a continuous stream of bytes from a text file.

Because you are using the segmented memory there is some blind time between segments. I'm not sure how long this time is, but no doubt some characters will be missed.

A better test would be to try sending many very small files (a few bytes each) to the com port. For all intents and purposes that would look very similar to sending commands from the PC to a microcontroller.

I think it is possible that I am using a standard screw driver on a Philips head screw - but it's all a learning experience

This last set of tests was to see how much data (waveforms and decodes) could be recorded and played back.  I don't think I reached the threshold but I recorded and played back enough to think that whatever the limit is it will be sufficient for anything I'm likely to be doing in the near term.

I checked on a couple of the frames to see if the end of one frame aligned with the beginning of the next frame.  In one case there appeared to be a gap and in another it seemed to line up.  I didn't examine this closely but I can believe that blind time can be an issue.

This whole thing is a ground up attempt to learn everything from scratch from Ohm's Law to how data is encoded and decoded to how to write some software.  So every step is one very small step at a time including how to use the tools.  As I gain more understanding of each tool and can in turn make more repeatable results I can then test hypotheses on new concepts and learn something new, or not.  Someone here recently posted something to the effect that the difference between theory and reality is small in theory but bigger in practice - I can relate to this 

To many folks here this is elementary 101 level if not 100 level stuff but to me it's fun and exciting 

Back to the substance of the matter.... I can see that for some uses segmented memory is better than others, and that it's possible without a suitable use that data could be missed during the blind time - but an equal or larger challenge seems to be how to review and especially how to search for characters or waveform patterns.  I saw the video on making a mask but that looks kind of tedious.   The suggestion on using the recording functions to deal with data that otherwise is lost off screen was very good... any suggestions on now to search for data and waveform patterns? 

Thanks again for the guidance.

[hendorog]

No probs, happy to help where I can and don't be afraid of making mistakes.
Bear in mind I am no expert myself and am just giving my perspective based on what I've learned from my own mistakes

The search options were mentioned earlier.
The best way is to setup a trigger to only capture exactly what you want. Then the searching process isn't required at all. I've mostly used SPI and that can be set to trigger on a particular bit sequence on the ds4k.
The next easiest is the create a mask on the scope from a 'known good' waveform. Then the scope can go and search for anything that doesn't match that shape.
The hardest and most flexible is to create the mask off-scope as per the vid you've seen.

One of the subtle features with the multi-channel triggers like SPI (i.e. DATA + CLOCK + CS) - you need to set the trigger level for each of the channels individually using the trigger level knob. Obvious once you know but took me a bit of time to figure out why it didn't work.

[Electro Fan]

No probs, happy to help where I can and don't be afraid of making mistakes.
Bear in mind I am no expert myself and am just giving my perspective based on what I've learned from my own mistakes

The search options were mentioned earlier.
The best way is to setup a trigger to only capture exactly what you want. Then the searching process isn't required at all. I've mostly used SPI and that can be set to trigger on a particular bit sequence on the ds4k.
The next easiest is the create a mask on the scope from a 'known good' waveform. Then the scope can go and search for anything that doesn't match that shape.
The hardest and most flexible is to create the mask off-scope as per the vid you've seen.

One of the subtle features with the multi-channel triggers like SPI (i.e. DATA + CLOCK + CS) - you need to set the trigger level for each of the channels individually using the trigger level knob. Obvious once you know but took me a bit of time to figure out why it didn't work.

Thanks - that will help save some time figuring out the approaches.  Regarding triggering:  on an analog channel the scope offers the visible trigger line and the numerical readout; on the digital channels you get the numerical readout but no trigger line as best I can tell?  If the numerical readout is the only indicator, then to your point, it needs to be set for the particular channel - and that would no doubt require the user to know the normal voltage level for the particular type of signal (TTL, CMOS, etc.).  Since the digital channels can be moved up or down anywhere on the screen, the numerical readout can be assumed to be relative to 0 for the selected channel-correct?

Thanks again

[CustomEngineerer]

Thanks - that will help save some time figuring out the approaches.  Regarding triggering:  on an analog channel the scope offers the visible trigger line and the numerical readout; on the digital channels you get the numerical readout but no trigger line as best I can tell?

For the visible trigger level line for the analog channels. The line is shown if you have Trigger Coupling set to DC or HFReject, but is not shown if you set Trigger Coupling to AC or LFReject. Dave did a video on Trigger Coupling in #685 and why it wouldn't make sense to show a trigger level line for AC Trigger Coupling. Link to #685 thread, video contained within.
https://www.eevblog.com/forum/blog/eevblog-685-what-is-oscilloscope-ac-trigger-coupling/

From page 1-23 of the MSO2000A&DS2000A_UserGuide.pdf (https://www.cpp.edu/~ece/department/labs/MSO2000A&DS2000A_UserGuide.pdf).

"When the trigger source is set to D0 to D15, the trigger level is displayed at the upper-right corner of the screen. No trigger level label is displayed."

So you get the numerical readout, but no visible line or label. I can't verify this since I don't have the MSO, but sounds right.