[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] 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] 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
