The Rigol DS1052E

[David]

Anyone know of the cheapest supplier of Rigol scopes for UK customers? I am sure they used to be on ebay for £200 from China before they all got removed?

Dave

[EEVblog]

Anyone know of the cheapest supplier of Rigol scopes for UK customers? I am sure they used to be on ebay for £200 from China before they all got removed?

See:
https://www.eevblog.com/forum/index.php?topic=6.msg3392#msg3392
Joy at MCS is an official UK rep and has it for £281, which sounds like a top price for buying from an official dealer.

Dave.

[David]

Thanks Dave, looks like a good future purchase.

P.S - Good work on the For sale section! I was going to suggest such an idea.

Dave

[Simon]

Anyone know of the cheapest supplier of Rigol scopes for UK customers? I am sure they used to be on ebay for £200 from China before they all got removed?

See:
https://www.eevblog.com/forum/index.php?topic=6.msg3392#msg3392
Joy at MCS is an official UK rep and has it for £281, which sounds like a top price for buying from an official dealer.

Dave.

just remember that you need to add VAT to that (17.5 % in the UK) but it is still a good price

[drieg]

...just wish we could find out where the Model and Serial are stored in the scope as i believe i may have corrupted this area when changing the model number, the scope has a few problems. Still im not sure its hardware or software, but id like to try rewriting the correct info back into the scope to see if that can solve it. As you can see from a previous post( with link to RC groups http://www.rcgroups.com/forums/showthread.php?t=1222045) someone else has also managed to corrupt this data and has very similar problems to my scope.

You are definitely right. Using serial cable (especially in connection with HyperTerminal) is very risky way, how to upgrade your DS1052E to DS1102E. In some cases it corrumpts part of internal flash memory. Especially if you accidentally hit the ENTER instead of sending correct <LF> code, you can bet that you have just corrupted some data. Sometimes I've experienced these corrupted data even if I sent correct <LF>. Internal flash holds some important factory calibration data (different from Self-Calibration) which are unique to every unit. There is no easy way how to recreate these data if they gets corrupted. So this is the reason why I DO NOT RECOMMEND TO DO IT VIA SERIAL CABLE! I know what I'm talking about.

Check these cases:
https://www.eevblog.com/forum/index.php?topic=30.msg2901#msg2901
https://www.eevblog.com/forum/index.php?topic=30.msg2954#msg2954
https://www.eevblog.com/forum/index.php?topic=30.msg3270#msg3270
http://www.rcgroups.com/forums/showthread.php?t=1222045

@Dave: I'm sorry to say, but I don't think it was a good idea to make a video encouraging people to do this...

[Ferenczyg]

Then, what approach is the rigth one? USB and the National Instruments Tool?

/F

[Mark_O]

Using serial cable... is very risky... In some cases it corrupts part of internal flash memory. Especially if you accidentally hit the ENTER instead of sending correct <LF> code, you can bet that you have just corrupted some data. Sometimes I've experienced these corrupted data even if I sent correct <LF>.

Drieg, thanks for raising a flag on this.  Your second point I find most alarming.

Internal flash holds some important factory calibration data (different from Self-Calibration) which are unique to every unit.

Yes.  People should think of it like this.  The precise values of the components in every Rigol unit is different.  So during the initial factory calibration process, they fed in specific reference standard values in each range, and save the correction factors in NVM.  These are per channel, per voltage range, per frequency range base/offset values.  Those are what the scope uses when it later does it's own self-cals.  It has to have an externally supplied and internally remembered reference to calibrate to.  Normally, once set, these would never be changed, and thus the scope has a solid reference to rely on.  But when backdoor mods are done, it's possible to change more than what you were planning on.  Once overwritten, they're gone.  

You mentioned "internal flash".  Do you happen to know where this non-volatile data is being stored?  I had assumed EEPROM.

Lastly, is sending these commands via USB any safer?  I.e., isn't sending too long a string still a potential (though more easily avoided) problem?  I would think if done properly they would be 100% reliable and safe, since that's how it's done in the factory.

- Mark

[Mark_O]

BTW, the downside of all this is that it's essentially destroyed the resale value of used Rigols.    It's the Law of Unintended Consequences.

Why do I say that?  Because now there's no way to know whether a used unit was tampered with.  Even if it's set back to 1052E, you don't know what's been done with it.  And so far, if a unit is modded improperly, there's no way to recover vital data.  It still displays a trace, but there are strange and unexplained behaviors.  The bottom line is that there is invisible data that's critical to proper Rigol operation.  Normally that data is secure, but a side-effect is that this data is vulnerable and can be undetectably destroyed.  

One thing that no one here has done is perform a full set of base measurements with their unit (reference set), and then compare them with the readings after the mod.  That would be extremely time-consuming, and here was no reason to think it was necessary.  Yes, several have done some spot and range checks, which were indicative of good results (mostly at the high end of the frequency spectrum).  But we don't know WHICH reference data is located immediately after the strings involved.  So the problem might be only on, e.g. Chan2, 200-2000 mV, in a certain frequency range.

Who'd like to buy shafri or dimlow's unit now (sorry, guys), and try to use it for meaningful measurements you can rely on?  Now, potentially any unit you come across could be like this.  The mod has certainly been publicized widely enough.  Until we find a solution to their problem (if one exists), it's now a problem for everyone.  While shafri's problem may be very obvious, due to his making repeated mistakes when sending strings in, others may be much more subtle.  I'd really like to hear more from Drieg on the corrupted data he's experienced when sending the proper <LF> terminator.

Rigol may even need to get involved with this, since it could completely undermine their integrity as an instrument that can be trusted.  And it was their oversight that left the door open to this damage, so ultimately it's THEIR responsibility.  Yeah, let's blame it on them.  

- Mark

[EEVblog]

@Dave: I'm sorry to say, but I don't think it was a good idea to make a video encouraging people to do this...

Err, so I shouldn't have told anyone about it at all?
What is a safer method? USB and a linux script? maybe, but plenty of people have had success with the serial port, with only a few failures it seems, and they probably didn't follow the instructions.
If you follow my instructions you shouldn't corrupt your firmware.

Dave.

[Simon]

I can't see what the hype is about over calibration etc, the 1052 and the 1102 are the SAME machine and work in the same way, the only difference is that the input filter on the 1052 is told to lower it's bandwidth and the firmware will allow you to go to 2ns/div. I don't quite see here. of course if data that is required for calibration is overwritten then well it's an issue but frankly if changing the model in the same way as rigol clearly do it can have such adverse effects who is to say that rigol are not selling scopes that are already defective, their firmware should be more solid, this is after all a feature that they put in themselves. really this is no "hack" this is how the machine was made, it was meant to do this but we were never told

[Mark_O]

Dave,
> plenty of people have had success with the serial port <

They seem to have had.  Though I'd really like to hear more from Drieg on the corruption he experienced.  It could be quite subtle.  Or he could just have been using a unit from a different hardware batch.

> ...with only a few failures it seems, and they probably didn't follow the instructions. <

The folks reporting significant problems most certainly went beyond the boundaries.

> If you follow my instructions you shouldn't corrupt your firmware. <

We hope.  It's possible there could be a single corrupted byte, and it may not matter.  E.g., byte alignment for word data may have the critical information starting one byte later than the string termination.

- Mark

[Mark_O]

Simon commented:
> I can't see what the hype is about over calibration etc <

That's very true.  You can't see it.     However, that does not stop it from being a potential problem, in spite of that.

> the 1052 and the 1102 are the SAME machine and work in the same way... <

Irrelevant.

> of course if data that is required for calibration is overwritten then well it's an issue <

Bingo.

> but frankly if changing the model in the same way as rigol clearly do it can have such adverse effects... <

The point being precisely that Rigol does NOT change the Model "in the same way".  They do it over USB.  Just because the RS232 and USB commands operate in the same way most of the time, doesn't mean they do in all cases.  These are "special" commands, and I might point out again, in case anyone has forgotten, also undocumented.

- Mark

[EEVblog]

Sure, this needs some investigation and further monitoring, and if it turns out to be a serious problem then it needs to be addressed, and I'll be happy to alert people once facts are known.
But until then it's all just speculation really.
What can I say, my unit appears to work just fine on every range and function I have tried it on.

It's an undocumented hack, so as always, mod at your own risk.

I think it's not very feasible that there is a technical difference between using USB or serial. And nobody knows how Rigol do it at the factory, but the command exists, so I'd be surprised if that's not how they do it. But they probably have an automated script.

Dave.

[Mark_O]

Dave commented:
> I think it's not very feasible that there is a technical difference between using USB or serial. <

Of course there is.  Higher-level software can make them look similar, but USB doesn't handle variable-length strings, with terminators.  It handles blocks of data, with size info in the header or descriptor.

With serial, you're looking at an endless stream of bytes.  Byte come in and are processed one at a time.  Things like control characters (e.g., BS) that you'd think would be handled by a command parser, aren't.  They're just another character.  CR's don't work.  They're not a line-terminator, as you'd expect.  It's not until you hit the specific terminator character it is looking for (LF, ^J, or Alt-010) that it then attempts to process the command you've typed.

> my unit appears to work just fine on every range and function I have tried it on.  It's an undocumented hack, so as always, mod at your own risk. <

Yes, and as you pointed out, it seems to have worked well for many others too.  So hopefully, you (and they) are all in the clear.  There's a good chance that is the case, and there's "No worries, mate".  But until we get more information from Drieg, that apparent success itself is, as you say "just speculation really".  

And for those who blindly (as in, didn't understand the ramifications) typed in strings that were too long (NOT the people who followed your video, to the letter)... they're in a pickle.  This is a really easy mistake to make, since all our experience typing commands into things tells us that we can do things like back up and fix mistakes.  And hit Enter when we're done.  And that if we type in something that's too long, the software will just chop off the excess for us.  But none of that applies on the Rigol.    Which is where the problems are coming from.  This is a sharp-edged sword... without a proper grip.

- Mark

[rossmoffett]

I don't see that all of this bold print and borderline ridicule are merited... We're just discussing oscilloscope modification here, after all.  Keeping the conversation civil would be helpful to everyone.

With the problems people are experiencing using serial modifications, I also suggest that people try to use the USB protocol (who knows whether this is what Rigol does at the factory, until they say so I don't think anyone can guess).  I had intended to do it this way myself, but because I have only two weeks left of university things are really hectic and I just threw together a three-pin serial cable to do my modification.  All sorts of things can go wrong when using serial com, as has been mentioned thoroughly, but I don't see how Dave can be held liable for this.  Would you say the same to user mxmxmx?  To me, for posting my hardware mod?  After all, my mod was corrected by user JimBeam later (and I'm happy for it, I didn't know better).  This is how things get done by groups on the internet, post everything, if it doesn't work, it'll come out eventually.

It's unfortunate that some units have been made unusable, but everyone should know they take their own risks when performing "hacks" to their equipment.  It's just the way it is, regardless of how it's portrayed.  Right now the success rate seems awesome, more users than are posting have probably done this successfully, as I'm sure any unsuccessful users would post for help.

[rct]

I think it's not very feasible that there is a technical difference between using USB or serial.

I may not know much about hardware, but that's a bad assumption when it comes to software.  I can see many ways that the code paths in the firmware between handling serial input and USB input can be different.   Even forgetting that, the byte stream the computer sends to the scope can be very different depending on whether it is line based or character based.

Unless the terminal emulator has been set into a line buffered mode, every character typed will be sent as it is typed.  So if you type *, I, D, X, <backspace>, N, ?,  <newline>.  It is up to the rigol to interpret the backspace, erase the X and leave the pointer there.  It doesn't do that, so the input buffer contains *IDX<BackSpace>N?.  When it tries to interpret that it will be considered an invalid command and be ignored (doesn't match the stored string).  If you type *IDN?<return><newline>, it will also ignore the input as not valid (again the string compare that it is likely doing doesn't match)

Here's a test you can do to see how the "parser" is behaving.  First disable local echo, so it doesn't mislead you about what you are sending to the scope.  When you type a command like *IDN? to the scope and hit alt-010 to get a newline, after the response text, the cursor goes down one line and does not return to the left edge of the screen since there is no carriage return.   To see that the scope's serial parser will add happily control characters to the parameter buffer try entering :IO:TEST testing<return><newline>.  The scope will echo "testing", a carriage return, and a newline, so the cursor should now be on the left in column 0.   If you have local echo off, the carriage return came from the rigol, showing that it was part of the input buffer that was echoed back.   Now type :IO:TEST abc<return>testing<newline>.    You will see testing.  (the abc if the cursor was started column 0 was echoed but was written over on the screen by "testing".  The carriage return was stored in the middle of the buffer.

So using a terminal emulator (especially with local echo turned on) it's entirely possible people could be writing very long strings like :INFO:MODEL DS1052<bs><bs><bs>1102e<bs>D<cr><bs>

I just checked the video, you don't say you can't hit backspace while typing.  Of course during the video you typed the strings perfectly.

So You should probably warn people they can't make any mistakes while typing these commands.  I suppose one thing people could do would be to type the commands into Notepad, verify they are correct and then very carefully copy & paste one line at a time   I don't see a line buffered or "cooked" mode for hyper terminal.

I can't think of a safe way to abort the command entry once you've started typing.  The safest thing I can think of is to enter the newline to end the command early so it will be a short string and then start over, *without* rebooting the scope until the bad input has been corrected.

[dimlow]

well, i just confirmed that long strings are not the problem. As my scope is buggered, i just set my serial and model no to 123456789123456789123456789123456789123456789123456789

*idn? responds with

Rigol Technologies,123456789123456789123456789123456789123456789123456789,123456789123456789123456789123456789123456789123456789,00.02.02.02.00

but the system info screen now shows model as 123456789123456789123456789123456789123456789123456789
and the serial no surprisingly is now showing DS10000001

if i do another *idn? after a reboot i still get the same as above, so im now thinking the serial that is displayed on screen, is not stored as a string but is decoded from the string you send it. but still that string is stored and retrieved from memory when you do *idn? or :info:serial?

long sting lengths dont seem to be the problem here, i think maybe it has something to do with my scope crashing whilst setting the model or serial no, pretty sure its nothing to do with string lengths

[EEVblog]

I think it's not very feasible that there is a technical difference between using USB or serial.

I may not know much about hardware, but that's a bad assumption when it comes to software.  I can see many ways that the code paths in the firmware between handling serial input and USB input can be different.   Even forgetting that, the byte stream the computer sends to the scope can be very different depending on whether it is line based or character based.

I was assuming that Rigol would simply implement a standard USB to serial converter in there somewhere, and use the serial interface (from RS232 or USB) as the lowest common denominator interface. From a design point of view that would reduce the need to code two entirely separate serial interfaces. But I have not looked into this at all, so they could very well be entirely different beasts.

Dave.

[EEVblog]

So You should probably warn people they can't make any mistakes while typing these commands.

I've added a note to the blog page. It's not possible to update the video.

I can't think of a safe way to abort the command entry once you've started typing.  The safest thing I can think of is to enter the newline to end the command early so it will be a short string and then start over, *without* rebooting the scope until the bad input has been corrected.

FYI
I actually had several attempts at it before I got it to work, I accidentally pressed ENTER and backspace etc too several times, and even switched the unit off half way through. Several times it model number would not stick after the reboot.
But like I said, I had no issues at all, hence there was no warning in the video as there did not appear to be any risks at the time. And maybe there still isn't any risk, perhaps it's something else entirely as Dimlow suspects?

Dave.

[rct]

well, i just confirmed that long strings are not the problem. As my scope is buggered, i just set my serial and model no to 123456789123456789123456789123456789123456789123456789

I think all that proves is that there is no bounds checking in the way the command is implemented, and that the string is read out as a string with a terminator (probably null) instead of a fixed length. 
 
I think the question is now that a long string has been written has any of the scope's behavior changed?  (after a reboot)

The affect of writing the longer string depends on how the flash/nvram memory is organized and updated.  If that was a fixed string size it overwrote something immediately after it.    If the flash is organized as say a list of null terminated attribute value pairs that gets completely rewritten as a whole unit, it might not cause any issues if there is enough free space in the flash.   If there wasn't enough extra space possibly something could fall off the end.

We'll know a lot more if anyone determines a method for reading the contents of the flash/nvram.   Maybe with a bus pirate...   but that's a different blog...

[rct]

And maybe there still isn't any risk, perhaps it's something else entirely as Dimlow suspects?

I'm not saying we understand what is going on inside.  However, I think the change would be least likely to have any unintended side effects if the model & serial strings stayed exactly the same length without any hidden control characters (like backspace, carriage return).    Unfortunately I think it is very easy for someone typing at a terminal emulator to do so without being aware of it.

Dimlow, if you're game for testing things on your scope, could you try a test to prove it will blindly store control characters?      If you type :INFO:SERIAL bad<backspace><backspace><backspace>123456789<return><newline>  Then do a :INFO:SERIAL?<newline>  I think it will display as 123456789 and the cursor will move to column 0 instead of just dropping down mid-screen.   It might look like you entered what you intended and when you display it would display as what you intended plus the extra carriage return which you might not even notice,  but if you were able to look at the actual bytes coming back you'd see 'bad<0x08><0x08><0x08>123456789<0x0xd> and the length of the string would be 16 instead of 9 (not counting the terminator).

[Mark_O]

well, i just confirmed that long strings are not the problem. As my scope is buggered, i just set my serial _and_ model no to 123456789123456789123456789123456789123456789123456789

dimlow, most excellent!  I would have been worried that a string that long would result in a totally non-functional unit.  Doing both was pretty brave.  Are you sure though that things didn't get worse?

i think maybe it has something to do with my scope crashing whilst setting the model or serial no, pretty sure its nothing to do with string lengths

Based on what you did (BOTH strings super long) that would sure seem to the case.  There's been lots of experimenting going on, without noting what the detailed steps were when things went wrong.  I was kind of hoping it was string-related, because that held some hope of resolving your problem without the expense of a round-trip to China.  If it really was due to a crash, as you suspect, that would seem to make it more unlikely (though not impossible) you could fix it yourself.

- Mark

[Mark_O]

I was assuming that Rigol would simply implement a standard USB to serial converter in there somewhere, and use the serial interface (from RS232 or USB) as the lowest common denominator interface. From a design point of view that would reduce the need to code two entirely separate serial interfaces.

That really is a good and logical assumption.  However, like lots of embedded controllers these days, the devices in the Rigol have many independent comm channels available.  They've got USB with MSD (mass-storage device) Class.  Another USB with serialDevice Class.  And an RS232 port.  All independent, AFAIK from browsing the spec sheets.

- Mark

[Mark_O]

Ross wrote:
> I don't see that all of this bold print and borderline ridicule are merited...  Keeping the conversation civil would be helpful to everyone. <

I just went back and looked, and the only one I see bolding anything is me.  Apparently you're not a fan of my writing style.  That's fine.

But when you refer to "ridicule" and imply that the conversation has not been "civil", I'm really confused.  At no time has it been my intent to ridicule anyone (except Simon , and he's been a good sport about it).  Like everyone else here, I've simply been trying to make a contribution to the discussion.  Nor did I realize I was being uncivil.  Thanks for clarifying that for me.

Luckily, it's a problem easily rectified.  I have lots of ways and places to spend my time.

- Mark

[Simon]

At no time has it been my intent to ridicule anyone (except Simon , and he's been a good sport about it).

- Mark

Story of my life 

I was very shaky about the mod but now you see why, I was a dumb noob asking stupid questions because I don't like messing with things that costs me lots of money and wrecking them. Luckily mine went off without a hitch but I did take the precaution of copying and pasting the commands from this thread, once they the exact method had been posted