Re: FLARM data format for contacts logged in IGC files

[[email protected]]

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[_2_]]

At 13:30 10 August 2015, 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).

[[email protected]]

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

[[email protected]]

On Monday, 10 August 2015 18:42:27 UTC+1, 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