[Flightgear-devel] ACFT models: XPDR prop's over MP

[Michael]

Hi,

This follows the thread started on the forum [*], which confirmed that
there was a problem with almost every aircraft model regarding the MP prop
for selected XPDR mode.

[*] https://forum.flightgear.org/viewtopic.php?f=4&t=31492

<QUOTE>
prop 1503 never reflects any cockpit setting. It is mostly fixed to a value
1 or 2, and never changing. ACFT dev's mostly update plane-specific knob
properties but seem not to bother with what eventually ends up in MP
traffic. As I said, this problem has been around for years, and I have been
relying on other XPDR-related prop's to decide on how to deal with the
planes, mostly using what seemed like common (though undocumented---I
suspect mere copy-paste propagation) practice among dummy property values.
E.g. rules like "if 1501 is < -999, consider this mode A" or "if 1500 is <
0, consider XPDR off". Basically, discarding 1503 since it was consistently
UN-reliable.

The problem with this non-solution is that some planes are still not
covered (most 777s do not ever fill an altitude), and modes C and C+S are
technically undistinguishable. So I would love to clear that up if possible.
</QUOTE>

To help cleaning this up, I proposed the following spec for FGMS property
1503:

- int 0: off
- int 1: ground mode
- int 2: mode A (prop 1500 should contain a valid XPDR code)
- int 3: mode C (id. prop 1500 + prop 1501 should contain a valid std
pressure-alt)
- int 4: mode S (id. properties 1500 and 1501)

and created an ATC-pie Git branch "xpdr" implementing this clarified
behaviour. This way aircraft developers have a way to check their changes
in an actual MP set-up if they wish.

Does everybody agree on calling this an official requirement for the future?

Of course, some corrections will be needed on aircraft whose maintainers
will not respond. I have had some volunteering for this, and well-informed
people seemed to say it was not too bad. But we can also remove the prop
all together if it is easier. Up to the radar clients then to decide what
to do and show.

[James Turner]

• int 0: off
• int 1: ground mode
• int 2: mode A (prop 1500 should contain a valid XPDR code)
• int 3: mode C (id. prop 1500 + prop 1501 should contain a valid std pressure-alt)
• int 4: mode S (id. properties 1500 and 1501)
and created an ATC-pie Git branch "xpdr" implementing this clarified behaviour. This way aircraft developers have a way to check their changes in an actual MP set-up if they wish.
Does everybody agree on calling this an official requirement for the future?

One possible better thing would be to improve the C++ transponder instrument to align with the values above (or maybe they are the same). The C++ instrument already uses the correct properties for MP, but has some issues (I guess) which means aircraft-developers have avoided it. Unfortunately I don’t know what those issues might be, but the transponder C++ code is very simple, I overhauled it once many years ago but never submitted the changes, I can’t even recall why, now.

Kind regards,
James

[Michael]

Hello all,

The winding MP XPDR discussion has taken another turn, this time I think
for the better (more backward compatible and less updates needed on
FGaddon):
https://forum.flightgear.org/viewtopic.php?f=4&t=32320

But it broke the ground mode... What would the cleanest short-term solution
for it be, in your opinion? To summarise the state of the discussion, the
two candidates currently are:
1. use .../transponder/inputs/mode: new value 3 for GND squawk
2. repurpose .../transponder/ident into an integer "flags" prop, and
reserve a GND bit and an ident bit

Number 2 may require renaming the prop. I am not fully aware of how much
will be broken if we do that.

Post by Michael
Hi,
This follows the thread started on the forum [*], which confirmed that
there was a problem with almost every aircraft model regarding the MP prop
for selected XPDR mode.
[*] https://forum.flightgear.org/viewtopic.php?f=4&t=31492
<QUOTE>
prop 1503 never reflects any cockpit setting. It is mostly fixed to a
value 1 or 2, and never changing. ACFT dev's mostly update plane-specific
knob properties but seem not to bother with what eventually ends up in MP
traffic. As I said, this problem has been around for years, and I have been
relying on other XPDR-related prop's to decide on how to deal with the
planes, mostly using what seemed like common (though undocumented---I
suspect mere copy-paste propagation) practice among dummy property values.
E.g. rules like "if 1501 is < -999, consider this mode A" or "if 1500 is <
0, consider XPDR off". Basically, discarding 1503 since it was consistently
UN-reliable.
The problem with this non-solution is that some planes are still not
covered (most 777s do not ever fill an altitude), and modes C and C+S are
technically undistinguishable. So I would love to clear that up if possible.
</QUOTE>
To help cleaning this up, I proposed the following spec for FGMS property
- int 0: off
- int 1: ground mode
- int 2: mode A (prop 1500 should contain a valid XPDR code)
- int 3: mode C (id. prop 1500 + prop 1501 should contain a valid std
pressure-alt)
- int 4: mode S (id. properties 1500 and 1501)
and created an ATC-pie Git branch "xpdr" implementing this clarified
behaviour. This way aircraft developers have a way to check their changes
in an actual MP set-up if they wish.
Does everybody agree on calling this an official requirement for the future?
Of course, some corrections will be needed on aircraft whose maintainers
will not respond. I have had some volunteering for this, and well-informed
people seemed to say it was not too bad. But we can also remove the prop
all together if it is easier. Up to the radar clients then to decide what
to do and show.

[James Turner]

Post by Michael
1. use .../transponder/inputs/mode: new value 3 for GND squawk
2. repurpose .../transponder/ident into an integer "flags" prop, and reserve a GND bit and an ident bit
Number 2 may require renaming the prop. I am not fully aware of how much will be broken if we do that.

Without knowing the context, I’d strongly suggest option 1 - repurposing existing props this way, and renaming then, is usually a big compatibility problem. Adding a new value of an existing prop will confuse existing code, but hopefully the code will simply ignore it.

Kind regards,
James

[Michael]

Without knowing the context, I’d strongly suggest option 1 - repurposing

Post by James Turner
existing props this way, and renaming then, is usually a big compatibility
problem. Adding a new value of an existing prop will confuse existing code,
but hopefully the code will simply ignore it.

I think so too.
Also, since data compression is being introduced to MP packets, this could
imply re-typing (bool -> int), in which case we would be adding to the
problem.

[Richard Senior]

Without knowing the context, I’d strongly suggest option 1 - repurposing existing props this way, and renaming then, is usually a big compatibility problem. Adding a new value of an existing prop will confuse existing code, but hopefully the code will simply ignore it.

I think the context is important in this case.

The transponder instrument (transponder.cxx) currently transmits four properties over multiplayer:

1500 instrumentation/transponder/transmitted-id (aka squawk code)
1501 instrumentation/transponder/altitude
1502 instrumentation/transponder/ident
1503 instrumentation/transponder/inputs/mode

The first two merit no further explanation. The ident is a flag triggered manually on an in-cockpit transponder to provide a positive indication to an air traffic controller that they are looking at the correct target.

The mode is a read-only property that indicates the capability of the transponder. There has been some debate over this in the past, with some people believing it should indicate the position of the transponder OFF/GND/ON/ALT/TST knob (knob-mode). That doesn’t make sense reading the code: it could easily adjust the mode value based on knob-mode, but it doesn’t make any attempt to do so. The associated documentation shows mode as a configuration setting in -set.xml, which further reinforces my view that this was intended as a configuration property.

Transponders come in three main flavours: Mode-A, Mode-C and Mode-S. Mode-A is squawk-only, Mode-C is altitude+squawk and Mode-S has “other stuff" coded into its response. In real life, when a radar interrogates a Mode-C transponder switched to ALT, all it gets back is squawk code, altitude and position (the latter from the radar echo). When a radar station interrogates a Mode-S transponder it gets "other stuff” as well. The mode is transmitted over MP so that an ATC client can decide whether it is realistic to look for “other stuff” in the MP packet or whether it should restrict itself to squawk+altitude.

The “other stuff” should include a ground-bit but there is no place to transmit this in the MP packet. The ground bit is transmitted by a Mode-S transponder either as a result of manual switching (transponder set to GND) or automatic (either gear/gear/wow or airspeed). So it isn’t easily derived from other properties — the aircraft must decide and the transponder instrument can implement that decision.

To transmit the ground bit from transponder.cxx, I see three options:

1. Add a new boolean to the MP packet

1504 instrumentation/transponder/inputs/ground

This is the cleanest solution but I have been assuming that there is already pressure on the size of the packet and this wouldn’t be welcome. Maybe that assumption is wrong?

2. Bitwise encode the ground bit into the existing ident flag

To avoid confusion the ident should probably be renamed as “flags”. I don’t think anything other than an ATC client has a reason to look at the transponder ident flag so the impact should be small. The name of the property isn’t actually transmitted in the packet so renaming is just a documentation issue isn’t it? Maybe the change of type from boolean to int is more of a problem?

The backward compatibility issue is that anything looking at what it thinks is transponder ident will see it go true if the ident is set or the ground bit is set. Given that only ATC clients need to use either of these, I hope that this is an issue that is easily contained.

3. Treat mode=3 as Mode-S plus ground bit.

This looks to me like it could be a problem in the future because it misuses the mode. What happens if a new generation of transponders are standardised, let’s call it Mode-X? We can’t then use mode=3 for Mode-X, we have to use mode=4. Then we have to work out whether mode=3 goes back to mode=2 (Mode-S) or mode=4 (Mode-X) when the aircraft is airborne. So do we have a mode=5, which is Mode-X with the ground bit set or do we use mode=3 to mean either Mode-S or Mode-X with the ground bit set?

I’m happy to make the changes to transponder.cxx either way, but I think 1 is preferable to 2 and 2 is preferable to 3. We need an insight in terms of the feasibility of each option.

Regards,

Richard (sanhozay)

[James Turner]

I’m happy to make the changes to transponder.cxx either way, but I think 1 is preferable to 2 and 2 is preferable to 3. We need an insight in terms of the feasibility of each option.

Thanks for the clear description.

Based on that, I entirely agree option 1) is the best way to go. Packing fields into existing fields manually is an ugly solution, we should be letting the MP layer handle that.

Kind regards,
James

[Richard Harrison]

Post by Richard Senior
I think the context is important in this case.

...

Post by Richard Senior
1. Add a new boolean to the MP packet
1504 instrumentation/transponder/inputs/ground

This is the best option (although it seems the whole /inputs is a
smidgen misleading as it would seem to be an output)

Generally if there is a 1-1 mapping we can reuse another property[1].
but for this property on the transponder we cannot for all the reasons
stated in your message.

Post by Richard Senior
...but I have been assuming that there is already pressure on the size of the packet and this wouldn’t be welcome. Maybe that assumption is wrong?

With the compatible protocol this will cost 8 bytes; with 2017.2 it will
be four bytes encoded as a TT_SHORTINT.

We don't currently have a way of transmitting a single property (e.g. as
a bool or byte) in less than 4 bytes [2]

----------------------
[1] For example it could be a reasonable saving to only transmit
/gear/wow rather than for each leg.
[2] I did consider transmitting the property ID as 15 bits and using the
top bit for the boolean (i.e. mask 0xefff), or having a TT_BYTE but
didn't implement either of these as it meant more encoding schemes to
consider. I've been working on Emesary over MP as an easier, more
configurable solution and will be posting soon about this.

[Michael]

Post by Richard Senior
1504 instrumentation/transponder/inputs/ground

I think this entire discussion has repeatedly been taking place assuming
that this was better avoided, even at the cost of dirty tricks. If this
*is* an option after all, I do not see any future in which it would be
dismissed.

The only questions I see:
- do we want a single bool "ground" bit or an int "flags" bit vector for
whatever future use saving properties. Given the foreseeable progress on
packet compression a bool typing, a properly named bool like 1504 above
seems the best choice.
- why "inputs/ground" and not "ground"?

[Richard Harrison]

Post by Michael
- do we want a single bool "ground" bit or an int "flags" bit vector
for whatever future use saving properties. Given the foreseeable
progress on packet compression a bool typing, a properly named bool
like 1504 above seems the best choice.

Bear in mind that this will be harder work for the ATC clients - they
will need more changing to extract the bit.

However it could easily be done this way by taking one of the
generic/bool properties

e.g.

{ BOOLARRAY_BASE_3 + 30, "instrumentation/transponder/inputs/ground",
simgear::props::BOOL, TT_BOOLARRAY, V1_1_2_PROP_ID, NULL, NULL },

So we lose one generic boolean but save some space, providing that the
model is already using something in the third part of the boolean array
- if the model isn't using this particular array already it will cost 4
extra bytes (booleans are transmitted as 4 byte index, 4 byte value)

Or, we could add fourth boolean array at the to be used for all future
booleans.

[jsb]

I would avoid using generic bools - they are not generic any more if we
start this ;)
I just had a look to my development branch of the CRJ700 familiy. I have
roughly 180 bits to transfer in dual control for all cockpit switches
and lights. As they unlikely change all at the same time I use a TDM...
anyhow, I am happy about all generic bools I get ;)

Anyhow, I strongly prefer to setup an extra bit array for future use and
declare it as reserved (e.g. not to be defined individually by AC
developers).

just my 2ct
Regards
Henning

Post by Richard Harrison

Post by Michael
- do we want a single bool "ground" bit or an int "flags" bit vector
for whatever future use saving properties. Given the foreseeable
progress on packet compression a bool typing, a properly named bool
like 1504 above seems the best choice.

Bear in mind that this will be harder work for the ATC clients - they
will need more changing to extract the bit.
However it could easily be done this way by taking one of the
generic/bool properties
e.g.
{ BOOLARRAY_BASE_3 + 30, "instrumentation/transponder/inputs/ground",
simgear::props::BOOL, TT_BOOLARRAY, V1_1_2_PROP_ID, NULL, NULL },
So we lose one generic boolean but save some space, providing that the
model is already using something in the third part of the boolean
array - if the model isn't using this particular array already it will
cost 4 extra bytes (booleans are transmitted as 4 byte index, 4 byte
value)
Or, we could add fourth boolean array at the to be used for all future
booleans.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Michael]

My opinion about "flags": I only brought it up one last time because we had
been considering the option beforehand, but in the end I don't see a point
in reserving bit flags without knowing what for, and not int vectors or
other things. I do not think mode S has a huge array of flags more than it
has values for flight parameters of many other types.

Post by jsb
I would avoid using generic bools - they are not generic any more if we
start this ;)
I just had a look to my development branch of the CRJ700 familiy. I have
roughly 180 bits to transfer in dual control for all cockpit switches and
lights. As they unlikely change all at the same time I use a TDM... anyhow,
I am happy about all generic bools I get ;)
Anyhow, I strongly prefer to setup an extra bit array for future use and
declare it as reserved (e.g. not to be defined individually by AC
developers).
just my 2ct
Regards
Henning

Post by Michael
- do we want a single bool "ground" bit or an int "flags" bit vector for

Post by Michael
whatever future use saving properties. Given the foreseeable progress on
packet compression a bool typing, a properly named bool like 1504 above
seems the best choice.

Bear in mind that this will be harder work for the ATC clients - they
will need more changing to extract the bit.
However it could easily be done this way by taking one of the
generic/bool properties
e.g.
{ BOOLARRAY_BASE_3 + 30, "instrumentation/transponder/inputs/ground",
simgear::props::BOOL, TT_BOOLARRAY, V1_1_2_PROP_ID, NULL, NULL },
So we lose one generic boolean but save some space, providing that the
model is already using something in the third part of the boolean array -
if the model isn't using this particular array already it will cost 4 extra
bytes (booleans are transmitted as 4 byte index, 4 byte value)
Or, we could add fourth boolean array at the to be used for all future
booleans.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Richard Harrison]

Post by jsb
I would avoid using generic bools - they are not generic any more if we
start this ;)

We've got 91 of them; and given the other recent developments that I've
been working on (see below), I'm not as sure of how useful these will be
moving forwards.

However it's reasonably straightforwards to add BOOL_ARRAY_BASE_4 (30
elements) - and simply to define the properties as required. it's just a
bit of an editting job to set it up. However I'm going to need some
extra votes for this feature before adding it.

Post by jsb
I just had a look to my development branch of the CRJ700 familiy. I have
roughly 180 bits to transfer in dual control for all cockpit switches

At this point I'd recommend holding off doing anything further with
multiplayer and/or dual control - I've been working on Emesary
notifications bridged over MP and I've made some good progress using the
F-14 for development.

* improvements in the efficiency of the way notifications are packed for
transmission over MP; probably a 30% saving over the previous scheme[1].
* notifications are packed and unpacked in such a way that the minimum
size for a property is 1 byte in total, compared to 4 bytes for a short
int, or 8 bytes for a normal int/double property.
* because of the above, the total packet size for the F-14 is now 360
bytes instead of nearly 1100.
* The properties to be transmitted are configured within the model.
* It's easy to setup a transmission schedule such that packets are
interleaved, or having two transmission rates.
* Hopefully it will have a seamless slave to master bidirectional
interface for dual control; such that the slave model transmits
properties back as they are changed and the master model will be able to
process these as though they had been set locally.

------------------------------
[1] The new scheme isn't backwards compatible, but I don't think there
is anything using Emesary over MP so the new scheme will simply replace
the previous method.

[jsb]

What is Emesary?

The later points sound very interesting.
For the last point there is an issue I did not solve yet with bidi props
(e.g. all OHP switches), my first experiments did not result in all
switches and cockpit lights being consistent across master and slave...
If you just copy between MP/AI and local props you can create feedback
loops due to bad timing and network delay, e.g. props get out of sync
between master and slave and start oszilating - quite funny if you click
a switch only once and it turns on-off-on-off ... ;)
I thought about converting all slave inputs into (propID, value,
timestamp) and transmit this to the master for processing but the
copilot then suffers from the network delay, e.g. copi clicks on a
switch, but it will be animated only after the value is echoed by the
master.
Of course we could copy copi input directly to the /ai/multiplay props
used for animation of the dual controlled model to kill the delay but
still we need some timestamp to avoid race conditions

Please feel free to contact me for discussion and exchange of ideas

Henning

Post by Richard Harrison
At this point I'd recommend holding off doing anything further with
multiplayer and/or dual control - I've been working on Emesary
notifications bridged over MP and I've made some good progress using
the F-14 for development.
* improvements in the efficiency of the way notifications are packed
for transmission over MP; probably a 30% saving over the previous
scheme[1].
* notifications are packed and unpacked in such a way that the minimum
size for a property is 1 byte in total, compared to 4 bytes for a
short int, or 8 bytes for a normal int/double property.
* because of the above, the total packet size for the F-14 is now 360
bytes instead of nearly 1100.
* The properties to be transmitted are configured within the model.
* It's easy to setup a transmission schedule such that packets are
interleaved, or having two transmission rates.
* Hopefully it will have a seamless slave to master bidirectional
interface for dual control; such that the slave model transmits
properties back as they are changed and the master model will be able
to process these as though they had been set locally.
------------------------------
[1] The new scheme isn't backwards compatible, but I don't think there
is anything using Emesary over MP so the new scheme will simply
replace the previous method.

[Oliver Schröder]

Hi,

Post by Richard Harrison

Post by jsb
I would avoid using generic bools - they are not generic any more if we
start this ;)

[...]
[1] The new scheme isn't backwards compatible, but I don't think there
is anything using Emesary over MP so the new scheme will simply replace
the previous method.

I wonder why you don't just implement a new message type with a MsgId of
it's own?
It would be very easy to do so without the problem of incompatible
clients. Neither flightgear nor fgms do try to interpret unknown message
types, in fact they simply ignore them. Additionally: they don't hurt.

And talking about message types: In my opinion, properties should not be
send in a position message, but send in it's own packet. The same is
true for chat messages.

Just my 2¢,
Oliver

[Richard Harrison]

Post by Oliver Schröder

Post by Richard Harrison
[1] The new scheme isn't backwards compatible, but I don't think there

I wonder why you don't just implement a new message type with a MsgId of
it's own?

Just to be clear the incompatibility here is the encoding scheme that
the Emesary bridge uses to encode into a generic/string. I don't
consider it to be worth adding a backwards compatible version when I
don't believe anyone is using the current scheme.

There is the possibility of moving support for Emesary and the bridge
into the core code;

However at the moment I'm more focused on getting it to work. This maybe
something that gets into 2017.3 - however it might be later.

It's been suggested before that this should have core support; and I'm
not against that idea, but it's not something that I have immediate
plans to address. Equally allowing more control from Nasal to be able to
construct packets for delivery over MP would be quite neat, but not
something that I plan to do.

If anyone is using the current implementation of the Emesary MP bridge
then I need to know this now....

[James Turner]

Just to be clear the incompatibility here is the encoding scheme that the Emesary bridge uses to encode into a generic/string. I don't consider it to be worth adding a backwards compatible version when I don't believe anyone is using the current scheme.
There is the possibility of moving support for Emesary and the bridge into the core code;
However at the moment I'm more focused on getting it to work. This maybe something that gets into 2017.3 - however it might be later.
It's been suggested before that this should have core support; and I'm not against that idea, but it's not something that I have immediate plans to address. Equally allowing more control from Nasal to be able to construct packets for delivery over MP would be quite neat, but not something that I plan to do.
If anyone is using the current implementation of the Emesary MP bridge then I need to know this now....

I tend to agree with Oliver, since Emesary is conceptually a new kind of data over MP, give it a new Msg ID, and old clients will just ignore it.

If we ever allow reliable sending of certain message IDs (chat, for example), this would make it easy to add Emesary to that.

(Actually I think having FG connect over UDP *and* TCP, and send ‘reliable’ messages via TCP, but everything else via UDP, would be a fairly nice change, but I suspect Oliver has bigger changes planned)

(And I really agree, chat and property updates should be separate from position updates)

Kind regards,
James

[Richard Harrison]

Post by James Turner
I tend to agree with Oliver, since Emesary is conceptually a new kind
of data over MP, give it a new Msg ID, and old clients will just
ignore it.

Emesary is currently all coded in Nasal[1]; the bridge uses
sim/multiplay/generic/string[x] to communicate; and thus it is
completely compatible at the protocol level; so any backwards
compatibility is only necessary within the bridge encoding itself - not
the transmission method. So the it would only be models using the bridge
that would be affected, and I don't think anyone apart from me has
started to use Emesary yet.

Post by James Turner
(Actually I think having FG connect over UDP *and* TCP, and send
‘reliable’ messages via TCP, but everything else via UDP, would be a
fairly nice change, but I suspect Oliver has bigger changes planned)

Mixing TCP and UDP (in a realtime context) isn't as straightforward as
it sounds - last time I did some detailed investigation (about 15 years
ago, 10mbps LAN) TCP often makes things worse if the packets are
transmitted at anymore than every few seconds, and even then the TCP
packets and UDP packets can interfere with each other. TCP is fantastic
for delivering a stream from a to b where the data is the important
thing, rather than the time, or sequence of arrival. Basically the
multiplayer protocol should always be UDP. see
https://www.isoc.org/INET97/proceedings/F3/F3_1.HTM;
http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

Post by James Turner
(And I really agree, chat and property updates should be separate from position updates)

Property and position, i.e. aircraft state, probably belong in the same
packet. It's hard to be definitive about this, but lets say as a general
rule the properties that affect the position and external model
certainly need to be sent in the same packet, properties that are slow
moving (e.g. cabin pressure) could be transmitted in an second packet;
but obviously extra packet types are going to impact the overall throughput.

--------------
[1] If there was to be core support for Emesary maybe using new packet
would be a good idea, but would need careful testing and evaluation of
what actually happens in MP rather than what we think is a good idea -
sometimes network comms can have surprising results when actually
measured, compared to what we think should happen..

[Richard Senior]

Thanks James,

why "inputs/ground" and not “ground"

Just a typo. Yes, it would be /instrumentation/transponder/ground. Not that you see that over MP, you’d just look for property 1504.

I have the bare bones of this working using a squat switch only at this stage.

@Richard: would you recommend I make this a 1_1 or 1_1_2 property?

Regards,

Richard

[Richard Harrison]

Post by Richard Senior
I have the bare bones of this working using a squat switch only at this stage.
@Richard: would you recommend I make this a 1_1 or 1_1_2 property?

All new properties should be V1_1_2_PROP_ID - it helps to ensure that
the packet is compatible with older clients by transmitting V1
properties in a partition at the start of the buffer - otherwise a
single unknown property could cause anything that follows to be
discarded or mishandled (depending on the version of FG).

[Michael]

If we assume the V_1_1_2 change lifts some of the packet size restrictions,
and since we are defining (or have defined) a new prop already for ATC, I
would like to mention that of all the extra data mode S allows to squawk,
indicated air speed could be a useful addition, at least for the hardcore
ATC simmers who still do not exist. :-)
Would it be acceptable and easy to sneak that one in with the ground bit?

[Richard Senior]

Post by Michael
I do not think mode S has a huge array of flags more than it
has values for flight parameters of many other types.

I found a list (these are in addition to id, ground bit and altitude):

https://www.aea.net/AvionicsNews/ANArchives/April05ModeS.pdf

Magnetic Heading
Speed
Roll Angle
Track Angle Rate
Vertical Rate
True Track Angle
Ground Speed
Selected Flight Level/Altitude
FMS Selected Altitude
Baro Correction Value
Inertial Vertical Velocity

I don't see any justification in there for having a flags field. I have the ground bit working now, with options to use the GND knob position or a property for auto switching. The airspeed is simple enough to add if we think we can accomodate it in the packet.

Richard