Hacking the Rigol DHO800/900 Scope

[AndyBig]

Agreed.  It seems an odd design choice that these AFE's are essentially heated by the big thermal generators.

I'll have to take a look at the radiator with the fan turned off sometime with a thermal imager. It seems that its surface is rough enough to get an adequate picture.

[ebastler]

It seems to me that front-end chips should not consume a lot of energy and get very hot. The main consumers are the processor, FPGA and ADC. Well, the display probably consumes something, but we are not interested in it in terms of cooling

Agreed.  It seems an odd design choice that these AFE's are essentially heated by the big thermal generators.

I am not sure whether the assumption that AFE power consumption is negligible is correct. The DHO1000 series even has four dedicated temperature readouts for CH1 and CH4 "chip" and "ambient" temperatures. (And those don't refer to the ADC, which has its own chip & ambient readouts. CPU temperature is monitored as well in the DHO1000, FPGA temperature is not.)

But an interesting thought about deliberately heating parts of the circuit. If Rigol had closed-loop temperature control of the heatsink, they could thermally couple the main 25 MHz oscillator to it to get a temperature-controlled oscillator. 

[TurboTom]

...
It seems to me that front-end chips should not consume a lot of energy and get very hot. The main consumers are the processor, FPGA and ADC. Well, the display probably consumes something, but we are not interested in it in terms of cooling

That's not exactly true...  . We are talking of a complex, 1GHz-capable low-noise analog design. This stuff unfortunately requires quite high quiescent currents, especially with regards to the low noise requirements. Just look at active microwave components, and their complexity usually is much lower than what we see here. I'ld assume that the four front end chips of the DHO8x4 consume as much power as all the ADC and digital circuitry.

If we could take accurate power measurements of the DHO8x4 and the DHO8x2 (preferably at the DC side, maybe with a USB power analyzer), and assume an internal PSU efficiency of 70% (switcher plus analog post-regulator), the difference would tell us approximately the consumption of one front end chip.

Would be useless but still quite interesting to know... 

[AndyBig]

I am not sure whether the assumption that AFE power consumption is negligible is correct. The DHO1000 series even has four dedicated temperature readouts for CH1 and CH4 "chip" and "ambient" temperatures. (And those don't refer to the ADC, which has its own chip & ambient readouts. CPU temperature is monitored as well in the DHO1000, FPGA temperature is not.)

That's not exactly true...  . We are talking of a complex, 1GHz-capable low-noise analog design. This stuff unfortunately requires quite high quiescent currents, especially with regards to the low noise requirements. Just look at active microwave components, and their complexity usually is much lower than what we see here. I'ld assume that the four front end chips of the DHO8x4 consume as much power as all the ADC and digital circuitry.

It's entirely possible that I'm wrong. Unfortunately, it is impossible to obtain a datasheet for these chips, so we can only speculate.

If we could take accurate power measurements of the DHO8x4 and the DHO8x2 (preferably at the DC side, maybe with a USB power analyzer), and assume an internal PSU efficiency of 70% (switcher plus analog post-regulator), the difference would tell us approximately the consumption of one front end chip.

Would be useless but still quite interesting to know... 

That would be really interesting

[AceyTech]

That's not exactly true...  . We are talking of a complex, 1GHz-capable low-noise analog design. This stuff unfortunately requires quite high quiescent currents, especially with regards to the low noise requirements. Just look at active microwave components, and their complexity usually is much lower than what we see here. I'ld assume that the four front end chips of the DHO8x4 consume as much power as all the ADC and digital circuitry.

Also not exactly true:   'We are talking about a complex 2Ghz.... design', borrowed from more advanced models.(that happens to be dumbed down to 1.2G)
Did you see the photo I posted?  The heatsink on the AFE is maybe 12x12mm.  That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.

[Mechatrommer]

Hello guys!
 I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?

glad to hear from you in PM and here... currently we are using rigol_vendor_bin from zelea2 to edit vendor.bin. with vendor.bin edited, other features such as 250MHz BW and 50Mpts memory, AFG and LA features automatically activated, no need extra *.lic anymore. although yours RigolTool can also still be applicable for the job, but its auto destruct now when we run it. its still very usefull for me as file explorer of DHO800, last time i pulled many file system using it.

and other update we were talking about your post is changing HW number read by hdcode_gpio.ko...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392

we managed to find where the config resistors are..
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916

but other guys (norbert.kiszka and Randy222 iirc) tried to do it in SW/FW by spoofing start_rigol_app.sh by disabling hdcode_gpio.ko and writing a number into its output file, but we dont find the method stable, i tried and caused the dso to hanged and reboot indefinetely.. so i'll stick with HW modification. since HW12 with hacked dho800 to 900 still not work correctly on LA channel trigger with latest FW 1.2.2 i suspect the FW will check for HW number before activating or not activating LA trigger. ymmv.

[TurboTom]

... That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.

Comparing the noise performance of the MSO5000 and the DHO series 12 bit scopes, that's not very likely.

[Randy222]

Hello guys!
 I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?

glad to hear from you in PM and here... currently we are using rigol_vendor_bin from zelea2 to edit vendor.bin. with vendor.bin edited, other features such as 250MHz BW and 50Mpts memory, AFG and LA features automatically activated, no need extra *.lic anymore. although yours RigolTool can also still be applicable for the job, but its auto destruct now when we run it. its still very usefull for me as file explorer of DHO800, last time i pulled many file system using it.

and other update we were talking about your post is changing HW number read by hdcode_gpio.ko...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392

we managed to find where the config resistors are..
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916

but other guys (norbert.kiszka and Randy222 iirc) tried to do it in SW/FW by spoofing start_rigol_app.sh by disabling hdcode_gpio.ko and writing a number into its output file, but we dont find the method stable, i tried and caused the dso to hanged and reboot indefinetely.. so i'll stick with HW modification. since HW12 with hacked dho800 to 900 still not work correctly on LA channel trigger with latest FW 1.2.2 i suspect the FW will check for HW number before activating or not activating LA trigger. ymmv.

When we unload the hdcode KLM (comment that out in the start script), the hdcode_gpio device tree is not built upon reboot. This allows us to create a file in /dev that has file type in inode of "reg file". We then wrote "08" into that file. Something apparently reads that file because Scope app will then show "8" in it's About section. But this strategy does appear to be flawed, because the logic of using resistor sets on RK gpio pins does not make sense if a simple file is all that's needed, so the logic tells us they used resistor sets for a reason. The hdcode KLM reads the 4bit code from RK gpio pins (0 or 1 of the 4 gpio pins), it's a 4bit binary word that coverts to integer values, two values for 800's, and "8" for 900's. I believe two values for 800's to distinguish 2 vs 4ch without logic probe, and just "8" for 900's to distinguish it as a 4ch with logic probe. We also know there's another loaded KLM for gpio, and I gave the pin mappings in some post a few pages back, I just not sure what that KLM is used for. Others have done some work with the two sets of resistors that appear to impact HW # and scope functionality, or at least access to that functionality. On the 800's, chaning them from HW12 to HW8 appears to make no diff at all (changed only via the hdcode KLM stuff as mentioned).

As an aside, the auklet .so file, a rather large C++ compiled shared object file which has a ton of functions/routines and stuff in it, and is responsible for most of what you see in the scope gui, example is all of the calibration stuff is done via this .so file. One reason why I think it's so large is, it appears there's lots of code in the file that is not specifically related to 800-900 series. Lots of the Rigol coding appears to be carry-over or re-used code from other scopes over the years. Rigol appears to do poor job of code cleanup when re-using previous code. There's a lot of rerences to 'DS' scopes in the code that runs on 800-900. As example, it's easy to see how the DS1074's have morphed into the DHO800-900.

[AceyTech]

... That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.

Comparing the noise performance of the MSO5000 and the DHO series 12 bit scopes, that's not very likely.

I wasn't comparing the noise performance. That would be silly.

Allow me to rephrase;  Since Rigol is using their custom ASIC front ends(RT1642IQ) across the scope lineup, and there are obvious differences in cooling design, I would be curious to know if there's a measurable difference between the common cooled and individually cooled models.

[ebastler]

... That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.

Comparing the noise performance of the MSO5000 and the DHO series 12 bit scopes, that's not very likely.

I wasn't comparing the noise performance. That would be silly.

Allow me to rephrase;  Since Rigol is using their custom ASIC front ends(RT1642IQ) across the scope lineup, and there are obvious differences in cooling design, I would be curious to know if there's a measurable difference between the common cooled and individually cooled models.

I guess what TurboTom was saying is: Considering that the noise performance of those two scopes is so different, it appears unlikely that they use the same front-end amplifier.

Do we know for sure that the RT1642IQ is used in both scopes? There might be teardown photos from the MSO5000 with the heatsinks removed?

[AceyTech]

... That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.

Comparing the noise performance of the MSO5000 and the DHO series 12 bit scopes, that's not very likely.

I wasn't comparing the noise performance. That would be silly.

Allow me to rephrase;  Since Rigol is using their custom ASIC front ends(RT1642IQ) across the scope lineup, and there are obvious differences in cooling design, I would be curious to know if there's a measurable difference between the common cooled and individually cooled models.

I guess what TurboTom was saying is: Considering that the noise performance of those two scopes is so different, it appears unlikely that they use the same fron-end amplifier.

Do we know for sure that the RT1642IQ is used in both scopes? There might be teardown photos from the MSO5000 with the heatsinks removed?

I'm not sure that it's the same AFE in the 5000. Teardown pics didn't get that detailed.  The 1000s and 4000s are the exact same part tho'.
The input path looks very similar on the MSO5000, but the 50 Ohm and coupling relays aren't present in the AFE section pix, so I'm confused.  I was hoping some of the long timers here could shed some light on the subject.

[AceyTech]

Hello guys!
 I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?

Hey there.  Looks like your Q was answered... I just wanted to thank you for your early work here in the forums, and welcome you back.  Cheers!

[ebastler]

The input path looks very similar on the MSO5000, but the 50 Ohm and coupling relays aren't present in the AFE section pix, so I'm confused.

The MSO5000 does not have internal 50 Ohm termination (which is a bit of a miss for a 350 MHz scope). That feature was reserved for the higher-end MSO7000.

I could not find any photos of the MSO5000's front-end "ASICs" without their heatsinks either, and no type designation. But I'm with TurboTom here: If the MSO5000 had the same front-end as the DHO scopes with their pretty decent noise levels, why would it be so notoriously noisy even for an 8-bit scope?

[AceyTech]

The input path looks very similar on the MSO5000, but the 50 Ohm and coupling relays aren't present in the AFE section pix, so I'm confused.

The MSO5000 does not have internal 50 Ohm termination (which is a bit of a miss for a 350 MHz scope). That feature was reserved for the higher-end MSO7000.

I could not find any photos of the MSO5000's front-end "ASICs" without their heatsinks either, and no type designation. But I'm with TurboTom here: If the MSO5000 had the same front-end as the DHO scopes with their pretty decent noise levels, why would it be so notoriously noisy even for an 8-bit scope?

For some reason I think we're talking about different subjects. The only noise I've mentioned is fan noise. 
   I was talking about thermal i.e., cooling design, and noticed the AFE parts on the 1000/4000/5000/7000 had different thermal solutions than the DHO8/900s, and shared the photo with the little heatsink poking through the shield, because @Randy222's comment about saving aluminum.
The whole thing made me think about how they're homogenizing the whole thermal design in the DHO800/900., and it makes me curious to separate the ADC/AFE thermally from the FPGA/SoC, since we don't have info for the analog parts.

[ebastler]

For some reason I think we're talking about different subjects. The only noise I've mentioned is fan noise. 
   I was talking about thermal i.e., cooling design, and noticed the AFE parts on the 1000/4000/5000/7000 had different thermal solutions than the DHO8/900s, and shared the photo with the little heatsink poking through the shield, because @Randy222's comment about saving aluminum.
The whole thing made me think about how they're homogenizing the whole thermal design in the DHO800/900., and it makes me curious to separate the ADC/AFE thermally from the FPGA/SoC, since we don't have info for the analog parts.

I know that the discussion is about thermal management. The only reason TurboTom and I were bringing up (electronic) noise is to point out that the analog front ends in the MSO5000 and in the DHO series are probably rather different.

Hence the argument "look at those small AFE heatsinks in the MSO5000 -- the large heatsink in the DHO800 is probably transferring more heat to the AFE than cooling it" appears invalid, since the dissipated power of those rather different AFEs may also be rather different.

Somehow we did not get that argument across, and I promise this is the last time I will try.   But if you read back over the past handful of posts, you may realize that this is what Tom and I have been saying throughout, in four different ways...

[TurboTom]

@ebastler: You are far more patient than I am... 

[Mechatrommer]

Hence the argument "look at those small AFE heatsinks in the MSO5000 -- the large heatsink in the DHO800 is probably transferring more heat to the AFE than cooling it" appears invalid, since the dissipated power of those rather different AFEs may also be rather different.

i think the most important thing is thermal stability... 70°C dT 1°C is better than 50°C dT 10°C... larger heatsink can provide that... anyway, this thermal discussion is moot.

[shapirus]

So I'm tweaking the webcontrol app. Decompiled, tweaked, rebuilt, signed (with a self-signed key), aligned, now trying to install.

attempt 1:

Code: [Select]

1|rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt1-signed-aligned.apk                                                                              
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]

ok, makes sense, since it's already installed. Uninstalling, trying again:

Code: [Select]

rk3399_rigol:/data/UserData/apk # pm uninstall com.rigol.webcontrol                                                                                                   
Success
rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt1-signed-aligned.apk                                                                                
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]

wtf? okay, googled, apparently it needs the "--user 0" argument. Let's try:

Code: [Select]

1|rk3399_rigol:/data/UserData/apk # pm uninstall --user 0 com.rigol.webcontrol                                                                                        
Success
rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt1-signed-aligned.apk                                                                                
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]

ok maybe it's installed for user 1000 too? let's see:

Code: [Select]

1|rk3399_rigol:/data/UserData/apk # pm uninstall --user 1000 com.rigol.webcontrol                                                                                     
Failure [not installed for 1000]

nope.

Does being a system app imply that there's more to be done than just "pm uninstall"? The app isn't showing as installed by "cmd package list packages", but can still be inspected with "pm dump com.rigol.webcontrol", and I see the following in its output:

Code: [Select]

  Packages:
    Package [com.rigol.webcontrol] (75e2815):
      userId=1000
      sharedUser=SharedUserSetting{df4892 android.uid.system/1000}

What the hell else does it want?

Do I need to remove the respective apk under /system/app as well? I'm kinda hesitant to do it until I figure it out.

Webcontrol shouldn't be any different in this respect from com.rigol.scope -- what did you guys do to fully uninstall it before reinstalling your rebuilt and self-signed versions?

[AndyBig]

So I'm tweaking the webcontrol app. Decompiled, tweaked, rebuilt, signed (with a self-signed key), aligned, now trying to install.

Code: [Select]

1|rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt1-signed-aligned.apk                                                                              
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]

...

What the hell else does it want?

Do I need to remove the respective apk under /system/app as well? I'm kinda hesitant to do it until I figure it out.

Webcontrol shouldn't be any different in this respect from com.rigol.scope -- what did you guys do to fully uninstall it before reinstalling your rebuilt and self-signed versions?

You need to remove android:sharedUserId="android.uid.system" from the application manifest. This property in the manifest specifies that the application should be installed as a system application and run under the "system" account. But for this, the application must be signed with a system key.
Well, yes, when you install your self-signed application for the first time, you need to completely remove the native system one before installing it. But you have already done it In the future, when you update your application (with the same signature), you can simply update it without first deleting it.

[shapirus]

You need to remove android:sharedUserId="android.uid.system" from the application manifest.

Nope, same thing:

Code: [Select]

rk3399_rigol:/data/UserData/apk # pm uninstall com.rigol.webcontrol
Success
rk3399_rigol:/data/UserData/apk # pm uninstall --user 0 com.rigol.webcontrol                                                                                          
Success
1|rk3399_rigol:/data/UserData/apk # cmd package list packages|grep rigol
package:com.rigol.launcher
package:com.rigol.scope
1|rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt2-signed-aligned.apk                                                                              
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]
1|rk3399_rigol:/data/UserData/apk # pm install -r --user 0 Webcontrol-rebuilt2-signed-aligned.apk                                                                     
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]

This property in the manifest specifies that the application should be installed as a system application and run under the "system" account. But for this, the application must be signed with a system key.

Yes, but the error is not just about a key mismatch, it's about a key mismatch for an already installed app. Unless they reused that message or used poor wording, I think the system still thinks that the app is installed.

Here's the error I'm getting when I try to install the original apk:

Code: [Select]

1|rk3399_rigol:/data/UserData/apk # pm install Webcontrol.apk
Failure [INSTALL_FAILED_ALREADY_EXISTS: Attempt to re-install com.rigol.webcontrol without first uninstalling.]

So the system really does think that it's already installed. I need to add the "-r" argument (reinstall) to make it install it.

Well, yes, when you install your self-signed application for the first time, you need to completely remove the native system one before installing it. But you have already done it In the future, when you update your application (with the same signature), you can simply update it without first deleting it.

Well apparently I still haven't uninstalled it well enough.

Any more ideas? Renaming the Webcontrol directory and the apk in it in /system/app doesn't help either.

Do I need to reboot? I'm a bit afraid to do it without webcontrol being installed, since the rigol boot scripts are so fragile and can render the system unusable.

UPDATE: I rebooted the scope, and lo and behold!

Code: [Select]

rk3399_rigol:/data/UserData/apk # pm install Webcontrol-rebuilt2-signed-aligned.apk
Success

Now it seems to lack permissions to access framebuffer or whatever, even though I did add the following to /etc/permissions/platform.xml:

Code: [Select]

    <system-user-whitelisted-app package="com.rigol.webcontrol" />

Did I miss something else?

...or maybe it's my changes that broke it. Will look at that tomorrow.

[AndyBig]

Code: [Select]

1|rk3399_rigol:/data/UserData/apk # pm install -r --user 0 Webcontrol-rebuilt2-signed-aligned.apk                                                                     
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]

Do I need to reboot? I'm a bit afraid to do it without webcontrol being installed, since the rigol boot scripts are so fragile and can render the system unusable.

Don't use "--user 0"
Yes, you can safely reboot the oscilloscope after removing the webcontrol, it works without any problems.
Did you stop it running before deleting this application?
rk3399_rigol:/ # am force-stop com.rigol.launcher
rk3399_rigol:/ # am force-stop com.rigol.webcontrol
rk3399_rigol:/ # pm uninstall com.rigol.webcontrol

I will now try to re-sign and install this application myself.

[shapirus]

Don't use "--user 0"

Yes it works without it.

Yes, you can safely reboot the oscilloscope after removing the webcontrol, it works without any problems.
Did you stop it running before deleting this application?

I've updated the post above -- yes a reboot fixed it and I was able to install the self-signed app. Nothing else worked, including the force-stop commands, which I did try at some point too (and I checked the process list to make sure that it wasn't running).

Now having what I think may be permission issues, despite the added line in /etc/permissions/platform.xml, and I'll debug this tomorrow, starting with installing a rebuilt apk without any changes except it being self-signed. Maybe it just needs another reboot btw so that the system sees the change in platform.xml -- I didn't try this. Hope it's this.

[Fungus]

So I'm tweaking the webcontrol app. Decompiled, tweaked, rebuilt, signed (with a self-signed key), aligned, now trying to install.

A good hack would be to fix the screen resolution in the web control and screen recording, it seems to have DHO1000 resolution. The resolution is set in an HTML file which seems to be embedded in the .apk (or at least, I couldn't find it as a file on the internal disk).

Saving the screen as .png instead of .jpg would also be good. I don't know if a simple patch to change .jpg to .png would work.

[AndyBig]

Don't use "--user 0"

Yes it works without it.

Yes, you can safely reboot the oscilloscope after removing the webcontrol, it works without any problems.
Did you stop it running before deleting this application?

I've updated the post above -- yes a reboot fixed it and I was able to install the self-signed app. Nothing else worked, including the force-stop commands, which I did try at some point too (and I checked the process list to make sure that it wasn't running).

Now having what I think may be permission issues, despite the added line in /etc/permissions/platform.xml, and I'll debug this tomorrow, starting with installing a rebuilt apk without any changes except it being self-signed. Maybe it just needs another reboot btw so that the system sees the change in platform.xml -- I didn't try this. Hope it's this.

Everything worked out for me using the following algorithm:
1. Stopped the launcher and web control:

Code: [Select]

rk3399_rigol:/ # am force-stop com.rigol.launcher
rk3399_rigol:/ # am force-stop com.rigol.webcontrol

2. Uninstalled web control:

Code: [Select]

rk3399_rigol:/ # pm uninstall com.rigol.webcontrol

3. Remounted /system to RW:

Code: [Select]

rk3399_rigol:/ # mount -o rw,remount /system

4. Deleted the /system/app/Webcontrol directory
5. Rebooted the oscilloscope.
6. Installed a modified (simply disassembled and reassembled and signed) application.

Well, there are problems with access to system APIs - screen capture is impossible, which means neither remote control nor screenshots/screen recording work.

A good hack would be to fix the screen resolution in the web control and screen recording, it seems to have DHO1000 resolution. The resolution is set in an HTML file which seems to be embedded in the .apk (or at least, I couldn't find it as a file on the internal disk).

Saving the screen as .png instead of .jpg would also be good. I don't know if a simple patch to change .jpg to .png would work.

Yes, all server files are stored inside the webcontrol application.

[shapirus]

A good hack would be to fix the screen resolution in the web control and screen recording, it seems to have DHO1000 resolution.

That's what I'm after.

The resolution is set in an HTML file which seems to be embedded in the .apk (or at least, I couldn't find it as a file on the internal disk).

Nah, html/js rely on what's being sent by the server, or at least they rely on that *too*, which remains to be seen. That the server pushes the picture with 1280x800 size is certain.

Saving the screen as .png instead of .jpg would also be good. I don't know if a simple patch to change .jpg to .png would work.

That may (or may not) be less than trivial. I'll check that once I get my modified apk to work at all.