Rigol MSO2000 SCPI problems with Logic Analyzer - Page 1
Forum section: electronics / testgear

author: atx
author_rank: Contributor
timestamp: October 31, 2014, 05:36:23 am
content: 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 hasfirmware: 00.03.01Hardware version: 2.2atx

author: Mark_O
author_rank: Frequent Contributor
timestamp: October 31, 2014, 10:08:12 am
content: 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,

author: atx
author_rank: Contributor
timestamp: November 01, 2014, 04:25:37 am
content: 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...

author: Mark_O
author_rank: Frequent Contributor
timestamp: November 02, 2014, 10:36:21 am
content: Quote from: atx on November 01, 2014, 04:25:37 amI 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.

author: atx
author_rank: Contributor
timestamp: November 03, 2014, 05:23:46 am
content: 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.

author: Mark_O
author_rank: Frequent Contributor
timestamp: November 03, 2014, 07:59:47 am
content: 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.

author: atx
author_rank: Contributor
timestamp: November 06, 2014, 05:59:36 am
content: 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?

author: kg6hum
author_rank: Newbie
timestamp: November 15, 2014, 09:41:15 am
content: 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.

author: atx
author_rank: Contributor
timestamp: November 16, 2014, 05:46:48 am
content: 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.

author: Mark_O
author_rank: Frequent Contributor
timestamp: November 16, 2014, 07:00:00 am
content: Quote from: atx on November 16, 2014, 05:46:48 amThanks 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.)

author: atx
author_rank: Contributor
timestamp: November 22, 2014, 09:06:28 pm
content: 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

author: Leiothrix
author_rank: Regular Contributor
timestamp: November 23, 2014, 05:59:26 am
content: Quote from: Mark_O on November 16, 2014, 07:00:00 amI would be one of those people, just in case anyone is reading.

author: David_AVD
author_rank: Super Contributor
timestamp: November 23, 2014, 08:01:09 am
content: Quote from: Mark_O on November 16, 2014, 07:00:00 amI 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.

author: atx
author_rank: Contributor
timestamp: November 23, 2014, 06:23:22 pm
content: 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.

author: marmad
author_rank: Super Contributor
timestamp: November 23, 2014, 07:45:59 pm
content: Quote from: atx on November 23, 2014, 06:23:22 pmI 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)

author: atx
author_rank: Contributor
timestamp: November 23, 2014, 11:26:31 pm
content: 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

author: electronic_eel
author_rank: Regular Contributor
timestamp: November 23, 2014, 11:45:12 pm
content: Hi atx,Quote from: atx on October 31, 2014, 05:36:23 amHave you heard ofhttp://sigrok.org/? Maybe it is more easy to add some features you want there than to reinvent the wheel.Quote from: atx on October 31, 2014, 05:36:23 amI'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?

author: atx
author_rank: Contributor
timestamp: November 24, 2014, 03:33:24 am
content: 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 readingNow 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

author: electronic_eel
author_rank: Regular Contributor
timestamp: November 24, 2014, 10:18:43 pm
content: 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 November 24, 2014, 03:33:24 amI 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 likehttp://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.

author: biot
author_rank: Regular Contributor
timestamp: November 25, 2014, 01:51:31 am
content: Quote from: electronic_eel on November 24, 2014, 10:18:43 pmNo, 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.

author: atx
author_rank: Contributor
timestamp: November 25, 2014, 05:12:29 am
content: Quote from: marmad on November 23, 2014, 07:45:59 pmI 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

author: marmad
author_rank: Super Contributor
timestamp: November 25, 2014, 05:37:30 am
content: Quote from: atx on November 25, 2014, 05:12:29 amYeah, 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.QuoteThat'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

author: atx
author_rank: Contributor
timestamp: November 25, 2014, 05:47:13 am
content: 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

author: atx
author_rank: Contributor
timestamp: November 25, 2014, 06:39:51 am
content: Quote from: biot on November 25, 2014, 01:51:31 amI 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.

author: marmad
author_rank: Super Contributor
timestamp: November 25, 2014, 10:25:33 am
content: 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.

author: atx
author_rank: Contributor
timestamp: November 27, 2014, 09:09:33 pm
content: Quote from: marmad on November 25, 2014, 10:25:33 amInteresting, the MSO2k does not have this function. Any results for the SCPI memory read out function?

author: marmad
author_rank: Super Contributor
timestamp: November 27, 2014, 09:25:25 pm
content: Quote from: atx on November 27, 2014, 09:09:33 pmNo chance to test it yet, but I'll post here as soon as I do.

author: atx
author_rank: Contributor
timestamp: December 03, 2014, 03:57:38 am
content: 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 channels2GSa - 1GSa1GSa - 1GSa500MSa - 500MSa200MSa - 125MSa100MSa - 25MSaetc.. (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

author: kg6hum
author_rank: Newbie
timestamp: December 03, 2014, 09:57:17 am
content: Quote from: atx on December 03, 2014, 03:57:38 amWouldn'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.

author: Mark_O
author_rank: Frequent Contributor
timestamp: December 03, 2014, 09:59:54 pm
content: Quote from: atx on December 03, 2014, 03:57:38 amWow. 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.

author: marmad
author_rank: Super Contributor
timestamp: December 07, 2014, 06:11:33 pm
content: 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).

author: atx
author_rank: Contributor
timestamp: December 08, 2014, 06:19:48 am
content: Quote from: Mark_O on December 03, 2014, 09:59:54 pmYou're welcome. I wish I would have known, but I certainly keep posting. So far no response from Rigol.Quote from: marmad on December 07, 2014, 06:11:33 pmI 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.atxatx

author: atx
author_rank: Contributor
timestamp: December 24, 2014, 04:23:52 am
content: 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 #27The 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

author: atx
author_rank: Contributor
timestamp: December 31, 2014, 08:44:09 pm
content: Some news: There is a new firmware out 00.03.03.SP1After 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

author: kg6hum
author_rank: Newbie
timestamp: December 31, 2014, 11:08:19 pm
content: 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.

author: atx
author_rank: Contributor
timestamp: January 02, 2015, 04:06:31 am
content: Quote from: kg6hum on December 31, 2014, 11:08:19 pmI 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 directlyAnyway, let's hope for the bestatx

author: meltTemp
author_rank: Newbie
timestamp: January 02, 2015, 12:18:48 pm
content: 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

author: e_60
author_rank: Contributor
timestamp: January 09, 2015, 07:37:05 pm
content: 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.

author: etl17
author_rank: Contributor
timestamp: January 09, 2015, 09:31:27 pm
content: 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.

author: e_60
author_rank: Contributor
timestamp: January 10, 2015, 03:08:07 am
content: 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).

author: atx
author_rank: Contributor
timestamp: January 10, 2015, 06:45:33 am
content: Quote from: meltTemp on January 02, 2015, 12:18:48 pmmeltTemp,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

author: atx
author_rank: Contributor
timestamp: January 10, 2015, 06:56:31 am
content: Quote from: e_60 on January 10, 2015, 03:08:07 amThe 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

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 10, 2015, 11:23:12 am
content: Quote from: atx on January 10, 2015, 06:56:31 amI 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.QuoteWell, 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).

author: e_60
author_rank: Contributor
timestamp: January 10, 2015, 07:50:03 pm
content: 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.

author: atx
author_rank: Contributor
timestamp: July 09, 2015, 05:38:25 am
content: 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 - works1Gs/s 1.4M - works1Gs/s 14M - fails500Ms/s 140k - works500Ms/s 1.4M - fails125Ms/s 8.75k - works125Ms/s 87.5k - works125Ms/s 8.75M - fails25Ms/s 7k - works25Ms/s 70k - failsWhile 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

author: Mark_O
author_rank: Frequent Contributor
timestamp: July 09, 2015, 06:14:25 pm
content: 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).

author: atx
author_rank: Contributor
timestamp: July 10, 2015, 04:40:09 am
content: Quote from: Mark_O on July 09, 2015, 06:14:25 pmMark,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

author: khaahk
author_rank: Contributor
timestamp: July 14, 2015, 09:03:18 pm
content: 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...

author: atx
author_rank: Contributor
timestamp: July 16, 2015, 05:37:44 am
content: 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