Sniffing the Rigol's internal I2C bus

[true]

bfin ida cpu module
be warned however, it has bugs - if aX registers are in use (math heavy stuff) you can not trust the ida output, take it from objdump or gdb bfin if so.
the bfin stuff is kraters work, not mine. those modules where compiled on a x86 32 bit, for ida 6.2 - might not work with other ida versions.

im currently working on enhancing the bfin flirt tools from krater or probably rewrite them because somehow they dont seem to work right.
then it should be possible to get better matchrate for VDSP libraries to the firmwares - which will ease reversing them.

thanks man, it's a start and should be good enough for looking for what I am looking for. much appreciated

After installing the keys on my DS2072 and making it 2202 I've got a strange bug that corrupts saved to external USB key images (format independent). Has anybody noticed this?

nope, haven't tried, but I may do that now. or maybe I tried but didn't notice it, can't remember. any type is corrupted?

[Marc M.]

After installing the keys on my DS2072 and making it 2202 I've got a strange bug that corrupts saved to external USB key images (format independent). Has anybody noticed this?

That's unfortunate .  I just checked mine saving a .png and there's no corruption.  I'm running version .02 and had been prior to installing any keys.  Also, I had used both DSA9 and DSAZ keys prior without any issues.

[tlu]

Can someone who recently purchased a dsa815 or dsa815-tg verify that the 10hz RBW is part of the trial option? There seems to be conflicting results at the moment.

If the 10hz RBW is not part of the trial option, does it mean it may actually be hardware specific? Any thoughts on this.

[Marc M.]

Can someone who recently purchased a dsa815 or dsa815-tg verify that the 10hz RBW is part of the trial option? There seems to be conflicting results at the moment.

If the 10hz RBW is not part of the trial option, does it mean it may actually be hardware specific? Any thoughts on this.

Purchased my 815-TG in May of this year.  It came without any trial options installed.  Info as follows:

S/N: DSA8A1449xxxxx
Main Board: 00.04
RF FPGA: 00.04
Digital FPGA: 00.04
Firmware: 00.01.05
Boot: 00.01.02

I doubt there's hardware differences, likely just a marketing decision by Rigol to include teaser options to stimulate sales of them.  I have 5 options listed under Option Info so presumably one is for the 10 Hz RBW. 

[ilya]

That's unfortunate .  I just checked mine saving a .png and there's no corruption.  I'm running version .02 and had been prior to installing any keys.  Also, I had used both DSA9 and DSAZ keys prior without any issues.

Yes, all formats are corrupted and look the same. I've noticed that it only happens when the waveform is recorded and the scope is in stop mode (only when there's a lable "Record=xxxx" in place where image is corrupt). In "run" and "stop" modes images come out fine fine. Can you check this on yours please?

[Marc M.]

Yes, all formats are corrupted and look the same. I've noticed that it only happens when the waveform is recorded and the scope is in stop mode (only when there's a lable "Record=xxxx" in place where image is corrupt). In "run" and "stop" modes images come out fine fine. Can you check this on yours please?

I set my scope up as you described and I was able to replicate the problem.  The 'Record = #' display gets corrupted when the image is saved.  I believe Marmad has been keeping track of any bugs discovered in the "REVIEW - Rigol DS2072 First impressions..." thread.  I'll PM him a link to your post to be sure he's aware of it so he can add it to the list.

Re-reading your original post, you mention this happened after installing the 2202 key.  Prior to installing the key did you save any pictures using the same settings that weren't corrupted?  I reverted my scope back to a 2072 and tried saving it again.  It was still corrupting the Record # display portion so I don't think it's related to the keys.

[kosh]

Re-reading your original post, you mention this happened after installing the 2202 key.  Prior to installing the key did you save any pictures using the same settings that weren't corrupted?  I reverted my scope back to a 2072 and tried saving it again.  It was still corrupting the Record # display portion so I don't think it's related to the keys.

I have tried this on my brand new DS2072 without any key installed yet and I can confirm this behaviour. But it seems this bug only happens when using the storage menu. If I save an image by using the print button there is no corruption.

[ilya]

Re-reading your original post, you mention this happened after installing the 2202 key.  Prior to installing the key did you save any pictures using the same settings that weren't corrupted?  I reverted my scope back to a 2072 and tried saving it again.  It was still corrupting the Record # display portion so I don't think it's related to the keys.

I'm now starting to doubt if I made the screen copies in that mode. I might've just hit stop and save a picture. So I assume that this issue has no connection to the keys.

Btw, how on earth did you revert your 2072 back to 2072? Mine is stuck in 2202 mode and I can't revert it.

[sha256]

I have tried this on my brand new DS2072 without any key installed yet and I can confirm this behaviour. But it seems this bug only happens when using the storage menu. If I save an image by using the print button there is no corruption.

I upgraded my DS2072 and can confirm kosh's findings.  If I use the Storage Menu I get the corruption but using the print button seems to work fine.

[sha256]

I have an unlocked DS2072 that I do NOT have corrupted images using either method to get a snapshot of the screen.

AFAIK it only does it when using the Storage Menu and the Waveform Record.  The corruption is of the little window that shows what frame/waveform your currently viewing.

[ilya]

AFAIK it only does it when using the Storage Menu and the Waveform Record.  The corruption is of the little window that shows what frame/waveform your currently viewing.

Correct. This looks like a general bug, that's not connected to keys in any way.

[JimFouch]

I stand corrected. I DO have the picture corruption on my DS2072 when using the Storage Menu.

[Marc M.]

... how on earth did you revert your 2072 back to 2072? Mine is stuck in 2202 mode and I can't revert it.

I have a couple of Python scripts that I modified (posted earlier in this thread by another user - somewhere ) on my desktop which will install and uninstall the options.   The uninstall just sends the SCPI command:   ":SYSTem:OPTion:UNINSTall" (the script also preserves the user settings).  I've had no problems with S/N corruption after installing/uninstalling the original temp. DSA9/DSAZ keys or the generated key dozens of times.  You can also send the SCPI command via Rigol Ultra Sigma.

[Maalobs]

Thanks for the tip, I went back and took a closer look at those Python-scripts.
I had tried fiddling with the SCPI control panel in Ultra Sigma before, but never managed to get the :SYSTEM:OPTION:UNINSTALL command to do anything, it just ended in a timeout.
I saw now that one of the Python-routines hammers the SCPI-commands up to 30 times, so that got me thinking about the control panel again.
I started Ultra Sigma and switched the control panel to Advanced Mode, and changed the timeout setting to 10.000ms, but still no dice with the uninstall-command.
Another thing I noticed was that one of the Python-routines does an expect-like check of the "*IDN?"-prompt, while the other does not.
Now I accidentally discovered (duh..) in the control panel that you can actually backspace away the *IDN? part, so I did it, and ran :SYSTEM:OPTION:UNINSTALL without any "prompt" ahead of it.
It took a few seconds, but this time it worked!

The scope made a loud CLICK noise and lit up both channels, and my DS2102 now identified itself as a DS2072! O0
I powercycled and tried installing my DSAZ-code through SCPI, but that still wouldn't work, even with the special settings in the control panel.
So I entered the DSAZ-code through the on-screen keyboard as I had originally done, and it worked.
After another powercycle I had a DS2202 with all options enabled again.

The purpose of my little exercise was that I had originally used a DSAR-code, which enabled 100M in the Options-list.
Later when the complete code-matrix was revealed to us in the thread, I entered the DSAZ-code, and this combination resulted in the Options-list showing both 100M and 200M, much like the DSA9-code I assume.

With the help of another DS2102-owner here at the forum, I was able to surmise that the 100M-option should NOT be displayed when activating a DS2102 to DS2202, so I wanted it gone.
Because who knows what could happen down the line...
First of all it's a clear sign that the options have been tampered with, and I suppose that discovering this state in the instrument could be targeted by Rigol in future firmware-updates in the coming antihack-war.
Not to mention that it's an invalid state in the instrument. I've worked enough with code monkeys in my career to know that it only takes a single if-clause that checks for the bandwidth-options in the wrong order to send me down a code path where I get 100M precision instead of 200M, or whatever else undefined behaviour that could result from something like that.
Maybe I'm too paranoid about this, it's quite possible, but I prefer reducing the risks of possible problems.

Thanks again!

[JimmyMz]

I tried fiddling with the SCPI control panel in Ultra Sigma, but never managed to get the :SYSTEM:OPTION:UNINSTALL command to work, it always ended in a timeout.
I discovered in the control panel that you can backspace the "*IDN?" typing, so I did, and typed :SYSTEM:OPTION:UNINSTALL without "*IDN?" ahead of it, and this time it worked! The scope made a loud CLICK noise and lit up both channels, and my DS2102 now identified itself as a DS2072.

I also had to erase "*IDN?" but I typed SYSTEM:OPTION:UNINSTALL <---note that there is no colon at the beginning of the word 'SYSTEM,' to make the command work for me. Although, Ultra Sigma gave an error message on this command, the scope carried out the command, posting official options erased (or something of that nature) at the bottom of the DS2102 screen. I suppose I should have reported this information sooner, so I could have saved you some effort. 

[Rory]

Can someone who recently purchased a dsa815 or dsa815-tg verify that the 10hz RBW is part of the trial option? There seems to be conflicting results at the moment.

If the 10hz RBW is not part of the trial option, does it mean it may actually be hardware specific? Any thoughts on this.

My 815-TG came from Tequipment a week ago.

The options listed in the License menu are not labeled but the 30 and 10 hz RBW items show up in the RBW item under the BW/DET menu.

[tlu]

Can someone who recently purchased a dsa815 or dsa815-tg verify that the 10hz RBW is part of the trial option? There seems to be conflicting results at the moment.

If the 10hz RBW is not part of the trial option, does it mean it may actually be hardware specific? Any thoughts on this.

My 815-TG came from Tequipment a week ago.

The options listed in the License menu are not labeled but the 30 and 10 hz RBW items show up in the RBW item under the BW/DET menu.

So I guess it does comes with the 10hz RBW option since I'm assuming you can make that selection under the BW/DET menu. Can you provide an image of what options it did came with? I'm curious as to see what you mean when you say options are not labeled.

[Marc M.]

... I'm curious as to see what you mean when you say options are not labeled.

Under the Options menu, the 5 items are simply numbered 1 to 5 without any labels indicating what each represents.  I know item #1 is the Tracking Generator option because that's the only option enabled on my unit (I wasn't lucky enough to get any trial options  ).  Earlier in this thread (#794) Spark posted a picture of a box label listing the included options in a Yes/No format (just like the option screen) with the TG also as the top option.  If we correlate that sequence to the license screen, the option numbers are:

1) Tracking Generator
2) Advanced Measurement Kit
3) 10 Hz RBW
4) EMI/Quasi Peak
5) VSWR

The only options offered so far are 1,2,4, & 5.  Since 5 options are listed on all the 815's, the 5th option they provide space for (presumably option #3) is for the 10 Hz RBW and is available on all 815's with the correct key.  Out of the 5 options, 10 Hz RBW is the one option I probably would have paid for if they had made it available  .

[jamesb]

The only options offered so far are 1,2,4, & 5.  Since 5 options are listed on all the 815's, the 5th option they provide space for (presumably option #3) is for the 10 Hz RBW and is available on all 815's with the correct key.  Out of the 5 options, 10 Hz RBW is the one option I probably would have paid for if they had made it available  .

You are not alone in this .. there are a growing number of people who are interested in this feature and if Rigol are too pig-headed to provide this as a paid-for option, I imagine that the DSA815-TG hacking effort will grow considerably.

[olsenn]

You are not alone in this .. there are a growing number of people who are interested in this feature and if Rigol are too pig-headed to provide this as a paid-for option, I imagine that the DSA815-TG hacking effort will grow considerably.

Right now, Rigol doesn't want to compete with itself. By allowing their $1500 DSA to be better in every respect than their $2500 DSA with the exception of being 0.5GHz less in BW, then for all intensive purposes, noone will purchase the more expensive unit. Once Rigol discontinues their next-teir-up spectrum analyzer and releases a new $2500 price range DSA that can topple the DSA815 even with 10HZ RBW, THEN Rigol will offer to sell the 10RBW add-on for the DSA-815.

[jamesb]

Right now, Rigol doesn't want to compete with itself. By allowing their $1500 DSA to be better in every respect than their $2500 DSA with the exception of being 0.5GHz less in BW, then for all intensive purposes, noone will purchase the more expensive unit. Once Rigol discontinues their next-teir-up spectrum analyzer and releases a new $2500 price range DSA that can topple the DSA815 even with 10HZ RBW, THEN Rigol will offer to sell the 10RBW add-on for the DSA-815.

To be honest, your speculation as to Rigol's motives are rather obvious. I was merely stating that such tactics will only further drive the efforts to see the 10Hz RBW option become permanently available to those who are willing to undertake the effort to hack the DSA815-TG firmware to shreds.

[olsenn]

To be honest, your speculation as to Rigol's motives are rather obvious. I was merely stating that such tactics will only further drive the efforts to see the 10Hz RBW option become permanently available to those who are willing to undertake the effort to hack the DSA815-TG firmware to shreds.

Since we're being honest, that is something that I hope to see done even if Rigol does release the add-on for a fee

[etc6849]

I really don't know how I sleep at night!?!  Seriously, I just tried the hack last night on my DS2072, works great!  Thanks for all your hard work

[jasonbrent]

It isn't clear to me from the thread (yes, I've read it all)... does the RiGen generator work with the DP832 Rigol DC power supply to enable options? (and as an aside, if it does, has anyone figured out if the 832's screen is full color or just a couple of different monochrome colors? in other words, do we think it can be turned into a full blown 832A?).

-jbl

[H.O]

Hi,
Has anyone tried using the protocol decoders?
My DS4000 series came without any trial licenses (at the time I didn't even know there WAS trial licenses to be had) so I never got to actually try it before installing the "license". Last night I tried the RS232 decoder and it's so PAINFULLY slow it's almost unusable. I don't know if I'm doing it wrong or what (don't think so) but geez, right now I'm SO glad I didn't pay for it.

I wonder if it's a firmware thing.... I'd appreciate if anyone else could report your experience using the RS232 (or any other) decoder, preferably on a DS4000 series (but 2000 would be interesting too) and what firmware version you're running, thanks!

Speaking of firmware, I see that Rigols website now lists the latest firmware, as of July 31, for the DS4000 to be 00.02.00 when it just a month ago was 00.01.00.07 or something like that (I'm currently running neither of those). I wonder if they have already implemented a fix for the hack....anyone knows?

Thanks!