As experimental aviators we weld, mold, polish, machine, rivet, sew, forge, and fabricate wildly complex assemblies within specific design constraints, loading targets, and budgets. Unfortunately, it seems only a very small number of builders have the same level of interest for designing their own electronic cockpit accessories.
Why is this so?
To save myself the hate-email, let me start with the following:
Disclaimer #1: No, I do not suggest you attempt to build yourself an auxiliary airspeed indicator (easy), an altimeter (even easier), nor a custom panel widget that tells you to switch your fuel tank selector from LEFT to RIGHT (downright fun). Garmin and others make great products.
I am saying that it is very possible for you to build auxiliary avionics using your same thirst for knowledge and skill building techniques found in every other facet of EAB construction. Armed with some basic electrical knowledge, some basic programming skills, and a whole lot of testing, you could build yourself most anything you can dream up with off-the-shelf-components.
A brief Google search would show you a thriving population of hobbyists who are producing their own multi-layer PCBs for their own electronics projects:
Disclaimer #2: My first professional love is embedded software. Small constrained MCUs coupled to custom PCBs with hardware-level languages performing very specific tasks is, to me, the bee's knees. Once you get a taste of how things actually work, your very existence becomes a palette for for your own design.
This post is not to teach you programming languages nor electronics design. My only hope is for you to see an area most builders overlook as too difficult or too magical is actually quite accessible. Design-build is not magic.
Where do we start?
First, define exactly what problem you are solving. This definition is not how something should be built but rather what this something should do, or allow you to do. Define the capability, define the functionality, define the use case. Don't design anything yet. For need, it is as simple as this:
- The solution shall provide a visual cue on a repeatable pre-defined time period
- The solution shall be user resettable at any time
- The solution shall not require reading small text or images
- The solution shall be noticeable in all cockpit conditions
- The solution shall indicate when it is active or when it is inactive
- The solution shall not require a large electrical load or a USB cable
Yes, I just defined a $1 stopwatch zip-tied to the panel.
But, I do not want a stopwatch zip-tied to my panel. We are design-builders! We can do better than a stopwatch zip-tied to the panel!!
Now We Can Design
I prefer simple, elegant, streamlined solutions. You will find that the electronics and code are complicated enough without shoe-horning hundreds of features into the solution, so always keep it as simple as possible. After sketching fifteen or so really interesting little ideas, I landed on the following idea:
I want to blink a superbrite LED on my panel every <n> minutes to tell me to switch my fuel tanks from LEFT to RIGHT.
(That was anti-climatic, wasn't it?)
Yes, a blinky-blinky-LED satisfies all of my needs. It is simple, does not add to pilot load, and is small enough to integrate nicely into an annunciation area of the new panel I am designing for a Vans RV-6.
If you wanted to flash an LED on your panel every 30 minutes with a method to reset the countdown, how would you do it?
Some glass panels let you program reminders. Some EMS systems let you perform actions based on tach time. Some EFBs allow you to pop up alerts on a repeating basis. My avionics stack provides none of the above capability, so instead I have decided to build it.
I am quite fond of PIC microcontrollers and I adore the PIC16LF18313 even if it does not have the ability to run an external clock. The chip is super low cost (sub $2 USD), super low power, far faster than what is needed, and used in automotive applications around the world. The programming interface is solid, it supports my favorite language of C via a very well supported GCC-based toolchain, and I bet I could use the watchdog timer to do most of the heavy lifting to make it only sip DC power.
Unfortunately, this chip solution would require me to CNC-etch my own single-sided PCB to support a buck style voltage converter and pin latching interface to capture momentary button pushes (to reset the timer), although I suppose I could use a proto-board and hand wire the creation up much like a hardened breadboard...
Rather than build a custom PCB, how about we buy one instead?
Thanks to electronics enthusiasts around the world, ready-to-run system-on-a-chips with entire supporting eco-systems are cheaper and more available than ever. A Raspberry Pi has been running my web servers for almost a decade now. An ESP32 dev board has been running my home automation for nearly as long. For my limited requirements however I don't need more than what a PIC can easily do. I don't need an RTOS, I don't need networking, I don't need a OLED, and I don't even need a UART for RS-232. I really only need two GPIOs that runs at 1hz!
Although frowned on by the professional embedded crowd, the Arduino ecosystem is aligns perfectly with my simple use case. Arduino is a hardware + software + libraries + community that abstracts many different lower-power microcontrollers behind a single, simple programming model and IDE, making embedded development dramatically more accessible. Arduino uses mainstream GCC toolchains, the ABI and instruction generation is well-tested, and much to the dismay of the professionals everywhere the ecosystem is not a “toy”. Many production systems ship Arduino-based firmware compiled using the example same toolchain as available to enthusiasts.
Yes, there are downsides to Arduino and truth be told I use the ESP32 boards more often, but there is more good with Arduino than bad. For my simple use case, Arduino fits perfectly between the PIC microcontroller world and the ESP32 IoT world. We are just blinking an LED after all...
Which Board?
I am a big fan and supporter of Sparkfun Electronics. For many years I worked right next to their headquarters and all of their products hit the sweet spot of price and functionality. Since I am value-oriented, I love the older line of Arduino Pro Mini boards. It can handle raw VCC up to 12 volts natively, has plenty of analog and digital pins, has the ability to do I2C, and can run at 8 or 16MHz (16MHz requires the 5V version). The Sparkfun produced board is even opensource, so if you want to create your own PCB from their design you can download the Eagle files directly from their product website for free (scroll to the bottom).
It's all downhill sledding from here: Pick the GPIO to drive the LED, pick the pin to listen for an interrupt, then write a wee-bit of C++ with your own distinct flair to create the periodic lightshow of your choosing.
It all sounds far more daunting than it really is.
The schematic is very simple: Provide the Pro Mini with regulated 3.3v from the AP63203, hook up the momentary switch to a GPIO pin (I chose pin #2), then use second GPIO pin to drive the LED (I chose pin #6).
Schematics are all fun and games, but the real proof is in the puddin' or in my case the breadboard:
My more astute readers will notice the LED is actually turned on. Yes, my silly simple idea works, and it didn't even give up the magic smoke on the first power up.
Writing C++ can be a bit of a steep learning curve, but honestly it is quite a beautiful language once you grasp some of its core concepts.
That said, I completely ignored just about every useful part of the C++ language and just wrote a blob of C instead (mostly). My love for the C language is deep and wide even if I will never truly master it like my favorite friend Paul did. Some people are just special.
If you are one of the three people who have read this far into this project and would like the source code, email me. I will gladly provide you the source and will even tell how to modify it for your own specific needs.
Prototype
3D Printed Enclosure
I drew then printed an enclosure in carbon fiber infused nylon (PA6-CF) because, well, it is awesome. I have gushed over the properties of this finicky filament in previous posts so I won't cover old ground. The enclosure was designed to use electronics potting compound to retain and protect the circuit.
Initial Testing
The potted board has been running on my desk from a small 12V power supply continuously for over two weeks now at time of writing. As I feel the urge during the day I press the momentary button to quiet down the highly annoying flashing LED. Here and there I reset the power source, but mostly I ignore it and let it flash the LED to notify me it is time to quit my day job and scratch build a Pitts S1S.
(That last sentence may be factually correct, but financially impossible)
The next step will be plugging this mini contraption into my flying contraption (the Cub) which is an electrically noisy, dirty, ugly, untamed environment. This test will represent a harsh environment, but also a no-consequence environment. I say no-consequence because I have no need for 30 minute timers in the Cub, so if the unit fails or provides false indications no harm will come out of it.
If you could add one thing to your experimental avionics stack, what would it be?