Rigol MSO2000 SCPI problems with Logic Analyzer

[atx]

Started testing the MSO1074Z today. First thing I tried was seeing if Frame recording captured the Digital channels (it does) - and whether it could decode the Frames while playing them back (it can't). It appears you can't turn on Decode while in Frame playback - and you can't turn on Record if you have Decode turned on. But the Plot function is kind of cool.

Interesting, the MSO2k does not have this function.  Any results for the SCPI memory read out function?

[marmad]

Interesting, the MSO2k does not have this function.  Any results for the SCPI memory read out function?

No chance to test it yet, but I'll post here as soon as I do.

[atx]

While waiting for a firmware update, I decided to check out the other SCPI commands. That opened another can of worms.  Here are some results that I also forwarded to Rigol for comments:

- There is no SCPI function for changing the SPI Trigger Menu setting „When“.  Thus, only the settings for Timeout are available.  It looks like this trigger section has not been updated for the MSO2k and provides only the functions for the DS2k.  However, the MSO has this great functionality of using one of the digital channels for the chip select signal ‚CS‘ of the SPI bus to do „real" SPI triggering.

- Another great setting in the SPI/I2C/RS232 trigger modes is the possibility to mask out certain bits in the ‚Data‘ setting.  The MSO2K allows to set each bit with ‚0‘, ‚1‘ or ‚X‘ wherein ‚X‘ masks the bit.  However, the SCPI command :TRIG:SPI:DATA do not allow any masking using the ‚X‘, there is only an integer value as a parameter.    (In the Pattern trigger function, the command :TRIG:PATT:PATT allows for this setting!) Why was this not implemented in the SPI, I2C and RS232 trigger commands? (This is a minor issue I have to admit)

- There is no way to directly set the sampling rate of the Logic Analyzer.  Why??? This is something I do not completely understand.  While this is of less relevance when operating the scope, using SCPI commands, this gets very tricky to set a sampling rate and even trickier to figure out what the sampling rate of the logic analyzer is.  There is no way of directly setting the sampling rate on the scope, only the time/div setting will eventually change the sampling rate for the analog channel and the digital channel. 

A related problem is:  The sampling rates for the LA and the analog channels are not correlated.  Whenever you turn the time scale knob any variations occur with ratios of 1:1, 1:2, 1:1.6, 1:4.  There is no clear order and some of the settings seem arbitrary. For example, here are some settings for the Sa rate of one analog channel and the corresponding settings for the LASa rate:

1 analog channels   8-LA channels
2GSa                -       1GSa
1GSa                -       1GSa
500MSa            -       500MSa
200MSa            -       125MSa
100MSa            -        25MSa
etc.. (there is a clear 5-2-1 order in the analog channels but this does not translate into the digital channels, thus the ratios are almost arbitrary)

Currently when I run the command :ACQ:SRAT? I only get the value for the analog 'Sa Rate‘ but there is no command for the LASa Rate which can be significantly different.
If I set the source for the data to the LA with :WAV:SOUR LA, I still get only the analog sample rate whenever I run the :ACQ:SRAT? command.   Moreover, the command :WAV:PRE? which returns the waveform parameters only returns the parameters for the analog channels even if the Logic Analyzer is set as the source. At least the :WAVE commands need to be corrected and return the values for the selected source.  This is IMO a software bug as it makes no sense to return the parameters for the analog channels when I set the digital channels as the source.

A similar problem exists for the memory depth.  The command :ACQ:MDEP? only returns the memory depth for the analog channels.  There is currently no way in obtaining the memory depth for the Logic Analyzer. The logic analyzer memory setting could be figured out by calculating the ratio between Sa rate and LASa rate.  But if there is no way of getting the LA settings, there is no way of calculating the ratio.  The only way is to use a table with all the correlated setting which is kind of annoying and makes things complicated as the ratios also depend on the memory depth and the number of digital channels.

There is probably more, but I stop here for now.
I start to feel a bit like a beta tester...
atx

[kg6hum]

There is probably more, but I stop here for now.
I start to feel a bit like a beta tester...
atx

Wouldn't it be great if Rigol open-sourced the firmware and ran a public bugtracker?  I doubt that would ever happen, but I bet they would get a lot of free bug fixes and maybe even additional features that people decided to add.  The only downside for Rigol would be the difficulty of supporting customers with custom firmwares.  Though I could see them just requiring someone to reproduce any problems while running an "official" firmware release.

I was about to purchase an MSO2k before seeing this thread along with others and the jitter video from Dave.  Now I am holding off to see if some of these problems get fixed quickly, and I'm looking at other alternatives.  Rigol has a great price point and good features, but the price may not be a good deal if there are a lot of bugs.

[Mark_O]

There is probably more, but I stop here for now.
I start to feel a bit like a beta tester...

Wow.  That definitely is another can of worms.  But even worse than a beta-tester (something has to exist, before it can be tested).  More like an explorer of uncharted territory, who keeps finding greater expanses of untreadable quicksand.  And roadways that just stop... leading nowhere.  It's pretty obvious that the current implementation is both buggy and unfinished.  Perfect condition to start promoting and selling it.   

Thanks for your continuing reports.  They are quite valuable to a lot of us.

[marmad]

An update:

I've been testing reading out the LA channels on the MSO1000Z to my PC, and it seems (so far) to work fine (both sample and display memory). One thing to note: the source command is different on the MSO1000Z - you don't use LA, but instead you set individual digital channels using the command :WAVEFORM:SOURce D4 (for example) - before using DATA?

Many of the SCPI commands are similar between the two DSOs - but there are some differences - and during my programming of RUU, I noticed one or two instances where the DS2000 was actually using the command form listed in the DS1000Z manual (not the DS2000A manual), so if you haven't checked already on the MSO2000A, I would at least try :WAVEFORM:SOURce DX - and see if you can set the source using that form (a very small possibility, I know, but worth a try).

[atx]

Thanks for your continuing reports.  They are quite valuable to a lot of us.

You're welcome. I wish I would have known, but I certainly keep posting.  So far no response from Rigol.

An update:

I've been testing reading out the LA channels on the MSO1000Z to my PC, and it seems (so far) to work fine (both sample and display memory). One thing to note: the source command is different on the MSO1000Z - you don't use LA, but instead you set individual digital channels using the command :WAVEFORM:SOURce D4 (for example) - before using DATA?

Many of the SCPI commands are similar between the two DSOs - but there are some differences - and during my programming of RUU, I noticed one or two instances where the DS2000 was actually using the command form listed in the DS1000Z manual (not the DS2000A manual), so if you haven't checked already on the MSO2000A, I would at least try :WAVEFORM:SOURce DX - and see if you can set the source using that form (a very small possibility, I know, but worth a try).

I just checked and it doesn't work.  If you send in that command, it freezes the USB connection and after unplug/reconnecting, while all other commands are working again, the :WAV:SOUR command is not functional until you send in a valid argument. Also, with this "wrong" setting, the :WAV:DATA command returns only the header with no data.  Was worth a try though...

I'll keep waiting for a comment from Rigol regarding the other issues.
atx

atx

[atx]

It's been a while that I have been posting regarding the issues with the Logic Analyzer section of the Rigol MSO2000.  I did sent my latest observations (see reply #27) to Rigol beginning of December with no answer for about a week.  Then, I sent the following to Rigol:

"I haven’t heard anything regarding the additional issues I sent you below.  This is also discussed on the eevblog forum.  It would be nice if I could report something positive.  Any comment or news?"  The "issues I sent below" included basically the detailed observations I posted in reply #27

The answer I got two days later: "I haven't heard anything from the product line. I'll check in with them but I think they are still developing at this point."

- No word about the detailed email I sent. Nothing.  Apparently my discoveries are a mere nuisance to them not worth commenting.  After I complained in another reply, I am now getting the silent treatment with no response at all. 

This is apparently the "Great Customer Service", Rigol advertises on their website. 

At this point, I have to warn anyone intending to buy a Rigol MSO2000.  According to Rigol, this product is still being "developed".

atx





 

[atx]

Some news: There is a new firmware out 00.03.03.SP1

After installing, I was hoping that the SCPI commands for the Logic Analyzer would work and the first impression was that it was fixed. Unfortunately it is not!  While the MSO will now return the proper amount of data after all parameters have been set correctly, the data I get looked a bit dubious at second sight.  And after investigating a bit more, it turns it is the analog channel data. Bummer?  No matter what I select, the scope only returns the analog data. No way to retrieve the LA data.

Decoding:  This section seems to be improved.  The SPI decoding now allows to select the CS signal in addition to clock and data (similar to the trigger menu) which is nice. Decoding information stays aligned without shifting anymore.  However, when selecting deep memory, the decoding starts failing again by skipping certain transmissions, usually when >2Mpoints.  This wouldn't concern me too much as it involves a lot of data which is not searchable on the scope anyway.  But due to the fact that you still cannot transfer the data through the SCPI commands, the deep memory is useless for the the Logic Analyzer.
 
I quickly checked the AC jitter trigger problem and this seems to be fixed.

Happy New Year,
atx

[kg6hum]

atx,

Thanks for the updates.  It is encouraging that they are fixing some things with firmware updates.  With the jitter problems fixed, hopefully they will now start looking into the Logic Analyzer and SCPI issues.

[atx]

Thanks for the updates.  It is encouraging that they are fixing some things with firmware updates.  With the jitter problems fixed, hopefully they will now start looking into the Logic Analyzer and SCPI issues.

I agree, it's promising even though I am disappointed as they apparently did change something to the SCPI-commands. It is a mystery to me why they didn't fix it when there is a routine available due to the fact that the USB save function works.

However, I got a response from Rigol clarifying that the update focused on the AC trigger malfunction and that the product group is still working on the LA portion.

This brings me to Rigol's priorities in fixing the firmware:
- I know I am not the only one complaining with respect to the MSO2k's LA functionality, but apparently there are not enough customers making a statement (at least that's my assumption)...

- Unfortunately, Dave didn't test/review the MSO2K, as these firmware issues would provide for some serious ranting material (in particular as they brought this scope on the market way too early, e.g., some of the issues are not just simple bugs) and then Rigol would have (maybe) set a higher priority for fixing this.

- My emails are apparently not really effective and thus these issues are on some back burner with Rigol.  But the fact remains that if you bought this MSO because of its large memory, the LA functionality is seriously crippled because you cannot download the data directly

Anyway, let's hope for the best
atx

[meltTemp]

An MSO2072a owner here.

I got it a few months ago but unfortunately a 30 days return period expired before I noticed this thread. I had some other serious issues with the instrument: in its horizontal menu every second button starting from the MENU button did not work and the LA cable plug did not fit into its port. I naturally got the instrument replaced but I wonder how Rigol's QC works...

Issues reported here and in some other threads are serious and as you guys say, Rigol's attitude to fix problems seems to be nothing but ridiculous. I also believe that there are not enough customers to complain so I encourage you guys to make a statement directly to Rigol and also to your distributors. Even if you do not ever use SCPI or other buggy features you should do that. We should show that releasing so buggy products is just not acceptable.

As mentioned, saving csv via USB works even though it's freaking slow (took over 10 minutes) if data are from full memory. Waveforms could help this but as far as I know, the MSO2000 waveform format is not yet decoded(?) and I do not have such skills. Anyway, this is only a temporary solution and far from being efficient.

Thank you for the updates so far and keep posting. Let's see how things plays out...

- OT

[e_60]

Hey,

Just got my MSO2072A to replace my MSO1104Z for purposes of improved serial decoding an SPI bus, and I am facing the same issue,   whereby  if the depth is set too large the decoding starts to fail by way of indicating errors, regardless the fact it looks fine on the display.   My scope came out of the box with 00.03.00.SP1  and I have made a request for the latest version.

I also look forward to getting the option of using the chip select instead of timeout,  as found on the MSO1000Z.

[etl17]

On more MSO2000A user here. I am also having the same issue with deep memory serial decoding.
This is a big limitation for the LA and Rigol should make it a priority to address it.

[e_60]

I just upgraded to 00.03.03.SP1 and so far it appears the decoding issue with the deeper memory is gone, or at least it is improved enough that it is no longer an issue in my application.  The addition of the chip select instead of timeout is also helpful (and expected).

[atx]

Issues reported here and in some other threads are serious and as you guys say, Rigol's attitude to fix problems seems to be nothing but ridiculous. I also believe that there are not enough customers to complain so I encourage you guys to make a statement directly to Rigol and also to your distributors. Even if you do not ever use SCPI or other buggy features you should do that. We should show that releasing so buggy products is just not acceptable.

As mentioned, saving csv via USB works even though it's freaking slow (took over 10 minutes) if data are from full memory. Waveforms could help this but as far as I know, the MSO2000 waveform format is not yet decoded(?) and I do not have such skills. Anyway, this is only a temporary solution and far from being efficient.

Thank you for the updates so far and keep posting. Let's see how things plays out...

- OT

meltTemp,
welcome to the forum.  Couldn't agree more that everybody that bought an MSO2k should contact Rigol and complain.  It's sad to see that a product which has such great potential is thrown on the market obviously unfinished. 

I did analyze the file structure a tiny bit and while I have no clue what they pack into it( the file is blown up with all kinds of stuff), I was able to figure out the main parameters. 

Here are the offsets for those parameters I could identify:

Address - Parameter
---------------------------
0x60     - SaRate analog sample rate (32 bit float)
0x70     - Trigger point measured in picoseconds (64 bit long)
0xF4     - MemDepth (32 bit int) (memory length of analog data)
0x100   - start address in the file for LA-data (32 bit int)
0x104   - LMemDepth (32 bit int) (memory length of digital data)
0x2CC  - on/off lower 8 channels flag, each bit associated with one of channels 0-7 (8 bit)
0x2CD  - on/off upper 8 channels flag, each bit associated with one of channels 8-15 (8 bit)

I think the start address needs an additional offset of 0x80 once retrieved (not entirely sure).  I could not find the LASaRate parameter, but it can be determined by the ratio LMemDepth/MemDepth and the current analog sample rate.  Anyway this is not a long term solution but may help if you need to analyze some data until this is fixed.

atx

[atx]

I just upgraded to 00.03.03.SP1 and so far it appears the decoding issue with the deeper memory is gone, or at least it is improved enough that it is no longer an issue in my application.  The addition of the chip select instead of timeout is also helpful (and expected).

The decoding is certainly improved but not fixed.  Rigol merely shifted the point of failure to a higher memory depth.  See attached figures which show a simple sequence of increasing 8-bit values at 8Mhz, triggered at 0:  At 140 kPts, everything is hunky dory.  At 1.4 MPts, the new firmware now works but a little bit of misalignment to the left shows up.  At 14 MPts, disaster strikes...

Makes me wonder how they implemented decoding.

atx

[Mark_O]

At 140 kPts, everything is hunky dory.  At 1.4 MPts, the new firmware now works but a little bit of misalignment to the left shows up.  At 14 MPts, disaster strikes...

I find that fascinating.  Identical input.  Identical extracted bit-stream on screen.  And totally different Decoding, just by increasing sample Depth.

That's some bizarre shit.   

Makes me wonder how they implemented decoding.

Well, it can't possibly be from on-screen data, regardless of what they may claim.  The traces are identical.  It's hard to imagine how they could screw things up so badly, or come up with the interpretation shown.  If I had to hazard a guess, I'd say their Decoder is using an Indexer to obtain its source data, and it's not accessing the correct data (i.e., its addressing is broken).

[e_60]

I am not sure if it is related, but I opened another thread titled "Rigol MSO2000A Logic Analyzer Memory Depth Display Problem"  to try and explain what I am seeing with the new firmware.   In my tests,  I can now capture and decode with deeper memory,  but  it seems to plot the actual digital signal traces on the screen based on the analog  memory depth,   but it is plotting the decoded trace  based on the logic analyzer depth which is not the same, always half?     I can avoid this misalignment issue by using auto depth, but it causes the other annoyances for looking at the information in run/wait mode. 

 I will do a few more tests to ensure it is in fact not encountering decoding issues,  just showing it misaligned.

[atx]

Here is an update of the SCPI  and decoding issues and whether the latest software 00.03.03 SP2 fixed the problems.

The good news first:  The SCPI download function has been fixed. Works with all settings.  Took only 9 months to fix this after I reported it in October to Rigol.  The only issue I found relates to the weird relationship between "analog signal" memory depth (MemDepth) and Logic Analyzer memory depth (LAMemDepth).  As reported somewhere in this thread these values are not correlated for all settings.  Whenever data is downloaded from the LA memory with the correct size settings (:WAV:POINTs and :WAV:STOP), the scope will send back the correct amount of data if MemDepth coincides with LAMemDepth.  If this is not the case then the scope sends back the size of MemDepth which means depending on how much larger that memory size currently is you will receive some superfluous data.  For example, in a setting where MemDepth=140kPts and LAMemDepth=70kPts, you will get back the correct 70kPts of LA data plus 70k of garbage.  This doesn't matter too much in the low settings but when it comes to the higher memory settings 14M it will add some additional download time. 

Decoding is still memory dependent.  I used a 8Mhz SPI signal to test it and here are some results:
LASaRate:     LAMemDepth:
1Gs/s            140k                - works
1Gs/s            1.4M                - works
1Gs/s            14M                 - fails

500Ms/s        140k                - works
500Ms/s        1.4M                - fails

125Ms/s        8.75k                 - works
125Ms/s        87.5k               - works
125Ms/s        8.75M               - fails

25Ms/s          7k                  - works
25Ms/s          70k                - fails

While decoding seems to be further improved it still fails in particular when using large memory.  Decoding also causes a lot of crashes and freezes.
However, the data is sampled correctly.  I managed to transfer data with all memory settings and analyze it on my computer and there is nothing wrong with the sampled data.  I could perfectly decode it on my computer. USB Transfer time for 14Mbyte are about 25 seconds.  Anything in the lower memory sizes transfers within a couple of seconds or less.

atx

 

[Mark_O]

Thanks very much for the update, atx, and the report on the still-broken decoding.

From my POV, this renders the instrument nearly worthless.  Why do I say that?  Because if I buy an MSO, I want to take advantage of both analog and digital channels for my protocol analysis tasks.  The Failure results you reported show that the Best Case scenario is the 1 GS/s + 1.4M Sa setting, which buys you a whopping 1.4 ms of capture time.  Now what one would normally do in that situation is back off on the sample rate (and increase the sample depth), to increase the time window.  However, doing either results in a broken decode, at smaller and smaller intervals (sub-millisecond).

What good is that?  If I'm doing SPI decode, for example, I may want to oversample by around 10x, just to have well-defined edge timing.  But I don't want to have to oversample by 125x, just so my decoder will work.  That's throwing away >90% of my sample space, for nothing.  And on top of that, being able to utilize only 10% of the memory I paid for.  (one should be able to do 175 ms, not 1.4 ms.)

The fact that you can pull the data out of the scope, and it is intact and analyzable on your PC, is small consolation (IMO).  There are cheaper (and faster) ways of doing that than an MSO2000.  Get a Pico box with a USB3 interface, and suck the data out at ~130MB/sec.  Instead of taking 25 sec for a 14M sample (560 kB/s), as you indicated on your MS2000, you're looking at a fraction of a second (about 0.2 sec, with overheads).

[atx]

Thanks very much for the update, atx, and the report on the still-broken decoding.

From my POV, this renders the instrument nearly worthless. 

Mark,
I fully agree.  The only reason why I chose the MSO over the DSO is that I prefer to turn knobs as opposed to a mouse when setting up an instrument and I also prefer a single instrument that does both.  Unfortunately, the Rigol MSO2K does only a good job on the analog side.  The additional $400.- for the LA section are a complete waste of money. And don't spend any money on the decoder option because it does not work.  After almost a year of waiting, I cannot recommend to buy this version and I would not have bought it if I'd known these issues.

The pity is that the LA implementation on the Rigol doesn't even qualify as a half-ass job.  Now that the SCPI download function works, I dared testing the device in the slower sampling modes.  The results are pretty bad.  In the lower sampling rates, the device freezes or crashes infrequently.  Besides the decoding failure, the lack of a decent operating interface on the timing setting is also bad.   Why isn't is possible to directly set the sampling rate?  To get to the lower sampling rates, you have to set the scope into RUN mode and turn the scale knob until you see the desired sample rate in the menu.  This causes the screen to generate a bunch of white bars (if you analyze e.g. a 8MHz with a 25MHz sampling rate). Then you need to put the scope in STOP mode and turn the scan knob back to get a readable screen.  Doing this causes infrequently a freeze during which the system has a reaction time of 20 seconds and the logic channels are sometimes not updated at all besides that decoding is long gone by then.

There is a menu for the LASaRate and an associated button, but it is deactivated and cannot be changed.  Why they tied the screen display to the sample frequency in the LA mode makes no sense whatsoever.

I don't want to invest in another separate analyzer at this time, so I am going to live with it for now that I can at least download the sampling data.  But, yeah I am not happy how things worked out with the MSO2k.
atx

[khaahk]

So what software do you use to analyze the dump on pc? You have written own? I also haven't had any luck with pulseview under windows. It seems a waste to buy another logic analyzer to get the data in pc readable format...

[atx]

Yes, I wrote my own. It is written under Cocoa using Xcode (OS X). I struggled a while with the USB interface but now its running. I tried pulseview but never got even a connection and gave up...

atx