Project Hobbes: Part 8 – Feedback

Last time I wrote about iteration 1 of the Output board, which more or less failed. I managed to burn the Red component of the new RGB LED and the new passive buzzer didn’t make any sound. I also introduced the BMI270 IMU, which could serve two functions: as accelerometer for planes equipped with an LX8000/LX9000 computer and a replacement for the pushbutton. I fixed this PCBA and visited Aero Friedrichshafen, where I got very interesting feedback from my friends at Idaflieg.

Fixing my mistakes

Both LED and Passive Buzzer now work.

First, I fixed my mistakes in the PCBA. With the help of a kind colleague, I learnt about the voltage drop across LEDs. The RGB LED now works fine and all components shine equally as bright. Indoors it is visible through the PLA housing, but it might not work in bright sunlight. We’ll see.

The buzzer now works too. I am working on some software errors, but the hardware works. In software, I’m using the timerfd mechanism combined with epoll to turn PWM on and off. Updating the timer does not appear to work, so I’ll probably write a small test program to see what I’m missing. While I use Test Driven Development for most of my code, I find it difficult to test code like this with side-effects.

The enclosure now also works, and I took that opportunity to bring my creation to Aero Friedrichshafen in order to show it and get feedback.


The enclosure with PCBAs as I brought it to Aero Friedrichshafen

So I took my new creation to the Aero. I met up with some friends from Idaflieg to proudly show the progress on my project and received some feedback.

The first and most important feedback was: during the flight the pilot should be assumed to be with both hands on the stick. This means I cannot ask them to use a PCB-mounted button or the IMU to mark when the airplane stalls. There should be a button on the stick. I can connect this with long wires and screw-terminals to the PCBA, but this creates new problems. Since I’m now connecting something to a primary flight control, I have to ensure that I do not ever prevent the pilot from using that control. The wires involved cannot restrict movement, and they may not move everywhere during inverted flight. I have to think of a way to connect the button to the stick in a way that does not obstruct the measuring tape that Idaflieg pilots also use during the same flight. This will take some thoughts.

The second piece of feedback was that the box may not be taped to the top of the instrument panel. This was my initial plan, but the pilots clearly stated that this obstructs the view of the pilot and is not safe for inverted flight. Instead, I have to prepare my enclosure for mounting in a standard 57mm hole in the instrument panel. With an adapter I can also mount it in 80mm holes if that works better. This means the enclosure should be larger and should contain either horizontally oriented holes or something that screws can tap into. The experiments with self-tapping are not enough here, I need to have a very secure connection to the instrument panel.

Next steps

Especially for the enclosure it’s back to the drawing board! I decided to abandon creating my enclosures with EasyEDA Pro and started experimenting with OpenSCAD. OpenSCAD is a code-based CAD tool. This requires much more time to create something than for example Fusion360, but it gives me the advantage of including checks with the assert function. This allows me to check that the housing can actually interface with the PCBA stack, something which I had to measure by hand before.

I will have to change the Output PCBA in order to include screw terminals for the – now remote – pushbutton. If the instrument is mounted in the instrument panel, the RGB LED and the buzzer possibly also need to change place. This might involve a large change in some PCBAs, especially if I decide to change the orientation of the PCBA stack.

Before I redesign everything, I want to test one other important aspect: EMC. Since I have something that technically works, I want to fly with the system in order to get more feedback.

With the season well underway, the rain becoming more and more rare, and mountains of inspiration from Aero Friedrichshafen, I’m eager to test my project further and learn more. Let’s get this thing in the air!

Project Hobbes: Part 7 – Failure

Last time I wrote about the next iteration of the Output PCBA. The PCBA features the first I2C IC, the Bosch BMI270. A passive Buzzer instead of an active one, which should allow me to produce different tones if users request that. And finally an RGB LED, which should give me the opportunity to convey errors to the user.

Long story short: this PCBA was kind of a failure. The RGB LED was fried on first try, and the buzzer didn’t produce any sound. I also made some minor mistakes with the BMI270.


This was the trigger for some reflection. When I started to design this PCBA, I caught myself thinking: “I am getting the hang of this. Let’s try to make bigger steps, and let’s make progress without asking for help. That’s too slow.”. I felt greedy, rushed.

These feelings are not new to me. Due to my inherent sense of urgency, this is a trap that I’ve stepped into quite a few times already when creating software. Where in more bureaucratic processes, I often have to wait on others, I find myself to be the bottleneck more often in Agile processes. This is not a bad thing, but something I have to learn to deal with. In making software, the thoughts involved are usually something like “This code is so simple that I don’t need to test it, let alone write tests in advance (as TDD prescribes).”. Which is inadvertently followed by the humble lesson that my code doesn’t work and that I’ve attempted to go too fast. I need to take a step back when I feel impatient and come back when I’m calm enough to follow the practices that I know work well.

The overall lesson, in both software and hardware, appears to be: slow down to speed up.


The RGB LED after some tests. The black burn mark is in the red component.

Back to what I screwed up and how I fixed it. The RGB LED had a datasheet…in Chinese. In my rush to complete something, I didn’t translate the datasheet and ended up mistaking the maximum reverse voltage (5 Volt) for the maximum forward voltage (around 2.4 Volt). The values for the maximum forward voltage differ per color, but the Red component has the lowest value. As a result that component burnt out immediately. Not knowing what happened, I tried to measure what was going on and had to conclude that everything worked as intended. Then I noticed the black marking on the LED itself. When I took unused PCBAs out of the box, I got what happened. I looked up the datasheet, translated it and got what happened.

Despite being able to fix this LED, I did conclude that the amount of light coming off the components was not enough for me. The intention is to illuminate the PLA housing from the inside, giving it a glow. This all has to happen in bright sunlight, so it needs to be bright. Power consumption is not my biggest worry here, since I will only turn on the LED in case of errors.

In an attempt to make all three LED components equally as bright (450mcd), I took some time to precisely calculate the needed resistor values for the PCBA. Not because the project requires it, but to show myself I understand this part of the design well.

Passive Buzzer

I expected the passive buzzer to work the first time, since I had already tested a passive buzzer on a breadboard. The setup was slightly different, as I didn’t use an NPN-transistor to toggle it, but I figured that my code worked and I had already used the same transistor for the active single-tone buzzer that I used in previous iterations.

Since my new buzzer was a passive version and thus does not include it’s own oscillator, I figured I wouldn’t need a flyback diode like I ended up needing for the active buzzer (remember the voltage spikes I wrote about earlier).

The buzzer only made small clicking sounds. Measuring what happened, told me that everything up to the NPN-transistor worked as expected, but the voltage levels around the buzzer made no sense and hardly correlated with the ON-OFF switching of the NPN-transistor. I was genuinely puzzled. My kind colleagues gave me some pointers on how they would connect he buzzer. In the end though, I ended up going back to the basics again: the datasheet. I found that I again had mistaken the maximum reverse voltage for the maximum forward voltage. I had picked a 30 Volt buzzer instead of a 5 Volt version.

So I replaced the 30 Volt buzzer with a 5 Volt version, and made sure that the datasheet also includes a application circuit. The circuit included a 1N4148 flyback diode I already used.

IMU – Bosch BMI270

I was genuinely excited about using the BMI270, since it is relatively expensive ($3 per PCBA) but has a good reputation among drone pilots. It is my first I2C device in this project, and thus a nice experiment to see if I understand the I2C bus on the Raspberry Pi enough to talk to it. According to online sources, no pull-up resistors are needed, so wiring was easy.

The BMI270 also has a downside: it is one of the few IMUs that needs to load firmware before actually working. Before loading this firmware, one can identify the device but not much more. The firmware is a whopping 8 KiloBytes large, which is kind of large compared to the 12 bytes that I normally read or write to I2C devices.

I was happy to see the device on the I2C bus immediately, and got to work with the “quick start” procedures in the datasheet. This worked more or less, except for the actual loading of the firmware. I got a very generic “Remote I/O error” from Linux, but a quick search online taught me that you have to send the firmware to the device in 32-byte chunks. That worked just fine, and after increasing some settle times beyond the datasheet values I was able to read accelerometer values.

One thing that I forgot with this device, is to attach the two interrupt lines that it features. These might save me some time and effort, since the device has a built-in step counter. The device might be able to interpret any “taps” as “steps” and thus give me an interrupt if a pilot taps on the device. Since I was already creating a new PCBA, I attached those two lines.


For the enclosure I ordered a third iteration. This was not intended to be production-ready, but instead to find the right diameter for the PCBA supports. In the first iteration, which was printed in SLA, I could have the m2.5 screw self-tap into the material. SLA appears to be somewhat elastic, which I suspect makes this possible.

The second iteration was printed in PLA, which appears to be less elastic. With the same diameter, self-tapping was not possible.

I went down a big rabbit-hole here to see what would be nice. My goal is to keep part-count as low as possible and make assemble simple too. Whenever I can use parts for multiple purposes at once, I would like to.

I decided not to use inserts that you have to melt into your 3d printed part, or tap threads into the 3d printed material. Instead I opted for mounting the PCBAs and securing the two halves of the enclosure with the same screws. This means the enclosure has counterbore holes on both sides, so I can use the m2.5 spacers I already have for both attaching the PCBAs and keeping the enclosure together.

This time I’m taking my time before ordering. I am getting closer to actual testing, so there is really no need to rush things. Slow down in the short term to speed up in the long term.

Towards an Audio Angle of Attack Indicator – Part 6: appearances

Last time I wrote about the things I did to close the feedback loop. I used an old PC with Condor Soaring to test the system, and I ordered an enclosure.

Results from Condor Soaring

My tests with Condor Soaring gave me a few interesting results:

  1. The system generally works as intended.
  2. One Indicated Airspeed update per second is worth testing, as long as I have 10 updates of the acceleration per second. This enables testing on LX8000/LX9000 devices, which my club has in their gliders.
  3. The system keeps on beeping after landing, and during take-off. This is very annoying, especially during the early phase of an aero-tow.
  4. The system lacks support for inverted stalls.
  5. My “let it crash” approach to software (inspired by Erlang) works and allows the system to recover gracefully from bugs. It does not restore the current maximum Angle of Attack, so I need to make that persistent.


In order to allow me to work with LX8000/LX9000 devices, I need to have an accelerometer on board. After some pondering, I decided to make it an accelerometer/gyroscope combination in order to re-use this PCBA to create an IMU in the future. Due to the massive amount of smartphones that get built each year, there are loads of devices on the market. I decided to go with the Bosch BMI-270. I have good experiences with devices from TDK Invensense, such as the MPU-9150 and the newer ICM-20948. The latter however, works on just 1.8 Volts and wants to communicate with 1.8 Volt signals. This requires level shifters to and from 3.3 Volts. This means extra components and extra chances for making mistakes. I’m still learning about PCBA design off course.

So I decided to go the the BMI-270. It is more resilient against fluctuations on supply voltage than other alternatives and it appears to be quite stable. For what I’m currently doing it is probably overkill, but combined with the uBlox ZED F9P GPS modules I have lying around it might make a good IMU.

Beeping after landing

This problem was easily solved. When the derived angle of attack exceeds 1.25 times the maximum, the system becomes quiet. Using Test Driven Development, I wrote tests for this case, implemented the code and everything worked. Condor confirmed that it worked fine.

Inverted stall

The code was expanded to keep track of both a positive maximum Angle of Attack and a negative angle of attack. Depending on the acceleration that we sense, we compare the derived Angle of Attack against either the positive of the negative maximum. Again, using TDD I wrote the tests for this, implemented the code and tested it using Condor. It works fine.


Whenever the system records the maximum Angle of Attack, be it positive or negative, it writes a file to disk with the values of both positive and negative maximum Angle of Attack. When the system starts it looks for that file and configures the values read from disk. Together with the restart mechanism I use, this makes bugs caused by transient phenomena a lot less annoying.


First (left) and second (right) iteration of the enclosure. Left is SLA, right PLA.

I ordered my first enclosure from JLC3DP. It was printed in SLA. I know this technique from a previous employer and I like how the results look. The surfaces a smooth. The first iteration cost me about $20 and took a week to arrive. I thought that this was a bit slow, so I turned to 3D Demand, a Dutch supplier or 3D printing. They were able to ship in 2-3 days for the same price (using PLA). This is not as smooth as SLA, but does the job for now. My first two enclosures both had errors in them, so having a quick feedback cycle is important for me. I want to get this right fast in order to start testing fast.


A friend suggested that the project really needs a name. We decided on Hobbes. I decided to adopt a logo for it too.

New Output PCBA

Since I have got something working, I’m looking towards simplification a little bit and towards the real-life tests in August. For this, I’ve ordered a new version of the Output PCBA with a few new aspects. Learning is the biggest goal here.

The first addition is the already mentioned BMI-270.

The second addition is an RGB LED. This can be seen in the center of the PCBA, just left of the Buzzer. This LED will hopefully mostly be off, but can use colors to indicate several error conditions.

The buzzer in the center has also been changed. Where I used an active buzzer, which generates it’s own 3kHz frequency when you apply voltage to it, I now switched to a passive buzzer. This requires the software to generate the 3kHz frequency. Using PWM I can also make the buzzer generate other tones. The Raspberry Pi has hardware support for PWM, which should make the tones accurate. Turning the buzzer on and off is now something I have to control in software. Some measurements on the timing the Raspberry Pi’s GPIO system indicated no more than 1 millisecond of delay and not more than 0.5 millisecond of jitter. I don’t think this will be noticeable in practice, so I decided to go with it. Should the need ever arise to generate different tones, then I’m prepared for it. I can even play entire melodies if needed.

The push-button was made taller. I really want to get rid of this button, since it requires a hole in the enclosure and it is hard to verify if it is still working. Due to the mechanical nature of the component, I can’t think of any ways to verify that it actually works. Instead I would like to see if I can use the accelerometer in the BMI-270 to detect “taps” on the enclosure as button presses. It is much easier to detect if the BMI-270 is still working and I need it anyway. It is also much smaller, and removing the button means less components that can silently fail. A challenge will be to accurately separate “taps” from turbulence or rolling on a rough surface. This is why I will keep the button until I am sure it’s obsolete.

I have made my first glider flights, and I’m looking forward to test this device in a real cockpit. This should tell me if the EMC that I’ve been warned about is a real issue, and if the power consumption of the device is low enough. I also look forward to seeing if the 80 dB speaker is loud enough during aerobatics. And I’m off course looking forward to the unexpected lessons I’ll learn from using the device in a real flight.

Towards an Audio Angle of Attack Indicator – Part 5: closing the feedback loop

Last time I wrote the challenges I faced with different types of equipment. Because different types of equipment provide me with different supply voltages, different UART signal levels and event different power supply polarities – I decided to introduce modules.

IGC Input Module

The first module PCBA I ordered was a new Input Module, one that deals with the standard IGC RJ45 pinout. It converts 12 Volts to 5 Volt for the Pi and translates the Pi’s 3.3V UART signal levels to the standard RS232 signal levels of approximately 10 Volts. This was exciting for me, since this was the first time I was doing something more significant than connecting stuff with traces and maybe a resistor here and there. The MAX232 Chip that I used needs a bunch of capacitors to perform its task. The 12 Volt to 5 Volt converter that I used also needs capacitors to work. I now have multiple voltages running over one PCBA: 12 Volt, 5 Volt and 3.3 Volt.

To my delight, everything worked as expected. In order to learn about unit testing for hardware, I wrote a bunch of tests. I can now verify the properties of the DC-DC Converter automatically, using just my Korad KA3005PS programmable power supply and my Hantek 6022BL USB scope. Here is a movie of the test running:

The first automatic test of the DC-DC Converter running

Later on I also verified that the MAX232 setup is working as expected. I have let some friends review my PCBA layout. I’m starting to get more and more confident about creating PCBAs. Even the quality issues I encountered last time, where JLCPCB had placed the wrong part on some of my PCBAs, is now gone. They did have a question about the holes in my PCB being defined two times, so I fixed that.

Now what?

After I verified that this board was working well, progress was slow. There are a lot of things that I can do, but not a lot of things that I have to do. I’m starting to get closer to my initial goal of having hardware that works. So what now?

Last time I mentioned EMC compatibility, fault handling and an enclosure. The enclosure felt useful, but was a bit scary because I have no experience in 3D modelling. EMC is a potentially expensive excercise, but might be important if my enclosure doesn’t block EM radiation. Fault handling feels almost like an academic exercise at this point, and I lack the experience to analyse faults properly.

So perhaps I should just keep doing what I did so far? Improve the PCBAs?

For the Output board, where the buzzer and push-button are currently located, I wondered about placing an RGB led for status indication. It might also be nice to have an accelerometer on the board, which allows me to connect my device with any LX8000/LX9000 device. My gliding club has their entire fleet outfitted with these. An accelerometer might even replace the push-button, if I can use tapping gestures on the device. This makes the device simpler and allows me to make a simpler enclosure. I have not yet gone through with this, because I wanted to test the gesture detection first and see if the 1Hz indicated airspeed that the LX8000/LX9000 devices give out is good enough to give a shot.

I wondered if upgrading the Input board for the LXNAV devices with a current shunt and INA226 current sensor might be a good step forward. This would be a first step towards fault detection and fault tolerance.

Closing the feedback loop

While the above things are nice, they do not bring my system closer to reality. After some thoughts, I decided that the system needs to face reality as quickly and as often as possible. Instead of refining the system over and over based on my idea of what is “better”, I have to face the unforeseen stuff that real-world usage brings.

So I decided to step away from PCBA redesign for a bit and focus on other things. I installed Windows 10 and Condor Soaring on an old iMac I had lying around. This allows me to test my system at home. Condor Soaring is capable of sending out the exact values my system needs at 10Hz. This allows me to fly with the system at any time I like.

Testing the system with a simulator brings many interesting lessons. I can no longer start the software myself. What happens when (part of) the software crashes? I’m finding lots of small issues and questions arise.

Another thing I did was design and order my first enclosure. EasyEDA Pro has a tool that lets you design an enclosure quite simply. I can then order that enclosure at JLC3DP. It should arrive in about a week from today.

Now that the gliding seasons got started and that I have actually booked my visit to this year’s Idaflieg Sommertreffen in August, I’m eager to start testing my hardware in real life. I can’t wait to use the system and learn more.

Towards an Audio Angle of Attack Indicator – Part 4: Modularity

Last time I wrote about some setbacks. The LXNAV devices that my club owns (LX8000 and LX9000 series), do not support the 10Hz data that I require. This has been the source of a major change in the project: the introduction of modularity.

But before I discuss this major step forward, I should describe iteration 3 of the PCBA.

Changes in iteration 3

There it is. I replaced the expensive female headers at the bottom with female headers at the top. This saves about $50 per order and allows me to stack as much PCBAs on top of each other as I like. But as the picture shows, it was not easy for JLCPCB to select the correct part. Three of the received PCBAs received the tall female headers visible on the right, while two received the correct female headers visible on the left. I off course filed a complaint, which was handled very nicely. The next batch of PCBAs is on it’s way to me as I’m writing this, and I’m curious how they turn out.

Another change is in the buzzer. As mentioned, the previous version had a 3.3V buzzer which was powered by the Raspberry Pi. Because the Pi can only supply a grand total of 51mA (at 3.3V) over all the GPIO pins combined, this solution wasn’t a very good way forward. Iteration 4 contains an NPN-transistor, which I toggle with the Pi’s GPIO pin. The transistor then allows about 200mA to flow directly from the +5V rails to the buzzer. Since the +5V rails is directly connected to the LXNAV device, I have about 1000mA available here. Much better than the 51mA of the GPIO pins!

This version also has the debug pins spaced more evenly over the board, because the lack of spacing was a hazard for shorting two pins in the previous version. The crocodile ground clamp on my scope is simply too large. I did not repeat the GND pin everywhere as well.

Buzzer changes for iteration 4

The spike and oscillation after turning the buzzer off. Yellow band is -5V to +5V

While testing iteration 3, I stumbled upon something that nobody really saw coming. When the transistor cuts the circuit between the Buzzer and GND, huge voltage spikes occur. They were clipped at 25V by my scope, and they appear to be periodic at about 2.2kHz and last about 15 milliseconds. This is suspiciously close to the 3kHz frequency of the buzzer. The electronic experts I consulted suspected it is the membrane of the buzzer which is still vibrating. A colleague was kind enough to solder a diode between the two pins of the buzzer, which should allow any excess current to flow to the +5V line. A quick check with the scope shows this is true: I see no spikes exceeding +7V now, which is great.

A diode soldered across the through-hole pins of the active Buzzer.
The same situation, but now with a diode placed across the buzzer.


An example of stacking multiple HATs on top of the Raspberry Pi Zero. The new female headers on top of each HAT allow for an infinite amount of HATs to be stacked.

The last thing to address is the issues I noticed when testing iteration 3 in the workshop of my gliding club: our LXNAV devices don’t send out the data I require to operate!

This has several solutions:

  1. I am now actively looking for private owners who have a glider with an LXNAV S80 or S100. My current hardware should work with those devices, and it provides me with the data.
  2. I am creating a separate version to support LX Navigation devices.
  3. I am considering adding my own accelerometer and seeing if the 1Hz Indicated Airspeed as provided by my club’s gliders is enough to test the system.

Point 2, supporting LX Navigation devices, makes life difficult. Whereas LXNAV provides me directly with 5V and TTL-level UART data, the LX Navigation devices provide me with 12V power and RS232-level UART data. To make matters worse, their pinout is exactly opposite from LXNAV!

After a lot of considering, I decided that this warrants splitting my single PCBA into two separate PCBAs: one for input (UART and Power) and one for output (Button and Buzzer). I can then create two different Input modules – one for LXNAV and one for LX Navigation – and iterate the Output PCBA independently.

The two modules are stacked on top of each other, using the stacking mechanism that I introduced in Iteration 3.

As I’m writing this, the first iteration of the LX Navigation Input Module is on it’s way to me. Since I now have to change the voltage from the 12V battery (providing anywhere between 9V and 18V) to the 5V that the Raspberry Pi requires, I have had to introduce a complete DC-DC Converter module. In order to change between RS232 voltage levels and TTL voltage levels, I have had to include a MAX232-like chip. It was a nice step up from the easier circuits that I had to make before. I’m eager to learn if I got it right. If everything works, this version should also be compatible with other devices that adhere to the IGC standard pinout, like LX Navigation does. That means it should also work with devices like the XCVario.

This is what version 1 of the LX Navigation Input Module should look like. RJ45 connector on the left, DC-DC Converter module in the center, MAX-232 on the right.

Future plans

As the hardware is getting more and more mature, there are some things that I still have not addressed…

I have not performed any ElectroMagnetic Compatibility (EMC) testing. This is something that I should really do before I the system in a glider. The device might otherwise interfere with other on-board electronics. Especially the radio is susceptible to interference in my experience.

I have not made any enclosure for the device yet. An aluminium enclosure might help prevent any EMC issues too. However, I am not yet skilled with 3D modelling. The PCBA design tool I’m using, EasyEDA, does include a 3D modeller for enclosures. Perhaps that is the easiest solution, as JLC also provides 3D printing and CNC services.

There is the aspect of fault detection and fault handling. I have not yet added the LEDs that I talked about last time.

Which brings me to perhaps the most important aspect: getting feedback. Despite all my talk about iteration, I still have to get my hardware airborne. I hope next month I will get the first user feedback.

Towards an Audio Angle of Attack Indicator – Part 3: First tests

Last week iteration 2 of my PCBA arrived in the mail, just a week after ordering. There is a lot of good news, and some disappointments…

First things first. This is what the bottom of the PCBAs look like. There is a 2×20 row of female headers on the bottom, ready to be placed onto the Raspberry Pi’s pin header! For an additional $100, I selected the more elaborate PCBA service with parts placement on both sides from JLCPCB. That means no more soldering for me, and ready-to-use PCBAs right in the mail. This is a bit expensive for my taste, but for the time being it enables me to iterate on my design faster. I will probably move to female SMD headers on the top, which should accomplish the same thing without the hefty pricetag.

The PCBs are now 4 layers thick, with Signals on the outside layers (for easy modification when I make errors) and a 5 Volt and Ground layer in the middle. These planes make save me a lot of individual tracks for 5 Volt and Ground, which makes routing a bit easier. The tracks that I did have to place, I placed such that they are always visible and easy to remove if I make a mistake.

After ordering this iteration, I had some doubts about the buzzer pulling so much current (30 mA) that the Pi couldn’t supply it properly. At first this seemed to be confirmed by my Hantek 6022BL Linux-supported USB-scope, which showed just 2.5 Volts on the pins. Further investigation seems to indicate that it’s actually the scope that’s at fault here. A normal multimeter shows the expected 3.3 Volts. The buzzer also uses less than the 51 mA that the Pi should be able to supply on all of its GPIO pins combined.

It still makes sense to look into powering the buzzer from the 5 Volt plane, using a transistor of some sort to toggle it. After talking to some wise men around me (you know who you are), I decided to re-design the circuit a bit and use an NPN-transistor to toggle the buzzer. I also considered a MOSFET, but that was overkill and introduced the need for voltage divider circuits. I want to keep things as simple as possible, and the NPN-transistor is as simple as I can make it right now.

For the next version I’m thinking about introducing an RGB-LED to communicate the software status to the user. I figure this might be useful when things don’t work as expected. Such a LED uses around 20mA per color, which makes using transistors good practice.

Raspberry Pi Zero booting with power from my PCB for the first time, powered by an LX8080.

Back to this iteration… After the board arrived I quickly checked if things work as expected. The debug pins are very helpful for this, although it would be better to place them further apart. I have no need for connectors, and the ground-clamp on my scope is so big I’m running the risk of creating shorts. Also, it makes no sense to duplicate Ground pins everywhere.

The board works and the Pi boots fine with it. The button now works as intended and the buzzer still works. So then it was time to take the board to my gliding club and test it with real hardware!

The RJ45 pinout seems completely correct! That is a big win for me, since I’m always struggling with pinouts. Matters were not any better this time, as even the numbering of the pins was non-standard in the LXNAV manual. I’m pleased I got it right the first time. The Raspberry Pi Zero boots without a problem using the 5 Volts from the LXNAV, and it can receive the NMEA data from the LXNAV. Progress!


A mild disappointment was finding out that only the S-series variometers from LXNAV support the particular feature I’m using. I assumed from the specification that I had read that any modern device from them would export the needed values (G and IAS at 10Hz). This turned out not to be true. From a first glance at the LX Navigation dataport specification, it should be possible to get the correct data from those kinds of devices. Hopefully the RJ45 pinouts match enough so I can connect to both.

All in all I am quite pleased at how far I have been able to get within a few weeks. I am especially thankful for all the help I have been getting and the encouraging messages I’ve received.

Towards an Audio Angle of Attack Indicator – Part 2: Hello World

Last time, I wrote about the first PCBA being on it’s way. As I’m writing this, the second PCBA is on it’s way towards me. And boy, does it have a lot of improvements…

My very first PCBA!

The first iteration was a “Hello World” of PCBA: it featured just a button and a buzzer. Long story short: the button didn’t work and the buzzer did…sort of.

As soon as the PCBAs arrived, I soldered one onto a 40-pin header and tested it on my least expensive Raspberry Pi: a Zero W. The Pi didn’t even turn on. That’s not good, but it still worked without my PCBA. Although my soldering isn’t that great, it wasn’t the cause for the problems I was seeing: all PCBAs had a short between the button’s terminals.


During design of the PCBA, I decided to tie unused pins from the button to ground. Not such a great move, since I created a short between the 3.3 Volt pin and ground this way. Luckily the Raspberry Pi Zero has some protections and just didn’t power on. No fried hardware yet.

It took me a while to figure this out, but once I did I could easily fix the problem by scratching through one of the lines towards the button. Now the button didn’t work at all, but at least I could test the buzzer.

Another problem with the button was the GPIO pin I had connected it to. Aparently GPIO pin 17 is sometimes used for other things, even though it’s not documented.


The buzzer worked! It made a sound and it was nearly loud enough. A good result for a first try.

What’s next?

First I created an Excel sheet to keep track of which pins I was using and what pins the other Pi HATs I own use. In the future I want to combine my PCBA with perhaps a 12-Volt powerboard and a 5-inch LCD screen.

I then fixed the short-circuit for the button, and started to look at the extra features for the next iteration.

After spending way to long on soldering this PCBA, I decided to see if I could have the manufacturer of the board solder header on it for me. I turned it he can. A few hours of fiddling with EasyEDA later and the 3D view showed a PCBA with female headers attached to the bottom.

The next version should also contain debug points, so I can attach my USB-scope to the board and see what’s happening.

Last, but certainly not least, the board should receive power and data. Lucky for me, this is rather easy. I’m connecting my board to an LXNAV 9070, which delivers 5 Volts of power at a maximum of 1 Ampere. This is precisely what I need and the Pi Zero W can operate well below the maximum of 1 Ampere. The LXNAV also provides a UART interface at 3.3 Volts, which is precisely the voltage that the Raspberry Pi Zero W wants. Since the Raspberry Pi Zero already contains protection against static electricity, there’s no need to build in extra protections at this point. It’s just a matter of routing the correct pins from the RJ45 connector to the correct pins of the Raspberry Pi 40-pin header.

Now that I’m feeding the Raspberry Pi via the RJ45 connector, I’m starting to thing about all the wiring. I remember a former colleague mentioning 4-layer PCBs and I start to investigate a little bit and talk to my electrical engineering colleagues. I decide to create a 4-layer PCBA for the next iteration, just to see if it makes life more easy for me. At JLCPCB, who I use to create my PCBAs, it makes no difference at all if I use 2 or 4 layers… so let’s try it!

Both the UART and the 5 Volt circuits get their own set of pins for attaching a scope, and I order the next version of the PCBA. Since I decided to place parts at both the top (button, buzzer, RJ45 connector) and the bottom (female headers to save me some soldering), I now have to move to a more expensive price category…which is about $100 extra compared to the previous iteration. That’s definitely something I’m going to look at for version 3.

After ordering, I’m again faced with the long wait for these PCBAs to be made. Although the week it takes JLCPCB to manufacture and send the PCBAs is quite quick by modern standards, I’m so used to feedback loops measured in seconds or maybe minutes that this feels like going back in time. Despite feedback being somewhat slower than I’m used to, I’m quite excited about this small project. I’m learning new things every time I’m working on this project, and people all around me are very willing to teach me. No amount of studying beats experience…

Towards an Audio Angle of Attack indicator – Part 1: Inspiration and simulation.

We all know that Angle of Attack (AOA) is the measure of our approach to stalling. However, in general aviation we don’t measure or display it. I’ve always thought that it’s a shame we don’t; in military aviation the use of AOA is ubiquitous, reducing pilot workload. Most military aircraft even show the AOA in their Heads-Up Display (HUD), both as a value and in a projected velocity vector. In my experience flying military simulators, this makes landing quite simple.

Since we fly large portions of our flight at a high AOA, I thought it would be valuable to have the pilot know their AOA. We don’t have fancy HUDs, so we would need to convey the AOA information in another way to the pilot. Both DG and the Akafliegs have used “Seitenfaden” – strings at the side of the canopy – with good results.

A flight in a SF-34 with the forward instrument panel covered. Source: YouTube./AKAFLIEG Köln

These side-strings work well, but they have to be looked at and interpreted by the pilot. Interpretation of visuals happens in a relatively recent part of the human brain, and requires more effort than processing sound or tactile information. I’ve experienced this when I navigated through a city using just a tactile car seat myself. So I started looking for ways to convey the AOA – a pretty vital piece of information – by sound or touch. Then I stumbled upon an existing audio AOA indication, which was present in the F4 Phantom jet.

A video game demonstrates how roughly the F4 Phantom’s AOA warning worked. Source: YouTube/CAFubar


After last year’s Idaflieg Sommertreffen, I decided that for 2024 I wanted to test a more intuitive version of an AOA system. Idaflieg’s Zacher experiments, where students take their first steps as test pilots, provide the ideal environment to test such an experimental system. The goal is to provide the pilots with a small electronic device that can easily be plugged into the existing instrumentation, does not require too much workload to operate and will always give an audio indication of your AOA.


It is probably easiest to approximate the AOA by the Lift force, as we can calculate it from the Indicated Airspeed (IAS) and the Load factor (G’s). After indicating what the system should consider as the maximum AOA, it can estimate the AOA in most situations.

Simulation with Condor Soaring

The first step was to write simply try something and simulate it. So I did: I wrote a Linux program which receives Condor Soaring’s UDP information 10 times per second and estimates the AOA. It them generates 100ms worth of sound to indicate the AOA to the pilot.

When I tested this with Condor Soaring, the result was very pleasing. It became pretty effortless to fly steep turns with a glider, right on the edge of stalling. During loops you also get valuable feedback for flying your figures well. During landing it allows you to direct your focus to the outside world and not scan your airspeed indicator for things like wind-shear.

Simulation of the AOA indication on an aerobatic flight from 2016, in a Pilatus B4AF.
Turn your sound on. The “clicks” indicate the AOA: the closer to MaxAOA, the faster the clicks.

Overall, flying in the simulator felt more relaxing. Funnily enough, this was also the major problem that instructors mentioned when I asked them if they would consider such a system for their students. With increased automation and assistance comes an increased risk of automation complacency.

Overall I’m pleased with the results of the simulation. The next step will be creating a small device that the pilots can actually bring during the next Idaflieg Sommertreffen. This requires me to learn something new: designing Printed Circuit Board Assemblies (PCBAs). As I’m writing this, the first iteration of a PCBA is on its way to me…