Retrieve LOC distance from GPS Var XML

[Guest jouha]

Hi!I've been trying to get lat/lon position and that way the distance to a tuned LOC station via IcaoSearch variables, without any results.I was wondering if it's possible at all with that method?Never before handled with these variables so understanding the way these act is a bit going over my head.Let's make this little easier to understand:I have a click area which I'd like to trigger the code and store the distance to a local var. (Just an e.g it doesn't matter what finally triggers this event)I've tryed the following code (Simplified).C:fs9gps...visual elements etc... (A:NAV1 IDENT,string) (>@c:IcaoSearchEnterChar) (@c:IcaoSearchCurrentIcao) (>@c:FacilityICAO) (@c:FacilityLatitude,degrees) (>@c:GeoCalcLatitude2,degrees) (@c:FacilityLongitude,degrees) (>@c:GeoCalcLongitude2,degrees) (A:PLANE LATITUDE,degrees) (>@c:GeoCalcLatitude1,degrees) (A:PLANE LONGITUDE,degrees) (>@c:GeoCalcLongitude1,degrees) (@c:GeoCalcDistance,nmiles) (>L:DISTANCE TO LOC,nmiles) The main problem is that IcaoSearchCurrentIcao doesn't return nothing but a null string. Tried everything what comes to mind.Please help someone!?

[WarpD 824]

You're going about it the really, really hard way... why not just use this:NAV DME:index where index is the nav unit tuned to the LOC... 1 or 2?

[Guest jouha]

>You're going about it the really, really hard way... why not>just use this:>>NAV DME:index where index is the nav unit tuned to the LOC...>1 or 2?Cause it's not working with stations without DME even in FS. ALways showing 0 for localizers which I've tested with. There's some VOR's and multiple LOC's which don't have DME available.I still think that there must be set coordinates for every station available somehow in FS.P.S Found "NAV DME LATLONALT:index" from latest SDK but I'm looking for FS9 combatilibity too.Thanks for the quick reply anyway!

[taguilo 33]

Hi,Assigning (>@c:FacilityICAO) returns data on the next cycle.Instead you can try this: ... (L:Async,bool) if{ (@c:FacilityLatitude,degrees) (>@c:GeoCalcLatitude2,degrees) (@c:FacilityLongitude,degrees) (>@c:GeoCalcLongitude2,degrees) (A:plane latitude,degrees) (>@c:GeoCalcLatitude1,degrees) (A:plane longitude,degrees) (>@c:GeoCalcLongitude1,degrees) (@c:GeoCalcDistance,nmiles) (>L:distance to loc,nmiles) 0 (>L:Async,bool) }(A:NAV1 IDENT,string) (>@c:IcaoSearchEnterChar)(@c:IcaoSearchCurrentIcao) (>@c:FacilityICAO)1 (>L:Async,bool)Tom

[WarpD 824]

Localizers without DME? I've heard of VORs without DME... but localizers?Considering the number of approaches and departures that require the use of DME equipment onboard... I really find this hard to believe.I honestly don't ever recall dialing in a localizer and not getting a DME value. Well, except if I'm out of range of the localizer... but if you're out of range... it's unrealistic to return a distance to that which you don't actually have a signal from.

[Guest jouha]

>Localizers without DME? I've heard of VORs without DME...>but localizers?>>Considering the number of approaches and departures that>require the use of DME equipment onboard... I really find this>hard to believe.>>I honestly don't ever recall dialing in a localizer and not>getting a DME value. Well, except if I'm out of range of the>localizer... but if you're out of range... it's unrealistic to>return a distance to that which you don't actually have a>signal from.I don't know the case in the States but in europe LLZ (read LOC) without DME information is not so uncommon. Actually LLZ/DME is more rare. Most of the cases we use LZZ frequency to have the LOC/GS deviation information and distance is retrieved from VOR/DME's or from Markers etc... As far as what comes to believing in instrument approach charts. Correct if I'm wrong here. It's just that I want this ACT to be combatitle with all possible situations.

[Guest jouha]

>Hi,>>Assigning (>@c:FacilityICAO) returns data on the next cycle.>Instead you can try this:>>> ...> (L:Async,bool)> if{ (@c:FacilityLatitude,degrees)>(>@c:GeoCalcLatitude2,degrees)> (@c:FacilityLongitude,degrees)>(>@c:GeoCalcLongitude2,degrees)> (A:plane latitude,degrees)>(>@c:GeoCalcLatitude1,degrees)> (A:plane longitude,degrees)>(>@c:GeoCalcLongitude1,degrees)> (@c:GeoCalcDistance,nmiles) (>L:distance to loc,nmiles)> 0 (>L:Async,bool)> }>>>>>>>(A:NAV1 IDENT,string) (>@c:IcaoSearchEnterChar)>(@c:IcaoSearchCurrentIcao) (>@c:FacilityICAO)>1 (>L:Async,bool)>>>>Tom>>>Hi there!I actually tested this method once and tested it once again and seems that the distance given is always measured from the "origo" (Somewhere west Africa) to present location, which indicates that the coordinates are not set for the navaid station. Tested it by setting (@c:FacilityLatitude,degrees) to a local var in above example and that var didn't have other values than default zero.So the problem must lie within these two lines:(A:NAV1 IDENT,string) (>@c:IcaoSearchEnterChar)(@c:IcaoSearchCurrentIcao) (>@c:FacilityICAO)I was wondering that do I have to assign the FS GPS to the panel (panel window to panel.cfg) before I can use this macro and the Facility variable? Any suggestions?Thanks again for reply!

[mgh 89]

Cranfield (EGTC) has an LLZ but no associated DME. Indeed, there is a note in the aerodrome data stating "Any DME indications received when using the ILS facility should be ignored".

[WarpD 824]

But if the localizer isn't returning DME... and it's something that's not available real-world... then what is the purpose of your retrieving it?You can't possibly be wanting to provide DME info that isn't available in the real world, are you?

[taguilo 33]

Hi,I suppose that maybe you forgot to define the search string?'AVNW' (>@c:IcaoSearchStartCursor) must be set before a search to indicate which navaids include: Airport-VOR/ILS-NDB-WPT(fixes).This assignment must be placed before doing a (>@c:IcaoSearchEnterChar).Besides it's not that easy to search by NAV IDENT, because it will return more than one result if there is more than one navaid with the same ident. I think you'll have to test for matchedICAO or similar to find the number of hits, then loop through each one, retrieve its distance, and finally choose whichever is closer to the airport of reference.Tom

[Guest jouha]

>Hi,>>I suppose that maybe you forgot to define the search string?>>'AVNW' (>@c:IcaoSearchStartCursor) must be set before a search>to indicate which navaids include:>Airport-VOR/ILS-NDB-WPT(fixes).>>This assignment must be placed before doing a>(>@c:IcaoSearchEnterChar).>>Besides it's not that easy to search by NAV IDENT, because it>will return more than one result if there is more than one>navaid with the same ident. I think you'll have to test for>matchedICAO or similar to find the number of hits, then loop>through each one, retrieve its distance, and finally choose>whichever is closer to the airport of reference.>>Tom>I didn't just forgot to add the search string, I didn't even know that it should be defined before search. But yeah, it definitely did the trick! Big thanks for that Tom!Now I'm really studying the default GPS xml code to perform the search for multiple navaids with the same ID. (I found it very stupid that the GPS doesn't find the closest navaid first by default)P.S to WarpD: I'm not trying to offer this DME for pilots, it's just helping me for my autopilot system calculations. Not so big deal :)

[martinboehme 491]

>P.S to WarpD: I'm not trying to offer this DME for pilots,>it's just helping me for my autopilot system calculations. Not>so big deal :)Hm, can jump in here and take this off on a tangent...? ;-)I'm guessing what you want to do is adjust the sensitivity of the autopilot's corrections depending on your distance to the runway... so that as you get closer, your corrections become smaller and smaller...?This is something I've thought about as well (one of those "projects I'd like to do when I find the time" is a custom autopilot), and I've wondered how autopilots do it in the real world. Computing a "fake" DME is something that obviously can't be done in real autopilots -- so how do they deal with this? This is something I'd love to know... if anyone has this knowledge, please share it!I'm guessing that real autopilots do one of two things, depending on their level of sophistication:1. Just ignore the fact that LOC and GS get more sensitive the closer in you are. Adjust the gains in the autopilot controller until it works "reasonably well" between say ten miles out and 2/3 of a mile out (i.e. CAT I decision height).2. Use radar altitude as a surrogate for "distance to the threshold" -- this is probably a good enough substitute for adjusting the autopilot gains, and it's going to get more and more accurate the closer you get (CAT II/III even has certain guarantees).Has anyone got any real-world knowledge on this?Cheers,Martin

[WarpD 824]

From documentation for the Primus 2000 system by Honeywell:"Lateral gain programming adjusts the gain applied to the localizer signal as the aircraft approaches the localizer antenna. The lateral gain programmer is controlled by a distance from the transmitter estimator.If radio altitude and glideslope deviation are both valid, distance is calculated using radio altitude and glideslope deviation data, as shown in Figure 7--17. If only radio altitude is valid, distance is first estimated for capture. When it is in the final trackmode, an approach to the runway without glideslope is assumed, and distance is calculated based on radio altitude only.If radio altitude information is not valid, distance is estimated as a function of glideslope deviation and true airspeed (TAS). If neither radio altitude nor glideslope data is valid, then distance is estimated as a function of TAS and time. The PFD shown in Figure 7--18 is in the tracking mode."Fun trig calcs :(

[martinboehme 491]

Ah...! Thanks for that, that's more detail than I'd hoped for!Martin