Current limitation
An apply only lands if DJI Fly has been opened first to wake the controller-to-aircraft command relay; the link then stays warm for a while after DJI Fly closes. Proven in the logs: two identical attempts, one 38 responses (relay warm) and one 0 responses (cold), with the aircraft "detected" in both.
Goal
Have the app initialise the relay itself, so users can go straight to FCC Unlock without the DJI Fly warm-up.
Direction
DJI Fly sends a session-init handshake over the MFi link that brings the RC→aircraft relay up. We already send a 2-frame bootstrap + keepalives; that is enough to talk to the RC but not (always) to make it relay to the aircraft. Capture / infer the additional init DJI Fly sends and replicate the minimum needed.
Approach
- Dump All Traffic is under FCC → Diagnostics and shows the frames this app receives. It can compare incoming traffic on cold and warmed sessions, but it does not capture DJI Fly outgoing commands.
- Obtain a separate capture of the DJI Fly app-to-RC handshake before attempting to reproduce its initialisation.
- Identify the frame(s) that flip the RC into relaying, add them to the connect sequence.
- Success = 38 responses on a cold start, no DJI Fly needed.
Reference
ExternalAccessoryTransport (session), FccController.sendBootstrap, keepalives in DumplTransport.swift.
Status, synced with v1.7 (build 8), 2026-09-09
The warmth gate (v1.5, linkIsWarm()) now tells a cold link from a wrong write, by writing max_height and requiring its 0xF9 echo: it is the detector for this issue's success criterion. The DJI Fly initialisation that flips the RC into relaying is still not captured. Next: capture the DJI Fly outgoing handshake with separate instrumentation, then add the minimum verified initialisation to connect(). Use this app's incoming census to compare cold and warmed sessions. The known successful apply had 38 responses; validate repeated cold starts without DJI Fly.
Capture-tool scope corrected during the v1.7.1 (build 9) review; no handshake capture or new hardware result is claimed.
Current limitation
An apply only lands if DJI Fly has been opened first to wake the controller-to-aircraft command relay; the link then stays warm for a while after DJI Fly closes. Proven in the logs: two identical attempts, one 38 responses (relay warm) and one 0 responses (cold), with the aircraft "detected" in both.
Goal
Have the app initialise the relay itself, so users can go straight to FCC Unlock without the DJI Fly warm-up.
Direction
DJI Fly sends a session-init handshake over the MFi link that brings the RC→aircraft relay up. We already send a 2-frame bootstrap + keepalives; that is enough to talk to the RC but not (always) to make it relay to the aircraft. Capture / infer the additional init DJI Fly sends and replicate the minimum needed.
Approach
Reference
ExternalAccessoryTransport(session),FccController.sendBootstrap, keepalives inDumplTransport.swift.Status, synced with v1.7 (build 8), 2026-09-09
The warmth gate (v1.5,
linkIsWarm()) now tells a cold link from a wrong write, by writingmax_heightand requiring its0xF9echo: it is the detector for this issue's success criterion. The DJI Fly initialisation that flips the RC into relaying is still not captured. Next: capture the DJI Fly outgoing handshake with separate instrumentation, then add the minimum verified initialisation toconnect(). Use this app's incoming census to compare cold and warmed sessions. The known successful apply had 38 responses; validate repeated cold starts without DJI Fly.Capture-tool scope corrected during the v1.7.1 (build 9) review; no handshake capture or new hardware result is claimed.