How does one enable this mystical 500MHz mode?
Have you tried what happens if you set E_CFG_MODEL_RAW to be an MSO7000 model?
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.
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 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.
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.
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?
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.)
<TotalItem>
<head>^(:?HACK|:?H)(:PROJECT|:PRO)$</head>
<service>utility</service>
<cmd>48</cmd>
<minSize>-1</minSize>
<indexes>
</indexes>
<unit>
</unit>
</TotalItem>
resource/menu/msg.h:#define MSG_APP_UTILITY_PROJECT 12073
<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
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 ....
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.
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.