Using LXNav IGC data and cockpit video for post-flight analysis

[lonkelly]

I've been recording cockpit video of my flights with an LX9000, and I neither the LX9000 screen nor the V8 screen is very legible in the video. It turns out that the IGC file contains most of the information I'm interested in. So I vibe-coded a Python script to extract flight data from an IGC file, using the I- and J-Records to define the extra fields LXNav put into the B- and K-Records respectively and dump to CSV for further processing in a spreadsheet. It's on GitHub. Now I'm able to directly read HAWK instantaneous wind and simulate average wind. The data can be overlaid on the video, which is GPS timestamped by the GoPro camera I use. Interestingly, the timestamps in the video sync to the time info-box I can see on the LX9000, but the IGC data are offset 2 seconds. The instantaneous wind arrow and heading I overlay seem to sync to the arrow and glider symbol on the display, but there is something going on with the average wind, which I calculate as the vector average of the most recent 20 K-Records (the K-Records have the HAWK instantaneous wind direction and velocity). I expect the LX is updating the display more than once a second, but also I think the average wind arrow isn't averaging just the HAWK instant wind. If anyone finds bugs in the igc2csv.py script, let me know please.

If anyone understands how the average wind arrow works and how best to derive it from data in the IGC file, please let me know. I'm trying to understand what is happening with the average wind arrow and instant wind arrow compared to what I see out the canopy and the displacement of my circles when climbing. I hope this will help me locate and stay in areas of convergence, and to better understand the local wind and airmass patterns where I fly.

Before I had AHRS and HAWK I would accomplish the same sort of thing by running LXSim with the IGC file and screen-recording that to sync with the cockpit video. But LXSim doesn't display the HAWK winds or the Attitude Indicator.

[cdeerinck]

This is not going to be easy.

According to the Hawk set up parameters, the horizontal wind average and vertical wind average are both settable by you (under Vario Parameters), and default to 30 seconds horizontal, and 10 seconds vertical.  You need to check your specific settings.  In addition to that, you have his (Heinrich Meyr) Kalman filter algorithm which takes a noisy signal from the IMU and uses a filter variable (which he calls the "wind variance") and smoothes the values.  If you really want to dive into the math, you can get to it here: https://en.wikipedia.org/wiki/Kalman_filter  assuming that Heinrich didn't alter the base algorithm too much.  Fair warning, he refers to it as an "advanced Kalman filter"., implying that he took it beyond the basics.

If you have ever worked with IMU x/y/z data, you know how insanely noisy it can be, and is kind of amazing that it cleans up with averaging.

Next up, we have the LX logging algorithm, which might be storing the values at the beginning of each second, somewhere in the middle as they are recalculated, or at the end of each second, and then writing it to the log file.  That could account for at least 1 of the 2 second discrepancies you are seeing.  I don't think they were intending for the data to be analyzed down to that detail.  One of the biggest limitations I found, was the accuracy of the GPS signal vertically, which is much worse than horizontal resolution.  Since all of the GPS satellites are in effect on the same side, the vertical resolution just isn't fine enough.  Generally +/- 2 to 4 meters.  While they do record to a tenth of a meter in the IGC file, that doesn't mean it is accurate to that same degree.  For this same reason, the actual lift you are seeing during playback can be significantly different than what really happened.  This is why GPS vario's (like in Navigator or Oudies) are notoriously bad, and why any respectable vario has to have a pneumatic source.

If you try to calculate the altitude by accumulating the vario numbers, and compare them with the GPS altitude (or even the pressure altitude), you will find one of two things:

a) either they drift apart significantly over time (hence the nature of the inherent errors)

     or

b) they match, which means that LX is back calculating the vario numbers from changes in the pressure altitude

I personally think they are doing a), but I haven't checked.

If you want to see how noisy that data is, try plotting the lift vs. the speed, and comparing that to the polar curve, and you will see it jumping about so wildly, that you couldn't ever hope to derive a polar from the actual data.  Or, just plot the VAT and NET values over time (you can even doo this in SeeYou), and look how noisy the vertical data is:

That was from a recent flight, and there was nowhere near +/- 14 knots of lift/sink.

If what you are trying to get is the yellow convergence vector, it is just the difference between the instantaneous wind, and the average wind.  But the tails of those two vectors together, and you get the yellow vector.  In essence showing a short term gust, which in theory is pointing toward an area of higher lift.  I have not found that nearly as effective in tracking convergence, as just paying attention to the crosswind component of the average wind, but it has seemed to help in determining which way to go when approaching a thermal.

All that said, not sure if any of this helps at all, but there you have it.  There is way more art than science in the interpretation of the noisy data.

[lonkelly]

Hey, thanks for your interesting reply.

I’m told by Uros that the WDI and WVI fields in the K-Records are instantaneous HAWK wind, and the VAT and NET fields in the B-Records are the HAWK values, not the TE-based ones. My overlay of instant wind and track align very well with the video of the LX9000 screen, when I can zoom in to see it. Unfortunately I am thousands of miles away from my glider so it will be a couple months before I can check my settings. I align the timestamps in the IGC data with the video frame where the info-box changes seconds. In general I cannot read the V8 screen from the video.

My object here is to be able to display what the LX9000 was saying and compare that to what I could see out the canopy while I’m sitting at home. I’m not trying to understand why the display looks like it does. I just want to be able to take some time to try to figure out how to use whatever I’m seeing on the LX9000 and V8 more effectively than I am now. I only get to fly my glider 100 hrs per year or so, so I’m eager not to have to restrict my learning to actual air time. I see plenty of stick and rudder errors in my cockpit videos I know hurt performance, and that has been helping me get better. It makes sense to me to review what the LX was showing me and to think how I could make better use of it. One thing I’m particularly interested in what is going on when the average wind is far from the instant wind and how this might relate to convergence or thermals.

I wrote to Naviter some time ago to ask them to display any available field in the B- and K-Records and they didn’t seem interested. I asked how they calculated the wind and they said it was proprietary. 

As far as the yellow arrow, it seems like it’s drawn after scaling the instant and average direction vectors with wind velocity before calculating the difference. I don’t have that yellow arrow showing in my glider, so I’m going by illustrations. If that idea is correct when the average wind unit vector and instant wind unit vector are pointing opposite you would still see a yellow arrow pointing in the direction of the stronger velocity. I’m at a loss to see how this helps find the best lift along a convergence, or which way to turn entering a thermal. (G Dale just says to turn into the instant wind to start so that is what I've been doing when I have no better reason.)

There are other benefits to displaying available data over cockpit video. It helped me recognize my Winter ASI had a persistent error, which was confirmed by manometer. So that was good. It also flagged the fact that the AoA number uses the centerline of the glider for the reference line as opposed to the chord line of the wing. That fact is in the documentation, but I wouldn’t have noticed it if I hadn’t been trying to make sense of the IGC data.

So, I’m still optimistic, and will keep plugging away. I wish I didn’t have to reverse engineer simple things like average HAWK wind, but it’s unreasonable to expect LXNav to answer all my questions.

Thanks again,

L

[lonkelly]

Using a 30-second period for the HAWK wind average gives me pretty good results. Thanks!

On Saturday, August 30, 2025 at 9:13:36 PM UTC-8 cdeerinck wrote:

[lonkelly]

The igc2csv.py on GitHub extracts data from IGC files without prior knowledge about what is there in addition to the mandatory data in the B-Records and K-Records. The wind_average.py script in the same repository makes the assumption that the K-Records output of igc2csv.py contain LXNav-specific wind data and processes that to output a CSV file with the vector average of the HAWK wind (assuming HAWK is active) over a specified window of K-Record lines. The window for averaging defaults to 30 lines, which is generally 30 seconds. This seems to track what is shown by the wind arrows on the LX9000 quite well.