FLARM data format for contacts logged in IGC files

[mark....@lenoxengineering.com]

After installing FLARM systems in two of our club aircraft this spring, I wanted to check on the performance of the systems. Unfortunately, both are trainers, and thus they tend to have lots of relatively short flights near the airport. Nearly all of the flights gave inconclusive results when analyzed with the online FLARM range analysis tool. So, I wrote some code to combine multiple IGC files together as if they were a single flight that simply passed by the airport multiple times and analyzed that. The results were very promising and gave a much nicer result but still not where I want to be. It takes a lot of statistics to tease out subtle things.

So, the online FLARM analysis tool limits me to 4MB IGC files. Apparently they have put in a hard limit for some strange reason. This is a bit problematic as it limits the total number of contacts for me at about 4000 and thus severely limits the statistical quality that can be expected in the result. I would like to be able to analyze far more than that so that I can really get a good look at how good my installation really is and compare that in a statistically meaningful way to installations in other aircraft.

Does anyone know exactly how FLARM encodes the data in their IGC files? I know they are encoded in the "LFLA" entries (a comment really), but it's in some very strange encoding after that that is not entirely obvious.


Mark Lenox

[Per Carlin]

I have never seen an IGC filer bigger than 1Mb, not eaven after 8h of flying with 2s recording interval. So the 4MB limit does not feel strange for me. Most likely is it to protect the site from harmful codes.

Sorry, but I do not know the Flarm coding for the LFLA lines in the IGC file.

Why do you not just limit the amount of data to max 4Mb, that has to be enough for your purpose.

[mark....@lenoxengineering.com]

With a typical IGC file at 4MB, that gives around 4000 contacts, which at first blush seems like it would be enough to get a good range. 360 degrees, more than 10 samples per degree. Unfortunately, the angular sampling isn't necessarily very uniform and the FLARM range analysis only gives you average range. There is no indication about the reliability of the range measurement in any given direction. I need to put some error bars on the measurement. I would like to be able to draw the same diagram, but with an inside ring that indicates average minus one standard deviation and an outside ring that shows average plus one standard deviation. The current display as portrayed by FLARM is very easy to misinterpret. In order to really get the standard deviation down To something reasonable in all directions it really takes a lot of samples. Probably several times that.

If I could interpret it myself, directly from the IGC files, or some combination of lots of IGC files I can get a more accurate view of what is actually happening.

[Tim Newport-Peace]

At 13:30 10 August 2015, mark....@lenoxengineering.com wrote:
>With a typical IGC file at 4MB, that gives around 4000 contacts, which at

>f=

>irst blush seems like it would be enough to get a good range. 360

>degrees=

>, more than 10 samples per degree. Unfortunately, the angular sampling

>is=

>n't necessarily very uniform and the FLARM range analysis only gives you

>av=

>erage range. There is no indication about the reliability of the range

>m=

>easurement in any given direction. I need to put some error bars on the

>m=

>easurement. I would like to be able to draw the same diagram, but with
an

>=

>inside ring that indicates average minus one standard deviation and an

>outs=

>ide ring that shows average plus one standard deviation. The current

>displ=

>ay as portrayed by FLARM is very easy to misinterpret. In order to

>reall=

>y get the standard deviation down To something reasonable in all

>directions=

> it really takes a lot of samples. Probably several times that.
>
>If I could interpret it myself, directly from the IGC files, or some

>combin=

>ation of lots of IGC files I can get a more accurate view of what is

>actual=
>ly happening.
>
If you are only interested in the LFLA records, then just cull out the
majority of the B-records. Try www.spsys.demon.co.uk/software/squashigc.exe
with a large interval (try 60seconds).

[mark....@lenoxengineering.com]

I am not exactly sure if exact position is important in the FLARM range calculation. I am modifying my code to throw away all B records except those that immediately precede a LFLA record. That will compress things and hopefully not interfere.


Mark

[rbp2...@gmail.com]

On Monday, 10 August 2015 18:42:27 UTC+1, mark....@lenoxengineering.com wrote:
> I am not exactly sure if exact position is important in the FLARM range calculation. I am modifying my code to throw away all B records except those that immediately precede a LFLA record. That will compress things and hopefully not interfere.
>
>
> Mark

Just thinking - I've got a RedBox FLARM hooked up to an Oudie running XCSoar. That gives me a FLARM radar display on the Oudie. Therefore XCSoar knows how to decode FLARM records sent over RS-232. Don't know if the format is the same but might give some pointers.
Bruce