But why then do you need to use a RADIO HEIGHT based algorithm to establish MaxItems? In a congested area and/or at high radio heights, is it possible you could come up short? Even if NearestAirportMaximumItems is set to something absurd like 100000, searching for Nearest Airports items will be stopped as soon as max distance is reached, correct?

Bob, The reason why I did this is from previous testing with line of site. IIRC I did this in the NY / BOS & LAX / SFO areas ( max congestion?) using the line of site Max distance @ 40,000 feet. It was found that there were aprox. 22,000 airports in that search, I increased it 25,000 then figured out airports per foot ( = 0.05) then doubled it (=0.1) so hopefully it wouldn't come up short. BTW in the code there is a minimum of 25 airports @ 25 NM when on the ground. Pure assumption here,, I believe that if max items is set to a large number the GPS database search engine has to allocate memory for that many items to search from, then from that queue it can search up to the max distance. Adjusting it dynamically will set up a small memory queue and adjust it in small steps while flying.

I appreciate that this is only a tutorial and a work in progress at that, but as presently coded, any change in RADIO HEIGHT will change NearestAirportMaximimDistance, and a change of that will trigger a NearestAirport items search, probably resulting in a constant Nearest Items search. Isn't that going to be a big resource hog? (Actually, the current version of your test gauge posted in this thread continuously cycles through the Nearest items and Nearest to Waypoint ICAO transfers anyway. I believe you said that in an earlier gauge you triggered this only when COM frequency changed.)

I'll have to test that more closely,,, Changing max distance and max items while in search, will it restart search? Come to think about it, I donot think so as (G:Var2) "nearest airport line select" remains. All that is really happening is the search database queue is just getting larger as aircraft height increases opposite as height decreases.

Perhaps I am beginning to see why you are storing the airport ident and frequency name strings ... is it because your code continuously updates the Nearest Airport search and the ICAO transfers?

Yes, I am continually doing a search. It gets rid of the problem of if I am tuned to a certain freq. and it's picking up airport "A" but I am flying towards airport "B" which has the same freq. . In the previous version the only way it would update to airport "B" is to double swap the stby/active freq. so it would initiate a new search as I was getting closer to airport "B". In this version it is automatic. Still in this version is the freq. change search restart for obvious reasons.

Even with string data. Maybe something like this is done in the gps500 xml. Don't know, but if so, I just never 'saw' it before.

That's where I found it... Oh boy! what a find! LOL

I will run into trouble, however, as I write code that lists the five nearest airport frequency matches.

Oh yeah! The brain is already smoking just thinkin about it. So here goes, a hypothetical way to do it. Changes in red, not full code, just updated sections.<!-- ADD these to vars description -->GVAR6 == The number of found freq. matches.s2 l2 = Waypoint Airport Ident #1s3 l3 = Waypoint Frequency #1s4 l4 = Waypoint Airport Ident #2s5 l5 = Waypoint Frequency #2s6 l6 = Waypoint Airport Ident #3s7 l7 = Waypoint Frequency #3s8 l8 = Waypoint Airport Ident #4 s9 l9 = Waypoint Frequency #4s10 l10 = Waypoint Airport Ident #5s11 l11 = Waypoint Frequency #5s12 l12 = Temp Airport Holders13 l13 = Temp Freq Name HolderL:Dig# = Airport Ident and Feq. Name String Digit Holders (_# 2-5)--><!-- Make sure waypoint is loaded, if so, check airport freq. to tuned freq., if matched save string and increment found airports if 5 are found then start over --> (@c:WaypointAirportIdent) (@c:NearestAirportCurrentIdent) scmi 0 == (G:Var3) 1 == and if{ (G:Var4) (>@c:WaypointAirportCurrentFrequency) (@c:WaypointAirportFrequencyValue,Mhz) @com == if{ @set (G:Var6) ++ s1 (>G:Var6) l1 5 == if { @reset } }<Macro Name="reset"> 0 (>G:Var2) 0 (>G:Var3) 0 (>G:Var4) 0 (>G:Var5) 0 (>G:Var6)</Macro><!-- Increment freq. for each airport until final freq, then increment airport. If nothing found at last airport start over and reset string holders and reset search -->(G:Var4) ++ s1 (>G:Var4) l1 (@c:WaypointAirportFrequenciesNumber) 1 - > (@c:WaypointAirportFrequencyType) 1 > || if{ 0 (>G:Var3) 0 (>G:Var4) (G:Var2) ++ s1 (>G:Var2) l1 (@c:NearestAirportItemsNumber) 1 - > if{ @resetdig @reset } } } <!-- Just reversed so found stack is not comprimised --><!-- Reset the string digit holders if nothing at "current" GVAR6 is found that matches --><Macro Name="resetdig">(G:Var6) 1 < if{ 0 (>L:Dig0, number) 0 (>L:Dig1, number) 0 (>L:Dig2, number) 0 (>L:Dig3, number) 0 (>L:Dig4, number) 0 (>L:Dig5, number) 0 (>L:Dig6, number) 0 (>L:Dig7, number) } (G:Var6) 2 < if{ 0 (>L:Dig0_2, number) 0 (>L:Dig1_2, number) 0 (>L:Dig2_2, number) 0 (>L:Dig3_2, number) 0 (>L:Dig4_2, number) 0 (>L:Dig5_2, number) 0 (>L:Dig6_2, number) 0 (>L:Dig7_2, number) } (G:Var6) 3 < if{ 0 (>L:Dig0_3, number) 0 (>L:Dig1_3, number) 0 (>L:Dig2_3, number) 0 (>L:Dig3_3, number) 0 (>L:Dig4_3, number) 0 (>L:Dig5_3, number) 0 (>L:Dig6_3, number) 0 (>L:Dig7_3, number) } (G:Var6) 4 < if{ 0 (>L:Dig0_4, number) 0 (>L:Dig1_4, number) 0 (>L:Dig2_4, number) 0 (>L:Dig3_4, number) 0 (>L:Dig4_4, number) 0 (>L:Dig5_4, number) 0 (>L:Dig6_4, number) 0 (>L:Dig7_4, number) } (G:Var6) 5 < if{ 0 (>L:Dig0_5, number) 0 (>L:Dig1_5, number) 0 (>L:Dig2_5, number) 0 (>L:Dig3_5, number) 0 (>L:Dig4_5, number) 0 (>L:Dig5_4, number) 0 (>L:Dig6_5, number) 0 (>L:Dig7_5, number) }</Macro><!-- Tear apart the found string and store them in digit holders --><Macro Name="set">(@c:WaypointAirportFrequencyName) 'Center' scmi 0 == if{ 'ASPC' s12 } els{ (@c:WaypointAirportIdent) s12 }(G:Var6) 1 == If{ l12 0 symb ord (>L:Dig0, number) l12 1 symb ord (>L:Dig1, number) l12 2 symb ord (>L:Dig2, number) l12 3 symb ord (>L:Dig3, number) } (G:Var6) 2 == If{ l12 0 symb ord (>L:Dig0_2, number) l12 1 symb ord (>L:Dig1_2, number) l12 2 symb ord (>L:Dig2_2, number) l12 3 symb ord (>L:Dig3_2, number) } (G:Var6) 3 == If{ l12 0 symb ord (>L:Dig0_3, number) l12 1 symb ord (>L:Dig1_3, number) l12 2 symb ord (>L:Dig2_3, number) l12 3 symb ord (>L:Dig3_3, number) } (G:Var6) 4 == If{ l12 0 symb ord (>L:Dig0_4, number) l12 1 symb ord (>L:Dig1_4, number) l12 2 symb ord (>L:Dig2_4, number) l12 3 symb ord (>L:Dig3_4, number) } (G:Var6) 5 == If{ l12 0 symb ord (>L:Dig0_5, number) l12 1 symb ord (>L:Dig1_5, number) l12 2 symb ord (>L:Dig2_5, number) l12 3 symb ord (>L:Dig3_5, number) } (@c:WaypointAirportFrequencyName) s13 l13 'Approach' scmi 0 == if{ 'APPR' s13 }l13 'Unicom' scmi 0 == if{ 'UCOM' s13 } l13 'Clearance' scmi 0 == if{ 'CLRD' s13 } l13 'Ground' scmi 0 == if{ 'GND ' s13 } l13 'Tower' scmi 0 == if{ 'TWR ' s13 }l13 'Departure' scmi 0 == if{ 'DEP ' s13 } l13 'Center' scmi 0 == if{ 'CTR ' s13 } l13 'Multicom' scmi 0 == if{ 'MCOM' s13 } (G:Var6) 1 == if{ l13 0 symb ord (>L:Dig4, number) l13 1 symb ord (>L:Dig5, number) l13 2 symb ord (>L:Dig6, number) l13 3 symb ord (>L:Dig7, number) } (G:Var6) 2 == if{ l13 0 symb ord (>L:Dig4_2, number) l13 1 symb ord (>L:Dig5_2, number) l13 2 symb ord (>L:Dig6_2, number) l13 3 symb ord (>L:Dig7_2, number) } (G:Var6) 3 == if{ l13 0 symb ord (>L:Dig4_3, number) l13 1 symb ord (>L:Dig5_3, number) l13 2 symb ord (>L:Dig6_3, number) l13 3 symb ord (>L:Dig7_3, number) } (G:Var6) 4 == if{ l13 0 symb ord (>L:Dig4_4, number) l13 1 symb ord (>L:Dig5_4, number) l13 2 symb ord (>L:Dig6_4, number) l13 3 symb ord (>L:Dig7_4, number) } (G:Var6) 5 == if{ l13 0 symb ord (>L:Dig4_5, number) l13 1 symb ord (>L:Dig5_5, number) l13 2 symb ord (>L:Dig6_5, number) l13 3 symb ord (>L:Dig7_5, number) } </Macro><!-- Rebuild the airport Ident from digit holders into a full string -->(L:Dig0, number) chr (L:Dig1, number) chr scat (L:Dig2, number) chr scat (L:Dig3, number) chr scat s2 (L:Dig0_2, number) chr (L:Dig1_2, number) chr scat (L:Dig2_2, number) chr scat (L:Dig3_2, number) chr scat s4 (L:Dig0_3, number) chr (L:Dig1_3, number) chr scat (L:Dig2_3, number) chr scat (L:Dig3_3, number) chr scat s6 (L:Dig0_4, number) chr (L:Dig1_4, number) chr scat (L:Dig2_4, number) chr scat (L:Dig3_4, number) chr scat s8 (L:Dig0_5, number) chr (L:Dig1_5, number) chr scat (L:Dig2_5, number) chr scat (L:Dig3_5, number) chr scat s10 <!-- Rebuild the freq name from digit holders into a full string -->(L:Dig4, number) chr (L:Dig5, number) chr scat (L:Dig6, number) chr scat (L:Dig7, number) chr scat s3(L:Dig4_2, number) chr (L:Dig5_2, number) chr scat (L:Dig6_2, number) chr scat (L:Dig7_2, number) chr scat s5(L:Dig4_3, number) chr (L:Dig5_3, number) chr scat (L:Dig6_3, number) chr scat (L:Dig7_3, number) chr scat s7(L:Dig4_4, number) chr (L:Dig5_4, number) chr scat (L:Dig6_4, number) chr scat (L:Dig7_4, number) chr scat s9(L:Dig4_5, number) chr (L:Dig5_5, number) chr scat (L:Dig6_5, number) chr scat (L:Dig7_5, number) chr scat s11<! -- NOTE -- Bitmap will have to get larger --><Element Name="Display"><Position X="5" Y="6"/><FormattedText X="147" Y="108" Font="Quartz" FontSize="11" VerticalAdjust="Center" Color="Red" Bright="Yes"><String>%\{tabs=1L,75C}%\t%(l2)%!s!% %(l3)%!s!%\n%\{tabs=1L,75C}%\t%(l4)%!s!% %(l5)%!s!%\n%\{tabs=1L,75C}%\t%(l6)%!s!% %(l7)%!s!%\n%\{tabs=1L,75C}%\t%(l8)%!s!% %(l9)%!s!%\n%\{tabs=1L,75C}%\t%(l10)%!s!% %(l11)%!s!%\n%\n%\{tabs=1L,75L}%DB Range %((@c:NearestAirportMaximumDistance, NMiles))%!d! nm%\t%DB Max Items %((@c:NearestAirportMaximumItems))%!d!%\n%\n%\{tabs=1L,75L}%Nrst Apt(2) %((@c:NearestAirportCurrentLine))%!d!%\t%Apt->Waypt(3) %((G:Var3))%!d!%\n%\{tabs=1L,75L}%Waypt Freq(4) %((@c:WaypointAirportCurrentFrequency))%!d!%\t%Waypt Apt Loaded %((@c:WaypointAirportIdent) (@c:NearestAirportCurrentIdent) scmi 0 ==)%!d!%\n%\{tabs=1L,75L}% %\t%Cycles(5) %((G:Var5))%!d!%\n</String></FormattedText></Element>_________________________________________________________________________I din't test this ( as of yet ) got a busy day today & have to get started on it.Have fun coding,Roman

I believe that if max items is set to a large number the GPS database search engine has to allocate memory for that many items to search from, then from that queue it can search up to the max distance. Adjusting it dynamically will set up a small memory queue and adjust it in small steps while flying.

Okay, I see what you mean. It's best to keep both parms (MaxDist and MaxItems) realistic but small, to limit resources the gps module may need and the work it has to do.

Yes, I am continually doing a search. It gets rid of the problem of if I am tuned to a certain freq. and it's picking up airport "A" but I am flying towards airport "B" which has the same freq.

Well, that's never been an issue for me, not yet, as I have always been parked on the runway, never moving, as I wrestle with this :(. I still have it in my mind, however, that a continuous NearestAirport search would turn out to have an unacceptable performance hit, but that hunch isn't based on a good understanding of how MSFS and the gps.dll module do their thing. Of course, I am sure the gps500.xml is constantly telling the gps module to do a lot of things I am oblivious to.And, I'll enjoy going through your red code. I can see that a brute force method (tear apart and reassemble ord-chr-scat) needs to be used to store the string data as opposed to the wishful thinking "is there a more elegant way to do this?"Thanks,Bob(you catch the last seconds of the Bears-Packers game? Of course you did)

(you catch the last seconds of the Bears-Packers game? Of course you did)

Of course... No comment LOL!

..just wanted to say you guys rule!Teaching me a bunch, thank you!

Is there an additional approach to the COM Frequency Ident problem?The method demonstrated in this thread involves nested NearestAirport and WaypointAirport if{ statements searching for a match of the COM Active Frequency. It checks one airport frequency for a COM frequency match each cycle, incrementing to the next frequency or the next airport until a match is found. All of the search logic is placed within the <Update> section. When a frequency match is found, the desired WaypointAirportIdent and FrequencyName information is displayed in a Text Element.Considering that the goal is to just display some information that matches specific criteria, could the frequency match requirement be accomplished using conditional string statements within a {if} {loop} sequence inside the Text Element as opposed to if{ statements in the <Update> section? Could you loop through the WaypointAirportCurrentFrequency indexes, displaying WaypointAirportFrequencyName only when WaypointAirportFrequencyValue matches A:COM1 Active Frequency? And, would be possible to handle the much more complicated nested NearestAirport - WaypointAirport nature of the original problem this way?

Is there an additional approach to the COM Frequency Ident problem?The method demonstrated in this thread involves nested NearestAirport and WaypointAirport if{ statements searching for a match of the COM Active Frequency. It checks one airport frequency for a COM frequency match each cycle, incrementing to the next frequency or the next airport until a match is found. All of the search logic is placed within the <Update> section. When a frequency match is found, the desired WaypointAirportIdent and FrequencyName information is displayed in a Text Element.Considering that the goal is to just display some information that matches specific criteria, could the frequency match requirement be accomplished using conditional string statements within a {if} {loop} sequence inside the Text Element as opposed to if{ statements in the <Update> section? Could you loop through the WaypointAirportCurrentFrequency indexes, displaying WaypointAirportFrequencyName only when WaypointAirportFrequencyValue matches A:COM1 Active Frequency? And, would be possible to handle the much more complicated nested NearestAirport - WaypointAirport nature of the original problem this way?

I'm pretty sure this is possible, as I've done calculations with conditional statements in formatted text for things like waypoint index and subsequent information and such.I'll test it when I get a chance. Below is some of the code I used on one of my FMC's:

<ScrollY>(L:FMC-FWD-PLN-SCROLL,number)</ScrollY><String>\n\n\{lsp=2.5}%((L:WP_counter,number) 4 + (C:fs9gps:FlightPlanActiveWaypoint) + s3)%((C:fs9gps:FlightPlanIsActiveFlightPlan) (C:fs9gps:FlightPlanWaypointsNumber) s2 0 != and)%{if}%((L:WP_counter,number) (C:fs9gps:FlightPlanActiveWaypoint) + sp1)%{loop}%(l1 (>C:fs9gps:FlightPlanWaypointIndex,number))%((C:fs9gps:FlightPlanWaypointRemainingDistance,nmiles) 0 !=)%{if}\t\{fnt2}%((C:fs9gps:FlightPlanWaypointMagneticHeading,degrees) d360)%!03d! °M\t%((C:fs9gps:FlightPlanWaypointRemainingDistance,nmiles) s0 100 >)%{if}%(l0)%!d! NM%{else}%(l0)%!3.1f! NM%{end}     %((C:fs9gps:FlightPlanWaypointETA,seconds) 0 >)%{if}@eta%{else}-------%{end}\n%((L:FplDelete,enum) 1 ==)%{if}\{rev}<\{nr} %{else}%{end}%((C:fs9gps:FlightPlanActiveWaypoint,number) l1 ==)%{if}%( l8 (>L:FlightPlanVS,number) 1 (>L:FlightPlanAltitude,number))\{rev}%{else}\{nr}%{end}%((C:fs9gps:FlightPlanWaypointIdent,string))%!s!%( l8 (L:FlightPlanVS,number) 5000 >)%{if}%( 5000 (>L:FlightPlanVS,number))%{end}\{nr}\t%((A:GPS FLIGHT PLAN WP COUNT, number) 1 - l1 ==)%{if}%((C:fs9gps:FlightPlanWaypointAltitude,feet) s7)%{else}@WaypointAltitude2%{end}%( l1 (C:fs9gps:FlightPlanActiveWaypoint,number) ==)%{if}%%(180 l0 1852 * / l11 (A:Indicated Altitude, feet) - 0.3048 * * 196.85 * 100 / near 100 * s8)%{else}%(180 l0 1852 * / l7 0.3048 * * 196.85 * 100 / near 100 * s8)%{end}          %(l8 0 >)%{if}CLB %(l8 abs 0 == !)%{if}%(l8 abs)%!d!%{end}%{end}%(l8 0 <)%{if}DES %(l8 abs 0 == !)%{if}%(l8 abs)%!d!%{end}%{end}%((C:fs9gps:FlightPlanWaypointAltitude,feet) 0 >)%{if}%((C:fs9gps:FlightPlanWaypointAltitude,feet) (>G:VAR4))%{else}@WaypointAltitudeSet%{end} %(45 180 l8 0.00508 * / / abs s10 0 == !)%{if}%(l10)%!5.1f! ° %{end}%((A:GPS FLIGHT PLAN WP COUNT,number) 1 - l1 == )%{if}/ %((C:fs9gps:FlightPlanWaypointAltitude,feet) s6)%!d! FT%{else}@WaypointAltitude%{end}\n%( l1 (C:fs9gps:FlightPlanActiveWaypoint,number) ==)%{if}%( l9 100 / near 100 * (>L:FlightPlanWPAltitude,feet))%{end}%{else}%(l3 ++ s3)%{end}%(l1 ++ s1 (C:fs9gps:FlightPlanWaypointsNumber) < l1 l3 < and)%{next}%{end}</String>

Thanks! It would be useful if this approach works for the COM Ident problem you posted. The thing I wonder about mostly is the multiple gps query nature of the problem. First is a NearestAirport search, then WaypointAirport via the 'ICAO transfer'. That's multiple cycle, and my first thought is that you can't pull that off within a string expression...but, I really don't know for sure. I will need to play around with this when I get a chance.

The thing I wonder about mostly is the multiple gps query nature of the problem. First is a NearestAirport search, then WaypointAirport via the 'ICAO transfer'. That's multiple cycle, and my first thought is that you can't pull that off within a string expression...but, I really don't know for sure.

After a little more searching through the forum I see that Tom Aguilo appears to have answered the multiple search within a loop question in 2008:

...you can't retrieve multiple data in a loop within a single cycle.

http://forum.avsim.n..._1#entry1510218I imagine you are right that conditional string statements can be used to display information only when a certain frequency match requirement is satisfied, but I guess one cannot retrieve additional data such as another WaypointAirport frequency list in the same {loop} that is, in the same cycle. Oh, well.Bob