Recommended Posts

Hi,

                I run voxATC ver 7.42 under Windows 10 and P3DV4.4. I have Orbx Global Scenery, Base, Vector and Landclass with REX Airports HD and Orbx ESSA. I also have FlyTampa Copenhagen (EKCH). My navdata is version Airac 1812. 

                I just did a second flight EKCH-EGCC with my PMDG 737 ng and had the same problem in both cases. I was on a Odin 2A departure from runway 04R (Flytampa scenery). VoxATC was up and running and everything seemed to be normal. When I got to CH368, 6000ft. I changed frequency to 119.90 (Kastrup departure) as requested. At CH 371 I was asked to contact Center on 119.42 and got a Fatal Error as a result. I have the error log for that phase if anyone is interested but right now I haven´t figured out how to include this as an attachment. I tried again at the end of the departure procedure (ODN) and the same error asked me to disable VoxATC.

I continued my flight without VoxATC, however, at LIBSO (beginning of approach to Manchester) I was able to restore contact with ATC again and fly the approach ROSUN1G to runway 24R. My instructed descent was way to late, however, and I had to declare a missed approach. This worked and I was able to land using VoxATC.

I would be grateful for your comments on this – is it scenery related and how do I fix it. On the second flight I added the line: <DescentRatio Value="3.5 /> to the VASettings file but it did not seem to have the desired effect.

I have since noted that my FlyTampa Copenhagen scenery had only one runway available in the P3DV4 scenario planner so I deleted the scenery.cfg file and allowed it to regenerate. This had the desired effect as far as available runways are concerned but did not eliminate the FATAL ERROR in VoxATC. 

If anyone has suggestions I would be most grateful.

 

John McWilliam

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Generally, this class of VOXATC errors stem from one of several sources, all of which are related to third party airports.

  1. The first possibility is that the airport in question has some inconsistencies in its geometry, such as orphaned parking spots and taxi links. Although this issue doesn't confuse the rather forgiving and simpleminded P3d4 ATC, it often causes logic problems in VOXATC, which generates an error. The airport may in fact be designed this way with a purpose, often to prevent specific types of AI aircraft from using certain parts of the taxiway network. The only way of determining whether this is the source of the error is to install Airport Design Editor (ADE and see what the airport BGL file (probably named something like EKCH_ADEX_FLYTAMPA.bgl) looks like. Although I own a number of FlyTampa airports and they all work flawlessly with VOXATC, I unfortunately do not own  FlyTampa Copenhagen. I have used ADE to fix certain airports and other people that use VOXATC have posted similar accounts.
  2. The second possibility is that there are two (or more) versions of the third party airport that are active in the P3d4 scenery library. The easiest way of determining which version is being used by VOXATC is to install the freeware Little NavMap, load the P3d4 scenery library in LNM and see what version of the airport is being used. Both ORBX Regions and Vector  (and some traffic packages like My Traffic 6) install many 3rd party versions of airports and the user may be totally unaware of such conflicts. This type of issue sometimes manifests itself additionally as autogen buildings and trees incorrectly displayed on aprons and taxiways.
  3. The third possibility is caused by the fact that the installed P3d4 navigation database (AIRAC 0612!) is completely out of date. This conflicts with what is being provided to the the aircraft by Navigraph (now AIRAC 1902). One way of fixing that inconsistency is to buy an additional subscription to fsaerodata. I wouldn't go to such lengths though, without ruling out the first two items above. A partial fix would be to download the Navigraph file that VOXATC uses for SIDs and STARs (Level D 767 format). Then enter the folder location of the navdata files in the VOXATC Advanced Settings utility. Most people put it in a navdata subfolder off the VOXATC parent folder:

                                         <drive>:\Program Files\Internal Workings\

The best way to display a log file is to upload the file to a cloud-based repository like Dropbox, One Drive, Google Drive, etc. and post a link to the file.

Also, keep in mind that one has to run the VOXATC Indexer utility every time either an airport or an aircraft is installed to the sim.  VOXATC maintains its own database of scenery and airports and the Indexer creates this database by reading P3d4's configuration files.

Share this post


Link to post
Share on other sites

I searched the web and discovered that there is an updated ADE file for FlyTampa Copenhagen that can be downloaded here:

http://www.flytampa.org/forum5745/viewtopic.php?f=28&amp;t=7013

It contains two separate replacement BGL files for different wind directions. There's no guarantee that this updated version will fix the VOXATC problem, but at least it allowed me to verify that the ADE file has only some minor errors with orphaned GA parking spots and those errors shouldn't be the source of your problem.

  • Like 1

Share this post


Link to post
Share on other sites

Thankyou for the detail in your reply - I am most grateful for your help. The situation at present is the following. I opted to eliminate your first two suggestions by reinstalling P3DV4.4 with the default scenery + Orbx Global. I did not installed my FlyTampa Copenhagen. After that I installed my PMDG 737 ng along with FS2Crew, EZCA 3.0 and VoxATC. Active Sky is on a remote and my Navgraph data came from AIRAC 1218.

I checked to see that everything was working and tried a test flight EKCH-EGCC using the ODN1C departure from runway 22R ( FS2Crew was not used). I noted the following:

1. VoxATC seemed to work on the ground, however, the taxilights did not appears after taxi clearance.

2. After takeoff I was asked to switch to the departure frequency and after responding the old FATAL ERROR appeared. I continued flying the departure and did not disable VoxATC.

3. I could hear other aircraft communicating with ATC but could not hear its response. I restarted Vox and was asked to contact Center. Again, my response after fequency change caused the FATAL ERROR.

4. The flight was terminated.

I tried a new scenario, EKCH-ESSA from runway 04R. This worked without any problem. (On the other hand, I have previously tried an ODN1C departure from 04R with a similar result to the above.) I then tried a flight EKCH-EHAM from runway 22R using a Lang1C departure. Again, no problem. So the runway does not seem to be the problem, rather the departure chosen.

I enclose an old error log:

https://www.dropbox.com/s/vfbdn3xcddzbhsk/error.log?dl=0

If you want I can do a rerun of the EKCH-EGCC ODN1C departure and sent you an updated error log.

John

Share this post


Link to post
Share on other sites

Yeah, delete error.log, run the scenario that generates the error and upload that error.log. 

6 hours ago, jsmcwilliam said:

1. VoxATC seemed to work on the ground, however, the taxilights did not appears after taxi clearance.

Do you have the option turned on in the settings?

Share this post


Link to post
Share on other sites
20 hours ago, jsmcwilliam said:

Thankyou for the detail in your reply - I am most grateful for your help. The situation at present is the following. I opted to eliminate your first two suggestions by reinstalling P3DV4.4 with the default scenery + Orbx Global. I did not installed my FlyTampa Copenhagen. After that I installed my PMDG 737 ng along with FS2Crew, EZCA 3.0 and VoxATC. Active Sky is on a remote and my Navgraph data came from AIRAC 1218.

I checked to see that everything was working and tried a test flight EKCH-EGCC using the ODN1C departure from runway 22R ( FS2Crew was not used). I noted the following:

1. VoxATC seemed to work on the ground, however, the taxilights did not appears after taxi clearance.

2. After takeoff I was asked to switch to the departure frequency and after responding the old FATAL ERROR appeared. I continued flying the departure and did not disable VoxATC.

3. I could hear other aircraft communicating with ATC but could not hear its response. I restarted Vox and was asked to contact Center. Again, my response after fequency change caused the FATAL ERROR.

4. The flight was terminated.

I tried a new scenario, EKCH-ESSA from runway 04R. This worked without any problem. (On the other hand, I have previously tried an ODN1C departure from 04R with a similar result to the above.) I then tried a flight EKCH-EHAM from runway 22R using a Lang1C departure. Again, no problem. So the runway does not seem to be the problem, rather the departure chosen.

I enclose an old error log:

https://www.dropbox.com/s/vfbdn3xcddzbhsk/error.log?dl=0

If you want I can do a rerun of the EKCH-EGCC ODN1C departure and sent you an updated error log.

John

About the no taxilights, it's because EKCH doesn't have ground control...

For airports that do not have ground control: " Press '0' to display the options menu and then press 1 'Show/Hide taxi route'.
Your taxi route will be indicated by a series of purple cones positioned about a metre above the
taxi way, pointing in the direction of the taxi destination. The threshold of the destination runway
or the parking position is marked by two cones apex to apex. The 'Show/Hide taxi route' menu
item toggles the display of the taxi route."

Share this post


Link to post
Share on other sites

My setup has been simplified and now consists of P3DV4 with Voxatc, default scenery, EZCA and my PMDG 737 ngx. I made a fresh install of Voxatc after running repairs on the P3DV4 Content, Client and Scenery. I repeated the ODN2A departure from runway 04R starting at the gate. The FATAL ERROR appeared as expected at the handover from tower to departure just as I was preparing for a left turnout. I enclose the error log here: https://www.dropbox.com/s/vfbdn3xcddzbhsk/error.log?dl=0

As I said before I'm grateful if you can shed light on this problem and find a solution.

John

Share this post


Link to post
Share on other sites

Not being the developer of VOXATC I can only speculate as to what's wrong. The last entries in the logfile from the last flight:

Quote

17:19:48.0221606 Current Position = 55.790325209237 12.6721429250395 6000.79525577605 Log Start 02/15/2019 17:19:59

indicate that VOXATC could not determine the target position of the user aircraft:

Quote

ATSO exception Target position not valid    at com.intworkings.voxatc.ProcedureSegmentBase.TargetPositionValid(Position posIn, Double heading)
   at com.intworkings.voxatc.IntcSegment.GetNextPosition(Position posIn)

As an aside, you also are showing a lot of errors associated with VOXATC being unable to obtain the weather data:

Quote

SCE:: SIMCON EXCEPTION=15  SendID=81  Index=-1  cbData=24 call=GetMetar

Let me look at the logfile a bit further, but that's all I can come up with ATM.

 

Share this post


Link to post
Share on other sites

Could you upload to Dropbox the flightplan that you used for the sim session that corresponds to the logfile? Thanks. In the interim you can try something. Download the AIRAC 1812 from your Navigraph account for the LevelD 767 and install manually it to this folder:

<drive>:\Program Files\Internal Workings\VoxATC P3D 4\navdata

In the VOXATC Advanced Settings dialog enter that folder name in the Navdata edit box by browsing to it. Then run the VOXATC Indexer and run the sim again using the scenario in your last post. Also, do you have any other logfiles in:

C:\Users\<USERNAME>\AppData\Roaming\Internal Workings\VoxATC P3D 4

other than error.log? With logging set to enabled in Advanced Settings, VOXATC produces a host of small logfiles for each comm frequency and each AI aircraft. I might need to look at some of those files also.

Share this post


Link to post
Share on other sites

Your flightplan has a SID and a STAR in it, which is okay as long as the waypoints are present in t he sim's database. Further, if any waypoints (procedural or enroute) are present in AIRAC 1812, but missing from the sim's database (AIRAC 0612), VOXATC cannot route the aircraft properly. You should be able to see this in P3d4, by opening up the flightplan window. I still have FSX installed with its legacy navaid database, so I checked FSX with Little NavMap. The following waypoints in your flightplan are not in the legacy FSX/P3D (AIRAC 0612) database:

NAVDA BAVTA ABKAS ROVNI

Note that those waypoints might be updated by one of your 3rd party airports, but I have no way of knowing that. In LNM, a missing flightplan leg is tagged as a bright red color. Again, the P3d flightplan window might show you what waypoints are missing. The P3d ATC ignores missing navaids and waypoints, but VOXATC is like the real world. If you file an incorrect flightplan, someone's going to complain.:ohmy: 

There are easy ways of fixing inconsistent AIRACs and not so easy ways. The easiest way is to delete the 4 waypoints from the flightplan. The second way is easy, but that entails buying a subscription to fsaerodata, so that your aircraft navigation database and the sim's database match. Both would then be Navigraph AIRAC 1902. The hard way is to go to this website and download a donationware version of AIRAC 1902. The ILS, NDB and VOR updates are here:

http://www.aero.sors.fr/navaids3.html

The enroute waypoint update is here:

http://www.aero.sors.fr/navint.html

The LevelD 767 download from Navigraph will update the SIDs, STARs and all their waypoints to AIRAC 1902. Unfortunately this still leaves comm frequencies that are out of date, which can also be confusing when VOXATC tells you to contact the tower on 118.2 and its been changed to 119.4. The donationware approach is a bit too complicated to maintain on a regular basis, so I gave up doing so several years ago and decide to pay for fsaerodata, which is fairly easy to install and update. It ends up being about how much money that you want to spend. 

Have a good weekend and we can talk more about this next week.

 

 

 

Edited by jabloomf1230

Share this post


Link to post
Share on other sites

I've lost track of what versions of the two airports are installed in your setup. If they are stock versions, they will be lower in priority than fsaerodata's folders in the P3d4 scenery library. If either airport is a 3rd party version, it could have either a  higher or a lower priority. You should use Little NavMap yourself to make sure that the PLN file is valid.

Anyway, I'll take a look at the two files.

EDIT: From the logfile, it appears that you are using only stock airports. You are still getting SimConnect exception 15 indicating that VOXATC is not able to retrieve METARs from the P3d4. Are you sure that your network setup of ASP4 is working correctly?  I'm going to fly that flightplan and see what happens.

Edited by jabloomf1230

Share this post


Link to post
Share on other sites

John,

I flew the flightplan and the exact same error occurred for me. By moving along the flightplan by re-enabling VOXATC when it displayed FATAL ERROR, I discovered that the error messages stopped once I reached a waypoint that was within London Center. Everything worked okay enroute until I was instructed to contact Approach and then I just got more errors from VOXATC.

So, I'm going to experiment with other flightplans out of Kastrup and into Manchester to see if I can understand what's happening.

One thing that you can try in the interim is to use a flightplan in the sim that doesn't explicitly include the waypoints of the SID and the STAR, except for the transition waypoint for each. That type of planning is slightly more realistic anyway, as ATC usually assigns the SID and STAR depending on the runways in use. There's more about this on p 58 of the VOXATC manual.

The flightplan then would be:

EKCH --> ODN --> RIDSI-->NAVDA  --> BAVTA-->ABKAS  -->GOLUM--> LESRA--> INPUT-->ROPAL --> ASKAM--> NIGOL--> ROVNI--> LIBSO--> EGCC

Jay

Share this post


Link to post
Share on other sites

The plot thickens! I have installed Little NavMap but it will take me a little time to acquaint myself with how it works. I have flown a Lang1C departure EKCH/EHAM and EKCH/ESSA departure without problem so the problem seems to be limited to EKCH/EGCC and specifically ODN departures. My setup is without third party scenery at present. A while ago I did a flight to EGCC and like you I restarted VoxATC at intervals along the route. My experience was similar, however, I was able to fly into Manchester but the descent profile given by VoxATC was way to late resulting too high altitude on approach followed by a missed approach senario which VoxATC handled satisfactorily.

I have since done the following:

1. Moved my installation of Level-D Simulations navdata from my E:\ drive to the recommended sim root directory (p58 in VoxATC manual).

2. Removed the SID/STAR waypoints according to your suggestion above.

3. Ran the indexer and runway numbers utilities.

4. Flew the EKCH/EGCC departure (ODN1C) departure without any hitches.

My conclusion is that somewhere along the ODN1C departure there is something (? waypoint) which generates a FATAL ERROR in VoxATC. I would not seem to be a frequency since they were all used during the LANG1C departure and did not cause any problem. I future I will program the my flightplans direct to the transition. I will try the approach to Manchester ASAP to see how that goes.

John

https://www.dropbox.com/s/002ryqglpuwk7a0/EKCHEGCC01.pln?dl=0

https://www.dropbox.com/s/vfbdn3xcddzbhsk/error.log?dl=0

Share this post


Link to post
Share on other sites

Also, just so we are using the same dataset, did you manually update the magnetic declination and ARTCC/FIR  BGL files as per the fsaerodata instructions? That update won't impact this odd VOXATC error but it cleans up a few more inconsistencies in the P3d4 navigation database.

I can post instructions here on how to do the manual update if you need that.

Share this post


Link to post
Share on other sites

I usually post here using my cell phone, so I try to wait for longer discussions until I get access to my computer. Here you go.

2019 Magnetic Variation

The default P3d4 file magdec.bgl is located here:

<drive>:\Program Files\Lockheed Martin\Prepar3D v4\Scenery\BASE\Scenery

The fsaerodata should automatically install the new version and rename the old version as magdec.bgl.FSAD

But if for some reason this doesn't happen, then the 2019 version of magdec.bgl is located here:

C:\Users\<Username>\Documents\fsAerodata Files\Navigation Data\MagVar   (C:\Users\<Username>\Documents\ is the actual path of your Windows Documents library)

and can be copied to the ..Scenery\BASE\Scenery folder. This only needs to be done each January.

AIRAC 19xx ARTCC/FIR Frequencies

Similarly, the default P3d4 ARTCC/FIR center comm frequency data file bvcf.bgl is located here:

<drive>:\Program Files\Lockheed Martin\Prepar3D v4\Scenery\World\scenery

The most recent AIRAC version of the file is named fsad_airspace_FIR.BGL and is located here:

C:\Users\<Username>\Documents\fsAerodata Files\Navigation Data\Navaids

If it already hasn't been updated by fsaerodata, rename the original bvcf.bgl file to bvcf.bgl.FSAD. Then copy fsad_airspace_FIR.BGL to ..Scenery\World\Scenery and rename it to bvcf.bgl.

This manual update could be done with each new AIRAC, but generally speaking, center frequencies aren't updated all that often, so skipping a few cycles probably won't hurt anything. The fsaerodata online documentation suggests a few other manual edits that can be made to airport names, but you can read about that on their official forum. Keep in mind that fsaerodata does not update the physical layout of taxiways, gates and runways. That can only be done by either purchasing a 3rd party version of an airport or editing the stock airport with Airport Design editor (ADE). The developer of fsaerodata has previewed an upcoming product that will update all P3d4 airport geometry to the latest real world conditions, but no release date has been announced.

Share this post


Link to post
Share on other sites

Checked:

1. 2019 Magnetic Variation data

2. AIRAC 19xx ARTCC/FIR Frequencies data

They appear to be installed correctly. Furthermore:

1. When I installed Little NavMap I was asked if I wanted to use the Offline Global elevation data. I did not persue this. Is it important?

2. I will now install my FlyTampa Copenhagen scenery, Orbx Global mm and fly the full EKCH-EGCC plan and let you know how it goes.

3. It will be interesting to see if I VoxATC gives me a descent in time to make my approach to EGCC. Previously it has come too late for me to get down. There was an option mentioned on the forum to change the settings in VoxATC to make this more feasible. Have you any experience of that.

John

Share this post


Link to post
Share on other sites

1. No, it's not important unless you want to use TOC and TOD while creating a flightplan offline

2. I hope it works but I suspect there's still some factor that we are missing about the departure handoff.

3. I've never had to adjust that setting. One other related item, though. VOXATC expects one to fly the  correct transition altitude for any approach. I remember people complaining about this before.

 

 

Share this post


Link to post
Share on other sites

I have just flown EKCH-EGCC and all went well. I was worried about the TOD coming too late and requested a descent from FL360 at ROVNI. I was only cleared to FL320 and decided to continue down but was immediately told to return to FL320. Later I tried to ask for "lower" and was cleared to FL260 and a DALE1G approach. I had a limit at GOLES of 20,000 ft, however, Vox got me there and the rest of the approach worked perfectly. I will try again and let Vox have its own way to see if this works. I don't know if there is any point in digging deeper into the original issue of the ODN departures from EKCH. Let me know if you are interested.

Thanks again for your input - grately appreciated!

John

Share this post


Link to post
Share on other sites
1 hour ago, jsmcwilliam said:

I don't know if there is any point in digging deeper into the original issue of the ODN departures from EKCH.

I don't think so. There are so many factors at work and some of them may have nothing to do with VOXATC itself. We could spend a lot of time on the issue and not discover anything. The coding and resultant AI in VOXATC is IMO, truly brilliant, but like any AI, it's never quite perfect. I for one would like a bit of personalization and humor on the part of the VOXATC AI (I always expect it to surprise me with either a "good day" or some other informal banter but of course, that never happens.), but adding that element of randomness to the conversation might take just as much effort as that which was put into VOXATC itself.

 

1 hour ago, jsmcwilliam said:

Vox got me there and the rest of the approach worked perfectly.

I'm glad that you figured that out. I have a similar problem with a Caribbean airport and trying to establish out a workaround is sometimes just as much fun as flying the approach.

Share this post


Link to post
Share on other sites

I agree - recently I have been spending 80% of my time fixing things and 20 % flying. At the moment I am trying to sort problems with GSX Level 2. On the whole I find VoxATC to be an excellent alternative to online flying but am disappointed in their client support which is almost non existent.

Share this post


Link to post
Share on other sites

To make GSX 2 work correctly at large numbers of airports requires way too much work, at least for me. What I did was either stick to 3rd party airports with default SODE jetways or add my personally modeled SODE jetway to stock airports (It's possible to modify the demo SODE jetway with not too much work with Photoshop). That way, GSX 2 still handles the user's aircraft, it's just that the airport's own SODE jetway is utilized. With that approach, one also gets the VOXATC aircraft being automatically handled by the SODE jetways.

Where I used to spend my efforts was in maintaining the database of AIG AI aircraft and flight schedules. Now that's been automated by AIG, so I've been freed up from that burden. What's left is correcting airports with ADE, which is time-consuming, but it's not like I'm editing 25,000 airports.

Share this post


Link to post
Share on other sites
On 2/22/2019 at 11:35 AM, jabloomf1230 said:

I for one would like a bit of personalization and humor on the part of the VOXATC AI (I always expect it to surprise me with either a "good day" or some other informal banter but of course, that never happens.

I have found, that within limits, VoxATC will accept some personalization on your part. For example, you can say, “Thank you” instead of “Roger” after FSS closes or opens your flight plan, and this gets accepted as an appropriate response. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now