Rigol MHO900 Fast Streaming (FFT viewer)

[Harvs]

I posted a couple of weeks back about some mods to speed up the SCPI readout on the MHO900. Here's another one that digs a lot deeper in the firmware, doing some more serious changes to maximize the continuous acquisition streaming rate out of the scope.  I have my own application for this, but I built a small FFT spectrum viewer as a test app. Might be useful in it's own right, but largely I just see this as a demo for the hacks to the firmware.

https://github.com/harvie256/mho-spectrum

If you try to acquire 1Mpt single channel captures from an MHO900 over the standard SCPI interface, you're capped about 0.57fps I think. It's about 1.4MB/s transfer speed and you have the SCPI overhead on top of that. It's a 12b scope, so two bytes per sample. This mod maxes out a USB2-Ethernet converter @ 35.2MB/s achieving 17.5fps on a single channel 1Mpt. It's capped at about 20fps for shorter captures, and longer or with multiple channels it scales roughly proportional to the data volume (8.8fps for 2 channels, 5.7fps for 3, 4.4. for 4 channels, etc.)

First it needed CPU time back, despite having a RK3399 it's a pretty CPU bound scope with how the software is built:
1. Hooked and bypassed the wave redraw - so it doesn't plot the waveform on it's own screen. That save most of one of the big cores.
2. Stops logd, simple adb shell stop logd, that was burning 0.6 of a core.

Next was to hook and bypass the whole SCPI system and implement a separate arming and data transfer system.  Sounds easier than it was, this binary is a number of separate threads competing on futexs with short delays. Some in kernel space and some in user. There's polling going on everywhere which is making the whole thing CPU bound. Anyway where it ended up is using SCPI to set the scope up at start, then hooking the functions to arm in single mode, then hooking the CDrvScope::ReadNormTrace return to know when it's done, take the config lock, read out the channel layout for the acquisition to know how the data is interleaved, then use the DrvWaveform_Export function to transfer the data into our own buffer that gets transferred to the PC. All the whilst skipping over the scopes normal data pathways.

It's all implemented as a Frida script, so no actual changes remain on the scope itself. When the PC app closes, Frida server unhooks from the scope memory and the scope is back to normal. Flash is never touched.

I have however setup a networking rule on the SD card to auto configure my USB-Ethernet adapter so I don't have to initalise via another interface to get that up each time.