Hacking the Rigol MSO5000 series oscilloscopes

[tv84]

I've tried holding down the SINGLE button while booting

It's not "holding". It's multiple presses.

[TopLoser]

Just press the SINGLE button, don’t hold it down.

[rucu]

Ah, I thank you guys so much, apparently I was not quick enough when I tried the first 10 times :-).

[tv84]

Model conversion of a MSO5000 to 500 MHz model (MSO5504) - PART 2

- The measurements used a genuine 50 Ohm termination 1Ghz model
- No significant changes in output (heat wise)

Some results/confirmations of the tests:

- The scope BW is 470 MHz, as previously announced by others.
- With the 500 MHz model setting, the horizontal scale can be lowered to 500 ps. But, no further BW increase is noticeable.
- Besides the official models, currently on sale, MSO5504/02 seems to be the only additional Model possible. Maybe the scope was designed to have a 500MHz BW but, in the end, they couldn't reach it.
- With MSO5504 model, and after a self-calibration, we made some attempts in creating eye diagrams. The scope clearly hasn't the BW nor the memory to do them in a usable way but, nonetheless, it's a nice accomplishment in a scope with these characteristics. You can check them in the attached pics. It seems to prove that it shares much code with the 8000 model.

BTW, and likewise, we also changed a MSO7000 to 1GHz model (MSO7104). It also seems the only possible model besides the "official" ones. No eye/jitter possible with the latest DS7000 FW. Real BW seems close to 989 MHz (measured with bodnar pulser). Further tests ongoing.

Edit1: Corrected the BW of both equipments, by using the correct formulas. The 7000 is almost 1GHz!!!

[NoisyBoy]

Tv84,

Excellent findings, thanks for sharing the additional data points to confirm earlier observations.  Did you use the 50 ohm termination in all these tests?  If so, is it the 50 ohm pass through with 1 GHz bandwidth?

The 500ps horizontal scale can be handy in some instances, and good to see there’s no heat issues.

[tv84]

50 ohm pass through with 1 GHz bandwidth?

Exactly.

[tv84]

Looking at the System Information menu code we can see that it was prepared to display the following params:

Manufacturer:   INF_SYS_VENDOR
Model:          INF_SYS_MODEL
Serial number:  INF_SYS_SERIAL
Firmware:       INF_SYS_FIRMWARE
Hardware:       INF_SYS_HARDWARE
Boot:           INF_SYS_BOOT
Build date:     INF_SYS_BUILD

FPGA.K7:
FPGA.ZYNQ:
FPGA.SP6:
ADC.ID0:
ADC.ID0:
AFE.VER0:
AFE.VER1:
AFE.VER2:
AFE.VER3:
Started:
Live Time:

The red ones are missing from the final display.

[nimish]

How does one enable this mystical 500MHz mode?

[tv84]

How does one enable this mystical 500MHz mode?

I won't go into details because the benefits are residual compared to the possible headaches when executing the procedure wrongly. I leave that as homework for the ones who are not faint of heart.

But, as general knowledge, I'll add the following:

These equipments keep their config in a FRAM memory. In that FRAM, among other possible things, usually there are the following params (specific to the unit):
- E_CFG_MODEL_RAW
- E_CFG_SN_RAW
- E_CFG_MAC
- ECC Public key of the scope
- Option's licenses

These fields are replicated in the sysvendor.bin, Key.data and the *.LIC files (for "external" consumption).

So, to change the Model, you just have to change the contents of the param E_CFG_MODEL_RAW, in the FRAM, and the scope will adjust everything else accordingly.

[TK]

Have you tried what happens if you set E_CFG_MODEL_RAW to be an MSO7000 model?

[tv84]

Have you tried what happens if you set E_CFG_MODEL_RAW to be an MSO7000 model?

It was discussed but not tried. I'll try it next time. I'm almost certain it won't be accepted as all other MSO5xxx models.

[oliv3r]

Looking at the System Information menu code we can see that it was prepared to display the following params:

Manufacturer:   INF_SYS_VENDOR
Model:          INF_SYS_MODEL
Serial number:  INF_SYS_SERIAL
Firmware:       INF_SYS_FIRMWARE
Hardware:       INF_SYS_HARDWARE
Boot:           INF_SYS_BOOT
Build date:     INF_SYS_BUILD

FPGA.K7:
FPGA.ZYNQ:
FPGA.SP6:
ADC.ID0:
ADC.ID0:
AFE.VER0:
AFE.VER1:
AFE.VER2:
AFE.VER3:
Started:
Live Time:

The red ones are missing from the final display.

Where the red ones are the more interesting finds

Do we know also how this information is read? Or is it simply not implemented. Have you managed to get it onto the screen? I'm curious to see if we can probe these over the SPI bus ourselves (should be possible of course). Maybe these fields are only shown when putting the scope into 'debug' or 'dev' mode. Getting the versions also means we can see if/when these are changed of course. Sadly, I don't think it'll be easy to extract this information from the FPGA binaries.

That the FPGA's had individual versions makes sense, they are uploaded each boot.

ADC.ID0 is in the list twice, a typo perhaps? I would guess there'd be ADC.ID1 as well, as we have 2 ADC's, didn't we (chan 1 + 2; chan 3 + 4)? Also interesting it's an identifier, and not a version. That would indicate it's not upgradeable or doesn't run software. So the ID probably relates to the board. MSO5000's vs MSO7000/MSO8000. I am curious how these relate.

It seems however that the Analog frontend's also have individual versions. That would explain why we sometimes see different behaviors between the 4? I wonder who and when uploads the software into the AFE's. Again, having this information visible, means we can see when they are changed.

The Live time used to be printed on the previous gen scopes, wonder why they are not showing it now. As a user, you may want to know this with regards to getting the device re-calibrated ...

[tv84]

Do we know also how this information is read? Or is it simply not implemented. Have you managed to get it onto the screen? I'm curious to see if we can probe these over the SPI bus ourselves (should be possible of course). Maybe these fields are only shown when putting the scope into 'debug' or 'dev' mode. Getting the versions also means we can see if/when these are changed of course. Sadly, I don't think it'll be easy to extract this information from the FPGA binaries.

That the FPGA's had individual versions makes sense, they are uploaded each boot.

ADC.ID0 is in the list twice, a typo perhaps?

I'll try to read it.

When you call appEntry with the param "-ds8000" you get another field (attached).

If it's a typo, it exists in all FWs (5k, 7k & 8k).

[AngusBeef]

Howdy -

Well after reading all of this thread and half the rest of the forum - bought my first Oscilloscope yesterday from the RigolNA clearance section - MSO5074. Buy once cry once - but I'll update once I get it setup and ... patched .... 

[NoisyBoy]

Hey tv84,

If I interpret your finding properly, does the model change actually upgrade the -3dB point from 350MHz to 470MHz by removing any hidden software limitation?  And other than the 500ps horizontal scale, is there any other benefit that you observed?

I won't go into details because the benefits are residual compared to the possible headaches when executing the procedure wrongly. I leave that as homework for the ones who are not faint of heart.

[nimish]

Hey tv84,

If I interpret your finding properly, does the model change actually upgrade the -3dB point from 350MHz to 470MHz by removing any hidden software limitation?  And other than the 500ps horizontal scale, is there any other benefit that you observed?

I won't go into details because the benefits are residual compared to the possible headaches when executing the procedure wrongly. I leave that as homework for the ones who are not faint of heart.

Yeah, I'd like to know this. Just adding 500ps/div is minor, but 120MHz of "extra" bandwidth is fairly useful!

[tv84]

If I interpret your finding properly, does the model change actually upgrade the -3dB point from 350MHz to 470MHz by removing any hidden software limitation?  And other than the 500ps horizontal scale, is there any other benefit that you observed?

As others have said before, the BW already approached the 460-470 MHz. And, that was without any 5504 "modelling".

You may gain a few MHz, but the -3dB threshold is very similar between 5354 and 5504, if not the same.

It seems the 500ps HS is the only visible difference (assuming that you can accomplish those proto-eye diagrams in 5354 mode).

[NoisyBoy]

tv84,

Thanks for the clarification, as well as all the wisdom you had shared on this discovery.  I think I will leave things as is for now until I need that 500 ps setting.

[mabl]

Yes, I also looked into these. However, I do think all interaction is via SCPI commands and there is hence no secret there, which is not also in the SCPI definitions in /rigol/resources.

It looks to me, that there is a message passing system, which is also partially used to define the SCPI commands. However not all messages are also exposed via SCPI commands. I believe the production version of the firmware is not shipped with a full set of SCPI command definitions, hence giving no way to access all possible messages.  (until we define our own SCPI commands to access them . I failed in my first quick attempt tough.)

Indeed by far not all commands are currently exposed via SCPI. I believe there is an additional command set not shipped with release firmwares. However, we can start and define our own SCPI commands. Let me start with a simple one.

Toggle Project Mode
Enables  ssh and ftpd. Also enables a "key recording mode". Maybe more.

Add this block to the SCPI definitions, e.g. into /rigol/resources/scpi/SYSTem.xml.

Code: [Select]

<TotalItem>
<head>^(:?HACK|:?H)(:PROJECT|:PRO)$</head>
<service>utility</service>
<cmd>48</cmd>
<minSize>-1</minSize>
<indexes>
</indexes>
<unit>
</unit>
</TotalItem>

This will add a new SCPI command HACK:PROJECT, which enables trigger mode.

EDIT: The definition might be a bit wrong. It only works when I execute a prior "SYSTem:PON?" or similar. Strange.

EDIT2: Project mode enables the talked about full About Dialog. Not sure what is unique info here. so blanking a lot.
EDIT3:
 Note that resource/menu/msg.h defines MSG_APP_UTILITY_PROJECT as follows:

Code: [Select]

resource/menu/msg.h:#define MSG_APP_UTILITY_PROJECT               12073
That code decodes inside the servEdgeTrigger::_cmdEntry  (at 0x0149e634)  to function at 0x0023ccbc. However that function forwards to  the identical code 12073 to "utility" (at 0x014a1f58) to fun at 0x0027839c.  That function returns if the project mode is enabled or not, I would have expected it to route to the project state toggle (cmd  48) defined one entry above. But anyways, it looks like there is a relation between edge trigger mode and project mode. Interestingly, going into edge trigger mode was one of the requirements to manually trigger project mode on older scopes, see also here.

[mabl]

In project mode, one can specify what to calibrate and export the calibration result (if a cal directory exists on the pen drive) in a user readable value:

Code: [Select]

<root@rigol>ls /media/sda1/cal/
ADC1_iDelay.csv          hzgnd1.csv               hzscale1.csv             lzgnd0.csv               lzscale_20x_flt0.csv     lzscale_20x_normal0.csv  lzscale_2x_flt0.csv      lzscale_2x_normal0.csv
ADC2_iDelay.csv          hzgnd2.csv               hzscale2.csv             lzgnd1.csv               lzscale_20x_flt1.csv     lzscale_20x_normal1.csv  lzscale_2x_flt1.csv      lzscale_2x_normal1.csv
go.csv                   hzgnd3.csv               hzscale3.csv             lzgnd2.csv               lzscale_20x_flt2.csv     lzscale_20x_normal2.csv  lzscale_2x_flt2.csv      lzscale_2x_normal2.csv
hzgnd0.csv               hzscale0.csv             lf.csv                   lzgnd3.csv               lzscale_20x_flt3.csv     lzscale_20x_normal3.csv  lzscale_2x_flt3.csv      lzscale_2x_normal3.csv

EDIT: There is also now a log output in the calibration window, which specifies what is currently done.

[mabl]

There is also an option to get system temperatures as well an additional self-check option for the screen. Further more one can reset the counters for LifeTime and BootTime.   

[Martin72]

Very interesting, how can I activate this ?

[mabl]

I have updated my initial post about this above. I think, the project mode is normally enabled by a key combination. I have not found it yet though. So for now, one can add a new SCPI command, which will also trigger project mode (see above post). One can than just use TCP/IP (default port 5555) or USB to send the SCPI command.

In general, I feel that I have not yet found all the user interface definition and logic. The binary has multiple resources inside, such as PNGs and XML data. That is a feature for Qt, see here. However, it also includes compressed artifacts, so just searching is not always successful. I looked at some binary extractors for Qt, but they failed. Possibly one can dump the memory of the appEntry process too...

[bitseeker]

Well after reading all of this thread and half the rest of the forum - bought my first Oscilloscope yesterday from the RigolNA clearance section - MSO5074. Buy once cry once - but I'll update once I get it setup and ... patched .... 

Nice catch. I wouldn't have expected MSO5000 to be in there already.

[AngusBeef]

Well after reading all of this thread and half the rest of the forum - bought my first Oscilloscope yesterday from the RigolNA clearance section - MSO5074. Buy once cry once - but I'll update once I get it setup and ... patched .... 

Nice catch. I wouldn't have expected MSO5000 to be in there already.

They had a 5072 there as well the other day but I wanted 4 probes and factory warranty for four channels