Re: [Flightgear-devel] generic input device support: wrong button event names in Linux
Hi Brant,
Though your problem should be looked and fixed, it is different from
this one since the generic input device support is not implemented on
windows yet.
Plus, it does nothing on any platform unless you make a configuration
file for your device under $FG_ROOT/input/event/Some Vendor/Some
product.xml.
Thus this problem doesn't affect the existing joystick feature.
Btw, is any one kindly enough to implement this feature on windows?
Tat
On 2009/09/15, at 8:30, Brant G ioncannon21...@gmail.com wrote:
Indeed. I have a X52 joystick and it's very confusing to configure
in the joystick .xml file. When I updated to CVS recently, the hats
buttons don't work properly in windows. This should be looked at and
fixed.
On Mon, Sep 14, 2009 at 6:45 PM, Tatsuhiro Nishioka tat.fgmac...@gmail.com
wrote:
Hi,
I've been testing X52 joystick with FGLinuxEventInput.cxx on liunx
and found that button event names for joysticks/gamepad are very
suspicious, and we need to consider some other means of naming
button events.
The problem is that a joystick (, mouse or gamepad) button can have
wrong event name if a device has more than 16 buttons.
This is because Linux hid driver (drivers/hid/hid-input.c) assumes
that a device has 16 buttons at most.
e.g. If a joystick has more than 16 buttons, a button event name for
button-#16 or higher are mistakenly assigned to ones in game pads,
digitizer, or others.
This is the excerpt from hid-input.c ( hidinput_configure_usage)
that shows how Linux driver converts HID usage to a code of hid
event written to /dev/input/js*
case HID_UP_BUTTON:
code = ((usage-hid - 1) 0xf); // Note:
assuming #buttons = 16.
switch (field-application) {
case HID_GD_MOUSE:
case HID_GD_POINTER: code += 0x110;
break;
case HID_GD_JOYSTICK: code += 0x120;
break;
case HID_GD_GAMEPAD: code += 0x130;
break;
default:
switch (field-physical) {
case HID_GD_MOUSE:
case
HID_GD_POINTER: code += 0x110; break;
case
HID_GD_JOYSTICK: code += 0x120; break;
case
HID_GD_GAMEPAD: code += 0x130; break;
default: code += 0x100;
}
}
map_key(code);
break;
As a matter of fact, event names for X52 buttons are assigned as
follows in FGLinuxEventInput.cxx:
#00 button-trigger: type=1, code=288 (trigger)
#01 button-thumb: type=1, code=289 (FIRE button on stick)
#02 button-thumb2: type=1, code=290 (A button on stick)
#03 button-top: type=1, code=291 (B button on stick)
#04 button-top2:type=1, code=292 (C button on stick)
#05 button-pinkie: type=1, code=293 (pinkie button)
#06 button-base:type=1, code=294 (D button on throttle)
#07 button-base2: type=1, code=295 (E button on throttle)
#08 button-base3: type=1, code=296 (T1)
#09 button-base4: type=1, code=297 (T2)
#10 button-base5: type=1, code=298 (T3)
#11 button-base6: type=1, code=299 (T4)
#12 button-300: type=1, code=300 (T5)
#13 button-301: type=1, code=301 (T6)
#14 button-302: type=1, code=302 (strong press of trigger)
#15 button-dead:type=1, code=303 (top hat up)
// buttons below are mistakenly assigned to GamePad buttons
#16 button-a: type=1, code=304 (top hat right)
#17 button-b: type=1, code=305 (top hat down)
#18 button-c: type=1, code=306 (top hat left)
#19 button-x: type=1, code=307 (hat up on throttle)
#20 button-y: type=1, code=308 (hat right on throttle)
#21 button-z: type=1, code=309 (hat down on throttle)
#22 button-tl: type=1, code=310 (hat left on throttle)
#23 button-tr: type=1, code=311 (mode1 on stick)
#24 button-tl2: type=1, code=312 (mode2 on stick)
#25 button-tr2: type=1, code=313 (mode3 on stick)
#26 button-select: type=1, code=314 (Function button on
throttle)
#27 button-start: type=1, code=315 (Start button on
throttle)
#28 button-mode:type=1, code=316 (RESET button on
throttle)
#29 button-thumbl: type=1, code=317 (i button on throttle)
#30 button-thumbr: type=1, code=318 (mouse button on
throttle)
#31 button-319: type=1, code=319 (wheel button on
throttle) // undefined in input.h
// buttons below
Re: [Flightgear-devel] Glideslope bugs/improvements
On 14 Sep 2009, at 23:31, James Turner wrote: At EGPH, at about 200ft above the runway, the navradio suddenly picks the 'other' end, with, as they say, hilarious consequences. Actually the GS angle jumps from 3.0 degrees to 177 degrees, instantaneously. I suspect penaltyForNav is broken, probably by me - so that's where I shall look next. Torsten, it would be good if you could confirm my analysis, by trying some approaches in runways where the ends do not share an ILS frequency, and report on what you see. This is 'fixed' now - except it's not. penaltyForNav is basically broken - we all know it's broken conceptually, but it's also broken in practice, because it doesn't even do what it claims (and never has, that I can see) - bias to directional transmitters based on aircraft *heading*. The problem is it's biasing based on *bearing* from the aircraft to the transmitter. The fix is sort of a work-around (but also a correctness improvement); in the problem cases, we're picking the 'opposite' end LOC, but still getting the correct GS. Eg at EGPH, as you pass over the Rwy 06 LOC (ident=IVG), while flying the rwy 24 (ident ITH) ILS, the navradio switches to the 06/IVG LOC - but we're still using the ITH GS. What I've done is adjust the navradio to handle this case (mismatched LOC and GS) sanely, and hence avoid the bizarre angles being generated. The CDI needle still jumps when the LOC switches, but since it jumps onto the back course lobe, that's much more tolerable. As ever, please test and let me know what you think. All of this is short-term fixes until we properly model active/inactive ILS installations; which I'm going to be working on 'soon'. Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] nontrivial external situations (was: Glideslope bugs/improvements)
On 09/15/09 03:25, James Turner wrote: I suspect penaltyForNav is broken, probably by me - so that's where I shall look next. This is 'fixed' now Thanks. - except it's not. penaltyForNav is basically broken - we all know it's broken conceptually, but it's also broken in practice, because it doesn't even do what it claims Agreed. It makes no sense. (and never has, that I can see) Agreed. It has been broken for many years, probably since Day One. - bias to directional transmitters based on aircraft *heading*. The problem is it's biasing based on *bearing* from the aircraft to the transmitter. Neither of those things is realistic. In real life, the reversible ILS transmitter is controlled by a switch in the ATC tower, switched to match the choice of active runway, which in turn is normally based on the _wind_ ... not on the position or heading of any particular aircraft. The fix is sort of a work-around (but also a correctness improvement); Improved but still highly unrealistic. It is only a very rough placeholder, pending a decent solution. Constructive suggestion: Seriously, unless/until we can do a reasonable job of switching the reversible ILS, it would be better to not switch it at all. In particular, it would be better to just settle on one end or the other and stick with it for the duration of the simulation. I would initialize it randomly during startup, and leave it alone thereafter. This would create a 50/50 chance of having to shoot a the ILS with a tailwind and then execute the circle-to-land procedure ... which is good practice anyway. If you make the switch visible in the property tree, on a per-navaid basis, anybody who really cares can go in there and throw the switch the way he likes. Having navradio.cxx throw the switch in mid-flight, based on completely bogus criteria, is really, really, really not appropriate. What's worse is that all of the above is only the tip of the iceberg. The iceberg as a whole is what I call nontrivial external situations. Here is another example of what I'm talking about: Suppose there is a multiplayer situation where there are N aircraft, each of which has one DME and two ILS receivers, all tuned to the same station. If we expect each nav radio to synthesize its own IDENT signals, there are then 5N different IDENT signals, all unsynchronized. This is unrealistic, because in real life there is only IDENT signal, synchronized across all three transmitters (LOC, GS, and DME) ... so the received audio will be perceived as synchronized across all 5N receivers. Similarly all N aircraft should receive the same audio, synchronized, from any ATIS transmitters. Similarly, to return to the topic that started this thread, all N aircraft should see ATC make the same choice as to which end of a reversible ILS is in use. Similarly, ATC should turn on the runway lights and approach lights for the runway in use, at night and during marginal weather. The lights for other runways should be turned off. All N aircraft should see the same set of lights. Similarly all N aircraft should see the same AI traffic. As far as I can tell, the simplest and best way to implement this is to have, at least conceptually, N+1 agents, i.e. N+1 processes: one for each of the N aircraft, doing the usual FGFS aircraft related functions, plus one representing what's going on outside the aircraft, including weather, ATC decisions, IDENT signals, AI traffic, et cetera. Call this the external process. I'm not sure about the implementation details. In an MP situation, the external process could be implemented on the MP server. Or all N aircraft in a given MP session could get together and elect one of the aircraft to implement the external functions and serve them to the other N-1 aircraft. Or all N aircraft could do all of the external calculations, redundantly, provided they synchronize all of the relevant data so that all copies of the calculation get identical, synchronized answers. (Identical is easy; synchronized maybe not so easy.) === I realize that doing a good job of implementing the external process is not easy. In the meantime, though, we should try to put in the hooks to make such a process possible in the future. That is, low-level routines such as navradio.cxx should not be making high-level decisions, such as ATC decisions about which runway is in use. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] generic input device support: wrong button event names in Linux
I guess it is safer to use button-0, button-1, ... button-N for button event names so the names stays the same on different OSs. maybe we need to pull out some info using ioctl to find the first hid event code for a given device (e.g. 228 for joystick). I think your are right, simply numbering the buttons is probably the better approach. I assume, that button numbers are consitent across OSes, because they are defined in the HID report descriptor. Torsten -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nontrivial external situations (was: Glideslope bugs/improvements)
On 15 Sep 2009, at 13:15, John Denker wrote: Constructive suggestion: Seriously, unless/until we can do a reasonable job of switching the reversible ILS, it would be better to not switch it at all. In particular, it would be better to just settle on one end or the other and stick with it for the duration of the simulation. I would initialize it randomly during startup, and leave it alone thereafter. This would create a 50/50 chance of having to shoot a the ILS with a tailwind and then execute the circle-to-land procedure ... which is good practice anyway. If you make the switch visible in the property tree, on a per-navaid basis, anybody who really cares can go in there and throw the switch the way he likes. Having navradio.cxx throw the switch in mid-flight, based on completely bogus criteria, is really, really, really not appropriate. Okay, that's food for thought, and is probably how thins will end up anyway, with my interim plan... see below What's worse is that all of the above is only the tip of the iceberg. The iceberg as a whole is what I call nontrivial external situations. snip === I realize that doing a good job of implementing the external process is not easy. I agree agree with this concept, but of course the implementation required is 'some' way off :) In the meantime, though, we should try to put in the hooks to make such a process possible in the future. That is, low-level routines such as navradio.cxx should not be making high-level decisions, such as ATC decisions about which runway is in use. Agreed. My plan in this area is to create classes / extend existing classes which capture your 'external' state, especially regarding ATC. Some of those objects currently live in the AI world (including multiplayer aircraft), and some live in weird places. The key one which I'm going to be seriously messing with is FGAirportDyanmics, which essentially represents all the dynamic (as opposed to static, apt.dat derived) state of an airport. (I'm also not happy with that division of labour, I might replace the class completely with some other helpers to FGAirport) One of these objects/helpers/etc is going to implement getActiveRunwayForUsage 'better'. There are various ways to define better - a heuristic using aircraft position, runway directions, current local surface wind speed and direction is one. Another is to use the rwyuse.xml files in the scenery. A third is just to roll a dice at startup as you suggested. As you point out, anything would be better than changing mid-approach. I'm not sure exactly what policy I will end up with - almost certainly I'll default to rwyuse.xml where it exists, but the point is there will be an object which represents part of the Tower/Approach for an airport's knowledge of it's own state. It's a very small step from there, to attach this to better ATIS (which I know you have already worked on), and then an *ambitious* person could look at making this do AI-based ATC. (Good luck with that task!) Incidentally, this would also be the path to implementing 'click the mic to activate' PCL field lighting at non-controlled airports. I might well end up with FGUncontrolledAirportTower, FGControlledAirportTower, etc to keep things sane. Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
On Tue, Sep 15, 2009 at 5:25 AM, James Turner wrote: This is 'fixed' now - except it's not. penaltyForNav is basically broken - we all know it's broken conceptually, but it's also broken in practice, because it doesn't even do what it claims (and never has, that I can see) - bias to directional transmitters based on aircraft *heading*. The problem is it's biasing based on *bearing* from the aircraft to the transmitter. Hi James, I believe the original intent was to make the system function in away that made it appear that whatever approach you were trying to fly was the one that was turned on. So biasing the choice based on which approach you are most likely to be flying seems to make some sense. You don't care about aircraft heading because (I don't know) maybe you do a 180 because you get lost or you want to fly back and start over again, or whatever. The active glideslope dme ils transmitters should change when you turn away from the airport. The important thing is which end of the runway you are off of. I think we can concede that we don't have real world controllers turning approaches and lighting on and off for us on the ground. So either we create an elaborate system and force the user to make all these detailed choices every time we start up the sim, or we create some functional defaults that behave like people would expect, and allow people to easily use the simulation to practice flying any published approach. Once that base line capability is reestablished with all this new code and development activity, then yes, it would be great to allow an instructor to disable one side of an approach, or select which side is active, or even disable both sides. There could be some good training value. I think it's pretty important to be able to fire up FlightGear and practice any published approach without needing to go through contortions or elaborate setup proceedures, or having to repeatedly restart the sim until the particular approach we are interested randomly is enabled. FlightGear is used as part of FAA certified flight training devices so this is an area of the code where the basics need to work and be solid, and then if we want to get fancy and add additional realism, that's great. So at the end of the day, somehow we need to be able to just fire up the sim and fly any published approach without needing to go through some extravagant setup procedure each time. Regards, Curt. The fix is sort of a work-around (but also a correctness improvement); in the problem cases, we're picking the 'opposite' end LOC, but still getting the correct GS. Eg at EGPH, as you pass over the Rwy 06 LOC (ident=IVG), while flying the rwy 24 (ident ITH) ILS, the navradio switches to the 06/IVG LOC - but we're still using the ITH GS. What I've done is adjust the navradio to handle this case (mismatched LOC and GS) sanely, and hence avoid the bizarre angles being generated. The CDI needle still jumps when the LOC switches, but since it jumps onto the back course lobe, that's much more tolerable. As ever, please test and let me know what you think. All of this is short-term fixes until we properly model active/inactive ILS installations; which I'm going to be working on 'soon'. Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS (was: Glideslope bugs/improvements)
On 09/15/09 06:31, Curtis Olson wrote: I believe the original intent was to make the system function in away that made it appear that whatever approach you were trying to fly was the one that was turned on. We agree that was the original intent. However it was doomed from the start, because navradio.cxx has never had any workable way of divining which approach you were trying to fly. So biasing the choice based on which approach you are most likely to be flying seems to make some sense. You don't care about aircraft heading because (I don't know) maybe you do a 180 because you get lost or you want to fly back and start over again, or whatever. The active glideslope dme ils transmitters should change when you turn away from the airport. The important thing is which end of the runway you are off of. We agree that basing it on heading doesn't work, because you might be approaching the airport from upwind and need to make a 180 to get established on the final approach course. But basing it on position doesn't work either, and is arguably worse, because a) You might be approaching the airport from upwind, and b) more importantly, you might need to fly the missed approach segment. Missed approaches are a matter of life and death in the real world. As the saying goes, if you are not prepared for the miss, you are not prepared for the approach. I think we can concede that we don't have real world controllers turning approaches and lighting on and off for us on the ground. That's not the right question to be asking. There are ways of achieving acceptable verisimilitude without having to hire actual real-world certified tower controllers. FGFS already solves problems that are vastly more complicated than reversible ILSs. So either we create an elaborate system and force the user to make all these detailed choices every time we start up the sim, or we create some functional defaults that behave like people would expect, and allow people to easily use the simulation to practice flying any published approach. No, those are not the only options. No, a workable system does not have to be elaborate. No, we do not need to force ordinary users to do anything at startup. I think it's pretty important to be able to fire up FlightGear and practice any published approach without needing to go through contortions or elaborate setup proceedures, Agreed. Right now *none* of the reversible ILSs are flyable, because of the aforementioned unrealistic behavior when approaching from upwind, and wildly unrealistic behavior on the missed approach segment. or having to repeatedly restart the sim until the particular approach we are interested randomly is enabled. Flying an ILS with a tailwind and then following the published circle-to-land procedure is not unreasonable. Indeed it is a good thing to practice. In the real world you cannot just show up at KJFK and demand that they turn on the ILS you are interested in. It is realistic to choose what airport you are interested in flying to. It is not realistic to dictate that the approach in use will be the one you are interested in. Glendower: I can call spirits from the vasty deep. Hotspur:Why, so can I, or so can any man; But will they come when you do call for them? FlightGear is used as part of FAA certified flight training devices so this is an area of the code where the basics need to work and be solid, and then if we want to get fancy and add additional realism, that's great. There is a lot of room for compromise between fancy and wrong. Right now it is wrong, as has been pointed out repeatedly over the years. It can be improved quite a bit without getting fancy. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
Curtis Olson wrote: I think we can concede that we don't have real world controllers turning approaches and lighting on and off for us on the ground. So either we create an elaborate system and force the user to make all these detailed choices every time we start up the sim, or we create some functional defaults that behave like people would expect, and allow people to easily use the simulation to practice flying any published approach. I think it's perfectly fine to have an unrealistic 'dummy' mode for those who don't care but setting such behaviour into stone by hard-coding it into the implementation of a navaid reciever is probably not qualifying for extremely clever design in the long run. A reasonable compromise would be having a radio that works as in real life, accompagnied by a separate routine - which allows to be manually disabled or overridden by a real world controller - to implement the desired dummy mode. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
On 15 Sep 2009, at 16:28, Martin Spott wrote: I think it's perfectly fine to have an unrealistic 'dummy' mode for those who don't care but setting such behaviour into stone by hard-coding it into the implementation of a navaid reciever is probably not qualifying for extremely clever design in the long run. A reasonable compromise would be having a radio that works as in real life, accompagnied by a separate routine - which allows to be manually disabled or overridden by a real world controller - to implement the desired dummy mode. I agree with Martin here - I think we need more accurate behaviour here, but it's easy to keep the current behaviour as an option, controlled by a flag - something I've been considering for a while anyway - eg /sim/realism prop. Possibly the same could apply to the false GS and LOC lobes. In 'non'-realistic mode, we'd keep the current behaviour, with all ILSs enabled, though I will add a cap on the code to stop the navid changing below a certain altitude (or some similar kind of test), so that we don't observe the current flicking from one transmitter to another at 100ft above the runway. Once that's done, I don't think anyone can object to providing more realistic behaviour. The only debate then is the default value of /sim/realism :) Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
James Turner wrote: I agree with Martin here - I think we need more accurate behaviour here, but it's easy to keep the current behaviour as an option, controlled by a flag - something I've been considering for a while anyway - eg /sim/realism prop. Possibly the same could apply to the false GS and LOC lobes. as well as runway lightning and probably a few more 'gimmicks' which depend on the active runway. Last but not least this would allow to have/create/add a general interface onto which to hook different methods to define the active runway (driven by wind direction, randomly, by manual operator, whatever) and let all dependent gimmicks to behave accordingly, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Linking newest FG/SimGear Link Errors in newly added file SGText.cpp
I am linking the latest versions of FG/Simgear and I got 3 unresolved external symbols: FGGyro.cpp, AIGroundVehicle.cpp, and SGText.cpp. The SGText error message is: 4simgear_d.lib(SGReaderWriterXML.obj) : error LNK2019: unresolved external symbol public: static class osg::Node * __cdecl SGText::appendText(class SGPropertyNode const *,class SGPropertyNode *,class osgDB::ReaderWriter::Options const *) (?appendt...@sgtext@@sapavn...@osg@@PBVSGPropertyNode@@p...@pbvoptions@readerwri...@osgdb@@@Z) referenced in function __catch$?sgLoad3DModel_internal@@yapavn...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pbvopti...@readerwriter@osgDB@@PAVSGPropertyNode@@@Z$0 Vivian said that these 3 files were recently added but I needed to include them in the projects. So I opened project FlightGear and clicked on Lib_JSBSim, models, flight_control and added existing items FGGyro.cpp/hxx. Then I clicked on Lib_AIModel and added existing items AIGroundVehicle.cpp/hxx. Then I clicked on SimGear, Lib_sgmodel and added existing items SGText.cpp/hxx. The 3 error messages went away but then I get 33 unresolved external references when linking fgviewer, all involving SGText. I think it has something to do with OSG, but I have OpenSceneGraph\lib under Linker-Additional Library Directories. (I left out some of the messages because this email would otherwise be too large to send). Thanks, Randy Green 8-- Build started: Project: fgviewer, Configuration: Debug Win32 -- 8Linking... 8LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library 8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall osgText::TextBase::update(void) (__imp_?upd...@textbase@osgText@@QAEXXZ) referenced in function private: virtual void __thiscall SGText::UpdateCallback::operator()(class osg::Node *,class osg::NodeVisitor *) (??rupdatecallb...@sgtext@@eaexpavn...@osg@@pavnodevisi...@3@@Z) 8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall osgText::TextBase::setText(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?sett...@textbase@osgText@@qaexabv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) referenced in function private: virtual void __thiscall SGText::UpdateCallback::operator()(class osg::Node *,class osg::NodeVisitor *) (??rupdatecallb...@sgtext@@eaexpavn...@osg@@pavnodevisi...@3@@Z) 8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall osgText::String::createUTF8EncodedString(void)const (__imp_?createutf8encodedstr...@string@osgText@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@XZ) referenced in function private: virtual void __thiscall SGText::UpdateCallback::operator()(class osg::Node *,class osg::NodeVisitor *) (??rupdatecallb...@sgtext@@eaexpavn...@osg@@pavnodevisi...@3@@Z) 8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: class osgText::String __thiscall osgText::TextBase::getText(void) (__imp_?gett...@textbase@osgText@@qaeaavstr...@2@XZ) referenced in function private: virtual void __thiscall SGText::UpdateCallback::operator()(class osg::Node *,class osg::NodeVisitor *) (??rupdatecallb...@sgtext@@eaexpavn...@osg@@pavnodevisi...@3@@Z) 8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall osgText::TextBase::setMaximumHeight(float) (__imp_?setmaximumhei...@textbase@osgText@@qa...@z) referenced in function public: static class osg::Node * __cdecl SGText::appendText(class SGPropertyNode const *,class SGPropertyNode *,class osgDB::ReaderWriter::Options const *) (?appendt...@sgtext@@sapavn...@osg@@PBVSGPropertyNode@@p...@pbvoptions@readerwri...@osgdb@@@Z) 8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall osgText::TextBase::setMaximumWidth(float) (__imp_?setmaximumwi...@textbase@osgText@@qa...@z) referenced in function public: static class osg::Node * __cdecl SGText::appendText(class SGPropertyNode const *,class SGPropertyNode *,class osgDB::ReaderWriter::Options const *) (?appendt...@sgtext@@sapavn...@osg@@PBVSGPropertyNode@@p...@pbvoptions@readerwri...@osgdb@@@Z) 8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall osgText::TextBase::setLayout(enum osgText::TextBase::Layout) (__imp_?setlay...@textbase@osgText@@qaexw4lay...@12@@Z) referenced in function public: static class osg::Node * __cdecl SGText::appendText(class SGPropertyNode const *,class SGPropertyNode *,class osgDB::ReaderWriter::Options
Re: [Flightgear-devel] Linking newest FG/SimGear Link Errors in newlyadded file SGText.cpp
Randy,
You don't need fgviewer for normal operation of FG. Just uncheck it in the
Configuration Manager.
Vivian
-Original Message-
From: Randall Green [mailto:randall.gr...@wright.edu]
Sent: 15 September 2009 18:29
To: FlightGear developers discussions
Subject: [Flightgear-devel] Linking newest FG/SimGear Link Errors in
newlyadded file SGText.cpp
I am linking the latest versions of FG/Simgear and I got 3 unresolved
external symbols:
FGGyro.cpp, AIGroundVehicle.cpp, and SGText.cpp. The SGText error message
is:
4simgear_d.lib(SGReaderWriterXML.obj) : error LNK2019: unresolved
external symbol public: static class osg::Node * __cdecl
SGText::appendText(class SGPropertyNode const *,class SGPropertyNode *,class
osgDB::ReaderWriter::Options const *)
(?appendt...@sgtext@@sapavn...@osg@@PBVSGPropertyNode@@p...@pbvoptions@Reade
rwri...@osgdb@@@Z) referenced in function
https://webmail.wright.edu/uwc/webmail/java_script:main.compose('new',%20't
=__catch$sgLoad3DModel_internal@@yapavn...@osg@@abv?$basic_str...@du?$char_
tra...@d@std@@v?$alloca...@d@2@@std@@pbvopti...@readerwriter@osgDB@@PAVSGPro
pertyNode@@@Z$0')
__catch$?sgLoad3DModel_internal@@yapavn...@osg@@abv?$basic_str...@du?$char_t
ra...@d@std@@v?$alloca...@d@2@@std@@pbvopti...@readerwriter@osgDB@@PAVSGProp
ertyNode@@@Z$0
Vivian said that these 3 files were
recently added but I needed to include them in the projects. So I opened
project
FlightGear and clicked on Lib_JSBSim, models, flight_control and added
existing items
FGGyro.cpp/hxx. Then I clicked on Lib_AIModel and added existing items
AIGroundVehicle.cpp/hxx. Then I clicked on SimGear, Lib_sgmodel and added
existing items SGText.cpp/hxx. The 3 error messages went away but then I get
33
unresolved external references when linking fgviewer, all involving SGText.
I think it
has something to do with OSG, but I have OpenSceneGraph\lib under
Linker-Additional
Library Directories. (I left out some of the messages because this email
would otherwise be
too large to send).
Thanks,
Randy Green
8-- Build started: Project: fgviewer, Configuration: Debug Win32 --
8Linking...
8LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other
libs; use /NODEFAULTLIB:library
8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol
__declspec(dllimport) public: void __thiscall
osgText::TextBase::update(void) (__imp_?upd...@textbase@osgText@@QAEXXZ)
referenced in function private: virtual void __thiscall
SGText::UpdateCallback::operator()(class osg::Node *,class osg::NodeVisitor
*) (??rupdatecallb...@sgtext@@eaexpavn...@osg@@pavnodevisi...@3@@Z)
8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol
__declspec(dllimport) public: void __thiscall
osgText::TextBase::setText(class std::basic_stringchar,struct
std::char_traitschar,class std::allocatorchar const )
(__imp_?sett...@textbase@osgText@@qaexabv?$basic_str...@du?$char_traits@d...@st
d@@v?$alloca...@d@2@@std@@@Z) referenced in function private: virtual void
__thiscall SGText::UpdateCallback::operator()(class osg::Node *,class
osg::NodeVisitor *)
(??rupdatecallb...@sgtext@@eaexpavn...@osg@@pavnodevisi...@3@@Z)
8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol
__declspec(dllimport) public: class std::basic_stringchar,struct
std::char_traitschar,class std::allocatorchar __thiscall
osgText::String::createUTF8EncodedString(void)const
(__imp_?createutf8encodedstr...@string@osgText@@qbe?av?$basic_str...@du?$cha
r_tra...@d@std@@v?$alloca...@d@2@@std@@XZ) referenced in function private:
virtual void __thiscall SGText::UpdateCallback::operator()(class osg::Node
*,class osg::NodeVisitor *)
(??rupdatecallb...@sgtext@@eaexpavn...@osg@@pavnodevisi...@3@@Z)
8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol
__declspec(dllimport) public: class osgText::String __thiscall
osgText::TextBase::getText(void)
(__imp_?gett...@textbase@osgText@@qaeaavstr...@2@XZ) referenced in function
private: virtual void __thiscall SGText::UpdateCallback::operator()(class
osg::Node *,class osg::NodeVisitor *)
(??rupdatecallb...@sgtext@@eaexpavn...@osg@@pavnodevisi...@3@@Z)
8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol
__declspec(dllimport) public: void __thiscall
osgText::TextBase::setMaximumHeight(float)
(__imp_?setmaximumhei...@textbase@osgText@@qa...@z) referenced in function
public: static class osg::Node * __cdecl SGText::appendText(class
SGPropertyNode const *,class SGPropertyNode *,class
osgDB::ReaderWriter::Options const *)
(?appendt...@sgtext@@sapavn...@osg@@PBVSGPropertyNode@@p...@pbvoptions@Reade
rwri...@osgdb@@@Z)
8simgear_d.lib(SGText.obj) : error LNK2019: unresolved external symbol
__declspec(dllimport) public: void __thiscall
osgText::TextBase::setMaximumWidth(float)
(__imp_?setmaximumwi...@textbase@osgText@@qa...@z) referenced in function
public: static class osg::Node * __cdecl SGText::appendText(class
Re: [Flightgear-devel] nontrivial external situations (was: Glideslope bugs/improvements)
I am confused... what the heck is a reversible ILS?
In 25 years as an instrument pilot and over 20 as an instrument
instructor--I've never of such a thing. Localizer beams are not
reversible. They are horizontally polarized, but not reversible.
Reference the FAA Instrument Flying Handbook, at this link:
http://www.faa.gov/library/manuals/aviation/instrument_flying_handbook/
Check out Chapter 7, pages 7-37 thru 7-39, but let me summarize here...
The localizer antenna for a given runway is located some distance
('x') off the *departure* end of that runway. This distance, x, is
determined by the length of the runway, so that the width of the
localizer beam (which is usually 5-degrees) is 700 feet at the
approach end of the runway. But the important thing to remember here
is that the beam is also directed out the other end of the
runway...along the departure path. There's a diagram on page 7-38 that
shows this. While I admit that I haven't read each and every post in
this thread, I have read enough to see that the importance of this may
not be appreciated by all in this discussion.
In a nutshell--an ILS approach is a *precision* approach, meaning
there is lateral guidance from the localizer (LOC), as well as
vertical guidance from the glideslope (GS), and various approach
lights that are integral to the approach. Without *any* component,
then the ILS approach is no longer do-able, technically speaking. But
an aircraft using the other end of the runway can still use the same
localizer--they would see reverse sensing on the indicator needle in
their cockpit (unless an HSI was used, and then the device could be
adjusted so that it would always be normal sensing).
As an example, let's say an aircraft is 5 miles out on the ILS RWY 36
approach at Oshkosh Wisconsin. With the NAV receiver tuned to 110.5
MHz, the pilot would fly to the needle and track the localizer
inbound. When they reached the GS intercept point, they could start
down, but let's say they ignored the GS and remained level at 2000
feet AGL. As the aircraft got closer closer to the approach end of
runway 36, the needle on their indicator would be more more
sensitive (as the beam is getting narrower and narrower), until the
aircraft flew reached the LOC antenna, located approximately 1000 feet
past the *departure* end of the runway, in most cases. But at that
point, the signal persists--nothing happens other than the indicator
in the cockpit indicates reverse sensing, because of the horizontal
polarization inherent to the LOC signal. So the pilot simply uses
reverse sensing, and now flies the needle to the ball, instead of
the ball to the needle, as on the front course. This reverse-sensing
area on the backside of the LOC antenna is known as the back
course, while the signal directed from the LOC antenna back towards
the approach end of the runway is known as the front course.
So where this concept of switching off an ILS transmitter in the tower
came from, I don't know. I can assure you that in many years of flying
IFR--I never had this happen. There were many times I flew into KOSH
IFR after the tower was closed for the night--and ALL approach
transmitters were active. When there is no wind, you're free to use
whichever instrument approach you see fit, as YOU are the expert at
that point. If the tower is open and there are certified meteorlogic
observers on site...then you use the approach they tell you, or you
request a different approach. If they can, they'll give it to you
(depending upon traffic conditions). But they don't have to turn it on
or off--that just doesn't happen as far as I know.
I hope this long-winded post has helped to clarify some of the
misconceptions that seem to be flying around here in this thread.
Maybe I have entirely missed the point here, and if so then I
apologize. But there is simply no on/off switch for an ILS that is
activated by the tower--at least none that I've ever seen. Maybe they
have the capability to turn the transmitter on or off from the tower--
but I have never seen them do this. In fact, all of the times I've
seen the LOC go down for maintenance, a ground maintenance vehicle has
to go out to the transmitter shack and turn the LOC off. But each LOC
on an airfield has it's own frequency, and you simply tune your NAV
receiver to it to use that particular approach. In my previous
example, you could in fact shoot a LOC BC (back course) approach for
RWY 18, simply by using the localizer frequency for the RWY 36
approach and using the published procedure for the LOC BC RWY 18...if
there was one. Or you could tune to a *different* LOC frequency and
shoot a front course ILS RWY 18 approach--if that was a published
option at that particular airport. In that case there would be two
localizers on that particular runway--one for the front course of
either runway (18 or 36). This would
Re: [Flightgear-devel] nontrivial external situations (was: Glideslope bugs/improvements)
On 15 Sep 2009, at 22:59, Thomas Betka wrote: But each LOC on an airfield has it's own frequency This is where the problems start: http://www.nats-uk.ead-it.com/aip/current/ad/EGPH/EG_AD_2_EGPH_2-1_en.pdf IVG and ITH share the same frequency - 108.9Mhz, and there's some circuit/switch/etc in the tower to activate one DME/LOC/GS trio or the other. Aside from that, I think everything you said was correct - as ever, I am not a pilot. The good news is, I think I've come up with a more consistent heuristic (to make Curt happy!) than the current one. Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nontrivial external situations (was: Glideslope bugs/improvements)
While my aviation expertise does not include foreign approach plates, there should be some degree of standard between designations world- wide. Thus I believe those are the designators of either the actual marker beacons, just off the runway...not the LOC itself. From what I can tell, there is only *one* LOC there. Check out this PDF: http://myweb.tiscali.co.uk/egpfgla/airportinfo/editaxi.pdf That small symbol I think you are referencing in the PDF you linked, is indicating the location of the DME transmitter, and the frequency it is associated with (a LOC, in this case). DME transmitters co- transmit on the NAV frequency, so you tune the DME simply by tuning the VOR/LOC frequency in your NAV radio. Now look at this approach plate: http://www.nats-uk.ead-it.com/aip/current/ad/EGPH/EG_AD_2_EGPH_8-6_en.pdf The localizer for runway 24 has the frequency you referenced (108.90), and thus the DME is located on-field and is required for use on the approach, per the name ILS/DME/NDB. Also, the fact that the small symbol is located to the side of the runway indicates that this is NOT an ILS approach...as a precision approach could not have a localizer misaligned with the runway centerline. So to your point--YES, the I-VG I-TH share the same frequencies-- but those are not different localizers. There is only one localizer pictured there, and it's frequency is 108.90. Rather I think those symbols are actually marker beacons at either end of the runway, as shown on the PDF that linked to in your response (just off either end of the runway). TB On Sep 15, 2009, at 5:11 PM, James Turner wrote: On 15 Sep 2009, at 22:59, Thomas Betka wrote: But each LOC on an airfield has it's own frequency This is where the problems start: http://www.nats-uk.ead-it.com/aip/current/ad/EGPH/EG_AD_2_EGPH_2-1_en.pdf IVG and ITH share the same frequency - 108.9Mhz, and there's some circuit/switch/etc in the tower to activate one DME/LOC/GS trio or the other. Aside from that, I think everything you said was correct - as ever, I am not a pilot. The good news is, I think I've come up with a more consistent heuristic (to make Curt happy!) than the current one. Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nontrivial external situations (was: Glideslope bugs/improvements)
Actually those are DMEs. Look at the approach plate I referenced in the email I just sent--I just noticed something I missed...this statement: Procedure not available without DME I-TH or radar It's in the text box towards the top of the plate. I missed this, because it's generally *not* done like this in the US...DME located just off the end of the runways. But it makes perfect sense--put a DME right off the departure end of the runway to give you a perfect reference for distance on the approach. Many times in the US, a DME will be located on the field, but not usually with the localizer (as it appears these might be.) So those are not two localizers--they are DMEs. One (I-TH) would be for the ILS/DME/NDB RWY 24 approach, while the other would be for the approach for RWY 6. Check out this plate: http://www.nats-uk.ead-it.com/aip/current/ad/EGPH/EG_AD_2_EGPH_8-1_en.pdf ...for the ILS/DME RWY 06. Note the I-VG DME associated with the 108.90 MHz LOC frequency on that plate. Sorry for two posts so quickly--I haven't used this stuff in a few years, so I'm a bit rusty...and of course the nomenclature is slight different than that on US approach plates. TB On Sep 15, 2009, at 5:11 PM, James Turner wrote: On 15 Sep 2009, at 22:59, Thomas Betka wrote: But each LOC on an airfield has it's own frequency This is where the problems start: http://www.nats-uk.ead-it.com/aip/current/ad/EGPH/EG_AD_2_EGPH_2-1_en.pdf IVG and ITH share the same frequency - 108.9Mhz, and there's some circuit/switch/etc in the tower to activate one DME/LOC/GS trio or the other. Aside from that, I think everything you said was correct - as ever, I am not a pilot. The good news is, I think I've come up with a more consistent heuristic (to make Curt happy!) than the current one. Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS (was: nontrivial external situations)
Hi Folks -- Of the 3050 ILSs in section four of my copy of nav.dat, 404 of them, i.e. more than 13% of them, are reversible. That's 202 pairs, if you want to count by pairs. -- In all such pairs, both ends use the same frequency. -- In all such pairs, the two ends have different IDENT codes. -- In all such pairs, the localizers face in opposite directions. -- In all such pairs, with two dubious exceptions, the localizers are documented to be more than 1km apart. Here are a few examples Airport freqLOC-LOC distance EGPH: IVG 06 == ITH 24 (108.90) 1.817 nm KJFK: IHIQ 04L == IIWY 22L (110.90) 1.646 nm KJFK: ITLK 13L == IRTH 31R (111.50) 1.953 nm KLAX: IGPE 06R == IHQB 24L (111.70) 2.044 nm KLAX: IUWU 06L == IOSS 24R (108.50) 2.099 nm KLAX: IMKZ 07R == ILAX 25L (109.90) 2.270 nm KLAX: IIAS 07L == ICFN 25R (111.10) 2.263 nm KPHL: IPHL 09R == IGLC 27L (109.30) 2.065 nm KPHL: IVII 09L == IPDP 27R (108.95) 1.898 nm The whole list can be found at http://www.av8n.com/fly/reversible.txt There are several reasons why the two ends of such a pair must be considered _different_ ILSs, and cannot be operated simultaneously: 1) First of all, you have to ask where the localizer transmitter sits. The rule is that they sit a little ways beyond the departure end of the runway. If you tried to use a transmitter at the departure end of runway 6 to serve approaches to runway 24, the LOC course width would go to zero long before you reached the threshold of runway 24. There is no way this would go unnoticed. Also, locating the localizer transmitter at mid-field is out of the question. 2) Secondly, if you tried to serve two reciprocal runways with the same localizer, one or the other of them would be reverse sensing. There is no way this would go unnoticed. 3) If you tried to operate two transmitters at the same time, they would interfere. In particular, the outbound (missed approach) segment of one would ruin the inbound (final) segment of the other. Also there would be no way to make sense of the IDENT. And FWIW, I have experienced this first-hand. Sometimes a student is capable of forming an unshakable expectation that he will be using runway 6 right. He has the approach plate already out. He listens to the ATIS, but ignores the part about landing and departing runway two seven left. He IDENTifies the ILS, hears some code, and assumes it is the right code, even though it's not. I tell him to double-check the IDENT, whereupon he double-checks the frequency, and sure enough the frequency is right. He has a real hard time getting established on the localizer, because it is reverse sensing ... not to mention various other problems. I explain to the long-suffering controller that my student got out the wrong approach plate, and we need to go hold somewhere and sort things out. The student overhears this, and still doesn't understand what went wrong, because he is absolutely sure that there is no such thing as a reversible ILS. In contrast, a skillful instrument pilot does not really need to know or care about reversible ILSs, because the wording of the ATIS and the wording of the clearance suffice to tell him which approach plate to use. I remark that section 4-7-13 of FAA 7110.65P, which specifies the duties of air traffic controllers, briefly mentions some procedures for Switching ILS/MLS Runways. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
On 09/15/09 20:17, I wrote: Of the 3050 ILSs in section four of my copy of nav.dat, 404 of them, i.e. more than 13% of them, are reversible. FWIW if we restrict attention to US airports, i.e. having ICAO identifiers of the form K..., then 276 of the ILSs are reversible i.e. more than 23% of the 1172 total ILSs. That's 138 pairs if you want to count by pairs. The higher percentage stands to reason, given the high density of airports and air traffic in the US, and the paucity of available ILS frequencies. Bottom line: These critters are not rare. Getting FGFS to handle them properly is worth a bit of effort. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS (was: nontrivial external situations)
Well, then indeed...you're going to have to implement a textbox-style warning to the user that there may be a potential conflict at those airports. You're correct about there being an issue with making the back-course reverse sensing, when the published approach plates indicate that it shouldn't be. That would be a problem. But remember that precision approaches need to have a specified LOC width at the approach end of a runway--thus the LOC antennas are located off the departure end of the runway the required distance (as practical) to fulfill that requirement. Of course the LOC beam width can be adjusted to accommodate this, to some degree. That begs another question then though--is this accounted for in FG at present? I haven't tested it, but maybe John has. I still think an acceptable solution is to hit the user with a textbox message, advising them of the potential conflict. While Elite has apparently gone away from having it on the pilot's screen (and thus interrupting program execution) in their current software, the new improved way provides for the feature on the instructor's screen in the enterprise-level software. But I don't see how you'll get around program interruption in the case when the pilot is using the software independently--who else is going to make the choice? And as for an automatic choice, based upon aircraft position, heading, or bearing from the station--this will be problematic as John mentioned. Pilot's are often required to tune NAV frequencies well before arriving at the initial approach fix (often the outer marker), and thus there's no way sufficient generalizations can safely be made regarding the approach they intend to use. For example, suppose an aircraft is approaching an airport from the south, but needs to use the ILS RWY 18. If RWY 36 uses a reversible ILS (weird term, and I still don't think I've ever heard it before...) and they tune to that frequency, then the only way for them to know which approach they were actually tuned in to would be the morse identifier (as John suggested). So John, are these 202 runways world-wide (I saw EGPH on the list, but the rest were in the US); and do you know if all of the ILS approaches on those runways are currently supported in FG? I suppose you could just fail to support the ILS for one half of those runways, although it wouldn't be a very popular decision with the users I'll bet. So if you must support the approach and cannot employ sufficient logic to make decisions as to which runway to (automatically) select when one of those frequencies is selected--then about the only option you have left is to ask the pilot which runway they intend to use... It might just be crazy enough to work. TB On Sep 15, 2009, at 10:17 PM, John Denker wrote: Hi Folks -- Of the 3050 ILSs in section four of my copy of nav.dat, 404 of them, i.e. more than 13% of them, are reversible. That's 202 pairs, if you want to count by pairs. -- In all such pairs, both ends use the same frequency. -- In all such pairs, the two ends have different IDENT codes. -- In all such pairs, the localizers face in opposite directions. -- In all such pairs, with two dubious exceptions, the localizers are documented to be more than 1km apart. Here are a few examples Airport freqLOC-LOC distance EGPH: IVG 06 == ITH 24 (108.90) 1.817 nm KJFK: IHIQ 04L == IIWY 22L (110.90) 1.646 nm KJFK: ITLK 13L == IRTH 31R (111.50) 1.953 nm KLAX: IGPE 06R == IHQB 24L (111.70) 2.044 nm KLAX: IUWU 06L == IOSS 24R (108.50) 2.099 nm KLAX: IMKZ 07R == ILAX 25L (109.90) 2.270 nm KLAX: IIAS 07L == ICFN 25R (111.10) 2.263 nm KPHL: IPHL 09R == IGLC 27L (109.30) 2.065 nm KPHL: IVII 09L == IPDP 27R (108.95) 1.898 nm The whole list can be found at http://www.av8n.com/fly/reversible.txt There are several reasons why the two ends of such a pair must be considered _different_ ILSs, and cannot be operated simultaneously: 1) First of all, you have to ask where the localizer transmitter sits. The rule is that they sit a little ways beyond the departure end of the runway. If you tried to use a transmitter at the departure end of runway 6 to serve approaches to runway 24, the LOC course width would go to zero long before you reached the threshold of runway 24. There is no way this would go unnoticed. Also, locating the localizer transmitter at mid-field is out of the question. 2) Secondly, if you tried to serve two reciprocal runways with the same localizer, one or the other of them would be reverse sensing. There is no way this would go unnoticed. 3) If you tried to operate two transmitters at the same time, they would interfere. In particular, the outbound (missed approach) segment of one would ruin the inbound (final) segment of the other. Also there would be no way to make
Re: [Flightgear-devel] reversible ILS
Well, right. They are apparently a lot more common than I gave them credit for--but it does seem that they tend to be at airports one doesn't frequent with a 172. But as many FG users are flying airline- style aircraft (and thus likely using these airports), it does become relevant. And the other problem is that if you've made the decision to support all of these approaches with NAVAIDS in Flightgear, then you've already made the decision to do it right--because these runways will all have published approach procedures that the users will have access to. Thus you cannot require them to follow some alternate procedure without published documentation. So even if there are only 10 such instances, you're pretty much stuck doing it correctly. I do agree with JD in that respect. TB On Sep 15, 2009, at 10:50 PM, John Denker wrote: On 09/15/09 20:17, I wrote: Of the 3050 ILSs in section four of my copy of nav.dat, 404 of them, i.e. more than 13% of them, are reversible. FWIW if we restrict attention to US airports, i.e. having ICAO identifiers of the form K..., then 276 of the ILSs are reversible i.e. more than 23% of the 1172 total ILSs. That's 138 pairs if you want to count by pairs. The higher percentage stands to reason, given the high density of airports and air traffic in the US, and the paucity of available ILS frequencies. Bottom line: These critters are not rare. Getting FGFS to handle them properly is worth a bit of effort. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
On 09/15/09 20:53, Thomas Betka wrote: Of course the LOC beam width can be adjusted to accommodate this, to some degree. Not to a sufficient degree if/when the localizer is at the wrong end of the runway. The localizer course width necessarily goes to zero at the antenna. There is no way around this. This adds to the excitement of back-course approaches. That begs another question then though--is this accounted for in FG at present? The last time I touched the code, reversible ILSs were working fine ... both ways ... except for the switching logic, which failed utterly for missed approaches, for arrivals from upwind, et cetera. I still think an acceptable solution is to hit the user with a textbox message, advising them of the potential conflict. I don't recommend that. Unrequested popups are near the nadir of bad user-interface design ... especially when, as in this case, they might confront a naive user who doesn't know what they mean. And as for an automatic choice, based upon aircraft position, heading, or bearing from the station--this will be problematic as John mentioned. Pilot's are often required to tune NAV frequencies well before arriving at the initial approach fix (often the outer marker), and thus there's no way sufficient generalizations can safely be made regarding the approach they intend to use. Agreed. There is no way that automatic switching based on aircraft position and/or heading will ever be acceptable. In real life, the active runway is changed when the wind requires it. Making the change at a busy airport is a big deal, since one way or another you have to make sure nobody is on final to the old runway. It's even trickier if the airport doesn't have a tower. So John, are these 202 runways world-wide (I saw EGPH on the list, but the rest were in the US); and do you know if all of the ILS approaches on those runways are currently supported in FG? There are 276 out of 1172 at US K... airports. There are 96 out of 431 at UK E... airports. There are 404 out of 3050 worldwide. I suppose you could just fail to support the ILS for one half of those runways, although it wouldn't be a very popular decision with the users I'll bet. There's no need for that. The simplest approach might be: 0) For naive users, and even experienced VFR users, they don't know and don't care about this issue, and everybody would like to keep it that way. 1) At startup, we shall set every reversible ILS to the higher-numbered end (19 through 36 inclusive). We choose this end because most users live in the temperate zones where the prevailing westerlies prevail most of the time. (I retract my earlier suggestion about initializing them randomly.) 2) There shall be a menu item, which appears when commanded by the user -- *not spontaneously* -- and can be used to reverse the nearby reversible ILS(s). Perhaps an array of buttons listing the nearest 10 airports with reversible ILSs or some such. And maybe a textbox to allow reversing an arbitrary airport or an arbitrary frequency. This should suffice for single-player FGFS. This would most likely only be used by instrument-rated pilots, or instrument students, so we can assume they have enough sophistication and dedication to deal with such a popup. We need some kind of switching, because the ILS is most needed when the weather is very bad, and that usually means the wind is *not* from the prevailing fair-weather direction. 3) Multiplayer is quite a bit trickier, as previously discussed. This is related to MP ATIS, MP lights, pilot-controlled lights, navaid IDENT, et cetera. This will have to be discussed quite a bit more before anybody starts coding it. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
On Tue, 2009-09-15 at 22:01 -0700, John Denker wrote: Can I also suggest, that like most things in FG, we have a property and a Nasal API. Now I haven't thought about this very much, but rather than forcing some UI into concrete, it might be better to provide a programmatic interface, then implement a default behaviour that can be overridden later, for example a ATC aircraft may wish to manipulate and control this at some point. * Nasal interface to lookup available ILS information (from nav.dat) - airportinfo() already gives us a list of runways and headings * some properties that can be changed to switch the ILS. Then someone else can make a Menu in Nasal that uses that above to achieve item 2 outlined below. Scott. There's no need for that. The simplest approach might be: 0) For naive users, and even experienced VFR users, they don't know and don't care about this issue, and everybody would like to keep it that way. 1) At startup, we shall set every reversible ILS to the higher-numbered end (19 through 36 inclusive). We choose this end because most users live in the temperate zones where the prevailing westerlies prevail most of the time. (I retract my earlier suggestion about initializing them randomly.) 2) There shall be a menu item, which appears when commanded by the user -- *not spontaneously* -- and can be used to reverse the nearby reversible ILS(s). Perhaps an array of buttons listing the nearest 10 airports with reversible ILSs or some such. And maybe a textbox to allow reversing an arbitrary airport or an arbitrary frequency. This should suffice for single-player FGFS. This would most likely only be used by instrument-rated pilots, or instrument students, so we can assume they have enough sophistication and dedication to deal with such a popup. We need some kind of switching, because the ILS is most needed when the weather is very bad, and that usually means the wind is *not* from the prevailing fair-weather direction. 3) Multiplayer is quite a bit trickier, as previously discussed. This is related to MP ATIS, MP lights, pilot-controlled lights, navaid IDENT, et cetera. This will have to be discussed quite a bit more before anybody starts coding it. ** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ** -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
