I seem to mainly get that with airports where I have an addon.
This is an Asobo issue. We can’t do anything on our side.
NEW GTN 750 RELEASE V2.0.6
- User waypoints (in beta for now).
- speed up the display of nearest pages.
- DA62 package updated for SU5 compatibility.
- the OBS angle initial value is now taken from the HSI/CDI (depends on the aircraft).
- Adding the map field ETA (estimated time of arrival at waypoint).
- The old map ETA field is now ETA Dest (estimated time of arrival at destination).
- Added the map field ETE Dest (estimated time left to destination).
Great Job – a lot faster ..
Now a request that may slow them down again (a little)
NEAREST VOR, NDB, AIRPORT, WAYPOINT
are all NEAREST
So please consider
(1) Sorting them by Distance (closest at the top)
(2) Limiting their number by both Distance & Quantity – as the RL Garmin Does.
( I think its like 200nm & max of 50 - but please check the Garmin Docs)
Also, if doing the sort, maybe its not too much extra to remove Duplicates within the GTN750’s JS ??
When creating a FP, and entering Info, obviously there should be no range limits on what is presented, if there are true multiple matches, but if there are true multiple ICAO matches, then they should also be presented for selection sorted on Distance.
User Waypoint - Saving to play with over he weekend !! Great Addition
Is the DA62 the only updated aircraft package? Thanks.
I think all that is already working like this with standard Asobo code.
For duplicates, We prefer waiting for Asobo to fix the bug instead or building (again) a new workaround.
It’s not really necessary to sort duplicates since you will have generally max 2 or 3 of them and the region is displayed.
Fair enough, but how about the sort by nearest first in the list ?
When I am searching for Nearest WP (for example) do I really want to see waypoint 4000nm away filling the screen, and have to scroll down to see the local ones ?
GREAT “IF” Asobo fixes these issue, but for them, it would seem to be a very low priority in the Big Picture of all they do, but maybe a more important priority to a dedicated Garmin Dev.
Searching BGL files seems so 90’s .. if one is going to simulate a Garmin why not build a Garmin type database, and then use that … (apart from the fact it’s a big job .. but it’s what LNM has done very successfully)
Just thinking out Loud . 
They are already sorted by distance.
Airport max num 20 max distance 200
Intersection max num 50 max distance 100
VOR max num 25 max distance 200
NDB max num 20 max distance 200
User WP max num 20 max distance 200
My appolgies, I was posting from memory, and the circumstances were stated incorrectly.
As you say NEAREST works very well, as the Real World Garmin Does.
The Sort issue is when ADDING a waypoint to a Flight Plan,
If there are multiple DIFFERENT waypoints that match the search Critera, they do not dislpay by distance from aircraft, or what might be even better, distance from insertion posistion.
This is of much lesser importance (to me) as the issue of Sorting on Nearest not working (which of couse, it does sort 100% correctly)
You have the same for the 530.
I think your issues are most related to the aircraft itself. The GNT750 just retrieves the current GPS OBS value from the sim and displays the line on the map.
I think the mechanical OBS just sends an OBS_INC order to the sim even if you do it fast instead of setting the value taken from the NAV OBS.
I will check that with Just Flight.
For your honeycomb, this one should also set the correct sim variable.
There are 3 variables in the sim to change the GPS OBS value:
K:GPS_OBS_SET
K:GPS_OBS_INC
K:GPS_OBS_DEC
To check the OBS mode this is the variable A:GPS OBS ACTIVE
To guaranteed SYNC, the GPS_OBS_SET needs to be used to set the OBS to the current OBI heading when OBS is 1st tuned on, and then
Either: Re-synced continuously if OBS is ON, (Crude brute force)
or
Re-synced whenever the OBI is moved, if OBS is ON (More elegant & efficient method)
This completely eliminates the Inc-Dec by 1 / Inc-Dec by 10 issues, and the OBS is always guaranteed to be in sync with the Nav OBI heading.
Its not the movement of the OBS knob that is the important thing, it is syncing with the OBI heading that is the RESULT of moving the OBS Knob.
GPS OBS Demo
A bit long, but it gets the point across, as well as the dangers of being obsessed on the GPS, with your head in the cockpit, and NOT flying the plane.
In Hindsight, with all the Map RED, it should have been obvious that I was far too near the Ground .. LESSON LEARN – thankfully in the SIM, where I live to fly another day.
Hello,
I would like to be able to send SimConnect events such as VOR1_OBI_INC/DEC or modify the NAV_OBS:1 VAR in order to set the OBS angle of the GTN750 from SPAD.neXt or from devices like RealSimGear ones. When I try to do that the OBS buttons and the wheels on the VOR1s or HSIs turn fine in the cockpit, but the GTN750 OBS angle is not synced.
I have to send the H Event GTN750_KnobSmallInc/Dec to be able modify the angle of the OBS of the GTN750. But in this case it is not synced either with the cockpits VOR1 or HSI gauges.
Did I miss something or did I not understand the above explanations?
Could you send both events at the same time?
VOR 1 position and GPS OBS are different things.
There are 3 variables in the sim to change the GPS OBS value:
K:GPS_OBS_SET
K:GPS_OBS_INC
K:GPS_OBS_DEC
If you want to sync, get the NAV OBS value and set it as the GPS OBS value, but only when the OBS mode is active.
The OBS active mode is checked via the A:GPS OBS ACTIVE variable
And for efficiency, also ONLY when Nav OBS changes (although in the big picture, setting GPS-OBS every update cycle only causes a very very slight loss of efficiency by the extra processing every update)
Thank you for your feedbacks guys.
I also previously checked the OBS chapter in the “integration.pdf” doc file, but it is intended for aircraft development.
I can get and use “A:GPS DRIVES NAV1” (CDI select) in SPAD.neXt, but I’m not able to find “A:GPS OBS ACTIVE”.
And “K:GPS_OBS_INC” and “K:GPS_OBS_INC” are also not available at SPAD level.
Am I wrong?
I don’t know about SPAD.
THe integration.pdf will be soon changed about the OBS.
OK, so in these last exchanges, we have to consider these data and events (K:GPS_OBS_SET, K:GPS_OBS_INC, K:GPS_OBS_DEC, A:GPS OBS ACTIVE) to be only accessible in the sim but not exposed to end user through SimConnect, HEvents or as LVARs?
By the way, PMS50_GTN750_RUNNING LVAR is externally exposed and readable via SPAD. So maybe will it be possible to have GPS variables like it? And new HEvents like GTN750_HomePush, GTN750_DirectToPush, GTN750_VolInc… that are already available?
Yes, it could have been a workaround for some devices, but with no sync guarantee (as we need to know the “A:GPS OBS ACTIVE” state). In the other way it will also not work when using the GTN750 knob with the mouse in the cockpit.