Board index FlightGear Development Aircraft

Transponder properties over MP

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

Transponder properties over MP

Postby mickybadia » Tue Jan 17, 2017 10:50 pm

Hi,
There is a small history behind this question, scattered over channels and years, but as far as I can tell it is not resolved, or no recommendations followed.

ATC clients rely on transponders to do their job, and read into the following propoerties:
- 1500: int 'instrumentation/transponder/transmitted-id'
- 1501: int 'instrumentation/transponder/altitude'
- 1502: bool 'instrumentation/transponder/ident'
- 1503: int 'instrumentation/transponder/inputs/mode'

Problem is, 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.

Questions:
1. I remember talking about this with Stuart at the FSweekend and he pulled up a one-line code comment from somewhere containing a short spec of what the values for 1503 should be. Anybody knows what that source might be, and whether it should actually serve as the spec we should all follow?
2. Should we go round all aircraft to correct this? Is this scriptable?

Cheers

[EDIT: syntactic mistake]
Last edited by mickybadia on Tue Apr 04, 2017 12:33 pm, edited 1 time in total.
mickybadia
 
Posts: 405
Joined: Tue Sep 24, 2013 9:12 am

Re: Transponder properties over MP

Postby Octal450 » Tue Jan 17, 2017 11:05 pm

My two cents
I did some looking, and it appears most aircraft use a custom system for the transponder modes, but none of them actually change -1503 in any way. I'm proposing an update to this transponder system to change that mode, and if I did it, I would recommend it to go inside FGdata, so other plane devs can update their planes.

This biggest issue right now, it that alot of planes, the transponder mode selector does not do much, except visual things. Therefore, an ATC client can't determine which transponder mode is the plane using.

If alot of planes could be updated to have a custom XPNDR system, that uses a generic numbering scheme, like 0=OFF/STBY 1=GND MODE (if applicable), 2=Mode C, 3=Mode S for example, then all planes could use it, and solve this issue.

Josh
Octal450
 
Posts: 4397
Joined: Tue Oct 06, 2015 12:51 pm

Re: Transponder properties over MP

Postby mickybadia » Tue Jan 17, 2017 11:15 pm

it0uchpods wrote in Tue Jan 17, 2017 11:05 pm:I'm proposing an update to this transponder system to change that mode, and if I did it, I would recommend it to go inside FGdata, so other plane devs can update their planes.

Eventually indeed, FGdata would need its update. But given the large number of planes therein, how about my last question: is this scriptable? I suppose we can neither force each dev to act now on this, nor can we dig into 300 different models...

it0uchpods wrote in Tue Jan 17, 2017 11:05 pm:If alot of planes could be updated to have a custom XPNDR system, that uses a generic numbering scheme, like 0=OFF/STBY 1=GND MODE (if applicable), 2=Mode C, 3=Mode S for example, then all planes could use it, and solve this issue.

Exactly. And my 1st question was about such a spec that I was shown, and that perhaps we ought to follow. Otherwise I would be happy with just that.
mickybadia
 
Posts: 405
Joined: Tue Sep 24, 2013 9:12 am

Re: Transponder properties over MP

Postby Gijs » Wed Jan 18, 2017 12:53 am

Did you see http://wiki.flightgear.org/Transponder?

mode: this is 0 for Mode-A, 1 for Mode-C and 2 for Mode-S.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9365
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Transponder properties over MP

Postby Octal450 » Wed Jan 18, 2017 6:47 am

But the PROP DOES NOT UPDATE in rarely any planes...
Octal450
 
Posts: 4397
Joined: Tue Oct 06, 2015 12:51 pm

Re: Transponder properties over MP

Postby tikibar » Wed Jan 18, 2017 6:53 am

It's my understanding that that prop isn't supposed to update. It's a configuration property that represents the capabilities of the transponder installed on the aircraft (Does the aircraft have a mode A, C or S transponder). 'instrumentation/transponder/inputs/knob-mode is the property containing the operating mode that the pilot has selected by turning the knob.
Boeing 747-8 (rename folder to 747-8i)
Boeing 757-200/300 (rename folder to 757-200)
Boeing 767-300/ER (rename folder to 767-300)
McDonnell Douglas MD-11 (rename folder to MD-11)
User avatar
tikibar
 
Posts: 514
Joined: Mon Mar 05, 2012 6:05 am
Location: Los Angeles
Callsign: CHT0009
OS: Ubuntu 14.04

Re: Transponder properties over MP

Postby stuart » Wed Jan 18, 2017 8:54 am

Hi All,

It should be straightforward to do a grep to identify the aircraft in fgaddon that have transponders, and either correct their mode settings to make them consistent, or if they don't have an appropriate know, modify the -set.xml file to set a reasonable default mode (for example, in real life, I sometimes forget to switch my transponder off, so it stays in ALT mode).

I would think that most aircraft maintainers would be happy to have the transponders made consistent - this is collaborative development :).

Normal process for this is to announce the change on the -devel list (and newletter), listing the aircraft that are non-compliant, give aircraft maintainers a reasonable time to correct their aircraft, and then modify them yourself.

tikibar - that's incorrect. the MP properties respresent what is transmitted by the transponder, so inputs/mode represents the transponder mode.

Gijs - I think we also need a GND mode - certainly my transponder has this in RL.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Transponder properties over MP

Postby mickybadia » Wed Jan 18, 2017 1:53 pm

For a second I thought tikibar had made us see the light, as his/her understanding all of a sudden explained why the 1503 values were being so consistently fixed regardless of pilot input. But it seems we do have the problem of an under-specified and under-used value for this prop.

stuart wrote in Wed Jan 18, 2017 8:54 am:Normal process for this is to announce the change on the -devel list (and newletter), listing the aircraft that are non-compliant, give aircraft maintainers a reasonable time to correct their aircraft, and then modify them yourself.

Roger. Given my initiating/reviving this question and Josh's clean-up proposal I will try and coordinate sth with him along those lines.

Is it OK if we go for values 0..4, respectively meaning off, GND, A, C, C+S?
(sorry it0uchpods I misread your proposal but we do need an A setting as well)

stuart wrote in Wed Jan 18, 2017 8:54 am:(for example, in real life, I sometimes forget to switch my transponder off, so it stays in ALT mode).

What?! Have you µ-lighters no checklists on board now? Tsss, bad bad bad :-}
mickybadia
 
Posts: 405
Joined: Tue Sep 24, 2013 9:12 am

Re: Transponder properties over MP

Postby Octal450 » Wed Jan 18, 2017 2:36 pm

Haha

Hmm. Regardless of that, each aircraft seems to have a different prop. Tiki's planes all have knob-mode. But a lot of others don't.
Octal450
 
Posts: 4397
Joined: Tue Oct 06, 2015 12:51 pm

Re: Transponder properties over MP

Postby Johan G » Thu Jan 19, 2017 5:40 pm

tl;dr Regarding prop 1503 (instrumentation/transponder/inputs/mode) and available modes: It is all there. But it is not clearly documented (except for the source code :roll: ). Many aircraft developers are most probably not aware of how to set up a transponder for their aircraft.


mickybadia wrote in Tue Jan 17, 2017 10:50 pm:I remember talking about this with Stuart at the FSweekend and he pulled up a one-line code comment from somewhere containing a short spec of what the values for 1503 should be. Anybody knows what that source might be, and whether it should actually serve as the spec we should all follow?

it0uchpods wrote in Tue Jan 17, 2017 11:05 pm:I did some looking, and it appears most aircraft use a custom system for the transponder modes, but none of them actually change -1503 in any way.
[...]
This biggest issue right now, it that alot of planes, the transponder mode selector does not do much, except visual things. Therefore, an ATC client can't determine which transponder mode is the plane using.

Looking at the source code (flightgear/src/Instrumentation/transponder.hxx and transponder.cxx, both at commit 8472a8c3) it is relatively clear what it should do, in essence to reflect the mode setting of the transponder. Unfortunately it does not seem to be all that clearly documented outside the source code.

I would guess most aircraft developers may simply not be aware of how the transponder can be set up in FlightGear and what it can do.

tikibar wrote in Wed Jan 18, 2017 6:53 am:It's my understanding that that prop isn't supposed to update. It's a configuration property that represents the capabilities of the transponder installed on the aircraft (Does the aircraft have a mode A, C or S transponder). 'instrumentation/transponder/inputs/knob-mode is the property containing the operating mode that the pilot has selected by turning the knob.

stuart wrote in Wed Jan 18, 2017 8:54 am:tikibar - that's incorrect. the MP properties respresent what is transmitted by the transponder, so inputs/mode represents the transponder mode.

Indeed

stuart wrote in Wed Jan 18, 2017 8:54 am:Gijs - I think we also need a GND mode - certainly my transponder has this in RL.

The source code already supports a ground mode. It is just not documented anywhere outside the source code. :roll:


I just edited The FlightGear wiki article Transponder (perm, diff), mostly to add links to related wiki articles, forum topics and to some source files. It really could be expanded to explain the possibilities and how to make them available for an aircraft's pilot.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5513
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Transponder properties over MP

Postby Octal450 » Thu Jan 19, 2017 6:14 pm

OK thanks
I'll try to get the prop working in one of my planes, and I'll try to have a test with Micky.

Thx
Josh
Octal450
 
Posts: 4397
Joined: Tue Oct 06, 2015 12:51 pm

Re: Transponder properties over MP

Postby tikibar » Thu Jan 19, 2017 7:10 pm

stuart wrote in Wed Jan 18, 2017 8:54 am:tikibar - that's incorrect. the MP properties respresent what is transmitted by the transponder, so inputs/mode represents the transponder mode.


In that case, then either the wiki is wrong or the wrong property is being sent over MP. According to the wiki, "instrumentation/transponder/inputs/mode" is a configuration property that is set in the Systems/instrumentation.xml file like so:

Code: Select all
<transponder>
    <name type="string">transponder</name>
    <number type="int">0</number>
    <mode type="int">1</mode> <!-- 0 = Mode A, 1 = Mode C, 2 = Mode S -->
    <bus-volts type="double">8.0</bus-volts>
    <encoder-path type="string">/instrumentation/altimeter</encoder-path>
    <kt70-compatibility type="bool">0</kt70-compatibility>
</transponder>


If you adjust "mode" in this block, it changes "instrumentation/transponder/inputs/mode."

Also according to the wiki, "knob-mode: sets the transponder operating mode." The knob modes are as follows:
Quoting the wiki page:
0 - off
1 - standby, basically the same as off for the C++ code (3D instrument would power up the display, presumably)
2 - test, again the C++ largely ignores this since the test configuration of real-world instruments varies. In particular the unit does *not* set altitude or transmitted-id to any test values, you should do that in your own logic. (Maybe we should allow the test values to be defined int he config section?)
3 - Ground mode, responds to altitude interrogation but does not broadcast an ID. This would typically be used while taxiing prior to takeoff.
4 - On, normal operation but altitude transmission is inhibited
5 - Alt, same as on but altitude is broadcast if transponder was configured in Mode-S or Mode-C


So, it sounds to me like the wrong prop is associated with 1503. 1503 should be instrumentation/transponder/inputs/knob-mode. I imagine that's a pretty easy thing to fix, as opposed to completely revamping the transponder code. In fact, changing line 177 in multiplaymgr.cxx would do it.
Code: Select all
{1503, "instrumentation/transponder/inputs/mode", simgear::props::INT},

should be

{1503, "instrumentation/transponder/inputs/knob-mode", simgear::props::INT},
Boeing 747-8 (rename folder to 747-8i)
Boeing 757-200/300 (rename folder to 757-200)
Boeing 767-300/ER (rename folder to 767-300)
McDonnell Douglas MD-11 (rename folder to MD-11)
User avatar
tikibar
 
Posts: 514
Joined: Mon Mar 05, 2012 6:05 am
Location: Los Angeles
Callsign: CHT0009
OS: Ubuntu 14.04

Re: Transponder properties over MP

Postby Johan G » Thu Jan 19, 2017 9:08 pm

tikibar wrote in Thu Jan 19, 2017 7:10 pm:[...] it sounds to me like the wrong prop is associated with 1503. 1503 should be instrumentation/transponder/inputs/knob-mode. I imagine that's a pretty easy thing to fix, as opposed to completely revamping the transponder code. In fact, changing line 177 in multiplaymgr.cxx would do it.

At first I thought you was correct, but after some thought and trying to understand the source code I am even more sure that lacking documentation is the real issue.

I did plug in the example from the wiki in an experimental aircraft and opened up the radio dialog and the property browser. Changing the transponder mode in the radio dialog do not change /instrumentation/transponder/inputs/mode (which is not one of those tied properties; it can be changed through the property browser), but it does instead change /instrumentation/transponder/inputs/knob-mode.

I wondered if there was a thought behind that. However, have not seen a rationale behind it in the few developer mailing list threads and forum topics I have found, and seen any in the source files either. The relevant commit message pretty much refers to the wiki page.

It also might just be some confusion caused by both "knobs" having mode in their name. I think one hint is that knob-mode is per default set to 4=GROUND, unless overridden by the -set.xml, another one that knob-mode have integer 6 values (0-5) corresponding to OFF, STANDBY, TEST, GROUND, ON and ALT. We would not want those transmitted as transponder modes.

I am starting to think that there was an implicit understanding that aircraft developers would add the required logic to for example make knob-mode=4 (ON) make mode change to 0 (Mode 3/A), knob-mode=5 (ALT) to make mode change to 1 (Mode 3/C). I am speculating a bit here, but it seem logical, and seem to agree with the wiki article. That would make for a good basis for a generic instrument though. ;)


A hint when writing documentation that I learned while lurking before editing on Wikipedia: Explain the obvious. If you are well read in or even the developer, do not expect other to fully understand otherwise. ;)


Edit: I think I need to try to figure out the source code and how that correlate to the wiki page so that it can be improved. I have to keep in mind that the authors of the current transponder code also wrote that wiki page, so it should rather be clarified then altered.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5513
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Transponder properties over MP

Postby mickybadia » Thu Jan 19, 2017 10:11 pm

Hi,

I was composing my own answer, but figured merging with the existing is better than duplicating, so basically and most importantly I agree with Johan G here:
Johan G wrote in Thu Jan 19, 2017 9:08 pm:OFF, STANDBY, TEST, GROUND, ON and ALT. We would not want those transmitted as transponder modes.


...and had always assumed the following myself:
Johan G wrote:there was an implicit understanding that aircraft developers would add the required logic


However, I repeat my proposition for a harmonised spec of prop 1503 (instrumentation/transponder/inputs/mode) value, to be updated by aircraft models on knob/F12 change:
mickybadia wrote in Wed Jan 18, 2017 1:53 pm:0..4, respectively meaning off, GND, A, C, C+S

In other words a 5-value set: 0 (off), 1 (GND), 2 (mode A), 3 (mode C), 4 (mode S).

My plan now unless anybody shouts against it: wait for this thread to cool down in a consensus, try to meet with it0chpods next week or whatever with an adjusted version of an ATC radar client, test, post on the devel list as an official invitation to all ACFT dev's to update, and get the call from stuart that "a reasonable time" has past :-)
Then a miracle should happen.
mickybadia
 
Posts: 405
Joined: Tue Sep 24, 2013 9:12 am

Re: Transponder properties over MP

Postby mickybadia » Thu Jan 26, 2017 10:25 am

After a week of silence and to keep things moving:
mickybadia wrote in Thu Jan 19, 2017 10:11 pm:wait for this thread to cool down in a consensus

Check?

In any case I will now post to the devel list, and for aircraft developers to work on enhancing their aircraft models and test their behaviour, I have created an ATC-pie Git branch called "xpdr" implementing the proposed spec for prop 1503 (instrumentation/transponder/inputs/mode), i.e.:
  • 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)

Feel free to use and make sure you test all XPDR settings and F12/cockpit knob sync. Here is what you should see on MP connect, with this branch "xpdr" and all cheats off:
  • off: no contact, unless primary radar is turned (radar contact marked "P");
  • for all modes except "off": a square contact (not a circle)
  • modes A/C/S: a code on tag line 2
  • beginning of line 3: "GND" in ground mode, "alt?" in mode A, an altitude/FL reading in modes C/S
  • mode S only: the callsign and aircraft type on line 1

NB: ATC-pie features cheats, for the full radar range or by contact. If cheated, a contact should behave like a mode S. Also see: quick reference from the help menu.
mickybadia
 
Posts: 405
Joined: Tue Sep 24, 2013 9:12 am

Next

Return to Aircraft

Who is online

Users browsing this forum: Google [Bot] and 3 guests

cron