Thanks – will have to check that out – maybe its not as difficult as I first imagined, especially, if one can use pre-existing Audio call outs.
1 Like
I have hardware radio tuners. With this mod my Com1/Nav1 knobs change freqs on the 430 and I can’t control the 530.
You need to start by telling us which plane you are flying or we can’t help you. This comment gives us zero information about what you’re doing.
Is this an in general situation, or when you have both a 530 and 430 in the cockpit. What if you are flying a Carenado plane with just a 530 in it?
Next, it would be interesting to know the code with which you are using to access the features of the gauges. What simvars are you accessing, what index?
I don’t have that issue. Confirm you didn’t copy config from COM1 to COM2, for example. I use SPAD, and the mod works fine for me.
1 Like
I have this issue in the classic(non g1000) C172. My hardware is 2x Propwash Simulations PWS155 radio displays using their FSX/P3D/MSFS simconnect plugin and FSUIPC7. Nothing is programmed in FSUIPC7( their plugin only requires the unregistered version of FSUIPC7). I just took the GNS530 mod out of my community folder and it still does frequencies as COM1/NAV 1 on both the 530 and 430, but at least the 530 is reacting now.
Switched planes: C152 and all four radios work properly. so It’s not a 530mod issue.
Thanks anyway folks.
You might want to take this to your own thread, as I doubt this has anything to do with the 530 mod.
This is from the Github page for this mod:
- U-turn bug: The airplane operates a 180° turn to come back to the last enroute waypoint if you activate an approach after the last enroute waypoint. I implemented a workaround in this MOD that consists of removing all enroute waypoints before activating the approach.
OK, me again. I know @ScorpionFilm422 has figured out a workaround/fix for this problem that works for his version of the 530 most of the time, but I’m curious if we know why this bug exists in the first place. People keep calling it an autopilot bug, but it’s not… The autopilot is doing precisely what it’s told to do, which in this case is to turn around and go back to a previously passed waypoint, or a seemingly made up one called “User” or “USR”, making it some sort of data error. Whether it’s in the source data or how it’s being accessed I couldn’t say, but I’m wondering if it’s something that’s going to be fixed from a big picture perspective?
I hope I’m explaining properly what my brain is trying to tell my fingers, but sometimes my fingers aren’t fast enough to keep up.
Thoughts or insights?
If I were designing a GPS and AP system, and a user loaded a flight plan, my own expectation would be the AP would guide the aircraft to join with the flight plan at the most efficient point it could be joined with given the current direction of flight and the direction of the flight plan.
Now, perhaps some users would actually want to go the first waypoint (silly users)… that could either be an option in the settings for the GPS, or, there could be an option when the user activates the flight plan or approach or SID or STAR that would ask:
- Merge with flightplan at closest point?
- Direct to first point
Unfortunatly, there appears to be a “Flight Plan Loading Issue” in the current version of GNS530 MOD (v26), where MSFS will CTD if the Flight Plan attached, is loaded into the GNS530, from the fpl530 folder.
The flight plan was generated in MSFS and saved.
It will load again, into MSFS, if loaded when on the non-flying WELCOME page, and when flying, displays correctly in the GNS530.
But if the same FP is loaded into the GNS530 when flying, MSFS will CTD.
Fpl5.PLN (5.3 KB)
This would indicate to me there is a BUG in the MOD’s loading of a good Flight Plan (in some cases, ie this Particular plan)
This is the 1st time I have seen this happen, but prior to this, all my FPs were in the USA.
This is my 1st FP for a flight across Japan. (so it being for Japan “may” be associated with this issue)
I got no issue with your flight plan. Loaded successfully in the GNS530 from the FPL catalog page.
Interesting – I wonder if it has anything to do with my installing Navigaph ??
Originally I made the Flight Plan from LNM, that has the latest naviGraph as its database.
That would not load – CTD.
Then I re-created the FP in MSFS (welcome page), and saved it.
On flying, it was loaded OK into the GNS530.
But when I sent to load that MSFS saved FP, into the GNS530 from the FPL Catalog page, that failed & cause a CTD.
I wonder if its one of those specific WPs causing it ?
I’ll try again, building up the FP, and testing as I add each WP, till it Crashes – (or loads !!)
Thanks for taking the time and testing it on your system … makes me a little confused now … but we will see …
Should I get a glide path on an RNAV approach with the GNS530 in the steam gauge c172? When I activate a RNAV approach I only seem to get horizontal guidance. ILS approaches seem to work just fine.
Another cosmetic one here, with a VOR.
For some reason, this VOR has an extremely tall row. Just tested this without Navigraph data, and it is the same.
I also have Navigraph, and it crashed for me too. Going to try now without it. This was in the event log:
Event log
Faulting application name: FlightSimulator.exe, version: 0.0.0.0, time stamp: 0x5fda32ba
Faulting module name: FlightSimulator.exe, version: 0.0.0.0, time stamp: 0x5fda32ba
Exception code: 0xc0000005
Fault offset: 0x000000000063c797
Faulting process ID: 0x2008
Faulting application start time: 0x01d6f80d370854fa
Faulting application path: C:\Program Files\WindowsApps\Microsoft.FlightSimulator_1.12.13.0_x64__8wekyb3d8bbwe\FlightSimulator.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.FlightSimulator_1.12.13.0_x64__8wekyb3d8bbwe\FlightSimulator.exe
Report ID: 06a90708-c711-42f3-905d-8df9b11d58e1
Faulting package full name: Microsoft.FlightSimulator_1.12.13.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App
It’s the same error message I have seen from random crashes that some believe are SimConnect related. Not here I guess, but it does make me wonder how useful those error logs really are to us.
Just tested the plan without Navigraph, and it works now. I had spawned at SCFA, near ■■■, so I could test both things at once, but I also noticed that the last leg of the flight plan was active for some reason.
I mention my location if it would affect this.
Loading it in LNM, TZT shows as a TACAN with Navigraph loaded. If I disable Navigraph, so I use MSFS data only, it becomes a DME. I’m going to try removing that waypoint from the plan, and see if it will then load with Navigraph data installed.
It makes no difference, it still crashes.
Fpl5_TZT_removed.PLN (5.0 KB)
Cutting it back to just FJFU to RJOO, it works. This is gonna suck! 
Okay, so this loads:
RJFU RJOF OYSTR RJOA ARIGI HABAR TZT ASANO RJOO
This does not:
RJFU RJOF OYSTR RJOA ARIGI HABAR TZT ASANO STEEL RJOO
No issue for me with your second flight plan. I’m using Navigraph too.
Now you have a strange distance in your picture of nearly 10 000NM.
Where were you when you have loaded your flight plan? At RJFU ?
No, I was killing two birds with one stone by spawning near that VOR I can’t type the name of. I’m done with that so now testing this flight plan of @N6722C
It’s looking like STEEL is the issue.
So this worked:
RJFU N0100F270 RJOF OYSTR RJOA ARIGI HABAR TZT ASANO RJOO
But this did not:
RJFU N0100F270 RJOF OYSTR RJOA ARIGI HABAR TZT ASANO MAIKO RJOO
Just send me your flight plans if you want me to test.
If you have your flight plan starting at RJFU, you should start the game at this airport.
This strange distance let me think that you were far away.
At this time the kernel cannot really estimate what is your current leg so that’s why the last leg becomes the active one with this long distance.
I think @N6722C already has. I was just playing around with it, and found that if STEEL is present it won’t load with Navigraph installed.
It looks like anything loaded after ASANO causes the plan to fail to load. STEEL, MAIKO, or TIGER, if present causes a crash. Just re-testing that.
I have also Navigraph but don’t have your issues.
I made the following:
- Starting the game at RJFU
- Loaded the flight plan from the FPL catalog page of the GNS530
No issues for both flight plans
Yes, ASANO then RJOO loads okay for me.
If I add any of the last three en-route waypoints it crashes. But if I remove Navigraph they all work.
I’m just going to try a completely different waypoint than those three to insert, then append the plan here if it crashes for me
So WAKIT works:
Aren’t waypoints supposed to be unique?
There is only one MAIKO though:
Adding MAIKO back, and it still works so I think I messed up my testing earlier:
I would assume that there is a an issue in the database, and that it doesn’t like multiple instances of STEEL or TIGER?