Re: [Flightgear-devel] Navaids radio propagation code almost production ready
Update: I've added new signal calculation for DME stations too. As explained detailed in the wiki, DME uses a very high frequency range, thus it is possible sometimes in reality to receive the VOR signal but not the DME signal. Screenshots provided in the wiki article. Also, TACAN reception is modelled now like the DME, since it uses basically the same frequency range. Unlike DME, I have not tested this yet, but should also work for AI/multiplayer tankers. All this disabled by default, of course. I have not updated the merge request with these features yet, waiting for the new radio to make it into 'next' since it's enough code there already. I have also added a Request for info chapter in the wiki page, asking anybody with deep knowledge of air navigation systems to contribute info on the discussion page. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On 27 Nov 2012, at 12:44, Adrian Musceac kanto...@gmail.com wrote: I have not updated the merge request with these features yet, waiting for the new radio to make it into 'next' since it's enough code there already. I have also added a Request for info chapter in the wiki page, asking anybody with deep knowledge of air navigation systems to contribute info on the discussion page. Gitorious was down this morning, or I would have already given some review comments. However I see quite a few new versions of the patch, it would be good to know it's 'ready' from your perspective, before reviewing. I too would prefer to merge smaller patches - I didn't yet see how big the current one is, since Gitorious is still being silly. James -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On Tuesday, November 27, 2012 14:53:07 James Turner wrote: Gitorious was down this morning, or I would have already given some review comments. However I see quite a few new versions of the patch, it would be good to know it's 'ready' from your perspective, before reviewing. I too would prefer to merge smaller patches - I didn't yet see how big the current one is, since Gitorious is still being silly. James Hi James, Thanks for reviewing the code. Gitorious is back for me now. The code is production ready and tested, I've just added some little fixes and improvements in the new versions, which don't affect stability on my system. I think it would be best to review and merge as disabled by default, and then allow users to test and find bugs. I can't do that properly alone. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Navaids radio propagation code almost production ready
Hi, I have added VOR, localizer and glideslope signal calculations for the old (classic) navradios (navradio.cxx) Now an ILS navaid is basically considered as two separate stations: Localizer and glideslope, as in reality. Both these stations can have separate parameters like transmitter power, antenna type etc. Tested ok on C172p, but I've seen other aircraft that fail to set the GS flag when the GS signal is lost and LOC signal still present. Localizer on backcourse has range about half the normal one, due to the antenna patterns. This still needs testing for realism, especially since I'm not very happy with the antenna patterns I'm using, and the transmitter powers may be well off for ILS (but are ok for VOR's, according to data I have). Merge request #1568 has been updated today to reflect the changes. The antenna pattern used everywhere should go into $FGDATA/Navaids/Antennas/ but I'm really not keen on placing a merge request for only one text file, so awaiting suggestions. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On 26 Nov 2012, at 17:11, Adrian Musceac kanto...@gmail.com wrote: I have added VOR, localizer and glideslope signal calculations for the old (classic) navradios (navradio.cxx) Now an ILS navaid is basically considered as two separate stations: Localizer and glideslope, as in reality. Both these stations can have separate parameters like transmitter power, antenna type etc. Tested ok on C172p, but I've seen other aircraft that fail to set the GS flag when the GS signal is lost and LOC signal still present. Localizer on backcourse has range about half the normal one, due to the antenna patterns. This still needs testing for realism, especially since I'm not very happy with the antenna patterns I'm using, and the transmitter powers may be well off for ILS (but are ok for VOR's, according to data I have). Merge request #1568 has been updated today to reflect the changes. The antenna pattern used everywhere should go into $FGDATA/Navaids/Antennas/ but I'm really not keen on placing a merge request for only one text file, so awaiting suggestions. I'll do a review if no-one beats me to it, but this definitely needs to be 'off-by-default' for the next release. We can add a checkbox to the realism dialog to enable it from the GUI, and give aircraft authors a chance to adapt. Well, that's my opinion at least. James -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On Monday, November 26, 2012 19:18:26 James Turner wrote: I'll do a review if no-one beats me to it, but this definitely needs to be 'off-by-default' for the next release. We can add a checkbox to the realism dialog to enable it from the GUI, and give aircraft authors a chance to adapt. Well, that's my opinion at least. James It's off by default of course. GUI checkbox would be a plus. Right now it's using command line properties. About aircraft authors needing to adapt, I've had a brief look between C172P which is ok, and C337 Skymaster which does not display the off flag for glideslope when LOC signal still present. It appears to be a case of not checking one property set by the glideslope code (old code, not new one). Aircraft authors basically should not have to worry about whether the new system is on or off, and just use the glideslope flag properties like it's used in C172p's panel. Again, this new code does nothing new to the logic of the navradios, except realistically computing whether a signal is present or not. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On Monday, November 26, 2012 19:18:26 James Turner wrote: I'll do a review if no-one beats me to it, but this definitely needs to be 'off-by-default' for the next release. We can add a checkbox to the realism dialog to enable it from the GUI, and give aircraft authors a chance to adapt. Well, that's my opinion at least. James Emilian pointed out to me that different aircraft can have different types of receivers and antennas for ILS equipment. Of course, if it is desirable, we can make a guideline regarding aircraft developers setting some properties somewhere according to a convention we make. Then we could use these inside the navradio code, so a 747-400 has different equipment behaviour than a Cessna. Also, I'd like to remind everyone who is interested in this that glideslope signals use a different (higher) range of frequencies than VOR/LOC, thus having totally different propagation characteristics, especially in hilly/mountainous terrain. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navaids update
Martin Spott a écrit : Salut Jean, jean pellotier wrote: Is nav.dat supposed to be updated from robin X-plane database? If nobody else is going to do that, I'll be updating the file from Robin's most current package during our pre-release phase (however this is going to be defined ). I see the update is done, thanks, (and sorry for windows users waiting for a compatible binary build :) ). It appears that Atlas don't like the new nav.dat.gz, and crash on start up, because some navaids contains empty field for the balise name (i guess it's the balise name). here's a diff where the missing fields are replaced with IXXX. may be the real name is available, but i didn't found the few i checked. and Atlas don't crash anymore. jano 12062c12062 4 47.49051500 -111.20608600 3526 10950 18 238.500 KGFA 21 ILS-cat-I --- 4 47.49051500 -111.20608600 3526 10950 18 238.500 IXXX KGFA 21 ILS-cat-I 12103c12103 4 38.85886700 -094.55694100 1090 10930 18 11.886 KGVW 01 ILS-cat-I --- 4 38.85886700 -094.55694100 1090 10930 18 11.886 IXXX KGVW 01 ILS-cat-I 12393c12393 4 46.5362 -087.54817000 1419 11050 18 76.841 KMQT 08 ILS-cat-I --- 4 46.5362 -087.54817000 1419 11050 18 76.841 IXXX KMQT 08 ILS-cat-I 13389c13389 4 70.33308600 -149.56581800 67 10970 18 107.900 PAKU 05 ILS-cat-I --- 4 70.33308600 -149.56581800 67 10970 18 107.900 IXXX PAKU 05 ILS-cat-I 14125c14125 5 45.29766700 -072.73483300375 11070 18 36.999 CZBM 05L LOC --- 5 45.29766700 -072.73483300375 11070 18 36.999 IXXX CZBM 05L LOC 14255c14255 5 35.27726300 -089.66926600312 11155 18 153.681 KLHC 15 LOC --- 5 35.27726300 -089.66926600312 11155 18 153.681 IXXX KLHC 15 LOC 14372c14372 5 70.25181500 -148.35802800 45 10970 18 106.500 PUO 05 SDF --- 5 70.25181500 -148.35802800 45 10970 18 106.500 IXXX PUO 05 SDF -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navaids update
Jean == jean pellotier writes: Jean I see the update is done, thanks, (and sorry for windows users Jean waiting for a compatible binary build :) ). It appears that Jean Atlas don't like the new nav.dat.gz, and crash on start up, Jean because some navaids contains empty field for the balise name Jean (i guess it's the balise name). Jean here's a diff where the missing fields are replaced with Jean IXXX. may be the real name is available, but i didn't found Jean the few i checked. Jean and Atlas don't crash anymore. Thanks for the fix. Although it doesn't really matter, Robin is in the habit of indicating no ID with ''. I've written to him about the navaids in question, since having a blank ID field seems to violate his file format specification. Brian -- Brian Schack 19 Xǔchāng Street 2Fphone: 2381 4727 Taipei 100 fax:2381 2145 TAIWAN -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navaids update
John Denker wrote: On the opposite side of the same coin, the last time I looked, the scenery database listed huge numbers of airports that were unknown to Robin's database. I don't know which scenery database you've been looking at, but it's certainly not been the one which we're using for building the FlightGear World Scenery from, aka. Landcover-DB, the one behind http://[mapserver,scenemodels].flightgear.org/ With probably _very_ few exceptions (one or two), the airport info of 'our' database has been populated from Robin's exports only, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navaids update
On 12/19/2009 07:40 AM, Martin Spott wrote: ... Robin's current set of navaids ... contains navaids for airfields which are otherwise unknown to FlightGear, On the opposite side of the same coin, the last time I looked, the scenery database listed huge numbers of airports that were unknown to Robin's database. This has never been a problem AFAIK. Copying the files from Robin's current set of navaids leads to a fault since it contains navaids for airfields which are otherwise unknown to FlightGear, From the keen-grasp-of-the-obvious department: Maybe the code should be made more robust so that this is not a fault condition. This is not the first time in history that code has needed to perform a join on two databases that are not in one-to-one correspondence. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navaids update
On 19 Dec 2009, at 16:19, John Denker wrote: Maybe the code should be made more robust so that this is not a fault condition. This is not the first time in history that code has needed to perform a join on two databases that are not in one-to-one correspondence. Well I wrote the code in question, and preferred to reject a corrupt data set rather than blindly carrying on - I am also a bit reluctant to encourage casual users to mess with a somewhat archaic data format. Nevertheless, it's pretty easy to tolerate this case, a fix will appear soon - the problem is some things aren't going to work, notably ILS - runway references. James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] navaids update
Hi, I've got a question about the navaids, particularly nav.dat. Is nav.dat supposed to be updated from robin X-plane database? The french missing navaids I submited to robin ( approach locators ) are included in recent nav.dat from X-plane, and I was waiting them to come in Flightgear, but apparently we are using the version just before. here's a diff toward our current nav.dat with the missing french locators, if you find some interest in using french airports :) . jano --- fg_nav.dat 2009-12-14 11:22:24.0 +0100 +++ jjano_nav.dat 2009-12-14 11:22:02.0 +0100 @@ -1,6 +1,104 @@ I 810 Version - DAFIF data cycle 2007.09, build 20070106, metadata NavXP810. Copyright © 2007, Robin A. Peel (ro...@xsquawkbox.net). This data is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program (AptNavGNULicence.txt); if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. This product was developed using DAFIF (the Defense Aeronautical Flight Information File), a product of the US National Imagery and Mapping Agency (NIMA). NIMA requires the following warranty statements: (A) Under 10 U.S.C. 456, no civil action may be brought against the United States on the basis of the content of a navigational aid prepared or disseminated by either the former Defense Mapping Agency (DMA) or the National Imagery and Mapping Agency (NIMA). (B) The DAFIF product is provided as is, and no warranty, express or implied, including, but not limited to the implied warranties of merchantability and fitness for particular purpose or arising by statute or otherwise in law or from a course of dealing or usage in trade, is made by NIMA as to the accuracy and functioning of the product. ©: Neither NIMA nor its personnel will be liable for any claims, losses, or damages arising from or connected with the use of this product. The user agrees to hold harmless the United States National Imagery and Mapping Agency. The user's sole and exclusive remedy is to stop using the DAFIF product. +2 43.9122 002.0644528 323 250.0 AB Albi le Sequestre NDB +2 49.9762 002.80941666361 321 1500.0 ABY Albert Bray NDB +2 43.26527778 005.58638000590 366 250.0 ADC Le Castellet NDB +2 44.1505 000.6738156 400 250.0 AG Agen la Garenne NDB +2 45.7105 000.4269397 404 250.0 AGO Angouleme Brie Champniers NDB +2 44.9558 002.3680 2310 343 250.0 AR Aurillac NDB +2 47.5772 -000.1513305 292 250.0 AS Angers Marce NDB +2 45.8616 006.0205 2205 384 250.0 AT Annecy Meythet NDB +2 44.4422 004.3619676 427 250.0 AUB Aubenas Ardeche Meridionale NDB +2 46.88167000 002.92888955679 306 250.0 AV Avord NDB +2 47.9202 003.5022505 417 250.0 AX Auxerre Branches NDB +2 47.6108 002.7827528 405 250.0 BIC Briare Chatillon NDB +2 45.52027800 004.29889000 1371 299 250.0 BO Saint Etienne Boutheon NDB +2 46.2038 005.2888869 423 250.0 BOR Bourg Ceyzeriat NDB +2 42.4258 009.5375 33 369 250.0 BP Bastia Poretta NDB +2 45.6158 004.99278000 1076 388 250.0 BR Lyons Bron NDB +2 47.0175 002.2816509 375 250.0 BRG Bourges NDB +2 44.3652 -001.1288 92 358 250.0 BRS Biscarrosse Parentis NDB +2 47.2669 006.2025 1348 370 250.0 BSV Besancon la Veze +2 49.4916 002.0294377 391 250.0 BV Beauvais Tille NDB +2 44.5669 003.4691 4062 393 250.0 BX Mende Brenoux NDB +2 46.7216 004.8430656 391 250.0 CC Chalon Champforgeuil NDB +2 45.8044 003.3616 1066 367 250.0 CF Clermond Ferrand Auvergne NDB +2 49.0052 002.7402352 370 250.0 CGZ Paris Charles de Gaulle NDB +2 45.5925 005.88361100840 346 250.0 CH Chambery Aix les Bains NDB +2 48.0077 003.6961545 353 250.0 CHY Chailley NDB +2 44.38527778 001.4155951 348 250.0 CL Cahors Lalbenque NDB +2 43.2225 002.2077489 345 250.0 CS Carcassonne Salvaza NDB +2 43.5228 007.04527778 98 385 250.0 CSC Cannes Mandelieu NDB +2 41.7952 008.7241295 387 250.0 CT Ajaccio Campo dell'Oro NDB +2 48.7591 004.3188604 347
Re: [Flightgear-devel] navaids update
Salut Jean, jean pellotier wrote: Is nav.dat supposed to be updated from robin X-plane database? If nobody else is going to do that, I'll be updating the file from Robin's most current package during our pre-release phase (however this is going to be defined ). here's a diff toward our current nav.dat with the missing french locators, if you find some interest in using french airports :) . I do - been flying there several times in real life and mostly had to do visual navigation because no navaids (neither VOR's nor anything else) had been installed on my routes :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] navaids update
Is nav.dat supposed to be updated from robin X-plane database? If nobody else is going to do that, I'll be updating the file from Robin's most current package during our pre-release phase (however this is going to be defined ). Can't the data be commited to CVS now ? pete -- 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] Navaids FIX data with duplicates entries
Yes, SBGL is in APT.DAT but the FIX around is not in FIX.DAT ( Like FICO, PERES ) And there duplicates entries in X-Plane data too, i have send mail for Robin check it, but FIX of around SBGL airport is in X-Plane but not in Flightgear. Tks, Cleber K. Hoercher [EMAIL PROTECTED] escreveu: On Thu, Feb 07, 2008 at 03:42:05PM +0100, Pietro wrote: At Thursday 07 February 2008 15:28:55 Cleber Santz wrote: One more thing, some FIX that find in X-Plane navaid data not appers in FlightGear ( FIX for SBGL airport for example ), is not the same database ? Well I checked LEPAS and HARDLY quickly in another source, and there are several of them too. Although the real world authorities strive for uniqueness, they cannot and do not guarantee so. Short of errors or oversights on the part of Robin Peel, his (thus X-Plane's and in turn our) navaids data does reflect this accurately. Also SBGL Galeão Antonio Carlos Jombim is to be found in apt.dat.gz and looks alright to me. Hi, AFAIK the fgfs navaids files have been converted from X-plane data files, but alas, years ago and therefore they are outdated. Pietro The last update was somehow shortly before the relase of 1.0.0, and taking into account the mentioned possible errors/delays it should be up-to-date within reasonable limits, although not following the very latest AIRAC cycle. regards K. Hoercher - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids FIX data with duplicates entries
On 02/07/2008 07:28 AM, Cleber Santz wrote: I have trace same routes using waypoints and find many duplicates entries in FIX Data ( like LEPAS, HARDY ) with different coordinates, thats is correct ? 1) That is a correct observation, there are duplicate fixes. That includes named waypoints, VORs, et cetera. 2) This is *not* a bug in the database. Complaining to Robin about it would be a step in the wrong direction. 3) Real-world pilots and real-world navigation instruments resolve the ambiguity by choosing the _nearest_ one of the possibilities. 4) This *is* a bug in the stock version of the FGFS code, in the sense that it is not smart about duplicate fixes. 5) This bug was fixed eons ago in the Sport Model. See item 31 on the list at http://www.av8n.com/fly/fgfs/README.sport.model - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids FIX data with duplicates entries
On Thu, Feb 07, 2008 at 03:42:05PM +0100, Pietro wrote: At Thursday 07 February 2008 15:28:55 Cleber Santz wrote: One more thing, some FIX that find in X-Plane navaid data not appers in FlightGear ( FIX for SBGL airport for example ), is not the same database ? Well I checked LEPAS and HARDLY quickly in another source, and there are several of them too. Although the real world authorities strive for uniqueness, they cannot and do not guarantee so. Short of errors or oversights on the part of Robin Peel, his (thus X-Plane's and in turn our) navaids data does reflect this accurately. Also SBGL Galeão Antonio Carlos Jombim is to be found in apt.dat.gz and looks alright to me. Hi, AFAIK the fgfs navaids files have been converted from X-plane data files, but alas, years ago and therefore they are outdated. Pietro The last update was somehow shortly before the relase of 1.0.0, and taking into account the mentioned possible errors/delays it should be up-to-date within reasonable limits, although not following the very latest AIRAC cycle. regards K. Hoercher - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Navaids FIX data with duplicates entries
Hi, I have trace same routes using waypoints and find many duplicates entries in FIX Data ( like LEPAS, HARDY ) with different coordinates, thats is correct ? One more thing, some FIX that find in X-Plane navaid data not appers in FlightGear ( FIX for SBGL airport for example ), is not the same database ? Tks, Cleber Santz. Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids FIX data with duplicates entries
At Thursday 07 February 2008 15:28:55 Cleber Santz wrote: One more thing, some FIX that find in X-Plane navaid data not appers in FlightGear ( FIX for SBGL airport for example ), is not the same database ? Hi, AFAIK the fgfs navaids files have been converted from X-plane data files, but alas, years ago and therefore they are outdated. Pietro - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAVAIDS ???
Mathias Fröhlich wrote: Jon, On Tuesday 24 January 2006 22:45, Jon Stockill wrote: I've just discovered that when using the null fdm I'm not getting updates to /position/ground-elev-m any more. So I can't actually retrieve the terrain elevation. Is there somewhere else in the property tree I could read this from? The attached patch should fix your problem. Yup - that's great - the values are updating now. Jon --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAVAIDS ???
Jon Stockill wrote: So with any luck I should have a full update of all the navaids in the database with correct elevations by this weekend. It seems I don't have any luck at the moment. I've just discovered that when using the null fdm I'm not getting updates to /position/ground-elev-m any more. So I can't actually retrieve the terrain elevation. Is there somewhere else in the property tree I could read this from? Jon --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAVAIDS ???
Jon Stockill wrote: Jon Stockill wrote: So with any luck I should have a full update of all the navaids in the database with correct elevations by this weekend. It seems I don't have any luck at the moment. I've just discovered that when using the null fdm I'm not getting updates to /position/ground-elev-m any more. So I can't actually retrieve the terrain elevation. Is there somewhere else in the property tree I could read this from? Hmmm, ouch, ground_cache issues? This was added by others so I don't understand it enough to know if this could be the issue or not. Might be something to look at though ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAVAIDS ???
On Tuesday 24 January 2006 22:45, Jon Stockill wrote: Jon Stockill wrote: So with any luck I should have a full update of all the navaids in the database with correct elevations by this weekend. It seems I don't have any luck at the moment. I've just discovered that when using the null fdm I'm not getting updates to /position/ground-elev-m any more. So I can't actually retrieve the terrain elevation. Is there somewhere else in the property tree I could read this from? Jon, I have added that to the todo list. :) But not until tomorrow ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
