Fatal Error On transmit after changing new agency Frequency

[jabloomf1230]

I think that this might be the same kind of issue as with the sim's stock ILS. Those ILS have changed a lot since AIRAC 0612, so it makes sense to update the APX files or they will continue to persist with either the wrong location or frequency. In contrast, I doubt that very many VOR and NDB names have changed since then.

As to the duplicate ID, it doesn't matter whether a Navaid has a duplicate ID in some other region, but I think the VOR ID at OBBI was changed just because there are a number of RL scheduled flights from the UK to Bahrain and somebody must of thought that changing BAH to BHR was a good idea.

In any case, VOXATC thinks that BAH is also a legitimate VOR name for the OBBI VOR approaches. The VOXATC error logs show that something is duplicated in the approach information for OBBI. Originally, I thought that it was the transitions, but that isn't the case, because other airports show duplicate VORDME transitions. That only leaves the option that there must be an approach component that can't be resolved by the enumeration. I doubt that it's duplicate waypoints, and I was able to make the OBBI ILS approaches work by creating a new OBBI with ADE. So my guess is that VOXATC attempts to collect and store the OBBI approaches and encounters two VORs at the same location, one from the stock airport and one from the most recent AIRAC. I also wonder what other ATC apps do with this airport. Even the default ATC has to figure out how to ignore the stock VOR.

[jabloomf1230]

I managed to sift through my VOXATC logfiles for OBBI and here is a snippet that shows that VOXATC is directing me to the BAH VOR:

https://www.dropbox.com/s/1l2d63d8480wo ... e.txt?dl=0

[jabloomf1230]

I asked the experts on FSDeveloper.com. The only way to get rid of a duplicate VOR is to update the stock APX file:

https://www.fsdeveloper.com/forum/threa ... ost-820080

[fsaerodata]

Unlike NDB's or ILS, there are no VORs stored in the airport files. All are located in the NVX...as enroute Navaids. Actually they are completely replaced by new ones on our database. Nevertheless, some add-ons include VORs, and thus they may appear as duplicates with FSAD active.
BR

[jabloomf1230]

Now i'm really confused. The APX files have the names for each VOR that's associated with a specific airport, even though the NVX files have the actual information about each VOR (lat long,DME, etc.). In any case, my NVX files are the default files from the sim and not anything that fsaerodata has installed. It looks to me that VOXATC is programmed to read the VOR information from the NVX files, no matter what else is installed at a higher priority in the scenery library. Sounds similar to the previous problem with the FIR/ARTCC file (bvcf.bgl) which has to be in the ...scenery/world/scenery folder or VOXATC doesn't find it.

[Julaibi]

That it’s looks a bit complicated

[jabloomf1230]

That it’s looks a bit complicated

Julaibi,

I made an updated airport with Airport Design Editor that at least allowed me to not get the FATAL ERROR when contacting Bahrain approach. I was able to do both visual and ILS approaches at OBBI, but when requesting a VORDME approach VOXATC sometimes worked and sometimes it threw a error message. I'm still testing a few other options, but it seems like OBBI is an unusual circumstance because the VOR was recently renamed and relocated and for reason that is not obvious, VOXATC is not picking up the revision contained in fsaerodata. It's really up to the VOXATC developer to fix this, but there may be a workaround, since it appears to be happening only at OBBI.

Jay

[Julaibi]

I just finished Flying with same leg but, without FsAerodata the flight was in order (sweet) from push back all the way to taxi to gate without any Fatal error Disable.