Products > Test Equipment
Sniffing the Rigol's internal I2C bus
<< < (552/899) > >>
stuartk:
I've had an unanticipated error in Ultra Sigma after placing the codes for my DS2102

The print screen function no longer works. I can still communicate by SCPI.

Uninstalling/reinstalling Ultra Sigma - NI  or the scope made no difference.

Has anyone else noticed this behavior? I wonder if it's a consequence of mangled serial number syndrome.

Thanks, Stuart
Marc M.:

--- Quote from: Co6aka on January 29, 2014, 03:07:05 am ---...if servicing a scope, if we had to do a board swap how would we program the instrument's SN and KEY to the new board?...
--- End quote ---

In the case of Rigol with hardware V1.0 boards - they don't.  At least not the S/N, I can't say how keys are handled as I didn't have any installed.  A while back I sent my scope in to Rigol NA for warranty work.  When I received the repaired scope back, sure enough I had the dreaded corrupted S/N reset to ...001  :--.  I used the serial/model # file I posted earlier to successfully correct the  S/N. 

While verifying my info was still correct, I happened to notice that my horizontal timebase now topped out at 500ps :-+.  I verified that it was indeed sweeping at 500ps/div by applying a 400 MHz signal and making sure it displayed a period of 5 divisions which it did (naysayers see attached pics).  I then re-applied the 300 MHz codes and it retained the 500ps setting.  Finally, I power cycled the scope and it lost the 500 ps setting.  At that point I again uninstalled the options via SCPI and the 500ps sweep rate returned.  I power cycled the scope again and tried sending the uninstall command again (without any active licenses) and it did not activate the 500ps sweep rate.  I didn't notice this behavior until after correcting my serial # and I see at least one other member mentioning having a 500ps time base setting as well.  Throughout this process, my model # has been stuck as DS2302 regardless of what/any licenses installed.  I was running firmware 00.02.01.00.03 with license code DSHH. 

At this point I removed all licenses and reflashed 00.01.01.00.02 firmware.  After power cycling the scope, my model # reverted back to DS2072.  I then applied the old DSA9 license code, power cycled, and the model changed to DS2202 as expected.  I again uninstalled the options and checked the horizontal timebase and sure enough, I had 500ps again.  However, this time the timebase was actually still running at 1ns even when switched to 500ps, just throwing the trigger point off a couple of divisions.  Once again, the 500ps setting disappeared after power cycling the scope.

Next, I reflashed the 00.02.01.00.03 firmware back onto the scope.  After power cycling the model remained DS2072.  I then installed the DSHH codes.  Although all options were installed, the model # remained DS2072.  The 500ps setting returned but again it was still running at 1ns/div. with the offset trigger.

The only obvious difference between when I had real 500ps horizontal rate and the fake 500ps rate was the model number.  So I took a chance and used the snmodfix.exe utility I posted earlier to forcefully change the model # back to DS2302 to see if it had any effect on the 500ps rate. This time around, I was unable to change the model # - it stayed DS2072 even with DSHH applied. I then tried to change both the S/N and model number.  The S/N changed but the model # didn't - still stuck on 2072.  If I reflash .02 firmware and apply the DSA9 key, it changes to 2202.

I've been too busy with other things lately to play further.  At this point it appears that the model # may affect the behaviour of applied keys inferred from having a real 500ps timebase when it was a DS2302 to a 5ns timebase (even with the DSHH key applied) when it's model # is 2072.  Also, it appears that there are certain circumstances where the utility to alter model/serial numbers will fail to do so as other members have experienced.  So far the author doesn't understand why it's failing to work and hasn't been able to replicate the failure on his scope.  The good news is I've confirmed it's capable of a 500ps horizontal time base if we can just determine the mechanism required to invoke it permanently.  As I get some free time I'll experiment further.
marmad:

--- Quote from: Marc M. on February 01, 2014, 11:33:48 am ---The good news is I've confirmed it's capable of a 500ps horizontal time base if we can just determine the mechanism required to invoke it permanently.  As I get some free time I'll experiment further.

--- End quote ---

Interesting story - but just because the DSO is capable of being forced into providing a function which isn't listed in the specs, doesn't mean it's advantageous in the grander scheme of things to do so. This is evidenced by the fact that the 1ns time base (which is a by-product of the 300MHz option) is fairly buggy.

During the 15 previous months I owned the DS2000, I found it extremely stable - perhaps locking up (i.e. crashing) 3 or 4 times in total over that period. OTOH, after enabling the 300MHz/1ns option, I had that many crashes within a week. Conclusion: the trouble was not worth the small benefit gained.
zombie28:

--- Quote from: poida_pie on January 29, 2014, 04:17:18 am ---What chances are there to patch a firmware so that it outputs the key and serial when you send it
"*IDN?". That would be good.

--- End quote ---

Done!

https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).
tiagobaracho:
Guys... Sorry to bother..
I bought one Rigol DS2072A
It shows Software version 00.02.00 and Hardware version 2.0... Is that possible to use the 200 mhz and high memory settings ?
I have been reading a lot of pages in this thread but i could not find....
Thanks
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod