Display form factor and electronics investigations

The state of the art for our displays remains Jeremy's new and improved, fully custom, and very compact Airball display. This design has everything we need -- bright screen; real-time clock; enough processing power and memory; the works.

As we have used our system in regular flight, however, we have discovered that the Airball use case does not require frequent manipulation of a control knob. This is not a GPS where you constantly need to pan and zoom and enter waypoints. Aside from initial calibration, there are two functions that are done regularly:

1. Change screen brightness; and
2. Change the altimeter setting.

It's perfectly okay to have "up/down" buttons for each of these, rather than a nice ergonomic encoder knob. And with that, it's possible to save some valuable front-panel space.

The culmination of this thinking is the following rough mockup:

Note we have a row of 5 buttons across the top, which take hardly any space at all. The remainder is just barely larger than the LCD display itself. There remains plenty of space on the PCB for our Raspberry Pi Compute Module 3, and any other electronics we might need. And without the knobs adding thickness, we can make the whole assembly very thin.

So -- this may seem like a step "back" in ergonomic goodness, losing the nice chunky aviation-feeling knob, but we feel it's a step forward in general usability in a cramped cockpit.

*  *  *

Now as for the innards, these will have to change somewhat. We are now going to need to use Wi-Fi rather than the XBee modules. The Raspberry Pi Compute Module 3 does not contain on-board Wi-Fi. We have two options, actually, which differ somewhat subtly....

The first option is to add to the board some sort of embedded processor that is Wi-Fi capable and which lets us grab the data we need. For example, we could embed an ESP32-WROOM-32U and have the Raspberry Pi "program" it on the fly using a USB connection, and somehow use it to grab the Airball data. This is completely possible and will definitely work.

But a second, better option is to add a Wi-Fi processor that the Linux distro and device drivers on the Raspberry Pi can recognize as a generic Wi-Fi adapter and use natively. That way the Wi-Fi connection could be better for general purpose use. Including uses that we might not ever have thought of -- I mean, if other folks can use this display for their own projects, for whatever reason, this just adds to our own economy of scale and makes the world a better place. Right?

So this second direction has us looking at stuff like a TI WiLink adapter connected to the Raspberry Pi Compute Module 3 via its SDIO interface. If we can get that working, it would be far preferable. The one problem with the TI WiLink modules is that they do not have an on-board u.FL connector for the RF -- they break that out as a pad on the module, and you must build your own antenna. I think that this still means we can consider our system to be "pre-certified", and it's not rocket surgery to create a tiny trace leading to a u.FL connector on the board we design ... but it's something we need to think carefully about.

*  *  *

While on the topic of display electronics, we thought somewhat about whether we should try to go with a BeagleBoard Black base rather than our current Raspberry Pi. The BBB has many advantages. For one thing, it breaks out "raw" LCD panel outputs from the board itself, whereas the Raspberry Pi (even the Compute Module 3) produce HDMI outputs, and we need an HDMI decoder to turn that into raw LCD signals. Also, at some point, we can simply embed the Octavo OSD335x System-in-Package in our system, which would contain pretty much everything we need and would be super compact!

We did some early comparisons of the performance of a BBB and a Raspberry Pi 3+.

This is a video of the BBB showing about 14 frames per second drawing Airball in an X11 environment. For comparison, this is a video of a Raspberry Pi 3+ showing about 23 frames per second on the same task. So the Pi gets about 164% of the performance of the BBB given these constraints. That's one data point.

We tried to run our Airball software with the Linux framebuffer on our BBB, but it locked up. We were not able to get it to run at all. We had that trouble a couple years ago, and things have apparently not changed. We are not doing anything "weird" in our software, so strike one against the BBB, from a viewpoint of just amorphous technical risk if nothing else.

Finally, we ran our Raspberry Pi 3+ with the framebuffer, with an 800x600 screen. Note that this will be slow than our regular 480x272 display, because even if we are not painting the whole 800x600 buffer, we still have to ship it in an out of display memory. But that was the test setup we had, in any case, and this is a video of it running at 16.5 frames per second.

Now recall that we are sending data from our probe at 20 Hz, and we really don't want to go below 20 frames per second so as to maintain the illusion of a smooth "analog" instrument. We therefore conclude that:

1. We are not confident that the BBB / Octavo 335x will give us adequate performance;
2. As best we can tell, we are probably pushing the display performance with our application anyway, so we can't afford to slack off;
3. The BBB / Octavo 335x has shown nontrivial technical risk due to framebuffer crashes;
4. The Raspberry Pi is updated constantly with new models, whereas the BBB has stagnated somewhat;
5. The Raspberry Pi is more popular in the usual hobby circles, and in particular in aviation hacking (note the "Stratux" ADS/B receiver, for example); but mainly
6. We already have a super performant and super compact Raspberry Pi Compute Module 3 design that Jeremy created, and any modifications we need to make to it are minor.

Our decision therefore is to continue to pursue the Raspberry Pi Compute Module 3 design. Maybe there will be a time when we need a super lightweight, super small Airball display, and we can revisit the possibility of using some other processor. But for now, we believe we have done our due diligence and should proceed as previous with the excellent design that Jeremy created.

*  *  *

One of the thoughts we have is, what about other output modalities? Folks are working on giving air data information to the pilot using haptics, sound, and any of a number of other things we haven't even thought of yet. Can we support these use cases? If so, then how?

The easiest way we can do that is to provide a series of GPIO pinouts in our new display board, arranged so that they can be populated with 0.1" screw terminal blocks or any other kind of connection that someone might like to think of. It's not yet 100% clear where or how, but basically, if there is a convenient I/O from the Raspberry Pi Compute Module 3, and we are not already using it, we should consider making it accessible as a simple pinout.