'TUNE LRA/AYT' - Airbus going into Antalya
Thread Starter
Join Date: Jul 2009
Location: Coast to Coast...
Posts: 202
Likes: 0
Received 0 Likes
on
0 Posts
'TUNE LRA/AYT' - Airbus going into Antalya
Flying into Antalya now for almost 10 years, I see this appear on the MCDU scratch pad a lot of the time. Has anybody made sense of it yet?
Join Date: Jul 2014
Location: Germany
Posts: 344
Likes: 0
Received 0 Likes
on
0 Posts
It reminds you to tune both the VOR located at the airport:
Lara VOR-DME (LRA) @ OurAirports
Lara VOR-DME (LRA) @ OurAirports
Thread Starter
Join Date: Jul 2009
Location: Coast to Coast...
Posts: 202
Likes: 0
Received 0 Likes
on
0 Posts
But we do. Depending on the procedure we might put LRA into VOR1 and AYT into VOR2. It then complains again, wanting AYT into VOR1. We do that then it wants LRA in VOR1 again! I will try it again just to be sure next time.
Only half a speed-brake
I've seen it happen many times too, not very frequently but repeatedly - yes. It is not a bug, it's feature.
The technical reason is that FMS logic suggests a certain NAVAID based on the procedure activated in the system. If you keep the RADNAV pg empty, or erase (*) whatever you have there when the message comes up, you would be able to observe what the FMS believes is the appropriate tuning.
It cannot be scrutinized from over here, as we have no way of knowing what procedure, leg sequence and active waypoint you had going on at the moment. Even if we did, we would need to see the definition of the legs (**) from the database dump, which may or may not include a "reference navaid" - that's where the FMS gets ideas from.
* = SOP, common sense, and airmanship requirements permitting
** = the FM DB coding does actually not consist of connected waypoints (as we may percieve), but track-to-WPT segments which are mostly made invisible to the pilot.
http://galileo.cs.telespazio.it/medu...inator_1.0.pdf
The technical reason is that FMS logic suggests a certain NAVAID based on the procedure activated in the system. If you keep the RADNAV pg empty, or erase (*) whatever you have there when the message comes up, you would be able to observe what the FMS believes is the appropriate tuning.
It cannot be scrutinized from over here, as we have no way of knowing what procedure, leg sequence and active waypoint you had going on at the moment. Even if we did, we would need to see the definition of the legs (**) from the database dump, which may or may not include a "reference navaid" - that's where the FMS gets ideas from.
* = SOP, common sense, and airmanship requirements permitting
** = the FM DB coding does actually not consist of connected waypoints (as we may percieve), but track-to-WPT segments which are mostly made invisible to the pilot.
http://galileo.cs.telespazio.it/medu...inator_1.0.pdf
Join Date: Mar 2017
Location: London
Posts: 172
Likes: 0
Received 0 Likes
on
0 Posts
Somebody mentioned to me that it was to do with the limited number of VOR heads available for position updating. So it is asking you to release the tuned VOR so it can use it for position updating in areas where there are limited DME's to fix the position. Could be wrong though.
