After months of learning to design PCBAs, going through numerous iterations, design changes, getting loads of interesting feedback and suggestions, software bugs and bugfixes… I was finally here: I arrived at Stendal.
Armed with a crate full of equipment, spare parts and some fresh clothes I was eager to get started. Let’s get my hardware in as many gliders as possible and start flying!
Neo Theo
The first glider to receive my system was FVA Aachen‘s DG-1001 “NeoTheo”. They had already generously agreed to have my system installed before the event. Great! With the help of one of their members, I installed my device on my second day in Stendal. Their beautiful glider is equipped with an LXNAV S100, which I initially designed my device for. The S100 is able to send both Indicated Airspeed and G-loading at 10Hz over a serial connection and it supplies 5Volts/1Amp for any device connected to it. More than enough for the Raspberry Pi Zero 2W that I use, which only needs 0.2Amps.
After installation everything seemed to work on the ground. So I updated the software to the latest version, verified that the device uploaded it’s logs after landing and I went for a CS-STAN technical checkout flight. Together with Kobo, Idaflieg’s current president, I towed to 1250 meters. Kobo had asked if my device would also support inverted flight, since his aerobatic students sometimes manage to stall the DG-1001 during inverted figures. The device does support inverted flight, so an inverted test was to be included too.
First we evaluated the device in normal flight, and below 850 meters altitude we rolled the DG inverted and stalled it. The device worked exactly as intended and signaled the pilot nicely before he would negatively stall the glider.
Kobo simulated a classical error: a student flying an un-coordinated base-to-final turn. These are especially dangerous, because there is very little room for spin-recovery.
The French connection
The day after my arrival, I suddenly saw a familiar face walk towards me: it was Matthieu Scherrer! I bought my last glider, my Ls6b, via him from his gliding club. Matthieu flies an Ls6 too, and performs research on gliders. Matthieu was eager to talk to DLR about the comparison flights, and he was attending the OSTIV Congress in Uvalde in the afternoons.
It turned out that Matthieu was also presenting a paper on estimating Angle of Attack (AoA) from accelerometer data. Off course this was very interesting to me, since I estimate AoA too. My method has a clear problem: I cannot deal with flapped gliders. Matthieu’s method should have a way to solve that issue. Matthieu and I talked a lot about his method, my device, and how the two could be combined. Long story short: I received an A4 paper with formulas to implement and will test those with Condor Soaring.
What about other gliders?
I had brought 5 pieces of my device to Stendal. Before visiting, I knew that my device could be mounted in “Neo Theo” and what hardware was present. About the other gliders, I had to make assumptions. I chose two assumptions, which were more or less false:
- Most gliders will have recent LXNAV equipment. An S80 variometer or an LX8000/LX9000 device with PDA port.
- The rest will have RJ45 IGC-compatible pinouts.
Both turned out to be wrong. I encountered gliders with older LX9000 devices, which did not feature a PDA port yet. I also encountered gliders with an XCVario, which looks RJ45 IGC-compatible but isn’t (it uses 3.3V UART instead of RS232). An LX7000 device that I encountered needed an RJ12 connector, which the local hardware-store didn’t have.
Even the simulator didn’t work, as the different WiFi clients were not allowed to exchange data. That meant my device couldn’t receive the simulator’s telemetry.
Taking a step back
This was all pretty frustrating. After the initial success of installing the first device, I now failed 4 times in a row. For reasons that were outside of my control in Stendal. With my departure closing, I was afraid that this was going to fail. Six months of work for nothing.
Then I remembered some of the wisdom that I had heard: it’s not reality that’s the problem, it’s how your relate to it. I decided to take a small step back, get out of my daily routine at the airport and have a good lunch in the city center of Stendal.
I then decided that I should put my money on NeoTheo and have as many people fly it as possible. I announced that I would donate to Idaflieg for every evaluated flight that took place on NeoTheo. That worked very well, and the next day four flights with NeoTheo took place, despite windy conditions.
Further evaluation
In total my system has now been evaluated 8 times. It has flown with experienced pilots, inexperienced pilots and even a test-pilot. My device has worked well: I see no bugs or crashes in the logs. The installation of the PushButton also worked well, as there were no accidental presses and it was never close to obstructing any flight controls.
Lessons learnt
Apart from the analysis of the evaluation, I think many lessons can be learnt from my experience. I’ll list a few here…
Optimize for change. This is also the first principle of eXtreme Manufacturing. The fact that I could see my logfiles after the landing of a glider and could build+test a new software-version within 5 minutes was hugely powerful. Several times have I made small improvements to the device, to make the experience a bit smoother. For example: I did not read 5 Volts from the LXNAV S100, but more like 4.6 Volts. That should not be enough for the Pi to run, but it still did. I could make the low-voltage warning go away with a simple change in software and continue testing.
The more generic an interface, the better. I falsely assumed that most of the gliders I would encounter would have either an LXNAV instrument with an RJ45 PDA port (5V + 3.3V TTL UART), or a RJ45 IGC-compatible port (12V + RS232). I was wrong in many ways. I encountered many gliders with either no external port or a (just slightly) incompatible port. This cost me many hours of trying to make things work, without any results. If I would have designed my system with simple screw-terminals instead of a fixed-pinout RJ45 connector, I would have been able to get more gliders to work.
Resilience is all about how you relate to the circumstances, and yourself. When I failed to do 4 installations in a row, I noticed my mood deteriorating pretty quickly. As soon as I stopped beating myself up and started to be kind to myself, the ideas started to flow and better outcomes followed quickly.
Speak up. A lot of days went by where not much happened. I was waiting for people to “discover” my project. It turned out they were busy with projects of their own. Only when I clearly stated that I wanted people to fly with my device, things started to happen. I had to speak up.
integration is crucial. Since I’m not the only instrument in the cockpit, it must co-exist with other instruments. It is vital that the pilot can distinguish between your instrument and all others, and that mental workload remains low. One pilot reported having issues managing their attention between my device and the variometer. Another thought it was difficult to determine if my device was beeping or if FLARM was warning about nearby traffic.
There is synergy between software and physics. Many of the people I spoke to were jealous of the level of software-engineering that has gone into my device. The fault-tolerance attempts that I made were clearly working. On the other hand, I was often very jealous of the amount of physics knowledge that these people have. I can hardly understand the physics behind AoA estimation, let alone improve upon it. The right software engineer and the right physicist can create something far greater and useful than each can on their own.
The value of feedback cannot be overstated. The amount of useful feedback I got from Idaflieg’s pilots was brilliant. No amount of development or thinking can replace this. If I would have had multiple days of testing, I’m sure I could have made tremendous improvements.
Results
I need some time to evaluate the results of the questionaire that the pilots filled in for me. This will feature in a separate post, and will be published at Idaflieg.
In general I think it can be said that the system as such proves valuable. There are some issues to work out, such as the integration with other instruments in the glider cockpit: FLARM, the variometer, the radio. All of these produce sounds too, and we need to be careful about where we direct the attention of the pilot. We also need to take care we do not overwhelm the pilot. In general my device was not loud enough when flying fast (especially in the backseat) and the LED was hard to see. Making it louder might make the integration with other devices more important.
The device appears to detect the approach-to-stall well in most cases. Dynamic stalls appear to be challenging, as the onset is too quick for my device to detect it in time.
Acknownledgements
I would like to thank these people for their invaluable assistance in my project:
- Idaflieg and DLR, for allowing me to execute this project.
- FVA Aachen, for trusting their glider with my home-built electronics.
- My colleagues, for helping me learn PCB design and fixing mis-manufactured PCBs.
- Roald, for helping me with 3D printing and mounting a PushButton on the stick.
- Kim, for mental support and helping me out with the evaluation form.
- The Idaflieg pilots, for their evaluation and suggestions.
There’s no greater thrill than seeing your ideas become reality. Thank you.
One Reply to “Project Hobbes: Evaluation in Stendal”