Hacking the Rigol DHO800/900 Scope

[tv84]

Also, as @souldevelop has shown in this thread's beginning, the FW has some "hdcode" bits checking. So, only changing the model in vendor.bin might not be enough to complete the model change. One would have to patch the FW (all of them in the future)! Just saying because I don't remember having read any development in this area saying that this is not a problem.

[ebastler]

Yes, and the appearance of the offset error after a DHO800 to 900 "conversion" via vendor.bin is not understood or resolved yet.

[souldevelop]

Yes, and the appearance of the offset error after a DHO800 to 900 "conversion" via vendor.bin is not understood or resolved yet.

With RIGOL TOOL, you don't need to worry about new problems brought by firmware upgrades of any version, no offset error ,no other error , no app anit-check   which is currently the perfect solution.

Replacing the vendor .bin of another model of device directly will result in offset error, because the vendor .bin has serial number and model information, so you must have the ability to unlock the vendor's .bin to solve some other problems such as offset error. XXXX.apk running on the device checks the vendor's .bin and adjusts the way it calibrates based on what's inside, and what I know is not speculation, it's a credit to IDA.

[ebastler]

But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?

[Fungus]

But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?

It's been measured at 200MHz with the "100Mhz" hack applied. 

If you really need the decoders then just turn it into a 924. A few mV offset on one of the channels isn't going to affect decoding.

[souldevelop]

But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?

The DHO800 can be modified to DHO900 200MHz by rigoltool.

Because it is done by directly modifying the vendor.bin device information file, no additional OPT license is required, and a certain series model already comes with the corresponding option function by default.

[souldevelop]

Also, as @souldevelop has shown in this thread's beginning, the FW has some "hdcode" bits checking. So, only changing the model in vendor.bin might not be enough to complete the model change. One would have to patch the FW (all of them in the future)! Just saying because I don't remember having read any development in this area saying that this is not a problem.

No apps.apk have been found to check HDCODE.

[Mechatrommer]

But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?

The DHO800 can be modified to DHO900 200MHz by rigoltool.
Because it is done by directly modifying the vendor.bin device information file, no additional OPT license is required, and a certain series model already comes with the corresponding option function by default.

your tool still cannot solve offset issue, and it does not allow me to upgrade to DHO924S (it warned me that my model doesnt support FG feature how clever the program is ) what do i miss? https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126331/#msg5126331

there's 3rd branch of the hack (1st is v1.14 DHO924S, 2nd is your rigol tool) https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5131482/#msg5131482 i'm not sure if it can fix the issue

[souldevelop]

But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?

The DHO800 can be modified to DHO900 200MHz by rigoltool.
Because it is done by directly modifying the vendor.bin device information file, no additional OPT license is required, and a certain series model already comes with the corresponding option function by default.

your tool still cannot solve offset issue, what do i miss? https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126331/#msg5126331

xu

there's 3rd branch of the hack (1st is v1.14 DHO924, 2nd is your rigol tool) https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5131482/#msg5131482

After the modification is complete, it needs to be calibrated from scratch.

[Mechatrommer]

After the modification is complete, it needs to be calibrated from scratch.

i did..

[ebastler]

After the modification is complete, it needs to be calibrated from scratch.

i did..

Do you guys mean running a self-cal, or something that goes beyond that?

[souldevelop]

After the modification is complete, it needs to be calibrated from scratch.

i did..

Can you take a screenshot of your firmware version page and what is the deviation of offset error?

[t_i_t_o]

IMHO, the hackability of their products is main part of Rigol's marketing strategy, so I do not expect making hacking harder with FW updates.

[ebastler]

Can you take a screenshot of your firmware version page and what is the deviation of offset error?

Here's a screenshot by Martin72. He did run into the offset problem, and self-cal could not fix it: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5128053/#msg5128053. -- Edit: Reply #139, dunno why I can't link to the right post.

Fungus did not have an offset issue though: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126985/#msg5126985. -- Edit: Reply #119.

They both had replaced the vendor.bin with the one from hubertyoung. But that should not make a difference for the offset issue compared to your approach, right? It seems to be unit-specific whether a model change causes the offset problem. (And also a problem with the DC accuracy, as demonstrated by serg65536 in reply #200.)

[Fungus]

After the modification is complete, it needs to be calibrated from scratch.

The calibration fails.

[Martin72]

But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?

It's been measured at 200MHz with the "100Mhz" hack applied. 

If you really need the decoders then just turn it into a 924. A few mV offset on one of the channels isn't going to affect decoding.

The extra decoders are needing the LA, they're parallel decoders.

[ebastler]

The extra decoders are needing the LA, they're parallel decoders.

CAN and LIN??

[Martin72]

My fault, overlooked in the datasheet the sources ch1-ch4 on both....

[souldevelop]

After the modification is complete, it needs to be calibrated from scratch.

The calibration fails.

My God, how can this be.....

[ebastler]

My fault, overlooked in the datasheet the sources ch1-ch4 on both [CAN and LIN]....

It's just one or two wires after all. But both protocols have long been used as a differentiator for the better oscilloscopes, or as a chargeable option.

I find it interesting that Rigol still makes hacking easy withing the limited range of DHO800 options, but has moved several options "out of reach" by declaring the DHO900 to be a different product line. The total opposite of what they did in the MSO5000 range! Maybe someone decided that the hacking was getting out of hand and hurting revenue too much -- so they wanted to preserve some of it, to keep the hobbyists interested, but put tighter constraints on it.

[Fungus]

The extra decoders are needing the LA, they're parallel decoders.

LIN bus is 1 wire, CAN bus is two.

[Mechatrommer]

After the modification is complete, it needs to be calibrated from scratch.

i did..

Do you guys mean running a self-cal, or something that goes beyond that?

i mean self-cal from dso menu. iirc i tried both in testmode on and in testmode off...

After the modification is complete, it needs to be calibrated from scratch.

The calibration fails.

My God, how can this be.....

iirc if we enable adc gain or phase (self-cal in testmode on), calibration will fail, but if we just do normal self-cal (testmode off), calibration succeeded, but there are offsets everywhere on all channels. and the worst is, if i feed signal to channel input, there is no signal at all on the display. i tried both FW v0.1.0.0.9 and v0.1.1.0.2 using your tool but no success, i wish it to be success because i can use the latest FW revision from rigol, but i have to use image of DHO924 FWv1.14 from hubertyoung now. self-cal works ok.

[Mechatrommer]

After the modification is complete, it needs to be calibrated from scratch.

i did..

Can you take a screenshot of your firmware version page and what is the deviation of offset error?

sorry i didnt save the screenshots, my DHO804 now running hubertyoung image, try doing all again from v1.0.0.9 will take hours.

since at it, you all DHO900 owners (@souldevelop and @hubertyoung and @others) can help us identify components labelled a,b,c,d,e in attachment? they are unpopulated in DHO800. i'm guessing a is MPPY 3630 280, similar to adjacent ICs, not sure what it does, cant even find datasheet for it. thank you.

[Mechatrommer]

After the modification is complete, it needs to be calibrated from scratch.

i did..

Can you take a screenshot of your firmware version page and what is the deviation of offset error?

or maybe i forgot to power cycle the dso after using rigol tool? i cant remember.

[Fungus]

i mean self-cal from dso menu. iirc i tried both in testmode on and in testmode off...

Yep. I tried all the options and always had an offset on channel 3.

Maybe we need to copy some ".cal" files from the 924 image to make it work, I don't know for sure. See my theory below... 

At this point I don't really care. All I really wanted for my DHO804 was the extra memory and a decent bandwidth. I have both of those now and no useless on-screen junk from the 900-series LA.

The only missing thing is the extra 200uV/div range of the DHO900 but I can easily live without that.


Theory: The extra 200uV/div range might be the reason the DHO800's cal files don't work with a DHO900's vendor.bin.