Hacking the Rigol DHO800/900 Scope

[ebastler]

The screen device runs it's own native "resolution", it has physical pixels. I'll look into the screen model and driver file to see if that's really the best res it is.
The app runs on a specified resolution. If that's not the native device res then the driver would need to interpolate. If the aspect is not the same then you get squishing and such.

I think perhaps the spec sheet tells us what the Scope app is, and less about the underlying devices of the hardware.

All good info.

Look, Randy, I really did not need an explanation from you on physical screen resolution vs. driver resolution etc.  Nobody here needs that. We have all used LCD monitors and seen the effect of different resolutions and driver settings; quite a few here have designed LCD monitors into systems and driven them on a low level. Seeing you dish out those explanations just makes me wonder whether (a) you have an unrealistic picture of the audience here, or (b) you have an unrealistic picture of yourself.

On the other hand, please consider why on earth Rigol should build in a higher-resolution display and then drive it a lower resolution?! The display would be more expensive; it would take more power; it would take more CPU/GPU bandwidth to drive the pixels; the interpolated picture would look worse than on a native-resolution display. And if they still were to use that high-res display despite all that: Why would they put anything but the highest justifiable resolution number into the datasheet??

I think you can safely drop that resolution hypothesis.

[AceyTech]

Installing wasn't so easy. At the beginning Rigol app was randomly switching up to front.

You could kill the scope app.  -It will be less annoying and will draw considerably less power. (and generate less heat, etc.) 

Now I think to install Linux instead of Android. Maybe Rigol app will work on anbox (app to use Android apps on Linux). That will be much more useful.

And might even boot faster!

[Randy222]

Installing wasn't so easy. At the beginning Rigol app was randomly switching up to front.

You could kill the scope app.  -It will be less annoying and will draw considerably less power. (and generate less heat, etc.) 

Now I think to install Linux instead of Android. Maybe Rigol app will work on anbox (app to use Android apps on Linux). That will be much more useful.

And might even boot faster!

You cant kill scope app, there's a watchdog that restarts it to MainActivity.
You can disable the app though so it can't start.

As side note, I am able to make edits in Sparrow.apk to change CH1 color.

However, Android is giving me grief. There are remnants of com.rigol.scope somewhere on the system that logs "versioning" along with the keys used for signing. My install of updated Sparrow.apk fails because the prrevious version used different keys.
I did full uninstall of the original app, removed all relative directories, but somewhere (possibly pm) it's holding onto previous version info.

I might try to rename the app to something like com.rigol.scopee and see if that works, but not today.

[AceyTech]

You cant kill scope app, there's a watchdog that restarts it to MainActivity.
You can disable the app though so it can't start.

Yep!  That's what I should've written., I couldn't quickly find the post by @Serg65536 referencing it, then got distracted with something else.  Thanks for the assist.

As side note, I am able to make edits in Sparrow.apk to change CH1 color.

However, Android is giving me grief. There are remnants of com.rigol.scope somewhere on the system that logs "versioning" along with the keys used for signing. My install of updated Sparrow.apk fails because the prrevious version used different keys.
I did full uninstall of the original app, removed all relative directories, but somewhere (possibly pm) it's holding onto previous version info.
I might try to rename the app to something like com.rigol.scopee and see if that works, but not today.

Would this Android APK Editor help at all?  looks kinda neat from the screenshots/description.  I don't know what the diff is from this and the G play store, but at least this one I posted has a normal looking version number.

EDIT:  @Serg65536's excellent guide to booting your scope without running the scope app by default

[AndyBig]

You could kill the scope app.  -It will be less annoying and will draw considerably less power. (and generate less heat, etc.) 

Before doing this, you need to kill the launcher app (com.rigol.launcher) first, otherwise it will restart the oscilloscope app every few seconds. And no, if the oscilloscope application has been loaded at least once, then it will no longer consume less. Consumption increases when the FPGA is initialized in the start_rigol_app.sh script and after that remains high until the device is turned off

And might even boot faster!

If you disable the launcher so that it does not cause execution of the start_rigol_app.sh script upon startup, then the startup time is about 38 seconds However, I haven’t figured out how to manually trigger the execution of this script from Android, and without it, the oscilloscope application, of course, does not work normally.

[AceyTech]

You could kill the scope app.  -It will be less annoying and will draw considerably less power. (and generate less heat, etc.) 

Before doing this, you need to kill the launcher app (com.rigol.launcher) first, otherwise it will restart the oscilloscope app every few seconds. And no, if the oscilloscope application has been loaded at least once, then it will no longer consume less. Consumption increases when the FPGA is initialized in the start_rigol_app.sh script and after that remains high until the device is turned off

And might even boot faster!

If you disable the launcher so that it does not cause execution of the start_rigol_app.sh script upon startup, then the startup time is about 38 seconds However, I haven’t figured out how to manually trigger the execution of this script from Android, and without it, the oscilloscope application, of course, does not work normally.

38 seconds is NOT very much of a savings. 

See the guide I posted above(from page 24) that I mentioned @Serg65536 wrote up.  Not exactly sure if it's still relevant these days., but worth a try for those who care.

EDIT:  @Serg65536's excellent guide to booting your scope without running the scope app by default

[AndyBig]

38 seconds is NOT very much of a savings. 

See the guide I posted above(from page 24) that mentioned that Serg wrote up.  Not exactly sure if it's still relevant these days., but worth a try for those who care.

It's not entirely clear there either. After you disable autorun for the native launcher, it will not automatically launch the FPGA initialization script and the oscilloscope application, this is understandable. But how can you launch the oscilloscope application at any time after this? The FPGA remains uninitialized and the application will not work normally.

[Fungus]

You could kill the scope app.

It restarts automatically. 

[Randy222]

You cant kill scope app, there's a watchdog that restarts it to MainActivity.
You can disable the app though so it can't start.

Yep!  That's what I should've written., I couldn't quickly find the post by @Serg65536 referencing it, then got distracted with something else.  Thanks for the assist.

As side note, I am able to make edits in Sparrow.apk to change CH1 color.

However, Android is giving me grief. There are remnants of com.rigol.scope somewhere on the system that logs "versioning" along with the keys used for signing. My install of updated Sparrow.apk fails because the prrevious version used different keys.
I did full uninstall of the original app, removed all relative directories, but somewhere (possibly pm) it's holding onto previous version info.
I might try to rename the app to something like com.rigol.scopee and see if that works, but not today.

Would this Android APK Editor help at all?  looks kinda neat from the screenshots/description.  I don't know what the diff is from this and the G play store, but at least this one I posted has a normal looking version number.

EDIT:  @Serg65536's excellent guide to booting your scope without running the scope app by default

apktool is my goto item.

I can unpack, edit, repack, zipalign, apksigner it. All the verify stuff seems to indicate the "new" APK is a-ok.
The issue now is an Android issue. It remembers previously install apps, even if you uninstall them. I not sure yet where this mapping lives in this Android.

As example, it's fully uninstalled, yet "pm list packages -u" still shows an entry for com.rigol.scope

[Fungus]

The FPGA remains uninitialized and the application will not work normally.

Maybe "/rigol/shell/reload_fpga.sh" will give a clue...

[shapirus]

BTW, how is the main app actually started?

The shell/start_rigol_app.sh script has it commented out (around line 150):

Code: [Select]

### Start Main APP
# sleep 3
# am start -n com.rigol.scope/.MainActivity

And nowhere in the shell scripts I see a command to start it, except restartScope.sh:

Code: [Select]

#!/system/bin/bash
su
kill -9 $(pidof com.rigol.scope)
am start -n com.rigol.scope/.MainActivity

but it isn't referenced in any of the other shell scripts. A mystery!

[AceyTech]

38 seconds is NOT very much of a savings. 

See the guide I posted above(from page 24) that mentioned that Serg wrote up.  Not exactly sure if it's still relevant these days., but worth a try for those who care.

It's not entirely clear there either. After you disable autorun for the native launcher, it will not automatically launch the FPGA initialization script and the oscilloscope application, this is understandable. But how can you launch the oscilloscope application at any time after this? The FPGA remains uninitialized and the application will not work normally.

His 11th(optional) step doesn't describe how to launch it from the new launcher?

[Randy222]

BTW, how is the main app actually started?

The shell/start_rigol_app.sh script has it commented out (around line 150):

Code: [Select]

### Start Main APP
# sleep 3
# am start -n com.rigol.scope/.MainActivity





And nowhere in the shell scripts I see a command to start it, except restartScope.sh:

Code: [Select]

#!/system/bin/bash
su
kill -9 $(pidof com.rigol.scope)
am start -n com.rigol.scope/.MainActivity

but it isn't referenced in any of the other shell scripts. A mystery!

The commenetd out stuff is old stuff, they just did not remove it from the script. Why they made this thing so convoluted makes you head-scratch. I suspect 800-900 is just a port down from their bigger brothers and sisters, and they just hacked out what was not needed using comment '#', and then added stuff as break-fix so it will work.

There are several Activities listed in the Manifest. You can us 'am' to call an Activity, like "am start -n com.rigol.scope/.MainActivity"
You can move the scope app to rear, and then recall the Main Activity, am will just say "already running, moving app to front", and then you see scope app on screen again.

They app start from init.rigol.rc:service startApp /system/bin/bootApp.sh

Basically an init start command (call other script). That bootApp script is also copied into /rigol/shell/, probably from doing an install of a GEL.

Look at /init.rigol.rc script, it does all that ssh key copying too, and some other stuff.
It's easier to leave the init script alone when it comes to doing scope update with a GEL file. So they make changes to the scripts in /rigol/shell , etc. This is an easier approach for the way they crafted GEL updates.

When you do some of these tests from scope screen, they call to an activity.

Code: [Select]

<activity android:name="com.rigol.scope.ActivityRigolTouchTest"/>
        <activity android:name="com.rigol.scope.ActivityRigolLcdTest"/>
        <activity android:name="com.rigol.scope.ActivityRigolKeyTest"/>
        <activity android:name="com.rigol.scope.ScreenSaverActivity"/>

[shapirus]

The commenetd out stuff is old stuff, they just did not remove it from the script. Why they made this thing so convoluted makes you head-scratch. I suspect 800-900 is just a port down from their bigger brothers and sisters, and they just hacked out what was not needed using comment '#', and then added stuff as break-fix so it will work.

There are several Activities listed in the Manifest. You can us 'am' to call an Activity, like "am start -n com.rigol.scope/.MainActivity"
You can move the scope app to rear, and then recall the Main Activity, am will just say "already running, moving app to front", and then you see scope app on screen again.

They app start from init.rigol.rc:service startApp /system/bin/bootApp.sh

Basically an init start command (call other script). That bootApp script is also copied into /rigol/shell/, probably from doing an install of a GEL.

No, still not clear.

All the bootApp.sh script does is initialize the logs directory (if not exists already) and call /rigol/shell/start_rigol_app.sh, which does not have any reference to com.rigol.scope except that commented out one.

Look at /init.rigol.rc script, it does all that ssh key copying too, and some other stuff.

This init script calls (among other things) the bootApp.sh script, but again no reference to com.rigol.scope.

In fact,

Code: [Select]

1|rk3399_rigol:/ # grep com.rigol.scope /*.rc                                                                                                                 
1|rk3399_rigol:/ #

None of the init scripts have it either.

However it's mentioned here:

Code: [Select]

./data/data/com.rigol.launcher/shared_prefs/spUtils.xml:    <string name="launch_package_name">com.rigol.scope</string>

Also this makes it clear that yes it's managed by com.rigol.launcher:

Code: [Select]

./data/system_ce/0/recent_tasks/260_task.xml:<task task_id="260" real_activity="com.rigol.scope/.MainActivity" real_activity_suspended="false" affinity="com.rigol.scope" root_has_reset="false" auto_remove_recents="false" asked_compat_mode="false" user_id="0" user_setup_complete="true" effective_uid="1000" task_type="0" first_active_time="1358470242648" last_active_time="1358470242667" last_time_moved="1358470242650" never_relinquish_identity="true" task_description_color="ff6200ee" task_description_colorBackground="ff303030" task_thumbnailinfo_task_width="0" task_thumbnailinfo_task_height="0" task_thumbnailinfo_screen_orientation="0" task_affiliation_color="-10354450" task_affiliation="260" prev_affiliation="-1" next_affiliation="-1" calling_uid="1000" calling_package="com.rigol.launcher" resize_mode="2" privileged="false" min_width="-1" min_height="-1">

(I'm referring to the calling_package attribute)

Now, how is com.rigol.launcher started? It's late, so I'll continue with this later, unless someone has an answer ready.

The purpose of this search is to get a clear understanding of the boot sequence and the component dependencies to adequately experiment with those hardcoded sleeps and other stuff to reduce the boot time.

[AndyBig]

The FPGA remains uninitialized and the application will not work normally.

Maybe "/rigol/shell/reload_fpga.sh" will give a clue...

Yes, but how can a user execute a script in Android? So I removed the launcher, now my oscilloscope starts with an output to the desktop. And how can I make it so that I can start the FPGA initialization from there?

[AndyBig]

I was able to modify the application, package it, and get it working. Tried changing the color of channel 1 to white, like Randy222. And I did it! True, not exactly where I expected ) It’s not the wave itself that has changed, but the channel indicator
True, the application now does not work fully - for some reason, screenshots are not saved. I had to take a screenshot via web control. I don't know why this could be.

[AceyTech]

I was able to modify the application, package it, and get it working. Tried changing the color of channel 1 to white, like Randy222. And I did it! True, not exactly where I expected ) It’s not the wave itself that has changed, but the channel indicator
True, the application now does not work fully - for some reason, screenshots are not saved. I had to take a screenshot via web control. I don't know why this could be.

Do you need to re-assign the shortcut key for the screenshot?  Maybe the defaults are saved elsewhere(or not saved) after modification...

Also, What method did you use to modify the app?  Manual or via an app?

EDIT:  Earlier I posted a link at #1533 to an app that modify/signs/packs APKs (that I haven't tried yet), but the hyperlink was obfuscated behind a word.  Since I'm not well experienced with Android I've been looking for apps to carry out some mods

https://apk-editor.en.uptodown.com/android

[AndyBig]

Do you need to re-assign the shortcut key for the screenshot?  Maybe the defaults are saved elsewhere(or not saved) after modification...
Also, What method did you use to modify the app?  Manual or via an app?

No, I checked that right away. The Quick button is assigned a screenshot action, but the screenshot is not created on disk. Even through the Storage menu, clicking the Save button does not save the screenshot. Settings or Wave are saved without problems.
Unfortunately, I didn’t understand the question about changing the application

[AceyTech]

Also, What method did you use to modify the app?  Manual or via an app?

Unfortunately, I didn’t understand the question about changing the application

I'm guessing you didn't use the app, then...     FYI: I edited my post above yours with the link.

[AndyBig]

I'm guessing you didn't use the app, then...     FYI: I edited my post above yours with the link.

Ah, I understand what application we are talking about. No, I used apk_tool and tools from Android SDK.

[AndyBig]

Yeah, I think I understand why screenshots are not being recorded. When you try to take a screenshot, the following line is added to the log, among other things:

Code: [Select]

02-22 07:44:35.551 221 279 E SurfaceFlinger: Permission Denial: can't read framebuffer pid=1753, uid=10035Apparently, this is due to the fact that I changed the user of the application to solve the problem with the new keys with which I signed the application after the changes.

[Fungus]

I was able to modify the application, package it, and get it working. Tried changing the color of channel 1 to white, like Randy222. And I did it! True, not exactly where I expected ) It’s not the wave itself that has changed, but the channel indicator

Exactly what I expected. 

The trace on the screen will be in the FPGA code. Good luck modifying that...

[AceyTech]

I was able to modify the application, package it, and get it working. Tried changing the color of channel 1 to white, like Randy222. And I did it! True, not exactly where I expected ) It’s not the wave itself that has changed, but the channel indicator

Exactly what I expected. 

The trace on the screen will be in the FPGA code. Good luck modifying that...

Are you suggesting the scope trace data is assigned colors in the framebuffer before it leaves the FPGA?  And if so, are all the math and FFT waveforms treated in the same way? 

Doesn't seem very logical.  Any UI changes would require modifying the VHDL.  Seems more likely that the Framebuffer would be color agnostic, but referenced to specific channels, and leave it to the UI team to apply the colors to the individual bit planes.

[ebastler]

Are you suggesting the scope trace data is assigned colors in the framebuffer before it leaves the FPGA?  And if so, are all the math and FFT waveforms treated in the same way? 

Doesn't seem very logical.  Any UI changes would require modifying the VHDL.  Seems more likely that the Framebuffer would be color agnostic, but referenced to specific channels, and leave it to the UI team to apply the colors to the individual bit planes.

I would also expect that the FPGA does not prepare the complete frame buffer. The resolution and number of pixels in the traces is probably defined by the FPGA, as well as the greyscale values based on the digital phosphor simulation. But then the CPU will transfer those data to the screen, most likely assigning colors at that point.

[maxspb69]

FPGAs have no user interface at all. User interfaces is not a task for FPGAs.
All screen rendering is done by the Rockchip SOC, but according to data prepared in the FPGA, as ebastler correctly noted.