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 mickybadia » Sun Jun 11, 2017 7:35 pm

FYI, I have asked for the devel list's opinion, with a summary of the two current candidate options for a ground mode: (1) inputs/mode=3; (2) repurpose ident for flags. And a link to here.
mickybadia
 
Posts: 475
Joined: Tue Sep 24, 2013 10:12 am

Re: Transponder properties

Postby sanhozay » Sun Jun 11, 2017 10:52 pm

OK, thanks. I'll explore the code changes in transponder.cxx but I'm away a few days this week so it might take a week or so.
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 sanhozay » Mon Jun 12, 2017 12:33 pm

If you've seen the mailing list, the recommendation is that we go with a new boolean for the ground bit. I've started coding this and it will be property 1504 (05E0 in hex).

EDIT: I've got the bare bones of this working, simulating a squat switch only at this stage, but I can see the ground bit coming through the MP packet. If you want to test with ATC-Pie, let me 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 Maerchenprinz » Thu Jun 07, 2018 7:58 pm

Hallo everybody!

You must be really happy that someone brings up this topic again! :P
Anyway, I've spent the last two days trying to implement a simple "GROUND" mode into a transponder capable of only "A" and "C" (not "S");
Everything is working, except that /transponder/inputs/knob-mode=3 still answers ident-interrogations. So /transmitted-id remains, and does not change to -9999.
The idea with the "ground-bit" is reasonable and working, unfortunately only for S-mode (which is correct), all other knob-modes do what they should in both C- and S-types ... Everything works! Except...
So my suspicion is that there's just a little flaw in the source code, which e.g. changes /altitude or /airspeed-kt to -9999 in corresponding /knob-mode and /mode configurations, but not /transmitted-id.
Fortunately, I have a ( fiddly :) )workaround for this for my transponder.xml in mind ; Unfortunately, I don't think that there are many (new) devs willing (capable) to do that.
What do you think, is this a bug (as I see it) and can I file a bug-report, or is there anything I have missed, and this is correct behaviour?

Ciao,

Adrian
User avatar
Maerchenprinz
 
Posts: 306
Joined: Thu Mar 15, 2007 6:24 pm
Location: Bochum, it's better, much better than you think!
Callsign: Adrian

Re: Transponder properties

Postby mickybadia » Fri Jun 08, 2018 7:21 am

Maerchenprinz wrote in Thu Jun 07, 2018 7:58 pm:I've spent the last two days trying to implement a simple "GROUND" mode into a transponder capable of only "A" and "C" (not "S");


The way I understand transponder modes, this is neither possible nor even meaningful in real life because the GND bit is a feature of the mode S.

Here is the expected prop-value spec by mode and capability. All prop's below come under instrumentation/transponder:
- transmitted-id (int)
- altitude (int)
- ident (bool)
- inputs/mode (int)
- ground-bit (bool) <-- INTRODUCED AFTER THIS THREAD
- airspeed-kt (int) <-- INTRODUCED AFTER THIS THREAD

For all transponders:
- off: transmitted-id < 0
- on: transmitted-id = "squawk code" integer as if to be read a decimal value
- if reporting altitude (modes C and S turned on): altitude = pressure-alt. value in feet
- otherwise (mode A): altitude = -9999
- ident = 0/1 (result of cockpit button press; up to the model to implement the timeout)

Modes A/C transponders:
- in all settings: inputs/mode = 1
- ground-bit and airspeed-kt irrelevant

For a mode S capable XPDR:
- in all settings: inputs/mode = 2
- airspeed-kt set to indicated airspeed
- ground-bit = 0/1 (this can be the result of squatting or manual setting)

For testing, the best is to check the property tree yourself against the spec, but for a real use case ATC-pie fully implements this. Just be careful what capability you set your radar to have (set to mode S without any cheats for actual account of the transmitted data). See the "display conventions" in the quick ref to interpret the stuff displayed on the scope.
mickybadia
 
Posts: 475
Joined: Tue Sep 24, 2013 10:12 am

Re: Transponder properties

Postby Maerchenprinz » Fri Jun 08, 2018 12:17 pm

Hi mickybadia!

Thanks for your reply! Sorry, I may have not pointed out clearly what I meant:
With "GROUND"-mode, I was referring to the FG-wiki page http://wiki.flightgear.org/Transponder#Knob.2FFunctional_Modes
3 - Ground mode, responds to altitude interrogation but does not broadcast an ID. This would typically be used while taxiing prior to takeoff.

- not a real bijectiv "GROUND"-mode identification (like sending a ground-bit): Is respond to "A"-interrogation deliberately turned off or does a faulty chiffrator form an invalid or no code?
- It is rather the "old" and rather inconvenient way of telling the controllers that you're still chilling 8) on ground or taxiing so that Approach and Departure controllers can ignore you with a clear conscience.
There were and are numerous transponder types around which have this option!

I'm only talking from the aircraft's transponder side and FG's internal representation; no real life ATC-, no ATC-Pie-, no FG-MP-side, no...

So either the FG-wiki page or the transponder.cxx/hxx is wrong. Having this /knob-mode=3 working as described in the wiki makes much more sense to me. But, beat me to it (Don't! Please! :) ), I wasn't capable of even finding the error in the code...

Thanks for all of your explanations; But after two :!: days of testing and cursing, I think I have tested and have thought through any possible property-configuration! As I said before (please discard "or is there anything I have missed"):

Maerchenprinz wrote in Thu Jun 07, 2018 7:58 pm:Fortunately, I have a ( fiddly :) )workaround for this for my transponder.xml in mind ; Unfortunately, I don't think that there are many (new) devs willing (capable) to do that.
What do you think, is this a bug (as I see it) and can I file a bug-report, or is there anything I have missed, and this is correct behaviour?


Ciao,

Adrian
User avatar
Maerchenprinz
 
Posts: 306
Joined: Thu Mar 15, 2007 6:24 pm
Location: Bochum, it's better, much better than you think!
Callsign: Adrian

Re: Transponder properties

Postby Isaak » Mon Nov 12, 2018 9:20 am

Hi there, I 'm fixing the transponder in the 777 currently. I've already implemented a functioning ident button locally, which I will push this evening (CET), but I 'm stuck at getting the correct transponder altitude. I 've already assigned the correct mode (2) to it (it was 0), and got the airspeed property to update correctly, but the instrumentation/transponder/altitude property keeps stuck at -9999, no matter what I do. I 'm not even able to update it manually because it seems tied to some other property, but I can't find out which one. The wiki page didn't help me much further. Enabling encode-mode-c and/or encode-mode-s in the altimeter configuration doesn't solve anything. Does anyone know which property-rule is preventing me from implementing a correctly functioning transponder?
Want to support medical research with your pc? Start Folding at Home and join team FlightGear!
Isaak
 
Posts: 768
Joined: Sat Jun 04, 2011 3:52 pm
Location: Hamme, Belgium
Pronouns: he, him
Callsign: OO-ISA
Version: next
OS: Windows 10

Re: Transponder properties

Postby WoodSTokk » Mon Nov 12, 2018 12:01 pm

In the 'Systems/instrumentation.xml' set the following:
Code: Select all
    <altimeter>
        <name>altimeter</name>
        <number>0</number>
        <static-pressure>/systems/static/pressure-inhg</static-pressure>
        <encode-mode-c>false</encode-mode-c>
        <encode-mode-s>true</encode-mode-s>
    </altimeter>

    <transponder>
      <name type="string">transponder</name>
      <number type="int">0</number>
      <mode type="int">2</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>
WoodSTokk
 
Posts: 1077
Joined: Tue Oct 17, 2017 3:30 pm
Location: Milky Way/Sol/Earth/Europe
Callsign: SX-W57
IRC name: WoodSTokk
Version: 2020.4.0
OS: Debian Bullseye

Re: Transponder properties

Postby Isaak » Mon Nov 12, 2018 12:33 pm

Thanks for the reply, will retry this evening!
Want to support medical research with your pc? Start Folding at Home and join team FlightGear!
Isaak
 
Posts: 768
Joined: Sat Jun 04, 2011 3:52 pm
Location: Hamme, Belgium
Pronouns: he, him
Callsign: OO-ISA
Version: next
OS: Windows 10

Re: Transponder properties

Postby Isaak » Mon Nov 12, 2018 6:12 pm

I 'm afraid it doesn't work. The altitude property stays at -9999. What I also find is that e.g. airspeed-kt doesn't get disabled when transponder/inputs/knob-mode changes. I 'll dig a bit deeper into the code, but I do think someone once implemented some transponder code that is competing with the default behaviour. I just need to point out where.
Want to support medical research with your pc? Start Folding at Home and join team FlightGear!
Isaak
 
Posts: 768
Joined: Sat Jun 04, 2011 3:52 pm
Location: Hamme, Belgium
Pronouns: he, him
Callsign: OO-ISA
Version: next
OS: Windows 10

Re: Transponder properties

Postby WoodSTokk » Tue Nov 13, 2018 12:32 am

BEL ISAAK wrote in Mon Nov 12, 2018 6:12 pm:I 'm afraid it doesn't work. The altitude property stays at -9999. What I also find is that e.g. airspeed-kt doesn't get disabled when transponder/inputs/knob-mode changes. I 'll dig a bit deeper into the code, but I do think someone once implemented some transponder code that is competing with the default behaviour. I just need to point out where.

I have changed the transponder on the Citation II and Citation X from mode C to mode S for a while and as far as i know, it works, but i will double check it.
Is your working copy of the aircraft everywhere in the net so that i can investicate it?

EDIT:
Have now checked the Citation II and all works correct in the property tree.
I dont know if the correct values are also transmitted over MP protocol.

XPDR Off:
Image
XPDR Standby:
Image
XPDR On:
Image
XPDR Altitude:
Image
WoodSTokk
 
Posts: 1077
Joined: Tue Oct 17, 2017 3:30 pm
Location: Milky Way/Sol/Earth/Europe
Callsign: SX-W57
IRC name: WoodSTokk
Version: 2020.4.0
OS: Debian Bullseye

Re: Transponder properties

Postby Isaak » Tue Nov 13, 2018 11:10 am

It's the official 777 I 'm working on, you can download it through the launcher or pull from svn. I 've tested various knob-modes, but can't get the altitude reporting to work. I did get the airspeed working by modifying altimeter and transponder config though (not yet committed because I don't want to commit non-functioning code). I 'll only have time on Thursday and Friday to continue my investigation, but please feel free to check it out too. I 'll take a look at the citation II to see if there are any differences. I have the feeling that there's some code competing with the default behaviour, but can't locate it.
Want to support medical research with your pc? Start Folding at Home and join team FlightGear!
Isaak
 
Posts: 768
Joined: Sat Jun 04, 2011 3:52 pm
Location: Hamme, Belgium
Pronouns: he, him
Callsign: OO-ISA
Version: next
OS: Windows 10

Re: Transponder properties

Postby WoodSTokk » Tue Nov 13, 2018 2:21 pm

BEL ISAAK wrote in Tue Nov 13, 2018 11:10 am:It's the official 777 I 'm working on, you can download it through the launcher or pull from svn. I 've tested various knob-modes, but can't get the altitude reporting to work. I did get the airspeed working by modifying altimeter and transponder config though (not yet committed because I don't want to commit non-functioning code). I 'll only have time on Thursday and Friday to continue my investigation, but please feel free to check it out too. I 'll take a look at the citation II to see if there are any differences. I have the feeling that there's some code competing with the default behaviour, but can't locate it.


Its a problem in the xml-file of the animation.
The mode-switch on the 777 change the property '/instrumentation/transponder/mode-switch'
insteed of '/instrumentation/transponder/inputs/knob-mode'.
WoodSTokk
 
Posts: 1077
Joined: Tue Oct 17, 2017 3:30 pm
Location: Milky Way/Sol/Earth/Europe
Callsign: SX-W57
IRC name: WoodSTokk
Version: 2020.4.0
OS: Debian Bullseye

Re: Transponder properties

Postby Isaak » Tue Nov 13, 2018 3:41 pm

Yes, I did correct that locally, but when I overrode the knob-mode property manually, nothing changed. I 'll look into it again on Thursday. Thanks for pointing me in the right direction already ;)
Want to support medical research with your pc? Start Folding at Home and join team FlightGear!
Isaak
 
Posts: 768
Joined: Sat Jun 04, 2011 3:52 pm
Location: Hamme, Belgium
Pronouns: he, him
Callsign: OO-ISA
Version: next
OS: Windows 10

Re: Transponder properties

Postby Octal450 » Tue Nov 13, 2018 6:09 pm

Wait what?
for me, overwriting knob-mode is needed, am I understanding that it should be mode-switch instead? or is knob-mode correct?

I am asking since I am modelling the Airbus XPNDR and the the GTX-327 garmin.

Kind Regards,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 9 guests