With the flying season of 2026 coming to an end, it’s time to look at the past year and to 2027.
Hobbes and the Discus bT
This year the Discus bT flew with Hobbes in it. Besides giving acoustic stall warnings, it has been used as a generic device for logging flights, testing new software and generally improving the software.
The fact that I chose a Raspberry Pi Zero 2W and not a micro-controller turned out to be a key decision here. As soon as the software detects I’ve landed, it tries periodically to upload the measured data over a secure VPN to my server at home. This works very well, and it makes working with the device very pleasant. Since the device has WiFi when I assemble it from the trailer, I can update the device over WiFi before every flying day.
This makes iteration pretty effortless. Every day, I update the device in the morning, fly in the afternoon (sometimes with audio disabled) and upload new data and logs for inspection in the evening. If I find out that things don’t work well, it takes less than 5 minutes to update the software in the glider.
During the season the Discus received its new radio: an Air Avionics AC-1. It works well and I look forward to the Air Avionics transponder. The panel of the Discus is getting more and more empty.
The Discus works very well as a platform for experimentation. I really enjoy how easy it is to work on the panel and how much room it has. A big improvement over my last glider, an Ls6b.
With a more forward center of gravity, the glider is more stable in pitch. Towing on the winch-hook is still something that needs more attention than usual, but thanks to a few years of flying aerobatics I have enough experience with aero-tow to make this happen.
One day I decided not to launch, when there was very turbulent 25km/h wind that was 30 degrees cross. I saw the ASG-29 before me struggle right at the point where I usually need most inputs and decided it would be better not to fly. This is the biggest downside to this Discus bT, but it also gives me room for an extra 18Ah battery. I guess it’s all about compromises…
Flight testing
After visiting the Idaflieg Sommertreffen this year, I was part of a joint NLR-DLR flight test as an independent contractor. Although the main goal of the test was to convince NLR that a research glider is cheap to operate but can still give you meaningful results, Hobbes was also installed in the Discus 2c DLR during the test.
We performed stalls with airbrakes open and closed in an effort to see how CLmax changes as a function of the airbrake extension. This test showed that what Hobbes does – assuming that stall happens at a fixed CLmax – is too simple. With airbrakes extended I noticed that the indication it gave was too little, so it would be too late in warning the pilot for an actual stall. The good news is that the Discus 2c becomes more stable as you increase airbrake extension. The risk of entering a spin appears to become less with airbrakes extended.
It was a great learning experience to be part of a real flight test, both as ground crew and as pilot.
GPS+RTK experiments
This year has seen a great advancement in AI. In some experiments where I just fed it raw data and let it figure out the rest, it did an unexpected well job. In about 10 minutes it went from raw ASCII data to nice plots without any extra input needed. I only told it what was in the file and what was measured, and it did the rest. It even solved some synchronization issues.
That got me thinking. I’ve owned an ArduSimple simpleRTK2B+heading kit for some years now, and I flew with it in the Ls6 for a few flights. What if I don’t have to make all the hardware nice or have to learn Kalman filters etc? What if I can just fly with the setup, measure the output (UBX-NAV-PVT and UBX-NAV-RELPOSNED) together with the measurements from the backup-IMU that Hobbes contains (a BMI270), and let the AI crunch the numbers?
First flight
Well, the result didn’t disappoint. First of all, it figured out on its own that since the glider has a turbo, there can be engine runs. So when it noticed a dramatic increase in noise on the accelerometers… it figured out it was probably the engine! And it was right. It also noticed that the pitot tube that it gets the data from is in the tail, so I’m not really flying 160km/h with the engine on. That’s just the prop-wash.
Next I went a bit further. I gave it this explanation of how the Borgelt Dynamis system works. No formulas, just the text. And it created the plot shown above. You can clearly see that with the Dynamis method the noise is much less than what the XCVario gets from the TE-probe in the prop-wash. That means that it might be useful to make a nice implementation of this algorithm at some point, so I can have a more reliable and steadier variometer indication during motor runs.
The AI (Claude Opus 5.5) was also able to suggest what I might do to get less noisy readings. It started to suggest that I make the timing of the IMU better and that I average readings and apply one of the built-in filters. On the next flight, things were indeed looking better.
Third flight
By the third flight, the setup had already improved quite a bit. So I decided to see if I might be able to measure the CL- curve around the stall of the Discus bT. I have the winglets and stall is very, very gentle with them, so I wondered what that would look like. Since I had purchased a relevant polar curve from Idaflieg, Claude knew what the sink rate should be at different speeds (compensated for the actual weight). The results look pretty plausible, but I might have to repeat this exercise a few times to cancel out air movement.
The landing of the third flight was a little bit harder than usual, and I thought I felt the tail wheel touch first. So I asked Claude to analyze the landing. The image above is what it came up with after a few minutes of number-crunching.
I am very much aware that pretty plots don’t make for verified findings. I do find this fun to play with and I find it helpful that it tells me where I’m leaving accuracy on the table.
Next year I want to place the IMU much closer to the center of gravity, and I want to place the aft GPS antenna more towards the rear. I will also connect the Pulse Per Second signal from the GPS receiver to the Raspberry Pi Zero 2W, so I have a common timebase for both the IMU and the GPS receiver.
Pathfinder
I’ve worked a bit more on the Pathfinder in the recent months, although not as much as I’d like. There is good news though: in 2 dimensions my new algorithm shows the first signs of working and it can easily handle flights of several tens of kilometers. This is already a big step compared to the efforts of previous years.
The next step is to verify that – although I never explicitly tell it to – the search algorithm does reproduce the well-known MacCready rule: “don’t circle in lift weaker than your current cruise setting”. And it should also be able to reproduce the strategies that John Cochrane derived in his paper called Just a little faster please.
Once this is true, I will add the third dimension and look for ways to test the algorithm against either weather predictions or data derived from past flights.
Next year
In order to take the next step in the cockpit of the Discus, aligning it more with the vision laid out in “The avionics revolution hasn’t happened yet”, I will bring the first LCD screen into the cockpit. I bought a sunlight-readable MakerPlane LCD a few years ago. That should fit easily in the existing 80mm hole in the panel. The fact that it has (multi-)touch input enables a whole variety of things that I can then use it for. That will probably trigger a whole lot of software that can be built around it.
The buzzer that’s used by Hobbes will be replaced by a speaker, so I can play all kinds of audio and also handle multiple channels playing audio if I want to.
The GPS+RTK set will be back in a more permanent installation, with proper synchronization to the BMI270 IMU to improve accuracy.
There will be more progress on the Pathfinder, hopefully proof that the approach works, followed by an expansion to three dimensions. If that works, the LCD screen will show route information and I will start testing it in real flights.
Software will be aimed towards implementing a Simplex Architecture: a safety-critical part that has clear boundaries (don’t play more than one warning, warnings have priority over generic information, define clear behavior when no fresh information is produced) and a non-critical part that can change much more freely and much more quickly.