v2.2: sweeps every working path + USB handoff

Thanks to everyone who tested and reported back — this release is built entirely on what came out of those reports.

What the reports showed

The reports contradict each other in a way that rules out a single correct command path. The same aircraft and controller pairing works for one tester and fails for another, and one report has the same build working on one phone but not another running the same Android version.

So v2.2 stops guessing and sends every path that anyone has confirmed working.

Timing was the main bug

Profile frame 1 opens the service-mode window and frame 21 closes it. Every write in between has to land inside that window.

Between v1.5 and v2.1 the sequence picked up a 150ms inter-frame delay, an unlock before every flight-controller write each with its own 350ms settle, and a 1.3s wait after the WLM command. That stretched a single apply to roughly 12 seconds. Every write reports success and the radio quietly stays on CE.

v2.2 sends at 30ms per frame — a round takes about 0.65s. This matches the timing values that were reported as making the older build work across a wide range of aircraft, and there is now a test that fails if the burst ever gets stretched out again.

One apply, several paths

Each apply sends, back to back:

1. the 21-frame profile with sender 0x82 — the value from the capture
2. the same profile with sender 0x02 — network 0
3. the WLM single-command radio switch, last, where it cannot delay service-mode entry

Each pass is self-contained, so a path your hardware ignores costs nothing but its own runtime. A full apply is about 3 seconds.

It now tells you what happened

Responses are counted per pass, so the Log tab shows lines like:

profile@82: 3 responses
profile@02: 0 responses
WLM 0x51/04: 0 responses

That distinguishes "the controller rejected FCC" from "the controller never relayed anything to the aircraft" — which the old log could not do, because it printed every telemetry frame and buried the useful lines. Background repeat re-sends whichever path answered.

If it still doesn't work, please post those three lines in an issue. They tell us far more than a screenshot.

USB handoff

Only one app can hold the USB accessory at a time, which is why people were unplugging the cable and force-closing the app to get DJI Fly to reconnect. There is now a Release USB for DJI Fly button that hands the port back without unplugging, and Connect retries for 15s so you can tap it and then close DJI Fly.

Also in this release

• Background repeat re-applies on an interval, for aircraft that drop back to CE when they set the home point on GPS lock
• Repeat interval is configurable in fcc.json
• Auto-FCC now starts the repeat, same as a manual apply
• Reconnecting after a release resumes the repeat
• CE restore sweeps both sender bytes
• Direct-to-drone (VCOM) mode surfaces received frames, and warns when the device it matched isn't DJI's vendor ID instead of reporting a confident connection to a dock or hub
• The connect retry no longer re-raises the USB permission dialog every half second

Honest note

This covers every path known to work and adds the diagnostics to find out why it doesn't when it doesn't. It has not been tested against every aircraft — that is what the log lines are for. Some drones may still need a second apply, and some reset the region on GPS lock and need one more pass once you're outside.

FCC mode is RAM-only. Power cycling the drone and controller always returns it to the factory region.