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.

Probe mechanical form factor investigations

Recall from our posting Ideas for a next-generation probe that we were thinking of going to a 1-inch diameter tube for our new probe, since the new ESP32 hardware is compact enough to let us get away with it. We have done a lot of thinking about this, and we'll share some of it.

We have been sheltering in place from COVID-19, and so our planned test flight schedule has been severely curtailed. This kind of work -- thinking and prototyping at home -- is still possible, though.

The quick summary is that this geometry imposes some difficult constraints that would be just fine if we were building some production device in a factory, but may conflict with our goal of making a probe design that anyone can easily reproduce from first principles in their home workshop. And so, this being still early in our development of Airball, we have rejected it in favor of our 2-inch diameter geometry. But we have some cool ideas for that, which you might find exciting. So read on.

It is important to understand our design constraints. We can build "anything" if we assume we have a factory producing stuff in volume, with injection molding and custom metal stampings and what not. But we don't. Our self-imposed constraints are:

1. Our design can be built from scratch using a commodity 3D printer and readily available parts. The builder will need to order a 2-layer PCB, perhaps with a paste stencil, and do a surface-mount assembly of the components.
2. Our design can be built from a kit by a hobbyist using screwdrivers, small wrenches, pliers, a commodity electric drill, sandpaper, and possibly CA glue ("Super glue"). The kit builder must not be required to do any soldering.
3. Our kit can be constructed via a farm of commodity 3D printers, and PCBs ordered pre-stuffed from a small volume assembly shop, with possible lightweight post-production operations like soldering on headers, connectors, or large-tolerance surface-mounted parts.

*  *  *

Recall that our new 1-inch probe started out with this idea:

This is all well and fine, but it required electronics in front of the battery (the sensors connected to the front nose) as well as electronics behind the battery (the connections for USB and the on/off switch, and perhaps also the temperature probe). How to hook all that up was up in the air.

Building ad hoc soldered wires between components like jacks and switches is always hard. And wires fatigue where they are joined to things, and eventually break. So really, we were talking about having two designs, which we will discuss in sequence. The first is to have two circuit boards, one in front of the battery and one behind it, connected via something like an FPC cable. (Standard ribbon connectors are way too bulky.)

This is the state of the art of where that design ended up. Note the 3D printed supports for the forward and rear circuit boards. Note how the battery is suspended inside the tube, and there is room for an FPC inter-board cable to slip into a slot beside it. Note also the fact that the rear board projects out of the housing and carries at its tip a tiny temperature sensor chip (e.g. a TI TMP102) so that we an do away with all random wiring. The rear board also contains the on/off switch and the USB connection. The printed circuit board can be single-sided from the factory to save money; the pressure sensors are easy to solder onto the second side and can be done as a separate step.

We fabricated some parts of this design and put them together briefly, and the parts looked like this:

Mechanically, everything worked out fine. There were two problems, though.

The first was the inter-board connection. We spent a bunch of time looking at FPC cables and connectors, and thinking through how this might actually work out. It's a bit of a finicky business, but it is not insurmountable. The number of connections to the rear board would actually be nontrivial; we would need:

• Power: GND, USB VIN
• USB data: D+, D-
• Power switch: A, B
• Temperature sensor I2C: SDA, SCL

This is 8 signals, meaning we'd end up with a 10-conductor FPC cable. It would all fit, but it would be finicky and customized. We could not see an easy way that the front or rear board could be "re-used" in a different design; at least not without some crazy hackery. So anyway.

The next thought was to try to consolidate the boards, and instead of sneaking electric signals past the battery, to instead sneek pneumatic connections past it. This caused us to investigate a whole family of designs that looked somewhat like this:

In these, the battery is pushed off to one side of the tube to make room for the six plastic hoses needed to get the six independent pressure signals to the (now, unitary) PCB on the back. We prototyped this, and it looked something like this:

 

Using 1/8" diameter plastic tubes, the fit was very tight. Not impossible, mind you, but tight. As a solution, we could go to a smaller tube, e.g., this 3/32" diameter Tygon tubing.

We investigated using the 3D printed parts themselves as conduits for the pressures, by building long channels into them:

In the end, the conclusion is that this is all possible, but it requires a bunch of engineering and testing to get it to work right. It is definitely an optimization.

Now as to the electrical connections to the battery. Clearly we cannot fit a simple 18650 battery holder into the tube. We must solder to the battery, or devise some sort of spring-loaded contact of our own. Soldering wires directly to the battery is possible, but it invites fatigue at the solder joints. 18650 batteries come with solder tabs, but we'd have to figure out how to finagle these into our overall design with the appropriate clearances. We'd also need to make sure we are not relying on a single boutique design of 18650 battery with tabs that are just so, and which could kill our design if it were discontinued.

Based on all of this, we decided (and it's a difficult decision, believe me!) to set aside our 1 inch diameter probe ambitions for the time being. This does not mean never. But our first kits will be built around our 2 inch "caliber".

*  *  *

To that end, we've returned to thinking about how we'd make things work. This is a very early snapshot of our arrangement:

Now we have lots of room for a standard 18650 battery carrier on one side of the board, and plenty of room for getting tubes to the sensors on the other side. This looks much more like a design that anyone can put together easily, without being too error-prone, and which is more likely to succeed at its mission rather than try to achieve premature optimality.

In this design, the circuit board length is bounded by the length of the battery and its carrier, which means the circuit board is 3.5 inches long. We end up with something still much more compact than what our earlier prototypes.

Again note how we have extended a little proboscis from our main PCB to carry our temperature sensor. We may or may not continue this trend. The thing is, with more space on the PCB, and more room in the probe overall, we can afford to have more "generic" connection options for I2C or 1Wire temperature sensors. We may even be able to use a standard Sparkfun TMP102 Breakout as our temperature sensor daughterboard, building strain relief and housings for it as appropriate in the 3D printed parts. Simple and easy is better than complex and hard at the moment.

*  *  *

With the decision to go with a 2 inch "caliber" probe, we now have a stubbier probe. This means that our bulky snap-off mounting that we've been using is going to be very close to the probe nose, and might disturb the airflow. Without doing wind-tunnel testing, we know that less disturbance is better than more. So if we can get our mounting behind the probe, away from the nose, this is likely to make things better, or at worst be neutral.

Our basic requirement from our mounting is what firearms people call a "return to zero" mount -- when put back together, it should maintain its original direction. It can move forwards and backwards along that direction a little bit, but the direction is what's important. This led us to think of some sort of Picatinny rail along with a quick release Pic rail mount. There are even plans for a 3D printed Pic rail quick release out there! We thought about building a back cover for the probe that incorporates a Pic rail shape:

Ultimately, though, this all seemed like lots of work. The sweet spot would be for the Pic rail to be mounted on top of the probe tube, but we already decided we don't want that because it interferes with the airflow. So we decided to set aside the Pic rail options for a while, regardless of how nice it would have been to somehow unify the aviation and firearms universes for a brief moment.

Our current best guess is screws on the back, and a slotted back plate that carries a RAM mount ball:

A screw with a 3D printed thumb knob goes into the bottom hole to secure and tighten up the arrangement.

This basically precludes sticking things like a temperature sensor "proboscis" out the back of the probe. This is okay. Our current idea is that we will embed our temperature sensor stuff, whatever that is, into some 3D printed parts that form part of the probe nose. It should be easy to make the nose half an inch longer and make a "pocket" of some sort within it so that air can circulate around a temperature sensor, yet not interrupt the outside radius of the probe as a whole. With the new-found flexibility in space that the 2 inch "caliber" gives us, we believe we can make this happen.

*  *  *

In the process of redesigning the nose, we are again looking into "design for kit-ability". Our current direction is to move away from extremely complicated 3D printed holes in the nose, and towards holes that have fewer kinks and can therefore easily be cleared of debris by a hobbyist using a pin or wire or some other simple manner. This means that we may be going to a "stacked manifold" design as we reported in our blog post from 2 years ago, Probe nose progress. The advantage of these kinds of designs is that they can also easily be machined or injection molded -- they do not rely for their feasibility on the ability to 3D print "impossible to machine" shapes.

Stay tuned for more progress on our designs!