Board index FlightGear Development Aircraft

Transponder properties

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: Transponder properties

Postby sanhozay » Wed Jun 07, 2017 12:54 pm

Thanks again to CaptB for helping me test.

Using the new multiplayer debug facility in 2017.2.x, my conclusion is that Flightgear's transponder and multiplayer transmission of transponder properties works as designed. Whether that meets the requirements of ATC clients is another question.

For these examples, I set the transponder mode to 1, which corresponds to Mode A+C, i.e. it will report squawk and altitude when interrogated, subject to the position of the transponder knob. As discussed above, I don't believe the aircraft needs to change this. It's a one-time setting that should go in -set.xml.

When looking at the hex dumps below, the rectangle highlighted in red shows these multiplayer properties:

Code: Select all
1500   instrumentation/transponder/transmitted-id   INT   SHORTINT   V1_1_PROP_ID   
1501   instrumentation/transponder/altitude   INT   same   V1_1_PROP_ID   
1502   instrumentation/transponder/ident   BOOL   SHORTINT   V1_1_PROP_ID   
1503   instrumentation/transponder/inputs/mode   INT   SHORTINT   V1_1_PROP_ID

Each property is prefixed with its ID, so 1500 appears as 00 00 05 dc, 1501 is 00 00 05 dd and so on.

Some hex translations will be helpful to understand the dump:

Code: Select all
-9999 = ff ff d8 f1
1025  = 00 00 04 01
700   = 00 00 02 bc

knob-mode = OFF
Image

knob-mode = SBY
Image

knob-mode = ON
Image

knob-mode = ALT
Image

The transponder mode is quite clear in my mind now as a one-time configuration of the capability of the transponder. The position of the knob (knob-mode) changes the behaviour of the transponder in terms of what it transmits, but it should not change the mode property.

Note that a Mode-S transponder requires an alitimeter that generates the required altitude property "instrumentation/altimeter/mode-s-alt-ft". In my Beagle Pup, I don't have that property so I got a warning message in the console when I tried to use my transponder as a Mode-S device (setting mode=2). I also checked the ident button and it worked OK but I didn't make screenshots.

When I was testing with CaptB, we observed that ATC-Pie didn't display the values that were shown in my property tree and it continued to display altitude when my transponder was powered off at the circuit breaker. That's something for the ATC-Pie developers to look at I think. My understanding is that an ATC client should only look at the transmitted squawk code and altitude for a pure transponder implementation. If they are invalid (-9999), the transponder is not transponding that value and an ATC client would show "n/a" or similar. I haven't looked at the source code of ATC-Pie but my best guess would be that it is trying to interpret the mode property in a way that was not intended when the transponder instrument was written. Perhaps even a bit shift somewhere as the modes appeared to be two off? So Mode-A was 2 instead of 0, Mode-C was 3 instead of 1 and Mode-S was 4 instead of 2.

Something else I noted was that the radio dialog is not a live update, so the transponder information doesn't update when changing values in the cockpit or property tree. I don't think this is a big issue, just something to be aware of if trying to use the radio dialog for debugging.

I haven't tested OpenRadar with the above and my copy doesn't seem to be working at the moment.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: Transponder properties

Postby CaptB » Wed Jun 07, 2017 2:47 pm

I have tested with OpenRadar, where the modes seem to work better, but still not perfect. I tested the FGAddon C172 where Transponder mode position "ON" is no different from "ALT" it should instead not report altitude, just squawk number, so basically mode A when set to "ON" and mode C when set to "ALT"
Ongoing projects(3D modelling): A320, MD-11, A350, B767
FG767: https://fg767.wordpress.com/
CaptB
 
Posts: 684
Joined: Thu May 23, 2013 7:36 pm
Callsign: EKCH_AP
IRC name: CaptB
Version: next
OS: Xubuntu

Re: Transponder properties

Postby mickybadia » Wed Jun 07, 2017 4:40 pm

Mmh, this looks like we are about to repeat this thread. Let's see if this one leads us further down the same line.

sanhozay wrote in Wed Jun 07, 2017 12:54 pm:The transponder mode is quite clear in my mind now as a one-time configuration of the capability of the transponder. The position of the knob (knob-mode) changes the behaviour of the transponder in terms of what it transmits, but it should not change the mode property.

I do not know whether this is the intended/original behaviour. Stuart and others seem to say no, you and others seem to say yes. In any case I do think it is better to have it evolve as suggested in the linked thread above.

The behaviour you encourage for ATC clients is the one ATC-pie implements when its "guess XPDR modes" option is turned on, except for mode S which becomes undiscoverable because the "mode" prop is not trusted with this option. If I took it as reliable in the terms you say (i.e. when "alt" and "id" are present: if "mode"=1 then assume mode C, if "mode"=2 then assume mode S), we would still have the following problems:
- ACFT cannot turn off mode S if they are capable of it (not too serious)
- no ground-vs-off distinction on MP (a real shame)

Obviously, knowing what the XPDR is "capable of" is not very informative for ATC clients, and we would rather be given what it is actually doing.

sanhozay wrote in Wed Jun 07, 2017 12:54 pm:When I was testing with CaptB, we observed that ATC-Pie didn't display the values that were shown in my property tree and it continued to display altitude when my transponder was powered off at the circuit breaker.

With all cheats turned off, ATC-pie snapshots the values in the last received packet at every radar sweep, and retains them until the next sweep. If the value does not change after a sweep, it is because it was still in the packets received from the aircraft.

sanhozay wrote in Wed Jun 07, 2017 12:54 pm:I haven't looked at the source code of ATC-Pie but my best guess would be that it is trying to interpret the mode property in a way that was not intended when the transponder instrument was written. Perhaps even a bit shift somewhere as the modes appeared to be two off? So Mode-A was 2 instead of 0, Mode-C was 3 instead of 1 and Mode-S was 4 instead of 2.

See the evolution proposed, you guess right (except for the bit shift). It is the intended behaviour of ATC-pie when its "guess XPDR modes" option is turned off, i.e. assume a "mode" prop meaning "current mode setting", not "instrument capability".

CaptB wrote in Wed Jun 07, 2017 2:47 pm:I have tested with OpenRadar, where the modes seem to work better, but still not perfect.

Do you mean to say OpenRadar has a different behaviour to the one in ATC-pie when "guess XPDR modes" is on? If so, there is something I missed. In my mind they were identical.
mickybadia
 
Posts: 475
Joined: Tue Sep 24, 2013 10:12 am

Re: Transponder properties

Postby wlbragg » Wed Jun 07, 2017 4:46 pm

I tested the FGAddon C172 where Transponder mode position "ON" is no different from "ALT" it should instead not report altitude, just squawk number, so basically mode A when set to "ON" and mode C when set to "ALT"

I started a possible issue on the c172p developers site based on the information here. After rereading the thread a second time, I need clarification as to whether or not this is a possible c172p issue or the remote application's problem?
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Transponder properties

Postby sanhozay » Wed Jun 07, 2017 5:56 pm

mickybadia wrote in Wed Jun 07, 2017 4:40 pm:Stuart and others seem to say no, you and others seem to say yes.

My reading of the code and of Clément's post brought me to that conclusion. Really all the mode does is disable altitude reporting (A) or change the property used for altitude (C or S).

Code: Select all
        Mode effectiveMode = (_knob == KNOB_ALT) ? _mode : MODE_A;
        SGPropertyNode* altitudeSource = NULL;
       
        switch (effectiveMode) {
        case MODE_C:
            altitudeSource = _pressureAltitude_node->getChild("mode-c-alt-ft");
            break;
        case MODE_S:
            altitudeSource = _pressureAltitude_node->getChild("mode-s-alt-ft");
            break;
        default:
            break;
        }

If the mode were an output property, the transponder instrument (C++ code) could easily set it based on the knob position. It doesn't make any attempt to do so and I find it more plausible that it was designed as a semi-fixed input property that describes the capability of the transponder rather than a property that each aircraft has to maintain.

Unfortunately the original developer has left the project so we have to piece this together.

mickybadia wrote in Wed Jun 07, 2017 4:40 pm:we would still have the following problems:
- ACFT cannot turn off mode S if they are capable of it (not too serious)
- no ground-vs-off distinction on MP (a real shame)

The capability is a feature of the transponder model. If you look at the Bendix King manual for example, it says this:

ON - The KT 70 is able to reply to all valid Mode A, C and S interrogations (Mode A and C on the KT 71).

So if an aircraft want to simulate a KT71, it sets mode to 1 (A + C capable) in its -set.xml file. If it want to simulate the KT70, it sets the mode to 2. In the latter case, it must have an altimeter instrument that creates the mode-s-alt-ft property, or do it through a property rule.

If an aircraft did want to switch off its mode S capability, it could easily have a switch that sets mode between 2 and 1.

I didn't explore GND but I'd agree that would be important. The transponder instrument does provide a GND position for knob-mode but I'm not yet clear on how that is transmitted in real life. The Bendix King manuals say:

GND (GROUND) - In the KT 71, all interrogations are inhibited. In the KT 70, ATCRBS (Air Traffic Control Radar Beacon System) Mode A&C interrogations are inhibited, but the KT 70 will reply to all valid Mode S interrogations, provided a Mode S status bit is set to indicate the aircraft is on the ground. In both units, the ID code is shown on the right side of the display, with altitude reported on the left side. The letters “GND” are also displayed in this mode.

Do you have any information about what real life ATC see from a transponder in GND mode?

mickybadia wrote in Wed Jun 07, 2017 4:40 pm:Obviously, knowing what the XPDR is "capable of" is not very informative for ATC clients, and we would rather be given what it is actually doing.

I agree, but if you want a reasonably accurate simulation outside any "cheat" type modes, you have to justify additional properties that are sent back. The mode and knob-mode are not sent in real life (not for mode A nor C anyway). The only things that are sent are squawk and altitude, the position coming from the radar echo.

Wikipedia says of mode S:

Upon interrogation, Mode S transponders transmit information about the aircraft to the SSR system, to TCAS receivers on board aircraft and to the ADS-B SSR system. This information includes the call sign of the aircraft and/or the transponder's permanent ICAO 24-bit address in the form of a hex code.

Unfortunately that doesn't say what else is in there, which could be the key to GND mode.

None of this is a criticism of ATC-Pie, by the way, I'm just trying to work out what's going on.

@wilbragg: I'll do the same tests I did this morning on the C172P.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: Transponder properties

Postby CaptB » Wed Jun 07, 2017 6:06 pm

I have retested with both radar clients using the UFO:

ATC Pie will work correctly except for GND mode, *only* if the option to guess transponder modes is active and will display correct data for ON and ALT settings respectively
OR will incorrectly show squawk+altitude for transponder setting ON and correctly squawk+altitude in pure simulation mode.

@wlbragg: this seems unrelated to the C172, same behaviour with UFO
Ongoing projects(3D modelling): A320, MD-11, A350, B767
FG767: https://fg767.wordpress.com/
CaptB
 
Posts: 684
Joined: Thu May 23, 2013 7:36 pm
Callsign: EKCH_AP
IRC name: CaptB
Version: next
OS: Xubuntu

Re: Transponder properties

Postby wlbragg » Wed Jun 07, 2017 6:07 pm

@wlbragg: this seems unrelated to the C172, same behaviour with UFO

Thank you!
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Transponder properties

Postby sanhozay » Wed Jun 07, 2017 7:55 pm

I tested the c172p and got the same results as the screenshots above. To confirm: when the knob-mode is set to ON, the transponder only transmits squawk code over MP and altitude is transmitted as -9999. When the knob-mode is SBY, both squawk and altitude are -9999, and when the knob-mode is ALT, it transmits both squawk and altitude. This is looking at the packets sent over MP, not through any other program.

The mode is set to 1 (A + C) and the altimeter does not have mode-s-alt-ft, so mode S would not work.

EDIT: Same with the 777-200.

MORE EDIT: In all the aircraft I've tried, the altimeter does not have mode-s-alt-ft, which means mode-S can't be used. Getting this property means setting "encode-mode-s" in the altimeter entry in instrumentation.xml. Searching fgaddon suggests the only aircraft that do this are the Extra500, MD-11, 757-200, 747-8i and 767-300.

For example:

Code: Select all
  <altimeter>
    <name>altimeter</name>
    <number>0</number>
    <static-pressure>/systems/static/pressure-inhg</static-pressure>
    <encode-mode-c>1</encode-mode-c>
    <encode-mode-s>1</encode-mode-s>
  </altimeter>

I don't have a definitive source of information about GND mode but what I have read suggests it only works with a mode-S capable transponder and an extra bit is sent in the additional mode-S information to indicate whether the aircraft is on the ground. Whether that comes from the transponder knob position or a gear sensor, I do not yet know.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: Transponder properties

Postby mickybadia » Wed Jun 07, 2017 11:05 pm

I like your approach because it is inspired by real life systems, which is always preferable when the choice exists. And on the cockpit/aircraft side, I see value in setting up a prop tree that makes real-world sense.
On the other hand I recognise that FGMS packets are not a simulation of real-life transmissions, but serve as a means of enabling the multi-player environment. And being stuck with the currently sent property list for any short-term solution, new mode S prop's are rather out of the question, and impossible GND mode is a shame.

Now I proposed to use the only property we have (inputs/mode) for what ATC clients need as it felt like a reasonable working solution. For longer-term solutions, I would agree with you more. But the protocol itself is being discussed elsewhere for improvement, addressing the chat system, etc. So why not simulate an actual bi-directional mode-S query-answer loop through a dedicated network message type in the future!

Not sure if this might help, but the following could be a middle-ground solution trick if we need one:
* inputs/mode=0 implies A if code is valid, OFF otherwise
* inputs/mode=1 implies C if alt is valid, otherwise A if code is valid, OFF otherwise
* inputs/mode=2 implies S if alt is valid, otherwise A if code is valid, OFF otherwise
(this is basically the behaviour you say, to which I am adding:)
* inputs/mode=3 implies GND
* inputs/mode=-1 implies OFF
(last one arguably unnecessary)

This way ACFT dev's can implement the extension that ATCs need if they are kind enough to do so. And the system remains compatible with the currently used aircraft, and will stay so even if none are ever updated. The problems for the latter will simply remain those we know: modes C-vs-S not selectable, and GND mode impossible with current architecture.

sanhozay wrote in Wed Jun 07, 2017 5:56 pm:Do you have any information about what real life ATC see from a transponder in GND mode?

The idea is to see a blip even without a code. It is usually linked to a callsign on radar screens (like any other contact), but I admit I do not know if it is entered by the controller, technically sent by the mode S technology, or something differently. Again as I see it, such detail is not fully relevant to the design of MP packet content though.

sanhozay wrote in Wed Jun 07, 2017 5:56 pm:None of this is a criticism of ATC-Pie, by the way, I'm just trying to work out what's going on.

I very honestly never thought it was!
mickybadia
 
Posts: 475
Joined: Tue Sep 24, 2013 10:12 am

Re: Transponder properties

Postby sanhozay » Thu Jun 08, 2017 7:44 am

mickybadia wrote in Wed Jun 07, 2017 11:05 pm:... the following could be a middle-ground solution trick if we need one:
* inputs/mode=0 implies A if code is valid, OFF otherwise
* inputs/mode=1 implies C if alt is valid, otherwise A if code is valid, OFF otherwise
* inputs/mode=2 implies S if alt is valid, otherwise A if code is valid, OFF otherwise
(this is basically the behaviour you say, to which I am adding:)
* inputs/mode=3 implies GND
* inputs/mode=-1 implies OFF
(last one arguably unnecessary)

This is basically what I am thinking. I think the last one is unnecessary. Maybe also the mode=3, read on.

mickybadia wrote in Wed Jun 07, 2017 11:05 pm:The idea is to see a blip even without a code. It is usually linked to a callsign on radar screens (like any other contact), but I admit I do not know if it is entered by the controller, technically sent by the mode S technology, or something differently. Again as I see it, such detail is not fully relevant to the design of MP packet content though.

It is relevant because if controllers see an automatic distinction between ground operation and airborne, the information must be in the mode-S packet. I did some more reading and mode-S does appear to have a bit within the transmitted data that indicates ground operation or otherwise. Airliners usually have a squat switch (equivalent to Flightgear's gear/gear/wow) that automatically flips this bit. For aircraft that don't have a squat switch, mode-S transponders may have a GND position which is like ALT with the ground bit enabled. Ground movement radar shows targets that are mode-S capable and transmitting the ground bit. Approach radar filters out mode-S targets with the ground bit set. Obviously, the more common usage of ATC clients in Flightgear is a different display of ground and airborne targets rather than filtering, because controllers usually act as ground and tower. That's just a user-interface choice in the ATC client; the required data is the same.

To simulate this properly, we would need the ground bit. That would have to be done aircraft-side because the aircraft developer has to decide if they have a squat switch or manual transmission with a GND position on a transponder. I don't see that happening across all the aircraft any time soon so it might be better to use an ugly solution of (mode == 2 and gear/gear[0]/compression-norm > 0 and squawk >= 0). In other words a mode-S transponder with the ground bit set (implicit squat switch) and transponder is not OFF/SBY. In a cheat mode, you might just use gear/gear[0]/compression-norm > 0. I think you can get that now; no code changes to Flightgear or aircraft and no old models causing problems.

Perhaps a bigger issue is what I touched on in terms of the altimeter mode-S support. Most of the airliners in fgaddon seem to be simulating a mode-A+C transponder because they use the default transponder mode of 1 and the default altimeter instrument which doesn't provide mode-s-alt-ft. That would require widespread changes in fgaddon, which might mean it is better to get GND mode as (gear/gear[0]/compression-norm > 0 and squawk >= 0).
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: Transponder properties

Postby D-EKEW » Thu Jun 08, 2017 7:39 pm

First of all, most transponder automatic GND/ALT mode switching is done by (indicated) airspeed nowadays. Usually aircraft with integrated avionics.
Older aircraft typically rely on WOW.
Lastly there are a lot of (especially older GA aircraft) that have neither. The Pilot must actively switch modes.

If the individual aircraft does not have that implemented, it is the fault of the aircraft developer.
D-EKEW
 
Posts: 174
Joined: Mon Jan 10, 2011 9:22 pm
Callsign: D-EKEW, ELLX-TWR
Version: git
OS: Linux

Re: Transponder properties

Postby mickybadia » Sat Jun 10, 2017 7:44 am

The gear compression look-up for squat is a neat little trick, but comes with the feeling of new lurking problems. As you say, not all aircraft squat, and as EKEW says, auto-GND can be handled without squatting. I also wonder: do fixed gear aircraft set gear compression in FG? A risk is that non-auto switching aircraft start setting compression only to mean XPDR ground bit set when their knob is set to GND.

Rather, if any ad hoc impl is to make it to practice or a spec, we might as well propose a cleaner mode=3 value directly, meaning S-capable + currently squawking GND bit. If they don't do it (we agree that old aircraft will not all be updated soon), we are only back to the current behaviour unable to squawk GND mode. Workarounds via unrelated prop's like the one you propose can be used by extra "guess"-type options on the ATC side to compensate the current lack of modes={2,3}.

OK I think this was fruitful, and I will yet again change the ATC client to reflect this, replacing the guess option currently featured in ATC-pie... until somebody raises this up again with a new thread ;-)

Two questions:
1. for those who have been trying multiple aircraft and observing the XPDR prop's: do STBY & TEST knob positions consistently fill prop's like the XPDR is OFF?
2. for those who have been doing the research: confirm a XPDR with GND bit set keeps squawking its code?

Code: Select all
* inputs/mode=0 implies A if code is valid, OFF otherwise
* inputs/mode=1 implies C if alt is valid, otherwise A if code is valid, OFF otherwise
* inputs/mode=2 implies S if alt is valid, otherwise A if code is valid, OFF otherwise
* inputs/mode=3 implies GND
mickybadia
 
Posts: 475
Joined: Tue Sep 24, 2013 10:12 am

Re: Transponder properties

Postby sanhozay » Sat Jun 10, 2017 12:07 pm

I agree that the gear squat is ugly and not ideal. I haven't tested it but I think most aircraft would set gear compression because it is used to animate the struts to prevent the wheel sinking. Nevertheless, you are right that it is open to misunderstanding.

Before looking at using the transponder mode to transmit the ground bit, perhaps we should explore the possibility of actually transmitting a ground bit in the multiplayer packet? I have been assuming that the length of that packet is already under pressure and that it wouldn't be welcome but maybe that's not a valid assumption. There is also the ident boolean, which is four bytes and has plenty of space for another flag. If the ident was repurposed as a transponder flags field, the ground bit and ident bit could be bitwise encoded into that and the mode would remain as a transponder capability field.

What do you think of those ideas?

If anyone else is reading who knows more about the multiplayer protocol, please add your thoughts. It's probably time to raise this on the mailing list.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: Transponder properties

Postby mickybadia » Sat Jun 10, 2017 5:59 pm

sanhozay wrote in Sat Jun 10, 2017 12:07 pm: have been assuming that the length of that packet is already under pressure and that it wouldn't be welcome but maybe that's not a valid assumption.

I have read this was currently under revision. Some compression has taken place. But for the moment (and probably anyway) I think the assumption is indeed valid. Also, the GND bit is not yet just like any other numbered property, so adding it in this way does not look that trivial.

sanhozay wrote in Sat Jun 10, 2017 12:07 pm:There is also the ident boolean, which is four bytes and has plenty of space for another flag. If the ident was repurposed as a transponder flags field, the ground bit and ident bit could be bitwise encoded into that and the mode would remain as a transponder capability field.

I think this is fine idea. I only see two problems, which we should confirm are minor enough but the second might not be:
1. the already running ATC clients may be comparing the prop to 0 to check ident. A ground bit would then be interpreted as ident for those. But as we said there will be few to start, plus the fix is simple, and beside me there is virtually only one person to warn about it.
2. the property should be renamed. Is this going to break much or require complex phasing in?
mickybadia
 
Posts: 475
Joined: Tue Sep 24, 2013 10:12 am

Re: Transponder properties

Postby sanhozay » Sat Jun 10, 2017 6:47 pm

mickybadia wrote in Sat Jun 10, 2017 5:59 pm:1. the already running ATC clients may be comparing the prop to 0 to check ident. A ground bit would then be interpreted as ident for those. But as we said there will be few to start, plus the fix is simple, and beside me there is virtually only one person to warn about it.

I think when I tested, the boolean was 0=false and 1=true, in which case it's easy enough to make changes to ATC-Pie and OpenRadar that are backward compatible with previous versions. The second bit is always zero in older versions so would never show up as the ground bit. Testing for ident would become (flags & 0x01) and testing for the ground bit would become (flags & 0x02). Obviously it would take time for ATC-Pie users to see the effect of this, so you might need to think about what you can do as an interim.

mickybadia wrote in Sat Jun 10, 2017 5:59 pm:2. the property should be renamed. Is this going to break much or require complex phasing in?

I don't know but early in a release cycle is a good time to find out.

I was thinking this could be coded into the transponder with a configuration setting for the property that sets the ground bit. So all an aircraft developer would have to do would be choose their property that sets the ground bit in their -set.xml file. For aircraft with a squat switch that would be gear/gear/wow. For aircraft with auto ground based on airspeed, the aircraft developer would have to make a new logic property for airspeed < x. The default would probably be knob-mode == GND.

So something like:

Code: Select all
<transponder>
  <ground-bit-source>gear/gear/wow</ground-bit-source>
  ...
</transponder>
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 18 guests