Rigol MSO2000 SCPI problems with Logic Analyzer

• Rigol MSO2000 SCPI problems with Logic Analyzer
  Posted by atx on 31 Oct, 2014 05:36
• Heads up for those who want to play with the SCPI commands when the scope is in LA mode:
  
  While the Rigol MSO2k has a high sampling rate for the Logic Analyzer, analyzing the data is not really feasible IMHO, in particular when you are looking for a specific data section in a long sample. The solution to this problem is to transfer the raw data from the LA memory buffer to your computer and analyze it there with whatever program is available (I intend to write my own). The Rigol programming guide gives you all you need to know to get this done.  However, currently this doesn't work! I tried all the proper SCPI commands, setting the right mode, source, and points, etc, all that comes back is 2812 bytes no matter how large you set the points and any other relevant parameter. Moreover, whatever comes back is not the actual RAW samples but rather coincides with the screen memory buffer.  The same command sequence when applied to the analog channels seems to work, but not for the digital channels (source set to LA with :WAV:SOUR LA).
  
  I contacted Rigol directly and they promised to look into it.  That took a while and some friendly reminders but I finally got confirmation that they detected the same malfunction.  While this sucks for the moment, I like that Rigol did not try to hide this firmware error with some bogus excuse.  Rather, I was also promised to get a workaround which I will post here if anybody is interested and if they ever find one. So, until it has been fixed in a firmware update, don't waste your time...
  
  My MSO2k scope has
  firmware: 00.03.01
  Hardware version: 2.2
  
  atx
• #1 Reply
  Posted by Mark_O on 31 Oct, 2014 10:08
• Welcome to he Forum, atx, and thanks for the bug report!
  
  I too am glad they were forthright about the problem, but a bit surprised that it basically doesn't work at all.  Essentially what it means is that QC is extremely poor.  Or that they already knew about it, before you even told them.  And just hadn't gotten around to it yet,
• #2 Reply
  Posted by atx on 01 Nov, 2014 04:25
• Thanks Mark_O,
  I have no idea why this doesn't work at all.  My current workaround is to save the file on a USB stick and then transfer it to the computer.  However, that procedure is cumbersome and required some reverse engineering of the file format which was painful too. But due to the fact that the save function works, there clearly is a routine in there somewhere that dumps out the raw data from the LA memory.  The SCPI command just never gets there...
  
  That certainly should have not made it through QC.  I still have the impression that the US support didn't know about it as they could have stalled and delayed the answer much longer. The support person I was dealing with was very apologetic for not checking it out quicker and the moment he did, he immediately confirmed the malfunction.  But who knows.  I still have my hopes up that they gonna fix this in one of the next firmware updates  otherwise this is pretty useless when it comes to long samples...
  
  
  
  
• #3 Reply
  Posted by Mark_O on 02 Nov, 2014 10:36
• Quote from: atx on 01 Nov, 2014 04:25

  I still have my hopes up that they gonna fix this in one of the next firmware updates  otherwise this is pretty useless when it comes to long samples...
  

  
  I think an update with a fix is realistic, since these are new products that are both actively supported and popular.  The downside though is that until that update eventually happens (3 months, 6 months, whatever), you don't have a capability you already paid for. 
  
  On the bright side, since the SCPI commands to dump the analog data do work, perhaps fixing the SCPI to redirect to source the digital data storage will be an easy fix.  It just needs to return Words, rather than Bytes.
• #4 Reply
  Posted by atx on 03 Nov, 2014 05:23
• I think so too, even though the output format is similar to analog. When 8 channels are chosen, then each bit of one byte represents one of the channels.  For 16 channels, a sample is stored in a word representing all 16 digital channels.
  
  Anyway, in the meantime I was playing around with the decoding which is a bit tricky as mentioned elsewhere in the forum. So far I only checked the SPI protocol but I am slowly coming to the conclusion that the decoding function has been put together rather quick and dirty. While decoding of slow signals generally works, it will eventually collapse depending on various parameters: 
  
  - decoding screen position with respect to SPI signals horizontally shifts and eventually loses the decoding value completely: this depends mostly on memory depth but sometimes also whether the analog channels are on/off - very weird
  - decoding screen position is ok but decoding fails depending on memory depth and also depending on clock speed of the SPI signals which is really weird as the signals are captured just fine.  For example, a 10 Mhz SPI signal will decode correctly if the memory <7M.  As I said, it is only the decoding that is malfunctioning, the waveforms are perfectly sampled
  - similar behavior when in auto depth mode: It happens a bit less because the auto function doesn't allow large memory when the sampling rate is getting low which is bizarre in the first place...
  
  
  It looks like the decoding routine loses correlation/sync between the clock and data signals when the memory gets larger.  I used a 10MHz SPI sequence of x0, x1, x2 ... xFF and it is correctly decoded until the memory is set to 7M or reaches 2.8M in auto mode, then the decoding starts to output: x0, x3, x4, x7, x8, xB which would match a 1 bit left shift as my SPI signal retains the logic state of the last transmitted bit.  How correct decoding could be dependent on the memory size is more than puzzling to me. How can software fail on this? When it works the scope does a pretty good job displaying the data it in real time so maybe they use some faulty compression algorithm that gets out of sync. 
  
  So if you analyzed SPI data that is clocked under 1MHz, you might not have seen these problems.   
• #5 Reply
  Posted by Mark_O on 03 Nov, 2014 07:59
• Thanks very much for the detailed report.  Until the MSO version, the 2000 couldn't really do full SPI, because there weren't enough channels available.  But I agree it's odd that the problem seems to be memory-related.  My understanding was that decoding was all based on data in the display memory, which should be independent of such issues.
  
  I hope you'll update us when Rigol issues a firmware update, whether they have corrected these problems or not.
• #6 Reply
  Posted by atx on 06 Nov, 2014 05:59
• I reported the decoding issue to Rigol.  I got a reply that it has been forwarded to the product line.  So far there is no work around solution for the SCPI command malfunction.
  
  I did some tests with I2C and it has the same issues as SPI but due to the fact that I2C generally doesn't use high clock frequencies, it is less of an issue.  However, I managed to produce the same weird behavior in some cases, in particular, when setting the sample memory into the mega range.
  
  I'll post an update if I hear anything new. Did anybody experience the same issues with decoding on the MSO2k?
• #7 Reply
  Posted by kg6hum on 15 Nov, 2014 09:41
• I'm curious if you have heard anything back from Rigol?
  
  I have been looking at getting a MSO2072A since I am interested in a mixture of analog/RF and digital circuits.  I had seen a lot of complaints about the decoding features being a bit buggy, so I was considering doing the decoding on a computer.  I noticed that sigrok didn't support the newer MSO models.  With the problems you have been seeing, it sounds like decoding on a computer may not be an option.
  
  Would that mean the usefulness of the Rigol MSO scopes is mostly limited to viewing the signals on the screen?  If that is the case, I may be better off with a DS1000Z or DS2000A model and something like a Saleae Logic Pro.  The main downside would be not being able to see the analog and digital signals together.
  
  I hope that Rigol is able to fix the issue in a future firmware update.
• #8 Reply
  Posted by atx on 16 Nov, 2014 05:46
• I have to send a friendly reminder and then after a couple of days I basically get the same answer that my observations have been forwarded (regarding the decoding) and there is no news regarding a workaround or an update yet for the SCPI problem.  That doesn't necessarily mean there are not working on it, but who knows...
  Apparently the MSO is not as popular as the DS version and therefore there is no outcry in the community as for the jitter problem and thus also no reaction from Rigol either on this forum.  However, these are in my opinion significant malfunctions and I still hope they get fixed in one of the next updates... 
  
  Seeing the analog and digital channels together was the main reason for me to buy this scope and I think this feature is way superior (if it works) to any stand alone logic analyzer besides the fact that you only have one measurement device on your desk.  I am aware of the sigrok application but the version I tried out wouldn't even recognize the Rigol on USB even though they list the DS as compatible (it brings up some weird RS232 dialog).  That's when I decided to write my own and discovered the SCPI malfunction and later the decoding malfunction.
  
  I'll post something as soon as I get any news from Rigol.
  
       
• #9 Reply
  Posted by Mark_O on 16 Nov, 2014 07:00
• Quote from: atx on 16 Nov, 2014 05:46

  I'll post something as soon as I get any news from Rigol.
  

  
  Thanks for the update, atx. 
  
  I suspect there are folks here watching, who have put MSO2000 purchases on hold, pending resolution of this issue.  (And they should... since the 4000 is proof there is no guarantee that Rigol will fix known bugs.)
• #10 Reply
  Posted by atx on 22 Nov, 2014 21:06
• Here is the last response I got from Rigol last week, when I asked whether Rigol is actively working on the SCPI and Decoding malfunctions:
  
  "Sorry I don't have anything new to report. I do know the product line is actively working toward a solution but I don't know the amount of progress that has been made or an expected date.
  
  I am keeping in touch with the product line concerning this as I have more than one customer that's interested."
  
  atx
  
  
• #11 Reply
  Posted by Leiothrix on 23 Nov, 2014 05:59
• Quote from: Mark_O on 16 Nov, 2014 07:00

  I suspect there are folks here watching, who have put MSO2000 purchases on hold, pending resolution of this issue.  (And they should... since the 4000 is proof there is no guarantee that Rigol will fix known bugs.)
  

  
  I would be one of those people, just in case anyone is reading.
• #12 Reply
  Posted by David_AVD on 23 Nov, 2014 08:01
• Quote from: Mark_O on 16 Nov, 2014 07:00

  I suspect there are folks here watching, who have put MSO2000 purchases on hold, pending resolution of this issue.

  
  I cancelled my MSO-2072A (back)order after reading about what seem to be fairly series issues.  Just when I thought I'd found a good first DSO/MSO.   
• #13 Reply
  Posted by atx on 23 Nov, 2014 18:23
• The SCPI download malfunction is absolutely serious and I would have waited to buy this scope too if I had known.  That's why I posted this issue here.  But I have my hopes up that this will be fixed.
  
  The decoding problem is less serious in my opinion as analyzing a huge data sample on the scope is not really feasible without a search function. Even if the Rigol would have such a search function, inputting search values with turn knobs is painful. Thus, such a sample needs to be transferred to a PC and analyzed there.  The decoding works with lower memory settings which as mentioned above is really bizarre.  Here are screenshots of a 20 MHz SPI signal using a memory setting of 280 kPoints, 700kPoints  and 1.4 MPoints, respectively which I made back when I discovered this.  The settings are the same except for memory depth which is shown in the menu.  The correct values are shown in the 280 k pic.  As you can see using the larger memory does not affect the actual sampling of D0 and D2.  It is identical to the other ones.  But now the decoding placement gets left shifted in the 700 k pic with the decoding still intact and then when using the 1.4M apparently the decoding gets completely out of sync.
  
  

  ---

  

  

  
• #14 Reply
  Posted by marmad on 23 Nov, 2014 19:45
• Quote from: atx on 23 Nov, 2014 18:23

  The decoding problem is less serious in my opinion as analyzing a huge data sample on the scope is not really feasible without a search function. Even if the Rigol would have such a search function, inputting search values with turn knobs is painful.
  

  
  I created a video showing how to search for data packets using the Analyze function on the DS2000, but I'm assuming that many functions from the analog side don't work on the Digital channels, right? (e.g. Analyze, Pass/Fail, etc)
• #15 Reply
  Posted by atx on 23 Nov, 2014 23:26
• marmad,
  I remember watching that video but I never checked out the recording function with the digital channels.  I pretty much stopped looking into further decoding functions after I detected the malfunctioning.  I might revisit this and report back....
  
  atx
• #16 Reply
  Posted by electronic_eel on 23 Nov, 2014 23:45
• Hi atx,
  
  

  Quote from: atx on 31 Oct, 2014 05:36

  The solution to this problem is to transfer the raw data from the LA memory buffer to your computer and analyze it there with whatever program is available (I intend to write my own).
  

  Have you heard of http://sigrok.org/? Maybe it is more easy to add some features you want there than to reinvent the wheel.
  
  

  Quote from: atx on 31 Oct, 2014 05:36

  The Rigol programming guide gives you all you need to know to get this done.  However, currently this doesn't work! I tried all the proper SCPI commands, setting the right mode, source, and points, etc, all that comes back is 2812 bytes no matter how large you set the points and any other relevant parameter. Moreover, whatever comes back is not the actual RAW samples but rather coincides with the screen memory buffer.  The same command sequence when applied to the analog channels seems to work, but not for the digital channels (source set to LA with :WAV:SOUR LA).
  

  I'd like to test that with my MSO4000 and see if it has the same problem. I plan to use the decoding functions of sigrok and download the data into it via SCPI.
  
  Do you have the SCPI commands you used at hand? Anything else needed except configuring the LA for full memory buffering?
  
• #17 Reply
  Posted by atx on 24 Nov, 2014 03:33
• Hi electronic_eel,
  
  Yes I have heard of it and I think I even mentioned it in this thread.  I checked out PulseView which is supposed to work with the Rigol DS series.  The last version I tested brought up some weird serial port choice for connecting which does not even find the device let alone connect to it.  If you have tried it out successfully, let me know. It certainly looks good.
  
  
  To your second question:  This is the command sequence for the DS2000 which I forwarded to Rigol and which they confirmed produces the malfunctioning:
  (Your scope needs to have some LA activity with a memory setting greater than the screen).  Then use UltraSigma (or whatever else you have handy) to manually communicate with the scope as this takes long enough to ensure the scope has all data ready before you send the :WAV:DATA? command.  Otherwise there needs to be a loop checking the status:
  
  :STOP
  :WAV:SOUR LA
  :WAV:MODE RAW
  :WAV:FORM BYTE
  :WAV:POIN <xxxx> (set to a bigger number than the screen resolution)
  :WAV:RES
  :WAV:BEG
  :WAV:STAT?
  the machine then returns "IDLE,xxxx" which correctly indicates that the set number of bytes (>1400) are available for reading
  
  Now the following command:
  :WAV:DATA?
  Will only return about 2812 bytes on the DS2000 even if the IDLE response shows that over a million bytes area available.  Plus, that data doesn't correspond to the raw LA memory but rather to the screen buffer.
  
  atx
• #18 Reply
  Posted by electronic_eel on 24 Nov, 2014 22:18
• Hi,
  
  thanks for posting the commands. Don't have time right now to test, will do within the next few days.
  
  

  Quote from: atx on 24 Nov, 2014 03:33

  Yes I have heard of it and I think I even mentioned it in this thread.  I checked out PulseView which is supposed to work with the Rigol DS series.  The last version I tested brought up some weird serial port choice for connecting which does not even find the device let alone connect to it.  If you have tried it out successfully, let me know. It certainly looks good.
  

  I guess that was designed to work on Linux where the Scope is recognized as a USBTMC compliant device and automatically made available as serial device by the kernel. So on Linux you'd enter the filename of this serial device (like /dev/usbtmc0) into the menu in Sigrok. On Windows you need this whole bloated UltraSigma stuff to just talk SCPI with the scope, on Linux the kernel does all what is neccessary.
  
  Here is a totally untested idea how you could try connecting the scope to Sigrok: don't use usb, but ethernet. Then use a TCP-to-Serial-Program like http://sourceforge.net/projects/serialtoip/. The scope listens on port 5555 for SCPI commands. The program will connect this port to a virtual serial port in Windows. You can then use this port in Sigrok.
  
• #19 Reply
  Posted by biot on 25 Nov, 2014 01:51
• Quote from: electronic_eel on 24 Nov, 2014 22:18

  I guess that was designed to work on Linux where the Scope is recognized as a USBTMC compliant device and automatically made available as serial device by the kernel.
  

  
  No, that's not how USBTMC works in sigrok at all. We have our own USBTMC transport based on libusb, so it's cross-platform. Also, USBTMC devices are always auto-discovered, so you certainly shouldn't have to enter any connection information.
  
• #20 Reply
  Posted by atx on 25 Nov, 2014 05:12
• Quote from: marmad on 23 Nov, 2014 19:45

  I created a video showing how to search for data packets using the Analyze function on the DS2000, but I'm assuming that many functions from the analog side don't work on the Digital channels, right? (e.g. Analyze, Pass/Fail, etc)
  

  
  I checked this out and while it is a pretty cool function, unfortunately there is no option to mask any of the digital channels even though they are recorded.  Surprisingly, the decoding on the digital channel basically works even when activated after recording is done.  I didn't test it in all details (only with a low speed RS232 signal) and am pretty sure that it has similar flaws as discussed. However, I remember from your very good video that decoding didn't work in this mode for the analog channels. Also wonder whether Rigol plans to add some functions here later (after they fixed all the other stuff;)
  
  atx
• #21 Reply
  Posted by marmad on 25 Nov, 2014 05:37
• Quote from: atx on 25 Nov, 2014 05:12

  I checked this out and while it is a pretty cool function, unfortunately there is no option to mask any of the digital channels even though they are recorded.

  
  Yeah, I thought that might be the case. I checked on the MSO1074Z I have here and noticed it wasn't possible to mask the digital channels.
  
  

  Quote

  Surprisingly, the decoding on the digital channel basically works even when activated after recording is done.  I didn't test it in all details (only with a low speed RS232 signal) and am pretty sure that it has similar flaws as discussed.

  
  That's good to know that decoding on the digital channels works on the segments. I haven't tested it yet on the MSO1074Z but will soon.
  
  BTW, I'll also test reading the LA data out via SCPI on the MSO1074Z to see if it works on this model.
  
  Mark
  
• #22 Reply
  Posted by atx on 25 Nov, 2014 05:47
• Marmad,
  I just played with the analog recording function and noticed that on my MSO the decoding actually works.  So the MSO doesn't have a problem with that.  It also works after recording similar as for the digital channels.  I just missed to adjust the trigger level...
  atx
• #23 Reply
  Posted by atx on 25 Nov, 2014 06:39
• Quote from: biot on 25 Nov, 2014 01:51

  
  No, that's not how USBTMC works in sigrok at all. We have our own USBTMC transport based on libusb, so it's cross-platform. Also, USBTMC devices are always auto-discovered, so you certainly shouldn't have to enter any connection information.
  
  

  
  I tried it again, but I cannot get this to work, no matter which USB library I select via the enclosed zadig tool.  All I see is what I attached. With no detection of the Rigol.
  
  If anybody gets this to work, let me know what I am doing wrong.

  ---

  
• #24 Reply
  Posted by marmad on 25 Nov, 2014 10:25
• 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.

  ---