No, just a few fly the 318.

Just 27 at the time this was filmed

https://www.youtube.com/watch?v=noAyUIk89AU

With 130 shorthaul Airbuses in BA's fleet, and only 2 operating from LCY, crews would never get enough experience of flying from there if it was a common pool of pilots.

If you want to fly on the NAT tracks across the atlantic you have to be CPDLC equipped. This rule came in a year or so ago. (CPDLC is a more sophisticated version of ADS position reporting.)

An atlantic waypoint of say 53 degrees North, 30 degrees West is encoded in the FMS as 5320N. Without the database covering the atlantic you can construct the waypoint using lat and long but it would have a different appearance in the FMS (remember the early FMS "Green Goddess" atlantic waypoints of Wpt 01, 02 etc?) and the position report would not be recognised by Shanwick/Gander. Therefore the CPDLC data would not be valid and the aircraft would not be CPDLC compliant. So that means no atlantic crossing unless you go above or below the NAT tracks and I doubt the Airbus would have the performance or fuel capability to do that.

Quote from wiggy:
"However if they only had a European database loaded in the FMGC they won't have had any US navaids, SIDS and STARS, instrument approaches, possibly even the airport position in the database, and that can get very limiting these days, not just from a navigation POV but it can also impact aircraft systems (e.g only a possibility for the bus but based on another type there can be implications for EGPWS, pressurisation)...
"...for example you can't legitimately 'hand build' the likes of the increasingly common RNAV STARS and RNAV approaches in the FMGC or FMS...they have to be extracted from the database."

Yes, all very good points. I was rethinking this overnight. Another thing is that, in the (admittedly unlikely) event of complete GPS failure, no radio-updating of FMGS PPOS (present-position) would be available, due to the absence of DME station frequencies and positions. (Not that that would make any difference in mid-Atlantic, of course.) So you'd be stuck with the Mix-IRS position plus any residual bias correction.

I wonder if database content is included in the MEL (DDM).

Quote from suninmyeyes:
"An atlantic waypoint of say 53 degrees North, 30 degrees West is encoded in the FMS as 5320N."

Can you explain the "5320N", or is it a typo? Must admit I'd never heard of CPDLC... :O

From The BA Source webpage:

The BA Source |

Anybody know what the issue was? I've made a crossing or two, can't think of a situation where I would hold for 90 minutes and then proceed across. The only similar case I can remember was holding for an overflight clearance number for the subcontinent decades ago.

G-EUNB was ferried empty JFK-LHR today according to BA Source.

Chris

5320N is a naming convention for latlong waypoints used on the North Atlantic. It fits in with the usual 5-character format (like REFSO, etc).

5320N is 53 deg North, 20 deg West ( the West is assumed, hence 5320N)

These waypoints are all stored in the FMC/FMGC database, so you enter them as 5320N giving less chance of entry error etc.

An Atlantic routing may be from domestic routing to xxxxx (Oceanic entry point) to 5315N, 5520N, 5730N, 5840N, 5750N, 5660N, yyyyy (Oceanic exit point) then domestic routing to destination.

The 747-400's didn't have CPDLC when I retired in 2009, but basically it replaces the need for HF reports/requests every 10 degrees with automated data reports.

TB

You are of course right about the naming convention, I nearly replied with similar, then realised that Chris was very specifically asking why suninmyeyes wrote:

;):ooh: .......Chris I suspect it was a typo.

I have no idea of the technicalities of loading maps & nav.data int the a/c systems but, how long have BAW been operating this flight through EINN ? - & the ground crew suddenly think that the a/c is on a European service & load the wrong data ?! It seems rather too simplistic an excuse, don't you think ?

I think you're misunderstanding what happened when. The maps were uploaded at LHR by gingers who possibly never looked right when getting on and so didn't notice the J config (didn't even notice they were on a A318). The euro maps got them happily to EINN when the crew noticed the wrong maps - it wasn't ground crew at EINN who uploaded the wrong maps.

Sorry to sound like the old f**t that I am but please, please - in order to stop the thread degenerating again into stories about plotting can we stop using "map" (unless it is a techie term) when it seems the problem was an seemingly an incorrect nav database. AFAIK the aircraft didn't have a built in Electronic Flight Bag, maps/charts would have been carried on the crew's own iPads, as discussed earlier

....but yes, rumour has it the problem was generated in London, not at EINN.

Thanks Wiggy

Hadn't noticed that!

As I say, I don't have a great understanding of what went on. Just found it surprising that this confusion " apparently " occurred. Thanks for the explanation. I know a little bit more, now !

Deferring Nav Database With MEL.
 

I've had a trawl through the A318 MEL and there is no reference to dispatch with incorrect database. There is a mention in the FCOM about operations with an outdated Nav Database. In the 777 DDG There is a specific requirement for both Nav Databases to be installed and in date, DDG 34-61-01-03 to be precise!

Not sure about the bus/FMGC but would be interested to know how easy or difficult it is to check which database is installed and active on a 'bus". Certainly according to our FCOM the database check (preflight, Boeing) is simply:

"Verify that the navigation data base ACTIVE date range is current.".

That is it, no check of database ident....then again perhaps there's no danger of getting the wrong "sort" of database on a "worldwide type".

Looking at the history of BA's two A318s, between them they have had 5 spells at LHR on checks of 3 weeks' duration (I don't think they call them Majors any longer).

It could be that G-EUNA's most recent check is the first to have straddled a 4-weekly AIRAC update (2nd February in this instance), necessitating a database load, or maybe they just got it right on previous occasions.

G-EUNB should be due for a similar check shortly, I think we can be confident that we won't see a repetition of last week's incident. :O

For the MEL check MEL-Mi-22-70-02.

Thats what my A320 MEL says:

One may be inoperative or out of date provided that:
1)
The operative database must be up to date for routes, departures, arrival and approach procedures that require the use of Navigation Database for RNAV/RNP, and
2)
The operative database is available and used by the flight crew member(s) responsible for navigation, and
3)
Radio navigation aids, which are required to be flown for departure, arrival and approach procedures are manually tuned and identified.

Ther is an operational procedure attached to that, that quite clearly states that RNP 4 and RNAV 10 operations are not permitted in that case.

If both are out of date or inop one has to check for every used RNAV/RNP procedure way point used that there haven't been any changes from the installed database to the current AIRAC cycle.

Big Air MEL Item 22-70-02A states with regard to Navigation Databases, Number installed 2, Number Required 2, Must Be Installed And In Date. A database Which Is Out Of Date Is Considered To Be Inoperative. Just different company requirements perhaps.

Chris

Yes sorry it was a typo. 53 degrees north 30 west is encoded as 5330N

I remember crossing in the military in the 1970's. The guy in the left seat told me 'Son, in five years these position reports will all be on the satellite, we won't have to do HF anymore.' :D