There's more showing up on screen which is always good.
I was thinking about making fullscreen mode, more or less like the others did, but when I was fixing bugs related to roll mode and LA, I noticed that waveform screen area is hardcoded in many places. Without the source code it will be very difficult to change those sizes and offsets dynamically. As always I need to manage my work time. Fullscreen mode with only 9% increase of waveform window (or other windows) to make it fully properly, can take maybe even two weeks. I already experienced many times that whole Android, Java and C++ languages are nothing else than reinventing the wheel. But instead of a circle shape, it ended as a triangle... If that things would be written in C with enabled compiler optimizations, it should boot (system+app) in like 10 seconds or maybe even less. Also working with properly written code in C is much easier and faster than working with the crap like the most of Java/C++ "software engineers" do - including Rigol ones.
Currently in my mod, space for the windows (one waveform window by default) as I calculated some time ago, is roughly 91%. I think this is good enough to work comfortably with this scope. Even it's quite good with the LA with all channels enabled. If that is not enough (more windows, decoders, etc), it should be better to connect PC monitor. With my very old 21'' Eizo (much better than today popular crap and current price is around 30 $) I can read everything from a couple meters.
On the side note, in Android framebuffer size can be easily changed to anything - for example, if somebody has a 1920x1080 monitor, it can be used in native resolution without interpolating pixels. But it will also affect internal LCD, which will be more or less unreadable, until framebuffer size will be changed back to the size of this LCD panel (1024x600). GPU in the RK3399 in most cases (it's complicated in details) can make a screen output up to the 1920x1080, so generally this is a maximum.
Once somebody asked here how to use HDMI monitor as a separate screen on this scope. On the hardware side this is possible (
proof), but the current kernel has a driver compiled as built-in and with enabled mirroring on the kernel configuration side. I have other reasons to compile more modern kernel version, so this likely should also fit together.
Also when moving the vertical graduations they now don't end on stupid offsets such as 0.012V, it's a nice snappy 0V.
I see three possibilities. You are doing something differently or I did another feature by accident. Like a unintended bug, but it's feature instead. Or it was one of many very small changes that it was too small to make an effort to put this into changelog and later it become completely forgotten. I did a lot of small changes like that.
it's mostly used for troubleshooting glitching setups.
In that case, "fast" acquisition in v0.3 can be useful for You. It does up to 100 k waveform updates per second with 10 kpts mem. depth. With lower mem. depth and linear interpolation, there is a bug in FPGA firmware - on the screen it looks like it's somewhere more than 100 k, but trigger output (AUX socket at the back) gives something around 23 Hz...
BTW. I was thinking about making a software fan control (separate app in the background or via the kernel) in order to maintain stable temperature inside. There are at least four GPIO pins (hw code, which is unused in my mod) that can be used for anything. Linux kernel (used in Android) has a PWM driver and even without recompiling it, it should be simple to use modified kernel module from the DHO4000 which uses exact same kernel (change of gpio pin number in the compiled module is very easy). That will require less parts than making it fully electronically.
This might be helpful for others that don't want to open their scopes. But I don't regret doing the swap, this is much more peaceful. You can probably do it without opening the scope anyways, I just wanted to plug to the original header.
I had in mind unused GPIO pins that are available on PCB (my mod doesn't read hw code, In most places it's hardcoded to 0 like in DHO4000, which enables some features). Originally, both fan and the LCD backlight power (looks like it's doubled...) are driven by the same GPIO pin. "Sleep mode" kills the app and pulls down this one gpio pin. In this case, I think the only one logical option to drive the fan programmatically, is by using "hw code" GPIO pins. But maybe somebody else has better idea than mine.
As I said, point of this is to maintain more or less the same temperature all the time. In that case we should have more stable vertical offset. This is one of the reasons why self calibration exists.
Can You provide a screenshot? All channels are the same? For a comparison, I attached screenshot from the upcoming v0.3, which has exactly the same layout of channels in the "navigation bar" - different color makes it clearly distinguishable, at least for me.
The screenshot shows that I have two channels active, but in the lower bar it doesn't display well which one is selected so it's a game of hit and miss when I want to open its options. I've played with it a bit and now I see that the 1 pixel vertical bar to the right of the selected channel changes color, but it's hard to see really compared to the original interface I was used to. They wasted screen real estate but it made more sense visually at least to me.
I misunderstood You earlier. Right now, You can look at the vertical scale on the grid (1V, 2V, 3V, etc), because it's color is the same as the selected channel color. Original thick background (which had channel color if this one was selected, grey otherwise) literally I changed to the line on the right side. If You watch closely, it changes color in the same way as in the original app. Now You made me idea to make this line thicker. Right now it's 1 px. I think 3 px or maybe 4 px should be good enough to see which one is selected.
On the other hand, probably it will be literally ugly with almost everything else being 1 px thick. Also, Android uses very crazy and developer unfriendly things, so that one change can take much more time than the same thing in CSS used in web pages - in CSS it's just a simple change of a single number in a text file or change line with path with the background image to something like:
border: 1px solid color_name_or_value and that's it. Anyway, I will look into that later.
Speaking of the vertical scale, in v0.2.1 and earlier versions it's being moved from right to left when You open measurements. I changed this behavior in v0.3 to be always on the left side.
Home
Help
Search
Login
Register
