Hi Paul,
OK, I was incorrect in what I said.
When I parse the PFLAA messages, I DO maintain the <AlarmLevel> field, so when the FLARM sentence is passed out, it contains the <AlarmLevel> as defined by Flarm
What I do not do, is to process the PFLAU message which is historical because this particular message I believe has no function in most Displays (EasyVFR, SkyDemon etc) it has no ID code associated with this alert.
PFLAU,<RX>,<TX>,<GPS>,<Power>,<AlarmLevel>,<RelativeBearing>,<AlarmType>, <RelativeVertical>,<RelativeDistance>
This could be passed transparently without parsing which would probably be fine for FLARM, not sure what it would do to some of the other NAV systems, I would need to check this.
According to the Flarm data spec, PFLAU is the main sentence to be used for connected applications.
Whether all such applications follow that I don't know, but given such a clear steer in the spec, it would seem to me dangerous to ignore it. I can think of some displays which may use this given their limited processing power. I think if it wasn't passed on, I wouldn't take the risk of putting PAW in the datastream like we're proposing.
The model we're talking about is Flarm -> PAW -> nav computer, displays and alarms. I'm trying to generalise it from my specific equipment case so that we've got a solution which will work for many glider setups.
So I think the minimum data on the output port is:
- GPS data (I think that's already there) - the Nav computer is going to need this. I don't know whether you just pass the relevant sentences on, or recreate them.
- PFLAU sentences - sounds like just pass them on
- PFLAA sentences - I guess that's a mixture then of Flarm traffic and other traffic (but given the Alarm bit in those sentences, if you dedup them from other position sources with the same ID, you should keep the Flarm ones).
- I think the Flarm uses PGRMZ as well for Barometric altitude, and some apps use that. That's quite an important one for glider pilots, though the loss of it doesn't make the thing unsafe (when used with, say, an Oudie - a type of flight computer - using this sentence improves the accuracy of the vario over the internal GPS alternative).
- There are one or two other sentences that might be passed to the nav computer (eg self test info) whose loss might be confusing though less obviously unsafe.
I think maybe the cleanest, simplest and safest thing to do is pass on all sentences that appear on a Flarm input to the Flarm output, adding extra traffic along the way, and prioritising the PFLAA sentences.
The input to the PAW from a Flarm is likely to be serial (may or may not be able to control the bit rate). The output can be serial (it is in my case), or might be through a wifi connection for a PDA (as you already have). Possibly both in some setups. So connecting both input and output on one physical USB port might be useful enhancement, but it might be possible that input and output baud rates will be different.
Did I miss anything?
