[Flightgear-devel] Bandwidth issues with mpserver07
Hello all, Since mpserver05 seems to be down, my server (07) has been receiving much more use. This has become a problem here on my home access. There are three of us in my home trying to use the internet in the evenings, for the most part. However when there are 10 or more people logged in to mpserver07, I am essentially relegated to dial-up speeds. I only have 10Mbps down, and 2Mbps up; and that's the fastest that my ISP will allow on a home network. It already costs my over $20 more per month for this, simply to have a static IP address assigned for the FG server. So at this point I don't have much choice other that to take mpserver07 down in the evenings when we need to have internet access. I can leave it run during the day when we aren't using the internet (8-5, US Central Time), but in the evenings and on weekends when we need to use the internet, it has simply become too much of a problem. Sorry for the bad news. TB -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
I am not exactly sure what you guys are talking about with the nut cracker reference, but the Oleo Strut the vertical assembly with compressed air (or Nitrogen) and hydraulic oil. There is a piston assembly and a metered orifice arrangement, allowing this assembly to act as a shock-absorbing device. The scissors assembly is a torque link, and helps dampen/resist torque moments imposed on the nose landing gear. AP school was a while ago for me, but generally speaking, I believe the torque link is considered a part of the entire Oleo assembly. TB On Dec 9, 2009, at 8:13 AM, Gene Buckle wrote: On Tue, 8 Dec 2009, dave perry wrote: On 12/01/2009 11:38 AM, John Denker wrote: On 12/01/2009 11:19 AM, Heiko Schulz wrote: To your note: So the c172p has now: -struts animation The reported bug http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-x1768 concerns the nutcracker, which as of 1 Dec 2009 looks quite weird because it doesn't fold; it just gets shoved rigidly up into the cowling. I just submitted a patch that animates the c172p nose gear nutcracker so it folds as the strut is compressed. It's called an oleo strut. :) g. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
A quick follow-up on my previous post... While researching this a bit more, I found a very interesting engineering document on the mechanics of landing gear systems: http://www.mecheng.adelaide.edu.au/~marjom01/Aeronautical%20Engineering%20Projects/2006/group11.pdf The PDF is just over 6mb in size, but well worth the download. There are very good descriptions of the mechanics involved with different gear systems--and included is some c172-specific information as well, in Chapter 8 (Page 38). The author also shows a calculation showing that a typical nose strut in a 172 compresses about 9.3 on landing. TB On Dec 9, 2009, at 9:02 AM, Thomas Betka wrote: I am not exactly sure what you guys are talking about with the nut cracker reference, but the Oleo Strut the vertical assembly with compressed air (or Nitrogen) and hydraulic oil. There is a piston assembly and a metered orifice arrangement, allowing this assembly to act as a shock-absorbing device. The scissors assembly is a torque link, and helps dampen/resist torque moments imposed on the nose landing gear. AP school was a while ago for me, but generally speaking, I believe the torque link is considered a part of the entire Oleo assembly. TB On Dec 9, 2009, at 8:13 AM, Gene Buckle wrote: On Tue, 8 Dec 2009, dave perry wrote: On 12/01/2009 11:38 AM, John Denker wrote: On 12/01/2009 11:19 AM, Heiko Schulz wrote: To your note: So the c172p has now: -struts animation The reported bug http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-x1768 concerns the nutcracker, which as of 1 Dec 2009 looks quite weird because it doesn't fold; it just gets shoved rigidly up into the cowling. I just submitted a patch that animates the c172p nose gear nutcracker so it folds as the strut is compressed. It's called an oleo strut. :) g. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] October $250 Flight Gear Developers
On Oct 6, 2009, at 3:19 AM, AJ MacLeod wrote: We understood and understand perfectly what you were trying to achieve, and having plenty of experience in the task knew that it was not only possible to achieve it with 3D instruments, but that it would be easier, quicker and more flexible. You're always welcome to ignore good advice and plod on doing things any sub-optimal way you please... but it's fairly bad manners to dismiss those who give that advice as uncomprehending idiots. AJ Yes, now there you go AJ...typical response that makes some folks on this developer's list so much fun to work with. I am sorry that you feel I've apparently dismissed you as an uncomprehending idiot. Are you? I've never heard that, and certainly did not and *would not* make that assumption. But were you in the IRC channels so many times when I was asking about reconfiguring a panel, only to have to answer question after question as to why I was wasting my time making a 2D panel? Hey, but everyone is entitled to their own opinion. But as for a 3D cockpit, I don't believe that the FAA is going to approve a product that requires the pilot (user) to have to pan around the cockpit (or a panel) using a mouse, while in the act of simulated flight. Are you flying an aircraft, or using a mouse? So suboptimal or not, as far as I (and several industry folks I know) can tell, that's what the FAA will approve; certainly not for a PC-based Advanced Aircraft Training Device. Oh, by the way: ...it would be easier, quicker and more flexible? LOL! Now who is dismissing whom as an uncomprehending idiot? TB -- 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] October $250 Flight Gear Developers
The project my company is working on will use FG v1.9.1 (with additions) to seek FAA Certification. But there are several things lacking in the production release--the instructor's station is the main thing. I haven't read the FAA Advisory Circular that governs certification of these things (PC-ATD's) in awhile, but I do not recall seeing a requirement for a GPS. But as I said, they have just changed the requirements, and I am not sure just where that leaves our effort. But for the record, our project is really *not* selling FG; as much as it selling an IFR training platform built on FG. For example, we really only plan on a couple aircraft right now. But we do plan to release scenario-based training content, as this will be the logical representation of the training product. But Curt is right that it takes an enormous amount of work to get this to the point where the FAA will evaluate it, and the software really is just the beginning. However the requirements are indeed published and if you make sure that your product meets or exceed these, then certification is pretty straightforward, as Curt mentioned. I want the developer community to know that, while there is proprietary code involved with bringing our product to the market, there will also be ample code contributed back to the FG development community--although I am not sure how much most users will find useful, quite honestly. Much of it will be related to driving flight controls. And up until the last 6-9 months, I really didn't hear many people even mention the IFR training opportunity that is being missed with FG; shoot, most people I talked to 1-2 years ago (when I was trying to learn how to modify the 2D panel in the 172) couldn't understand why I was even wasting my time by not going 3D! I have said this many times over the past 3-4 years--I have flown just about every PC-based flight simulation package that's been on the market in the past 15-20 years, and Flight Gear flies as well as any of them. The issue is functionality, at least in terms of training student instrument pilots. Develop that, and FG will have absolutely no problems earning FAA certification. By the way, our proposed timeline to make that application is within the next 6-9 months...with any luck. TB -- 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] New audio files for FG reciprocating aircraft
Hello all... With all the talk about FG audio here recently, it reminded me that I haven't yet gotten around to something I've wanted to do for some time--record some new audio files. I have access to a Piper Aztec, a light twin-engined aircraft. It's engines are six-cylinder Lycoming IO-540's, which are a bit larger than a 172's engine, but quite similar in some. But I also probably have access to smaller, single- engine aircraft such as a Piper Cub. I am not sure about turbine engine aircraft just yet, but that may be a possibility as well, as I have several contacts that might be able to help with that. I also have a Mac laptop with audio-recording software (Garage Band, Pro- Tools and Sonar for PC). In addition I have several professional dynamic and condenser microphones. The point is that I have the necessary tools to record some high-quality audio, and I have access to various aircraft to get the audio samples from. While I do not have a ton of time this fall, I do have some time that I can spend on this project. But I need to know what sorts of audio samples would be most valuable--certainly a list of *all* desired audio files would be nice; as this will allow me to categorize need and prioritize manpower to get as much done as soon as possible. So I am asking for some input from the developers, especially for things like: 1) Sources for audio samples: single vs twin; idle power vs various RPM settings; in-flight vs ground-obtained audio, propellor pitch variations, etc. 2) Any need for auxiliary samples such as: gear retraction/extension; flap extension/retraction; alarms (autopilot, NAV instruments, etc.) 3) Any support vehicle audio samples: aircraft tugs, firetrucks, snow- plows (plowing, for example), etc. My thought here is to build as comprehensive a list as possible as to just what samples are necessary, and then work on that list as the opportunities arise over the next year or so. With the weather in Wisconsin about to turn colder, I will probably not have enough time to get all desired samples (nor will I have the opportunity to do so). But as I am part owner of the Aztec, I can certainly get many samples of various things over the next 1-2 months. So your input is appreciated... TB -- 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 Sep 16, 2009, at 12:01 AM, John Denker wrote: 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. Well all I would say in response here, is that's why a LOC BC approach is *not* a precision approach. 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 will need to evaluate this more critically, I can see. I haven't tested an approach at one of these airports, but will try to do so this weekend, when I get all of the Elite hardware set up and driving FG. My new machines should be here in a couple of days, and I plan to get configured for testing this weekend. 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. Well, then I don't see how else you're going to accomplish the task of getting the user to declare their intentions--unless you do it at program start-up (ie; make them have the fore-thought to tell FG what they want to do at initialization). But this would prevent ad hoc approaches using the *other* ILS. 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. Then FG will have to make the determination of the active runway, and that's the way it is. If the user wants realism...well, it doesn't get much more realistic than that. 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 presume then for this statement, that FG currently supports all of these approaches? 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. If course not--I was being facetious, lol. 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. Well, I don't see that you even need to support this reversible ILS feature
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)
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)
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
[Flightgear-devel] Possible Multiplayer server
Hello all, With Jester's help, I have set up a server at my home in Wisconsin (US), for possible use as an Multiplayer server. I had to get a static IP from my ISP, and that took a few days. But as of today it is operational, and the IP address is: 98.100.234.6 (port 5000) What I would like to do is have some folks try the server over the next week or two, and give their feedback. I would also like to monitor how much it affects our normal household internet capabilities during this time. My ISP tells me that the maximum bandwidth for a cable modem is 15M down, and 2M up. So I am not sure how much of an impact this will have on our internet capabilities here in the house. With three people on the internet much of the time, I just want to test it on a smaller group before it gets synch'd with the rest of the mpservers--but if there are no issues, I intend to offer it for the general user group. So if I could get several folks to test this thing over the next 1-2 weeks and report the performance, it would be appreciated. As I am not online as much due to work-related issues, I have asked Jester to help administer the machine--so you can also contact him with questions or comments as well. Thanks! TB -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
