Thanks, Roman. I'm looking forward to going through your code. To be fair to DVA and other forum members, I wonder if it is time to take this dialog to a new thread ... it may be migrating off topic, or at least, the scope is growing.??This is a long post, so the up-front summary is that I am making a few observations related to "cycle skipping" timing issues in fs9gps searches.Your comment regarding long distance searches taking a while is interesting. Could be the netbook, but could also be big values set for max items and max distance. My big "ah-ha" in all of this has been to realize, at long last, that there are, or seem to me to be, specific instructions that cause the gps to take some time to retrieve data before it is ready to be queried. I know this is all so obvious to you experts, but I am a slow learner. In the code I posted above, there are two such instructions as I see it. The first is retrieval of the Nearest Airport list right after setting NearestAirportCurrentLatitude and Longitude. This can take many cycles if NearestAirportMaximumItems and NearestAirportMaximumDistance are set to large numbers. I parked at Chicago O'Hair and set MaxDistance to 2000 nm and MaxItems to 20,000 and well after a minute of waiting, it was ready for query after finding 15,553 airports (c:fs9gps:NearestAirportItemsNumber). Suffice to say, a lot of cycles.The second is right after the (c:fs9gps:NearestAirportCurrentICAO) (>c:fs9gps:WaypointAirportICAO) transfer. I find that the wait here is pretty short in my application, but I do not know if it can always be done in one cycle (that is, be ready for query in the subsequent cycle). Maybe it can take several cycles?Because of this, I don't favor skipping a predetermined number of cycles to wait at these steps. Instead, it looks to me as if there are certain gps variables, that when non-zero values are obtained, indicate that the gps search is complete. For the Nearest Airport search, I check (c:fs9gps:NearestAirportItemsNumber) and when it is no longer zero, I am ready to resume. For the ICAO transfer, I check (c:fs9gps:WaypointAirportFrequenciesNumber). Am I on the right track here?You may recall the dialog we had several months ago as I was struggling to cope with a duplicate VOR issue in my KD572. My memory is fuzzy, but I think my break-through came when I finally built in several cycle skips after the ICAO transfer, having initially been under the impression that it would only require skipping one cycle (but my VOR frequency search was never working correctly that way ...). I wandered all over the place trying to figure it out, but thankfully you and Ed Wilson patiently kept re-directing me. Thanks again to both of you.Anyway, it's time to restate my official disclaimer to all readers that I am a true novice at this, and I may well be off target on anything to do with the gps. As well, by writing this lengthy post, I do not intend to be lecturing as I'm not qualified. But, there isn't a lot of information on gps timing issues, and some that might have been in this forum in the past may have been lost. I am just interested in learning more about the gps and I want to keep the dialog going. Wish there was a fs9gps Wiki... Fr. Bill?Bob

<Macro Name="set">0 (>G:Var2) 1 (>G:var5) (@c:WaypointAirportFrequencyName) 'Center' scmi 0 ==

Roman, A few questions to start with:

• Looks like you are checking WaypointAirportFrequencyName for "Center". I have been going through dozens of frequency lists for airports within the WaypointAirport search, and so far I have never run across a frequency named Center. All seem associated with the airport or appr/dep environment, which seems logical. Are you sure the Center frequencies can be searched for under WaypointAirport?

Some basic 101 stuff -

• What's the difference between scmp and scmi?

• In DVA's code, he shows <Update Hidden="Yes" ... What does Hidden accomplish?

ThxBob

Thanks, Roman. I'm looking forward to going through your code. To be fair to DVA and other forum members, I wonder if it is time to take this dialog to a new thread ... it may be migrating off topic, or at least, the scope is growing.??

No worries at all mate, I'm totally enjoying just learning from all this. Although I've not made any posts I've been watching eagerly and learning much from this, thank you to the two of you very much!

I parked at Chicago O'Hair and set MaxDistance to 2000 nm and MaxItems to 20,000

Apologies to Chicagoans and the O'Hare family. Chicago O'Hare International airport.

DVA, You're welcome, I enjoy working on brain teasers like this too.Bob

My big "ah-ha" in all of this has been to realize, at long last, that there are, or seem to me to be, specific instructions that cause the gps to take some time to retrieve data before it is ready to be queried. I know this is all so obvious to you experts, but I am a slow learner.

Yes in two ways..1st is the initial nearest database load so nearest can be searched. I use 2500 as max items from previous tests using "line of site" @ 40,000 feet in the northeast of the US. Then max distance is using "line of site" w/ a 25 NM minimum. Max distance is continually updated as aircraft climbs/descends so that when a nearest query is initiated the database is already updated and ready to search w/ a minimum needed database size.2nd is the "wait" for the nearest --> waypoint transfer. I will not start a freq. search until nearest = waypoint letting the GPS do it in it's own time.

(@c:WaypointAirportIdent) (@c:NearestAirportCurrentIdent) scmi 0 == (G:Var2) 1 == and 

Looks like you are checking WaypointAirportFrequencyName for "Center". I have been going through dozens of frequency lists for airports within the WaypointAirport search, and so far I have never run across a frequency named Center. All seem associated with the airport or appr/dep environment, which seems logical. Are you sure the Center frequencies can be searched for under WaypointAirport?

Yes I am -- Center is indeed in the database, but IIRC only in towered airports or spaced evenly throughout the ARTCC area at random airports..I used nearest in the actual GPS 500 to confirm. I seach for "Center" because If I am at KGRB and dial in Center on the radio it will show up as "KGRB Center" not "KMSP Center" as it should. The scmi match will replace KGRB w/ ARTCC on the display to show "ARTCC Center". Another example, I was flying around KOSH and dialed in KORD Center -- it showed up as "WI33 Center" on the display.

 (@c:WaypointAirportFrequencyName) 'Center' scmi 0 == if{ 'ARTCC' s2 } els{ (@c:WaypointAirportIdent) s2 } 

What's the difference between scmp and scmi?

scmp compares 2 strings wholly by subtraction, if = 0 then they matchscmi compares 2 strings "ignoring case" by subtraction, if = 0 then they match

In DVA's code, he shows <Update Hidden="Yes" ... What does Hidden accomplish?

If the window holding the gauge with this update is closed the <Update> section will remain doing it's thing. Now my turn ,,, :( Can macros be used. The <Update Hidden="Yes"> window/gauge is closed can <Macros> in that gauge still be called from the <Update>? KGRB @ KORD tonight! Go Pack!Have a good day,Roman

Hey Roman -- this is very useful, as always ...

Max distance is continually updated as aircraft climbs/descends so that when a nearest query is initiated the database is already updated and ready to search w/ a minimum needed database size.

Clever. I like this.

(@c:WaypointAirportIdent) (@c:NearestAirportCurrentIdent) scmi 0 == (G:Var2) 1 == and

That's a little more to the point than my choice of WaypointAirportFrequenciesNumber. I will switch to yours.

Yes I am -- Center is indeed in the database

Great. Thank you. That will save me from any more skulking around in NearestAirspace for "Center".

If the window holding the gauge with this update is closed the <Update> section will remain doing it's thing.

Hmmm. I work with an aircraft that has an "ILS" panel and a "Landing" panel, each using many of the same gauges, but one set is 'hidden' when the other is displayed. IIRC, I had been running into trouble with gauges that had timing sequences built into the <Update> section of the code..... for example, blinking seemed to occur at twice the expected rate .. something like that, so I started using G:Vars for that part. But, I wonder if playing around with <Update Hidden= will help. I have never used it before, so I wonder if the default is "Yes". I might want "No".Rgds,Bob

Go Pack

yeah, I figured you were a Packers fan

BIG FLAW ! -While testing today a flaw was discovered where as if there are 2 airports that share the same freq. when the 1st is searched/locked getting closer to the 2nd airport it would not update unless the freqs. were toggled. This required a whole different way of doing it. The search is now always running in the background and when a station is found string manipulation was necessary to store it so that the search can keep running.Roman <Gauge Name="COMTest" Version="1.0"><!-- Bitmap can be a light grey, size = 157,108 Named Test.bmp --> <Image Name="Test.bmp"/><Macro Name="c">C:fs9gps</Macro><Macro Name="reset"> 0 (>G:Var2) 0 (>G:Var3) 0 (>G:Var4) 0 (>G:Var5)</Macro><Macro Name="com">(A:COM1 ACTIVE FREQUENCY, MHZ)</Macro><!-- Reset the string digit holders if nothing is found that matches --><Macro Name="resetdig">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)</Macro><!-- Tear apart the found string and store them in digit holders --><Macro Name="set">(@c:WaypointAirportFrequencyName) 'Center' scmi 0 == if{ 'ASPC' s2 } els{ (@c:WaypointAirportIdent) s2 }l2 0 symb ord (>L:Dig0, number) l2 1 symb ord (>L:Dig1, number) l2 2 symb ord (>L:Dig2, number) l2 3 symb ord (>L:Dig3, number) (@c:WaypointAirportFrequencyName) s3 l3 'Approach' scmi 0 == if{ 'APPR' s3 }l3 'Unicom' scmi 0 == if{ 'UCOM' s3 } l3 'Clearance' scmi 0 == if{ 'CLRD' s3 } l3 'Ground' scmi 0 == if{ 'GND ' s3 } l3 'Tower' scmi 0 == if{ 'TWR ' s3 }l3 'Departure' scmi 0 == if{ 'DEP ' s3 } l3 'Center' scmi 0 == if{ 'CTR ' s3 } l3 'Multicom' scmi 0 == if{ 'MCOM' s3 } l3 0 symb ord (>L:Dig4, number) l3 1 symb ord (>L:Dig5, number) l3 2 symb ord (>L:Dig6, number) l3 3 symb ord (>L:Dig7, number)</Macro><!-- Vars descriptionGVAR1 = Com2 Freq holderGVAR2 = Nearest Airport Line SelectGVAR3 = Airport FoundGVAR4 = Nearest Airport Freq Line SeleectGVAR5 = TROUBLESHOOT - # of cycles between nearest airport transfer and waypoint airport readys1 l1 = Temp Holders2 l1 = Waypoint Airport Idents3 l3 = Waypoint FrequencyL:Dig# = Airport Ident and Feq. Name String Digit Holders --><Update><!-- Reset all on COM2 change --> @com s1 (G:Var1) != if{ l1 (>G:Var1) @reset @resetdig }<!-- Tell GPS system where you are --> (A:PLANE LATITUDE,Radians) (>@c:NearestAirportCurrentLatitude, Radians) (A:PLANE LONGITUDE,Radians) (>@c:NearestAirportCurrentLongitude, Radians) <!-- Dynamically set up database for nearest airport search --> (A:RADIO HEIGHT, feet) 2 * sqrt 0 max 25 + (>@c:NearestAirportMaximumDistance, NMiles) (A:RADIO HEIGHT, feet) 0.1 * near 25 max (>@c:NearestAirportMaximumItems)<!-- Transfer current nearest airport ICAO to waypoint so freqs. can be checked --> (@c:NearestAirportItemsNumber) 0 != (G:Var3) 0 == and if{ (G:Var2) (>@c:NearestAirportCurrentLine) (@c:NearestAirportCurrentICAO) (>@c:WaypointAirportICAO) 1 (>G:Var3) } <!-- Make sure waypoint is loaded, if so, check airport freq. to tuned freq., if matched save string and start over --> (@c:WaypointAirportIdent) (@c:NearestAirportCurrentIdent) scmi 0 == (G:Var3) 1 == and if{ (G:Var4) (>@c:WaypointAirportCurrentFrequency) (@c:WaypointAirportFrequencyValue,Mhz) @com == if{ @set @reset }<!-- 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{ @reset @resetdig } } }<!-- 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 <!-- 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<!-- TROUBLESHOOT - Find number of cycles between nearest airport transfer and waypoint airport ready -->(@c:WaypointAirportIdent) (@c:NearestAirportCurrentIdent) scmi 0 == (G:Var3) == ! if{ (G:Var5) ++ (>G:Var5) } els{ 0 (>G:Var5) }</Update><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%\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><Mouse><Area Name="Reset" Left="0" Top="0" Width="157" Height="108"><Cursor Type="Hand"/><Click Repeat="No">(>K:RELOAD_PANELS)</Click></Area></Mouse></Gauge>

While testing today a flaw was discovered whereas if there are 2 airports that share the same freq...

Roman - This would be a common occurrence for Approach and Departure frequencies. As I work on my code to display a list of 5 airports, I guess I would run into the issue you raise. I'll have a closer look. Very interesting. Bob

Added some optimization -- Why search through all 35 frequencies at KORD when 12 of those are nav ?? Used (@c:WaypointAirportFrequencyType) 1 > in the following section.<!-- 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{ @reset @resetdig } } }Also reduced the string length to 4 for both airport ident & comm type. I.E. "Tower" now = "TWR "Changed from COMM2 to COMM1 - Just easier to use GPS for comm tuning rather than "dialing it in", for testing.Added a cycle counter to count how many cycles it takes from the nearest airport --> waypoint airport transfer and when waypoint airport is ready. BIG notice,,, It varies! I'm getting between 1 & 9 cycles. IF... the code is correct.:( Added Multicom to the string reduction -- forgot that one.The full code will be updated here as changes are made - http://forum.avsim.n...ost__p__1837216 or post #22 in this topic.Roman

Edited September 29, 201015 yr by spokes2112

Added some optimization .... (@c:WaypointAirportFrequencyType) 1 >

I suppose you could also bypass WaypointAirportFrequencyType = 0 frequencies to speed it up, as well. For all I know, there may be more of these than ILS's in a given area. And as for the cycles required for Nearest to Waypoint, I also have been getting values up to 10 or more, and it varies. One thing I think I have noticed is that the gps module seems somewhat independent of cycle frequency that is set in <Update Frequency="XX">. At least for Update frequencies above about 5. Try setting MaxDistance and MaxItems to very large numbers then time the Nearest search with a watch. When I start a search then pause FS, the search seems to finish more quickly. All of this suggests to me that system resource demands may affect the speed of the gps searches, so it is important to use internal gps variable checks to regulate when queries can begin rather than a pre-determined number of cycle skips.

Roman,For frequency names, add FSS, Multicom, and CTAF.Bob

Roman,For frequency names, add FSS, Multicom, ATIS and CTAF.Bob

Bob, Yes I forgot Multicom . FSS, CTAF, ASOS, AWOS are already 4 or less digits.Roman

Bob, Yes I forgot Multicom . FSS, CTAF, ASOS, AWOS are already 4 or less digits.Roman

Ah, okay, now I see what you are doing.

Roman,Help me out to see if I am thinking about a few items correctly:Determining a realistic and appropriately small MaxDistance from line of sight logic using RADIO HEIGHT is very clever. Good idea! 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? 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.)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? In the code I posted in this thread, I stop the search and transfer when the frequency is matched, then simply display @C:WaypointAirportIdent and @C:WaypointAirportFrequencyName, which are still available because the search has been stopped.I will run into trouble, however, as I write code that lists the five nearest airport frequency matches. Then, I will have to store the string data but you've shown me a good way to go about that. I did not know that you could store sting information in the internal registers - never thought about it - and I did not think that one could store internal registers within the <Update> section and load them later, outside of the <Update>. But, it looks like you're doing that, and it seems to work. 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.Bob