CPDLC: PROVIDER SETUP, REQUEST, RESPONSE AND FLIGHT-PLAN ACTION
CPDLC exchanges controller-pilot messages; it does not make an accepted MCDU route into a clearance. Establish the selected communications provider, available service and flight identity before a request. Fenix's official tutorial confirms the capability context. The concrete menu example here is specifically BeyondATC's own documented Fenix integration, not an assumed identical setup for Hoppie or every online network. [94, Official Fenix CPDLC tutorial link; capability context] [111, Initial setup; Pre-Departure Clearance; Logon to center; Handoffs] [112, Logon-code, callsign and CPDLC-service distinctions]
1. Configure the chosen service. BeyondATC documents selecting it under ACARS Provider in the Fenix App's Product Configuration. It uses MCDU AOC/ATC functions and the DCDU for received ATC messages. Follow the provider's actual current instructions if another service is selected. In particular, Hoppie's user credential and a four-letter ATC-station logon are different identifiers; one must not be typed into a field intended for the other. [94, Official Fenix CPDLC tutorial link; capability context] [111, Initial setup; Pre-Departure Clearance; Logon to center; Handoffs] [112, Logon-code, callsign and CPDLC-service distinctions]
2. Initialize the actual flight. The BeyondATC path uses MCDU MENU, AOC MENU, FLT INIT and INIT DATA REQ, followed by INIT REQUEST and review. Its FLT NBR must match the intended ATC callsign. The offline MC2026 example is not an assigned network identity. Reconcile identity before requesting a clearance so that the response can be associated with the flight actually filed with that service. [94, Official Fenix CPDLC tutorial link; capability context] [111, Initial setup; Pre-Departure Clearance; Logon to center; Handoffs] [112, Logon-code, callsign and CPDLC-service distinctions]
3. Request and read the clearance. In that provider's example, AOC ATC REQ leads to PRE DEP CLRNCE, with current gate, ATIS and station information before SEND. Read the returned DCDU message in full and respond as required, including WILCO only when appropriate. There is no automatic entitlement to send an example request to a live controller while merely reading this chapter. [94, Official Fenix CPDLC tutorial link; capability context] [111, Initial setup; Pre-Departure Clearance; Logon to center; Handoffs] [112, Logon-code, callsign and CPDLC-service distinctions]
4. Apply the clearance as a separate cockpit task. Compare its route, runway/procedure, level and other instructions with the prepared aircraft. Make and inspect the necessary flight-plan, FCU or transponder changes through their own supported interfaces. Acknowledging text is not proof those changes occurred. Conversely, completing them does not prove that a response was transmitted or accepted by the controller's system. [94, Official Fenix CPDLC tutorial link; capability context] [111, Initial setup; Pre-Departure Clearance; Logon to center; Handoffs] [112, Logon-code, callsign and CPDLC-service distinctions]
5. Handle unavailable service without guessing. Check provider/account identity, the actual station and its offered service, then follow the network's communication procedure. A communications timeout is not a reason to activate another navigation database. Keep the clearance and aircraft state understandable while resolving the connection. Detailed message classes, handoff behaviour and provider-specific limitations require the selected service's current documentation; they are not implied by a generic CPDLC label. [94, Official Fenix CPDLC tutorial link; capability context] [111, Initial setup; Pre-Departure Clearance; Logon to center; Handoffs] [112, Logon-code, callsign and CPDLC-service distinctions]