Artificial Horizon for LTM Telemetry

March 2021

GitHub
Artificial Horizon for LTM Telemetry

During the pandemic, one of my favorite pastimes was flying with my friend on XPlane 11. We were trying to learn what it’s really like to fly planes, and to make it more realistic I found a usb yoke and pedals. The connection the controls made from physical to software intrigued me, and I wanted to make my own cockpit instruments.

While I would have loved to use analog components to make the setup look great, I figured I should start off with something simple so I can understand the flow of data from the game to the Arduino (oh yeah, I’m using an Arduino for this).

I was glad I did that, because getting the data to the Arduino was turning out to be quite a bit of a challenge. My interest was more in an airplane instrument than it showing data from in game, so I switched gears. Instead, I wanted to make a better-looking instrument to show a dummy data stream. After rummaging through old parts drawers, I found a flight controller. A little bit of researched showed that I could interact with it through a UART port.

Next was what instrument to make. It was only going to be a quick project so I wanted to use parts I already had on hand. Now that I wasn’t connecting with the game, I was pretty much limited to receiving data only. Not much to transmit back to a dummy flight controller. I’d been working with 128x64 OLED displays quite a bit at the time, so I grabbed one and decided I could make a little artificial horizon with it.

Image of Garmin GI 275

I found a library to parse the data coming from the flight controller via an protocol called LTM – Lightweight TeleMetry protocol. From there it was trial and error using trigonometry to draw the lines.

The look I was going for was the Garmin small artificial horizon that appeared in my usual Cessna 172 in XPlane. I made the “wing” in the center first, then the primary horizon. After that was smaller lines every 10 degrees up and down, then a heading indicator at the top of the screen.

It was a pretty quick project, but it was fun to play around with and slowly build up the components on the screen. For a video demo, head to the YouTube link at the top of the page.

If I were to make the project again, I would actually connect with XPlane 11. Since it exports UDP data, I’d likely need to write a program to act as a middle man between the Arduino and the game. Python definitely comes to mind first to accomplish this. The other big improvement I would make is to take a different approach to drawing some of the lines on the screen. There was a lot of math happening every cycle, and it really started to slow down. One solution could even be doing some of the initial trig in the interpreting software to lighten the load on the Arduino