Maintenance Documentation – Garmin Update Issue
This flight started out as any normal flight would. It was a two day trip originating on November 2nd, with an overnight at KANE airport and ended on November 3rd in Milwaukee. During preflight on day 1 of the trip at KMKE airport it was noted that the Navigation databases were to expire on November 3 according to the initial start-up page on the MFD. Assuming maintenance action was already taken to update databases we continued with the flight. Upon landing at KFSD airport, a call was made to the captain that the databases had not been updated, and they were to expire on November 3rd. The question at the time was when they would expire.
Upon arrival at KANE airport for the completion of day 1 we as pilots were tasked with updating these databases via a database card stowed aboard the aircraft. We needed to download the JDM app to a computer and upload the databases to the card. Our first attempt was on the FBO computer but that did not work because administrative level access would not allow the application to be downloaded. The second attempt was on the first officer’s personal computer which is a MacBook Pro requiring a USB-C card reader. We went to the local Office Depot and purchased a USB-C to USB-A adapter and a USB-A multi card reader. We returned to the FBO and proceeded to download the JDM app to the personal computer and connect the card reader to the computer to be formatted. However, the JDM app had some issues. After calling a Maintenance personnel, it was discovered Jeppesen was having a “melt down” with many of its products that included the JDM app. Attempts were then made by the maintenance personnel to email the database file from another card that was supposed to be uploaded to the aircraft a few days prior. This attempt was unsuccessful.
After multiple attempts were made, we were approaching our end of duty time which happened to be a few minutes beyond 00:00Z making the start of November 3rd in Zulu time. After that time passed, we checked the initial start-up page on the MFD and the date had turned yellow. Further investigation by viewing the Database specific page stated the following “Databases have Expired”. Meaning databases expire at the start of the day listed.
00:18Z was the official end of our 14-hour duty day and we could no longer work on this issue. However, we still were receiving calls, text messages and emails from multiple individuals trying to resolve this issue. Approximately 40 minutes after our max duty time, a solution was settled on by management personnel. However, it was 1 hour and 15 minutes after our max duty time that I as the first officer (since I had the computer) received an email from the maintenance personnel with directions to download a database file from a Google Drive folder. I did not respond to this email.
It was decided that I would wake up at approximately 5:30am to determine if the JDM app was working and if so, download the databases from there. If not working, at 6am call management personnel to download a Garmin navigation database. Having experience with avionics, I downloaded the Garmin Database manager application that night to save time in the morning. This action took approximately 10 minutes to complete.
The JDM app was still down at 5:30am. I was on the phone with the management personnel at 6am to download the Garmin navigation database and the database was plugged into the aircraft shortly before 7am with a successful upload. On day two of the trip, I definitely felt more irritable and less rested and it showed throughout the flight as I felt I was not at the standard of performance I could have been at. The passengers never knew of the events that happened and at the end of day 2 were very happy with how the flights went.
There was pressure to make these flights work because the customer has shown a large potential of purchasing a share and potentially multiple shares of an aircraft based on the amount of flying he does and has been an excellent passenger to fly.
Technically speaking, I probably should not have accepted the flight. The last communication and work I did on my computer for the company (downloading Garmin database manager) was close to 9pm on day one and was up at 5:30am to start working again on day two. 8.5 hours of rest time. And after maxing out the duty day and probably going beyond. There was pressure to continue, and I probably should have said no but with making the customer happy, I continued.
ERC Notes:
- Report accepted as sole source.
- Flight departed before Garmin update could be uploaded.
- ERC recommended to add procedure to training manuals.
- Event will be revisited during next ERC meeting.
7/17/24 ERC:
- Procedure has been added to the GOM, with PIC having responsibility to ensure that FMS and GPS has been updated prior to each flight.
- FAA recommends to add a procedure to ensure that maintenance is notified.
12/11/24 ERC:
- GOM update has been released, currently under FAA review with PMI.
4/17/25 ERC:
- Changes have been implemented into GOM and training program.
Takeoff Deviation – Closed Runway
On Monday, 16 December at 0945 Local (1545z), our crew received a phone call from KDHN Airport Director [name] advising that a TMDX Operated Phenom 300 was observed (by Aircraft Rescue and Firefighting ARFF) departing a closed runway (Runway 14) at 2155 Local (0355z).
Company dispatch permission continuity was obtained and coordinated during preflight planning due to inability to obtain legal alternates for original destination of KATL. Mission was subsequently moved to KBHM as new destination to complete mission.
Re-release was accomplished with TMDX operations team in accordance with company operations and SOPs.
There were no NOTAMs referencing airport closure or closed runway published at time of perceived event by crew or TMDX Operations Team, ForeFlight NOTAMs, and ForeFlight NOTAM History.
All Airport operations were NORMAL at the time of perceived. All policies procedures and SOPs were complied during assigned mission. Normal Preflight, Normal Checklist, Normal Taxi route review and operations were accomplished. No abnormal indication of said closed runway, taxiway environments (white X signs and barricades were not installed or present in taxi route and runway environment).
Tower was scheduled to close at 2000 Local. Tower Controller announced that tower was closing over tower and switching to CTAF frequency at approximately 2000 Local as expected. No mention of runway or airport closure in ATIS was recorded or received by crew.
Pilot Controlled Lighting was ON and fully functional. Airport, taxiway, and runway lighting were normal.
Earlier in evening (post-arrival), during normal tower operations, crew heard ground operations/construction operations self-announcing movement within the airport environment, taxiways and runways. After tower closure, no ground operations/construction transmissions were broadcasted over airport CTAF frequency.
Previous aircraft was observed taxiing and departing runway 14 prior to perceived event and standard CTAF self-announcements were completed at least 5 times (starting engines at ramp, taxing onto taxiway A, taxiing down A for Rwy 14, holding short at taxiway and runway). Flight crew announced taking runway 14 after clearing approach and departure path. No radio traffic or responses to any CTAF announcements were received.
No barriers or obstructions were installed on taxiway environment preventing operations of said closed runway. Crew contacted Cairns approach 3 separate times to obtain clearance and clearance void time for departure (20:28L, 20:36L, and 21:50L) on phone number [phone number]. After initial contact, Controller requested a callback after controlling and managing Airline Carrier Endeavor Airlines CRJ successfully landed runway 14 at KDHN. No mention or discussion involving runway or airport closures at KDHN was advised at any time.
Normal taxi, takeoff and flight operations enroute to KBHM was accomplished safely and in accordance with company GOM and SOPs.
ERC Notes:
- Event investigated internally with FAA.
- NOTAM was posted minutes prior to departure.
- Departure issued take off on runway in question.
- Airfield had no markings of runway being closed.
- No fault of reporting crew.
In-flight Diversion – Runway Switch
During the JAKIE 4 Arrival to KTEB we were cleared to hold at MAZIE intersection as published. This was not a surprise and the weather in the area was heavy rain with gusting winds. Shortly thereafter, we were advised that KTEB was not accepting any additional arrivals due to LaGuardia’s change in landing runway. We were also advised that this was an indefinite delay.
Given the indefinite delay to KTEB, we requested to proceed to KEWR. While being vectored at 3000’ for the ILS to RWY 22L to Newark, approach control assigned us a heading and to intercept the final approach course but failed to clear us for the ILS Approach. We intercepted the final approach course as assigned. Approach Control was very busy, and communications were being stepped-on thus we were unable to contact approach control to obtain clearance to commence the ILS 22L approach. Without an approach clearance we maintained the last assigned altitude of 3000’ and tracked the ILS 22L final course.
Once we were able to contact approach control, they advised us to contact Newark tower. Tower told us to maintain 3000’ and then shortly thereafter assigned a vector to the west, to climb to 5000’ and contact approach control. We contacted approach control, and the controller apologized for not clearing us for the ILS 22L approach.
On the second attempt for an ILS 22L approach, we were assigned a heading, but not assigned to intercept the final approach or cleared for the final approach. Once again, the approach frequency was very busy with communications that were being stepped-on. This time we were able to contact approach control who cleared us for the ILS 22L approach. Immediately after that transmission a different voice (guessing a controller supervisor) came on the frequency and told us we had been cleared the approach and for people to listen-up. We completed the ILS 22L approach, landed and taxied to the FBO without any additional issues.
Note; the frequency was extremely congested with the weather etc. and people were stepping all over each other. Both pilots were monitoring the frequency and verifying between ourselves the instructions because of the heavy workload.
Contributing Factors:
- Weather: heavy rain with gusty winds
- Traffic Congestion: at 1730L there was a lot of traffic in the NE airspace and LaGuardia was switching landing runways
- Communications: approach control was saturated with communications that were being stepped-on
- Diversion: we were not the only aircraft diverting due to KTEB not accepting any additional aircraft
- Clearance Verification: if I recall correctly approach control is required to confirm that pilots read back/acknowledge approach clearances
ERC Notes:
- Sole source event as of 3/27.
- Event to be discussed during pilot safety meeting.
- Operator to plan for alternative airfields in case of anticipated weather in NY airspace.
- Crew acted appropriately to mitigate the situation.
