Aut
mastodon 4.7.3(He/ Him) Senior Software Engineer that flies planes as a hobby. Currently serving as the Social Media Coordinator of my EAA chapter and the President of my flying club. I'm building an RV-10 airplane (the kind you can sit in and fly) in my basement 🛩️. Full time Linux user. I dabble in embroidery, theater, circuits, and other random things.
Profile picture from Jazzybee's Stardew Valley Character Creator
I took my mother flying on Sunday to get brunch in Janesville, WI (KJVL). Since it was overcast there I also got to do an instrument approach which is fun. On our way back we flew over the Tornado damage in Menasha and it's not pretty.
#tornado #severewx #wiwx #wx #avgeek #aviation #flying #generalAviation
My internet just came back on! Almost 1 week exactly from when the Tornado took it out. I can be connected once again!
A pretty cool day but very light winds making for great flying. Mostly I wanted to test the Stratux and it works great.
I flew to Iron Mountain (KIMT) in Upper Michigan to take my mother to brunch today. Then we stopped by her cabin.
I found a video that a worker helping clear my town posted showing some of the conditions here from the EF-3 Tornado last week.
So while getting familiar with the oddities of GDScript i noticed that it really doesn't have much in way of handling errors as a language feature. So while most languages I'm familiar with use try-catch statements, there just isn't anything. I hate returning nulls or sentinel values from functions so... I took a page from Rust's design and implemented `Result`.
Now if I'm doing an operation where I would want to generate an error to notify the calling function you did something bad, I am in a more functional paradigm.
Attached is a unit test around some bit reading using the `Result` and a match function that will pass along either the value or error message as needed. Second picture is the match function, it is pretty simple. A great use case for Monads overall.
Trying to find information on error handling in GDScript lead to a lot of "Just don't write code with errors in it" advice... which is frankly unrealistic and unhinged. It is okay to admit a language has some missing features.
I needed an ownship icon for my application and I came up with this beauty (I am biased, I own this type).
After mucking about for a while I have managed to replay the GDL90 I captured off the Stratux (onto the network) and feed it into my Godot app map. In theory, this would work in in the cockpit off the Stratux.
This live traffic replay is pretty slick. I think I'll integrate it into the app at some point. I watched my departure and getting vectored around some other aircraft on the map. I want to color code the aircraft by height (similar to adsb-exchange) too I think. It gives me an easy scan of how high something is.
I got the "ownship" data working as expected and imported my icon. It isn't as readable as I would like so I'll have to modify it a bit but overall I'm happy I got to reuse a lot of my code.
I parsed out the traffic alert flag from my stratux and when it is received my map now displays the target as flashing yellow. The nice part about using Godot is I have access to shaders so I get a lot of freedom in visual presentation. I plan on tweaking this a lot more but this is a usable start AND it grabs attention.
I plan on having a banner as well to notify the pilot but one step at a time. This is from an actual flight I took when I was getting ready for takeoff I got a traffic alert.
I was playing back my Stratux capture and caught my own traffic report, which is cool. I should be able to get traffic showing on the map from this, which is cool. I'm still combing over the GDL90 specs and figuring out how to best structure it in my code.
I discovered some things today while doing GDL90 message parsing:
1) I didn't understand CRC16, and I had a subtle error causing some messages to fail. Fixed now
2) Part of the GDL90 document says to refer to RTCA/DO-282, Section 2.2 for how a payload is specified. This document is not free, because of course it isn't.
3) Stratux was written in go. Reverse engineering parts of the source is challenging for me as I don't know go.
4) Staring a bitshifts and hex will make you go slowly mad
I got all the CRC stuff working in the end. Not sure what I'm doing about the paywall (definitely not paying $800 for a specification that should be free). I'll probably reverse engineer it out of one of the other open source GDL90 parsers.
It has been a while since I got to sit down and be in "the zone" with code. It feels nice.
I got my Stratux today and assembled it. It didn't work at first so I flashed the SD card with the most recent version and it worked fine. Of course this meant I wanted to go flying right this moment but the weather looks like Tuesday is the earliest.
I plan on doing the same thing I did with the Sentry and recording the network data on my laptop so hopefully I can integrate it into my EFB application and have good test data.
