Hacking the Rigol DHO800/900 Scope

[ebastler]

FPGAs have no user interface at all.

That's not categorically true, of course. I have driven HDMI screens directly from FPGAs -- they certainly can maintain an on-chip frame buffer, or generate pixel information on the fly, and drive the required TMDS signals. But as you state, that's not how the screen in the DHO scopes is connected; it is driven by the Rockchip SOC.

[maxspb69]

I’m not saying this, it’s just done that way.
Moreover, Rockchip has HDMI and MIPI-DSI controllers, a hardware-based framebuffer, etc.
You can use FPGA to simply organize a framebuffer and even draw the simplest elements in it. But you can’t make a complex user interface on an FPGA, it’s not that it’s impossible, but it’s damn difficult and pointless, that’s what processors are for.

[AndyBig]

Exactly what I expected. 
The trace on the screen will be in the FPGA code. Good luck modifying that...

Yes, I also come to this opinion. Of course, I won’t even try to edit the FPGA configuration, it’s unrealistic

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 assume that the application can set the FPGA trace drawing parameters - window size, number of points, trace color, afterglow, etc. And then just take a ready-made buffer with an image of the trace and overlay it on the image of the interface. The interface itself is drawn by the application. I found in the decompiled sources the drawing of a panel with measurement results, the drawing of a grid in the trace window, and other things related to the interface. But I couldn’t find the process for drawing the traces. Although I didn’t search very carefully and I don’t understand the organization of programs for Android

[Fungus]

Are you suggesting the scope trace data is assigned colors in the framebuffer before it leaves the FPGA?

Yes.

And if so, are all the math and FFT waveforms treated in the same way? 

Probably.

Doesn't seem very logical.

Seems perfectly logical. The FPGA does all the work of decimating the samples and doing the sin(x)/x reconstruction.

[Randy222]

Everything to the screen is defined in Rigol APK.

[Randy222]

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.

Ahh. Sorry, I perhaps misunderstood the question from earlier.
The Rigol start script sets up xdma, screen, FPGA, TZ, some other stuff too.

Once an APK is installed it can have two states, ENABLED or DISABLED. The app can still run in both states, but ENBALED means that Android loads the app at boot time. You can still start a DISABLED app by manually calling an Activity in that app, such as using 'am start com.rigol.scope/.MainActivity'
It's like a service in Windows, "auto" vs "manual", but in Windows services "disabled" means just that, service cannot be started at all. Android is silly in many ways.

Not sure why they had a manual start command in the start script. Maybe they were testing, maybe the app was installed as disabled and they wanted to start app at specific time, or perhaps that line is just a leftover from another model.

[shapirus]

Once an APK is installed it can have two states, ENABLED or DISABLED. The app can still run in both states, but ENBALED means that Android loads the app at boot time. You can still start a DISABLED app by manually calling an Activity in that app, such as using 'am start com.rigol.scope/.MainActivity'
It's like a service in Windows, "auto" vs "manual", but in Windows services "disabled" means just that, service cannot be started at all. Android is silly in many ways.

All right, so then this question is morphing into "how does android boot initialization and service startup work?", which is outside of the scope of this thread :).

[Randy222]

Once an APK is installed it can have two states, ENABLED or DISABLED. The app can still run in both states, but ENBALED means that Android loads the app at boot time. You can still start a DISABLED app by manually calling an Activity in that app, such as using 'am start com.rigol.scope/.MainActivity'
It's like a service in Windows, "auto" vs "manual", but in Windows services "disabled" means just that, service cannot be started at all. Android is silly in many ways.

All right, so then this question is morphing into "how does android boot initialization and service startup work?", which is outside of the scope of this thread .

I was not the one to ask how the app starts.

[Randy222]

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.

Well, the /system/build.prop "persist.sys.framebuffer.main" option is set to only 1024x600@60
Whaaaa? The screen can do 1920x1080@60 just fine.
So, I can tell you, the device is not setup to use the screen at best resolution.

With the OEM setting, Scope app displays in the lower res, AND, taking screenshots and vid are in the lower res.

I changed the setting to be 1920x1080@60 and now the Scope app displays in that higher resolution (fonts and stuff will get smaller), AND, grabbing pics are now in the 1920x1080 resolution, even when you use Webcontrol take-pic.

There's also lcd_density setting, set to 228 by default. I tried 20 and the screen starts to look pixel-ated, then I try 300 and it looks good, but, from Android docs this setting appear to be some sort of "bucket" setting, so I suspect 300 is the same as the (probably calculated) 228 setting.

Why Rigol uses the lower res setting? Likely because the physical screen size is tiny, 7" diagonal, making things "hard to read" with a 1920x1080 res. I guess they figure if you want 1920x1080 you gonna slap down a larger 24" monitor with hdmi in 1920x1080 and view there?

I suspect though, if you run the DHO in 1920x1080, when you zoom in you get finer detail? I didn't do the math of painted signal pixels vs screen res.


As a side note, not sure what happened, maybe from mucking around with FPGA flashing, or maybe removal of Sparrow and reinstall did it. I have no front-end signal processing (at least not getting through Scope app to screen). 1kHz gen still works, the rest of Scope app seems to still be ok.

[AndyBig]

All right, so then this question is morphing into "how does android boot initialization and service startup work?", which is outside of the scope of this thread .

The Rigol.apk application is launched by the Launcher.apk application. There is no autostart of the oscilloscope application on Android

[ebastler]

Well, the /system/build.prop "persist.sys.framebuffer.main" option is set to only 1024x600@60
Whaaaa? The screen can do 1920x1080@60 just fine.
So, I can tell you, the device is not setup to use the screen at best resolution.

What lets you assume that the physical display resolution is the higher number? Display contents might just as well get scaled down to the physical 1024*600 if you set a higher res in software, right?

I have not seen teardown photos yet which went as far as removing the LCD panel and showing its type. So, short of taking a magnifying glass and counting pixels: Could you please measure the precise width and height of the active display area? (Scope powered on, measuring the outer dimensions of the gray frame that gets displayed.) The proportions of 1024:600 1280:800, 1920:1080 are all different. So those dimensions should give us a hint.

Edit: My bet is on 154 * 90 86 mm². Touch displays with 1024*600 resolution and 0.15 mm nearly square pixels are very common.

Edit²: Changed the vertical dimension above. Seems that the display manufacturer lies about "square" pixels. All those displays are only 85.9 mm tall according to their specs...

[AndyBig]

Why Rigol uses the lower res setting? Likely because the physical screen size is tiny, 7" diagonal, making things "hard to read" with a 1920x1080 res. I guess they figure if you want 1920x1080 you gonna slap down a larger 24" monitor with hdmi in 1920x1080 and view there?

I don’t believe that the developers from Rigol are so stupid that they didn’t think of installing a cheaper display with a real resolution of 1024x600 if everything in the oscilloscope is designed for this resolution.
When you specified a higher resolution to the application, it began to generate an image at this higher resolution, but Android automatically scaled it to the display resolution when outputting to it.
High resolution does not mean that everything on the screen will be small. You can look at smartphones with 2k or even higher resolution displays to see this.

[Randy222]

Why Rigol uses the lower res setting? Likely because the physical screen size is tiny, 7" diagonal, making things "hard to read" with a 1920x1080 res. I guess they figure if you want 1920x1080 you gonna slap down a larger 24" monitor with hdmi in 1920x1080 and view there?

I don’t believe that the developers from Rigol are so stupid that they didn’t think of installing a cheaper display with a real resolution of 1024x600 if everything in the oscilloscope is designed for this resolution.
When you specified a higher resolution to the application, it began to generate an image at this higher resolution, but Android automatically scaled it to the display resolution when outputting to it.
High resolution does not mean that everything on the screen will be small. You can look at smartphones with 2k or even higher resolution displays to see this.

1920x1080 , aka std "real hdmi" resolution, is just about the std starting point for any manufactured display these days. Buying something less is likely hard and-or more expensive, since everything is HD, 4k, 8k, etc.

1920x1080 on a physical 7" diag display makes things very tiny. So, you paint 1024x600 to that screen via the screen driver, which has to scale it up to native screen res, which simply means it blows up the image, making it easier to read.

If you painted 1024x600 without upscale to 1920x1080 in 1:1 fashion, in essence the 1024 paints with borders, that too would look very tiny on the screen.

You can test it to see if you get better zoom ability on a signal in the 1920x1080 setting.

The setting is not an App setting. It's a system build property. The app just says "ok, go paint my data to the screen". The screen driver (OS) needs to take the image and map it to the display.

[Randy222]

Well, the /system/build.prop "persist.sys.framebuffer.main" option is set to only 1024x600@60
Whaaaa? The screen can do 1920x1080@60 just fine.
So, I can tell you, the device is not setup to use the screen at best resolution.

What lets you assume that the physical display resolution is the higher number? Display contents might just as well get scaled down to the physical 1024*600 if you set a higher res in software, right?

That's false. Because if my physical screen (canvas) is 1920x1080 and whatever pic is being displayed fully on that canvas, I am looking at literally 1920x1080 pixels. If the source is native 1024x600 then I know some scaler inbetween had to do about x1.875 interpolation math. If my source is say 4k and my HD screen is full (assuming same aspect ratio, so no cropping), I know the scaler had to downscale using interpolation. Upscale means adding artifacts, downscaling means losing data. If however my source is 1920x1080 and I see full screen image on my HD 1920x1080 screen, there's no scaling, no artifacts, no lost data, it's a 1:1 mapping. A mismatch in aspect ration usually means cropping or having a border, like watching letterbox movie on an HD screen.

1024x600 is not same aspect ratio of 1920x1080, close, but not simple interger scaling.

As example, my Panny PHD plasma is an "HD" panel, yet does not have native canvas size of 1920x1080, the thing lieterally has to down-scale all HD signals to fit it's screen without changing the aspect ratio.

Anyways. There's a setting to try out. Need to remount /system as rw to make the change though.

[Randy222]

All right, so then this question is morphing into "how does android boot initialization and service startup work?", which is outside of the scope of this thread .

The Rigol.apk application is launched by the Launcher.apk application. There is no autostart of the oscilloscope application on Android

Launcher APK appears to be a watchdog type of app, keeps an eye on things.
com.rigol.scope should stay running when the Launcher is in disabled state.

The issue I have with not getting signal to the Scope app, seems to be that the APK did not install as a system app. So, back to figuring that out.

[shapirus]

The Rigol.apk application is launched by the Launcher.apk application.

...and what is that one started by?

[AndyBig]

1920x1080 , aka std "real hdmi" resolution, is just about the std starting point for any manufactured display these days. Buying something less is likely hard and-or more expensive, since everything is HD, 4k, 8k, etc.

No.

1920x1080 on a physical 7" diag display makes things very tiny. So, you paint 1024x600 to that screen via the screen driver, which has to scale it up to native screen res, which simply means it blows up the image, making it easier to read.

No.

You can test it to see if you get better zoom ability on a signal in the 1920x1080 setting.

Here is a screenshot taken with the resolution set to 1600x900. Does this mean that the physical display also has the same resolution?
And if I change the resolution to 2560x1440 in the application properties and take a screenshot, will this mean that the display also has this physical resolution?

Launcher APK appears to be a watchdog type of app, keeps an eye on things.
com.rigol.scope should stay running when the Launcher is in disabled state.

That's right.

The Rigol.apk application is launched by the Launcher.apk application.

...and what is that one started by?

Launcher.apk itself is located in Android autostart

[shapirus]

This screenshot looks awesome. So much better information density. Does it look good on the actual scope screen too?

[AndyBig]

Screenshot with a given resolution of 2560x1440

[AndyBig]

This screenshot looks awesome. So much better information density. Does it look good on the actual scope screen too?

No, in reality the numbers on the icons are almost unreadable. For example, it is impossible to see the voltage scale on the channel, horizontal scale parameters, etc. without looking closely. True, I have a matte film pasted on it, which slightly blurs the image, but I think even without it it will be difficult to read small numbers.

[gabiz_ro]

I have not seen teardown photos yet which went as far as removing the LCD panel and showing its type. So, short of taking a magnifying glass and counting pixels: Could you please measure the precise width and height of the active display area? (Scope powered on, measuring the outer dimensions of the gray frame that gets displayed.) The proportions of 1024:600 1280:800, 1920:1080 are all different. So those dimensions should give us a hint.

Just opened mine.
LCD is silicone glued into chassis.
So until someone (unlucky one) breaks one and need replacement and find model only option is to count pixels.
Take a high res photo zoom it on PC and start counting.
LCD flex cable is 30 pins
Looks like 5 pairs of high signals.
One may be clock rest 4 of them data lines.

There may be other method to count pixels.
Create some usual resolutions pics and mark some counts on pixels at bottom-top left-right open images on scope in full screen and see which one match.

[AndyBig]

No, in reality the numbers on the icons are almost unreadable. For example, it is impossible to see the voltage scale on the channel, horizontal scale parameters, etc. without looking closely. True, I have a matte film pasted on it, which slightly blurs the image, but I think even without it it will be difficult to read small numbers.

Hmm, but I was wondering how such a picture would be displayed on an external high-resolution display...

[ebastler]

Thanks for checking!

From my perspective there is no need to count pixels. The internet is full of 7" touch screens with 1024*600 pixels; they are thick on the ground; other scope manufacturers use them too. Higher resolution displays in that size are very exotic, and I have explained yesterday why it would seem absurd to install one and then drive and specify it at a lower resolution.

If Randy prefers to believe that he has a higher resolution display in his scope, so be it.

[Randy222]

This screenshot looks awesome. So much better information density. Does it look good on the actual scope screen too?

No, in reality the numbers on the icons are almost unreadable. For example, it is impossible to see the voltage scale on the channel, horizontal scale parameters, etc. without looking closely. True, I have a matte film pasted on it, which slightly blurs the image, but I think even without it it will be difficult to read small numbers.

But this is expected. We are taking a large canvas (larger than screen) and having it scale down into screen canvas. So as to not crop the source the scaler has to squish the source (to maintain a fully readable image), which means it has to remove pixels from the source in order to fit screen canvas. It's not like taking a 1920x1080 metal cookie cutter, cutting out a section of a 2560x1440 source, and then painting the screen 1:1 with the cutout. That would be cropping the image.

The lcd density setting of 228 is odd. That does not match up with a 7"diag screen in either 1920x1080 or 1024x600. However, 1920x1080 7" would need more density than 228. So, you tell me, what's the actual HxY pixel count for this DHO display?

[AndyBig]

The final point in the discussion about the physical resolution of the display. I am attaching images of a screenshot with a physical resolution of 1024x600, a photograph of a section of the display, and a comparative picture of a piece of the screenshot and the display. On a piece of screenshot, pixels are demarcated by lines. It is clearly visible that the display resolution matches the screenshot resolution, that is, 1024x600.