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.

v2.1: Cracked the actual FCC radio command

What changed

Previous versions sent a 21-frame flight controller parameter profile — the same commands used by smart controllers over TCP. These don't switch the radio mode on RC-N controllers.

v2.1 sends the actual WLM radio switch command:

• cmdSet=0x51 (Wireless Link Manager)
• cmdId=4 (link mode configuration)
• dst=0xEE (OFDM radio subsystem)
• sender=0xA2 (app identity for radio commands)

This is the command that tells the radio hardware to switch from CE to FCC mode. The 21-frame profile is still sent afterwards as a supplement.

How to test

Through RC (AOA):

1. Close DJI Fly → plug phone into RC TOP USB → Connect → Enable FCC → switch to DJI Fly

Direct to drone (VCOM):

1. Phone A: DJI Fly connected to RC
2. Phone B: FreeFCC USB plugged into drone's USB-C
3. Connect → Enable FCC

The activity log now shows response frames from the drone — please share a screenshot if testing.

v2.0: Direct-to-drone USB + response diagnostics

What's new

1. Direct-to-drone USB mode (VCOM)

If FCC doesn't work through the RC, try connecting a second phone directly to the drone's USB-C port. The app auto-detects which mode to use.

AOA mode (phone → RC USB): The normal path. Works if FCC persists after switching to DJI Fly.

VCOM mode (phone → drone USB-C): For drones where DJI Fly resets FCC. Requires a second device:

• Device 1: DJI Fly connected to RC normally
• Device 2: FreeFCC USB plugged into the drone's USB-C port

2. Response diagnostics

The activity log now shows every response frame from the controller/drone — parsed with sender, destination, command set/ID, and payload. This shows whether your drone is ACKing the FCC commands or ignoring them.

If you tested before and FCC didn't work: please try v2.0 and share a screenshot of the activity log after tapping Enable FCC. The response frames will tell us exactly what's happening.

How to use

Method 1 — Through RC (AOA):

1. Close DJI Fly → plug phone into RC TOP USB → Connect → Enable FCC → switch to DJI Fly

Method 2 — Direct to drone (VCOM):

1. Phone A: run DJI Fly, connected to RC normally
2. Phone B: run FreeFCC USB, plugged into drone's USB-C port
3. Tap Connect → Enable FCC on Phone B
4. FCC persists because DJI Fly never sees the change

v1.9: Direct-to-drone USB mode (VCOM)

What's new

Direct-to-drone USB connection (VCOM mode) — Some drones reset FCC to CE mode when DJI Fly connects through the RC. The fix: connect a second phone directly to the drone's USB-C port with a USB cable.

Two connection modes (auto-detected)

Mode 1 — AOA (phone → RC USB port):

• For drones where FCC persists after switching to DJI Fly
• Close DJI Fly → Connect phone to RC's TOP USB port → Enable FCC → Switch to DJI Fly

Mode 2 — VCOM (phone → drone USB-C port):

• For drones where DJI Fly keeps resetting to CE mode
• Requires a second Android device (old phone, tablet, etc.)
• Device 1: runs DJI Fly connected to the RC normally
• Device 2: runs FreeFCC USB connected directly to the drone's USB-C port
• Enable FCC on device 2 → FCC persists because DJI Fly never sees the change

If AOA mode didn't work for you before

Try VCOM mode: plug a second phone into the drone's USB-C port instead of the RC's USB port. This bypasses the RC entirely and sends FCC commands directly to the drone.

All fixes (v1.4 — v1.9)

Fix	Version
Direct-to-drone VCOM mode	v1.9
AssistantUnlock per FC write + 2s repeat	v1.8
Global sequence counter	v1.7
Inter-frame delay 150ms	v1.6
Sender address 0x02	v1.5
RX drain thread + dynamic route	v1.4

v1.8: AssistantUnlock + 2s repeat

Changes

1. AssistantUnlock before every FC write — The flight controller requires an unlock command (cmdSet=3, cmdId=0xDF) before accepting parameter writes. Previously sent once before the batch; now sent before each of the 5 FC parameter frames individually. The FC's unlock state can expire between writes.

2. 2-second repeat cycle (was 10s) — After enabling FCC, the app continuously re-sends the FCC profile every 2 seconds to prevent DJI Fly from resetting to CE mode. Matches the reference implementation's polling interval.

3. FCC repeat with per-frame unlock — The repeat service also sends AssistantUnlock before each FC write, not just the initial apply.

Cumulative fixes (v1.4 — v1.8)

Fix	Version
AssistantUnlock per FC write + 2s repeat	v1.8
Global sequence counter (no duplicates)	v1.7
Inter-frame delay 150ms	v1.6
Sender address 0x02	v1.5
RX drain thread + dynamic route	v1.4

How to use

1. Close DJI Fly completely
2. Connect phone to the TOP USB port of the RC-N1/N2/N3
3. Open FreeFCC USB → tap Connect → tap Enable FCC
4. Immediately switch to DJI Fly
5. The repeat service keeps re-applying FCC every 2 seconds in the background

Please report results — controller model, phone, and whether FCC shows in DJI Fly.

v1.7: Complete USB protocol fix

What's fixed (v1.4 — v1.7)

Fix	Impact
Global sequence counter	Round 2 frames no longer dropped as duplicates
Frames built per-round	Each send gets fresh, unique sequence numbers
Inter-frame delay 150ms (was 5ms)	Controller has time to process each command
Sender address 0x02 (was 0x82)	Frames reach the correct USB network
RX drain thread	USB pipe no longer stalls
Dynamic route bytes	Correct routing throughout session

How to use

1. Close DJI Fly completely
2. Connect phone to the TOP USB port of the RC-N1/N2/N3
3. Open FreeFCC USB → tap Connect
4. Tap Enable FCC (takes ~8 seconds)
5. Open DJI Fly → check the Transmission tab

Please report results — controller model, phone, and whether FCC shows in DJI Fly.