A320 FMGS B46

[spiliot]

Thanks JL for the update, it does give a few pointers to debug. My observations below:

1. I mainly had issues with going in and out fullscreen mode, but also when changing certain windows settings like adding a printer, changing windows defender active state, changing the windows taskbar autohide setting, changing monitor settings (enabling the extra displays I only use for flying or changing their virtual position), adding windows updates and finally skype autoupdating. Basically anything windows related. I had learned not to try anything windows related while flying, but sometimes especially during long flights it was inevitable. I don't think it has to do with P3D loosing focus, I do lots of stuff while P3D doesn't have focus and nothing breaks it but windows stuff.

2. Up to B45 I could restart FSXConnect and everything was back to normal. So on first sign of something going wrong (MW), I would pause, quickly restart FSXConnect (had it pinned on the taskbar just for this reason) and unpause, it would maybe take 3-5 seconds so I could even do it online in Vatsim without anyone noticing (or causing trouble to other traffic). Only downside was that on the ground I had to wait for APU to spool up again if it happened before engine start.

3. From B46, restarting FSXConnect doesn't seem to be helping at all. Once the values are lost they never come back.

4. Extra programs that use SimConnect are ActiveSky, vPilot, and one of my own. Neither one of those complains or gets any error messages when JH looses the connection.

5. I have teamviewer running on the background but I don't use it while flying and when I do it's only to connect to some other computer - no incoming connections.

Do you use the polling method for SimConnect (GetNextDispatch) or the Win32 message pushing (registering the window handle on connection)? Any ideas why wouldn't restarting FSXConnect get the connection back?

My next steps will be to run the sim again with only necessary applications running and see if anything has changed, as well as attempt to debug simconnect traffic through P3D. Hopefully I'll figure out something.

PS. The pushback behaviour changed in B46, but since you don't seem to know how that could have happened I'll try to figure it out myself. Do you use some other means to pushback?

[jeehell]

Thanks JL for the update, it does give a few pointers to debug. My observations below:

1. I mainly had issues with going in and out fullscreen mode, but also when changing certain windows settings like adding a printer, changing windows defender active state, changing the windows taskbar autohide setting, changing monitor settings (enabling the extra displays I only use for flying or changing their virtual position), adding windows updates and finally skype autoupdating. Basically anything windows related. I had learned not to try anything windows related while flying, but sometimes especially during long flights it was inevitable. I don't think it has to do with P3D loosing focus, I do lots of stuff while P3D doesn't have focus and nothing breaks it but windows stuff.

2. Up to B45 I could restart FSXConnect and everything was back to normal. So on first sign of something going wrong (MW), I would pause, quickly restart FSXConnect (had it pinned on the taskbar just for this reason) and unpause, it would maybe take 3-5 seconds so I could even do it online in Vatsim without anyone noticing (or causing trouble to other traffic). Only downside was that on the ground I had to wait for APU to spool up again if it happened before engine start.

3. From B46, restarting FSXConnect doesn't seem to be helping at all. Once the values are lost they never come back.

4. Extra programs that use SimConnect are ActiveSky, vPilot, and one of my own. Neither one of those complains or gets any error messages when JH looses the connection.

5. I have teamviewer running on the background but I don't use it while flying and when I do it's only to connect to some other computer - no incoming connections.

Do you use the polling method for SimConnect (GetNextDispatch) or the Win32 message pushing (registering the window handle on connection)? Any ideas why wouldn't restarting FSXConnect get the connection back?

My next steps will be to run the sim again with only necessary applications running and see if anything has changed, as well as attempt to debug simconnect traffic through P3D. Hopefully I'll figure out something.

PS. The pushback behaviour changed in B46, but since you don't seem to know how that could have happened I'll try to figure it out myself. Do you use some other means to pushback?

I use the windows messaging way, as I also use windows messages for IPC between apps (among other sharing protocols...). I suppose at some point something breaks the message pump of the FSXconnect window (which is what I always suspected with teamviewer issue). Though it is weird restarting it is not helping?
Have you been able to determine which system is better to handle frequent data exchange with P3D? I have to say I never tested that in depth...

[Rafape]

Are you saying using VOR or ADF matches up but not ILS? Have you updated your magnetic variation?

Yes, the "MAGDEC.BGL" of 01.01.2016, but still doing the same.

[Rafape]

Are you saying using VOR or ADF matches up but not ILS? Have you updated your magnetic variation?

Yes, the "MAGDEC.BGL" of 01.01.2016, but still doing the same.

And the "OVFY " in MCDU does not let me change it.

[emulov]

Today I installed the First Officer ND on a third computer. Then I performed the same flight again from LKPR to EDDF. And everything worked like a charm. I made several "DIRECT TO"s and also changed the Arrival Rwy and STAR/TRANSITION. Both NDs updated the route correctly. So for whatever reason, my problem with the ND seems to be gone. Before I never used the First Officer instruments.

Isak

[spiliot]

I have good news and bad news:

Good news is that teamviewer seems to be the culprit of all the problems I had with the connection being lost. I've only did this once but I was able to do everything that was causing issues in the past without a single failure! I'll monitor this more but I think we got down to it.

Bad news is that I debugged simconnect and I see that FSConnect registering itself at least 30 times in 20 seconds while the FMGS is loading. Some of those connections are closed later on, but lots stay open and unused, even after FSConnect is closed. The last connection to appear in the logs is also the one being used and is closed when FSConnect is closed.

This can also explain the multiple menu entries some users see, in the logs I can see several FSConnect connections registering the JH menus multiple times. Some of the extra connections might be attributed to my windows tests, but still point to a problem as reregistering a connection shouldn't be needed. Worth mentioning that even without changing any windows settings I still get two menu entries; one approximately when JH starts and one when it stops loading and is ready to use.

Finally, the simconnect logs also confirm that restarting FSXConnect doesn't get it to connect again, there are no further connections no matter how many times the program is restarted.

PS. Jean Luc I'll not go into details over frequent data exchange to FS here since I doubt it would be of interest to anyone else. We can follow up that from email.

[Eduardo Santos]

I have installed new version B46 and when i turn the external power on, I am unable to turn it on in the overhead section... None of the buttons move, I have no idea why.
Any ideas?
Thank you

[jeehell]

Rafape:
this kind of troubles is typical in two cases:
1. the navdata compilation process is not successful at scanning your bgl files
2. this is an iarport which has had major runways/ILS changes since FSX was released.

In your case, it most probably is the N°1.
Check in c:\A320FMGS\Navdata\fsscenery.cfg that the scenery.cfg path and the P3D root path are correct. If not, correct them then delete the bin files to recompile the navdata again.


For EVERYONE: it is NOT necessary to update the madgec file using Hervé Sors (though it might be useful if you use FS/P3D for other addons).
My software extracts the LLZ/GS data out of FSX/P3D bgl files (including addon scenery) and recomputes everything by comparing with real world data and up to date magnetic variation computations.
So for ILS's which just changed ID or Frequency, this is taken into account.
The problem lies with RWYs, LLZ and GS locations, which ARE very different in FSX and in real world data. So my software needs to know where your scenery is, compare it with navigraph/aerosoft. To keep runway/LLZ alignment, when possible (i.e. changes to RWY/LLZ are nil or limited) this works flawlessly.
On airports which added runways, or changed runways in a significant way, this is troublesome, for instance EDDB closed a runway, and started building another one, renaming 07R to 07L... I am working on a tool to counter that. But there are way over 1000 airports which had changes in the last 10 years (QFU changing due to magnetic variation, new RWYs, new ILS, different frequencies, etc...).
My approach is the only one which guarantees a total coherence between APPR charts and FMS data.



Anyway, as you can see below:

LEAS runway 29 ILS (AVS 110.10) is correctly reproduced (there is a very small 1 meter offset which can be due to rounding issues, or spherical earth models...).

[Rafape]

Rafape:
this kind of troubles is typical in two cases:
1. the navdata compilation process is not successful at scanning your bgl files
2. this is an iarport which has had major runways/ILS changes since FSX was released.

In your case, it most probably is the N°1.
Check in c:\A320FMGS\Navdata\fsscenery.cfg that the scenery.cfg path and the P3D root path are correct. If not, correct them then delete the bin files to recompile the navdata again.


For EVERYONE: it is NOT necessary to update the madgec file using Hervé Sors (though it might be useful if you use FS/P3D for other addons).
My software extracts the LLZ/GS data out of FSX/P3D bgl files (including addon scenery) and recomputes everything by comparing with real world data and up to date magnetic variation computations.
So for ILS's which just changed ID or Frequency, this is taken into account.
The problem lies with RWYs, LLZ and GS locations, which ARE very different in FSX and in real world data. So my software needs to know where your scenery is, compare it with navigraph/aerosoft. To keep runway/LLZ alignment, when possible (i.e. changes to RWY/LLZ are nil or limited) this works flawlessly.
On airports which added runways, or changed runways in a significant way, this is troublesome, for instance EDDB closed a runway, and started building another one, renaming 07R to 07L... I am working on a tool to counter that. But there are way over 1000 airports which had changes in the last 10 years (QFU changing due to magnetic variation, new RWYs, new ILS, different frequencies, etc...).
My approach is the only one which guarantees a total coherence between APPR charts and FMS data.



Anyway, as you can see below:

LEAS runway 29 ILS (AVS 110.10) is correctly reproduced (there is a very small 1 meter offset which can be due to rounding issues, or spherical earth models...).

JL thank you very much. I'll look to see, but all the same I uninstall and install again. It happens at several airports both in P3D and addons.

Nor did I get modify OVFY.

Thank's for your time! 😉

[OmniAtlas]

I have installed new version B46 and when i turn the external power on, I am unable to turn it on in the overhead section... None of the buttons move, I have no idea why.
Any ideas?
Thank you

This happens at times. Shut off FMGS. Restart and wait for server to complete its startup. Might be a simconnect issue others have mentioned.