A lot of my flights are in and around Norway. Great scenery (both payware and AoN), interesting lighting and weather, plus an abundance of available background chatter covering most of the major airports. Put all that together and it can be quite immersive. One particular airport is giving me problems though.

Alta/ENAT in the far north, has a single controller covering Tower and Approach on 120.400. That information is displayed on Navigraph plates and it is presumably Navigraph data which Pilot2ATC reads initially? From what I can make out that information needs to be read by Pilot2ATC correctly in order for ATC to work properly, and for background chatter to work as intended (if using the Airport structure).

I have a Navigraph subscription and everything is updated with the current AIRAC cycle. I'm running Pilot2ATC v2.6.3.2x64_PublicBeta6a.

Mr problem is that P2A reads the data correctly whilst disconnected, but incorrectly when connected to the sim (P3DV5.3 in my case). I guess this means the data in the addon scenery is incorrect and that I need to edit and recompile the airport.bgl in order for this to work properly? A check of the airport.bgl shows the discrepancy - 120.400 as Tower only, not Tower_App. This is where I'm having trouble - getting the freq to be read and displayed consistently as Alta Tower_App 120.400 when connected. If it's displayed as either Tower or Approach (as opposed to combined) the ATC sequences don't flow as expected. 

As far as I can tell, editing and compiling the .bgl in ADE is all going OK without any errors, but I am not really experienced with the software. I have edited the data so that there is an entry for Tower on 120.400, and another for Approach on 120.400 (there is no option for combined Tower_App as far as I can see). Having recompiled the airport I then replace the .bgl in the scenery folder, and run MakeRwys.exe and import the airport in Taxi Mnt for good measure. But it still doesn't work consistently in Pilot2ATC - sometimes displaying as Alta Tower 120.400, sometimes as Alta Approach 120.400 (depending on location of aircraft). I guess I'm doing something wrong, or missing a step somewhere. Or maybe I've completely misunderstood how P2A reads the data. It seems to have evolved over time from what I have read.

Airport is at the top of scenery list and potential scenery conflicts have been investigated and disabled.

Thanks for reading and for any suggestions on how to make this work.
 

P2A does not use the Scenery data to get Controller frequencies or names.  In fact, other than updating taxiways and gates using MakeRunways, P2A does not know or care about scenery files.

If the issue you're having is with Chatter, Twr_Apr frequencies draw their chatter files from the Controller "App" folder, so for that airport, you would put your Tower and Approach chatter files in the "App" folder and leave the "Twr" folder blank.  This is only because you are using the Airport structure for Chatter.

Dave

 

 

Thanks for the prompt reply Dave. Apologies if I didn't explain the issue clearly.

The chatter part of it is only incidental really to the main issue, which is that for me P2A doesn't recognise the airport as having a combined controller when connected to the sim. It recognises the combined controller correctly as Twr_Apr until connection is made, but then changes once connected. So if for example I am inbound to the airport and the frequency is showing up as App only, P2A assumes there is no Tower freq and instructs me to make contact again when on the ground to cancel IFR. However, if it shows up as Tower but not Approach, then I don't get handed from Ctr to Twr until at Twr radius - completely bypassing the approach part. Both scenarios are unrealistic. Sorry if I didn't explain that very well initially. I didn't want to make the post too long.    

For what it's worth there is at least one other Norwegian airport with a combined Twr_Apr controller, ENCN, and for me that is recognised by P2A correctly when connected, and the P2A ATC exchanges are more or less what I would expect. The fact that one works and the other doesn't (in my setup) is what caught my attention initially. By that I mean that ENCN stays recognised as Twr_Apr after connection, but ENAT changes to either Twr or Apr - depending on where the aircraft is.

Thanks for the more detailed explanation.

I'll look into it and see if there is a bug of some sort.

Dave

For anyone interested Dave has implemented a fix for this which should be released in the next Public Beta. My understanding is that this issue was a unusual problem only affecting airports with a single controller performing dual functions.