Project Hobbes: Part 9 – Foundation

Last time I wrote about how I got valuable feedback during my visit at Aero Friedrichshafen. As I mentioned, I’m now forced to go back to the drawing board with my enclosure. But not before I gather some more feedback…

Ground tests

Unfortunately I was unable to test my hardware in flight, but I was able to spend an entire day with the device connected to one of my club’s DG-1000’s. These are all equipped with an LX8000 and they have the PDA port avaiable for me to connect to. My main objective was finding bugs and more importantly: checking EMC compatibility. I connected everything and found no sings of any EMC issues. During the five hours everything was connected, the radio didn’t turn on, other instruments didn’t behave in an unusual way. No extra noise was audible over the speakers. I consider EMC to be okay for the LXNAV version of my hardware. The other input board, which features a DC-DC Converter (12V to 5V) module, will need a separate test.

I found a few bugs here and there, which were (ironically) all located in parts of the code that I hadn’t covered with Test Driven Development. I can do a better job at separating code that steers hardware from code that’s purely logic. That way I can test more of my code and find these bugs earlier.

After some bugfixes, I could see data flow. The $LXWP0 NMEA sentences from the LX8000 were parsed and the Indicated Airspeed was extracted from it.

My “Tap Detection” algorithm is too sensitive and will be removed. For the final Idaflieg tests I need a physical button anyway, so no use in keeping it around.

Test Driven CAD

A new enclosure arrived during the past few weeks. This enclosure was fundamentally different from previous versions in that I designed it entirely in OpenSCAD. Like with all first tries, this first enclosure was unusable. However, it did reveal important lessons about my CAD process: there are way much details in a CAD model for me to keep track of.

So I started to wonder what “Test Driven Development” in CAD might look like. I want to have an automatic check that tells me if my design satisfies certain constraints. Perhaps the most important constraint is: do the contents of the box actually fit? Another one might be: can I plug in the RJ45 cable? You get the idea…

I solved this by modelling the contents of the enclosure, the PCBs, the standoffs, the nuts and bolts. I then created a scene that is defined as the intersection between the enclosure and the contents. If there is any conflict between the enclosure and it’s intended contents, this intersection will not be empty. When I render this intersection from 3 angles, all 3 images should be empty. To check if the images are actually empty, I wrote a small python script.

I can now make changes in CAD and get feedback on my changes in a matter of seconds. This makes me much more confident that my next iteration of the enclosure will work. It makes me also a lot more confident to refactor the enclosure.

PushButton

One thing that I’m really struggling with is the PushButton location. I would like to place this at the stick, as one of Idaflieg’s pilots suggested, but it is proving to be difficult. There’s off course also a risk in mounting things to the stick, especially since there’s also a measuring tape mounted to the flight stick during the Zacher flights.

I have planned a session with a friend to try to address this, but anyone who has ideas is more than welcome to suggest them!

With some foundational work done, I’m starting to feel ready for a major refactor of the housing and the pushbutton. I am filling in the forms to officially submit my project for this year’s Idaflieg Sommertreffen, and I’m looking forward to the feedback from Idaflieg’s pilots.