Config-table parameter READ (0xF7/0xF8) returns nothing, get it answering

[andreapianidev]

Why this matters

This is the foundational tool that unblocks both the altitude unlock (#1) and the speed unlock (#3). Without reading parameters we cannot see the drone's current state, its firmware min/max/default bounds, or verify any write.

Symptom

• Config-table write by hash (FLYC 0x03 / 0xF9) is answered (36 to 38 responses during an FCC apply).
• Config-table read by hash, 0xF7 (Get Param Info) and 0xF8 (Read Value), gets 0 replies, even with the aircraft linked (serial detected, 17MB telemetry inbound).

Hypothesis (a fix is already committed but untested on hardware)

The flight controller keeps the config table locked outside the context the FCC writes run in: the AUTOTEST service-mode window plus the assistant unlock (0x03 / 0xDF). The read probe now opens that context first, reads, then exits (commit "Read FC config in the service-mode + unlock context"). Needs a hardware run to confirm.

Test steps

1. Warm the link: open DJI Fly, wait for camera, close it.
2. FCC Unlock: Connect, wait for the green aircraft line, Enable FCC.
3. Experimental tab, Read Attitude Parameters.
4. Pull the log and check whether flying_limit.max_height now reads back 500 (the self-check).

If it still returns nothing, next things to try

• Different cmd_type (currently 0x40 ack-after-exec; try 0x00, 0x0A).
• Different destination (currently 0x03; the write responder was also seen as 0x92/0xE9).
• The whole-table read 0xFB (Read Params By Hash, multiple) or the config command table 0xE2 (Get Item Value).
• Send the read inside the same burst as a successful write, not after service-mode exit.

Reference

FccController.probeSpeedParamsSync; command ids in dji-dumlv1-flyc.lua (0xF7/0xF8/0xFB).

[andreapianidev]

Confirmed on hardware (RC-N3 / DJI Neo, FW v00.05.00.12): the read verbs 0xF7 (Get Info) and 0xF8 (Read Value) get zero replies, tested across sender 0x82 and 0x02, cmd_type 0x20 and 0x40, and dst 0x03 and 0x92, each inside its own tight service-mode window (commit 9b964e3, two-phase probe).

The flight controller is not mute. The census taken during the probe shows it pushing continuously on set=03:

03->02 set=03 id=D7 x2456
92->02 set=03 id=CE x68     (responder behind sender 0x92)
03->02 set=03 id=53 / id=09 / id=42 ...

The working read channel on this firmware is the 0xF9 write reply itself, which carries status + hash + value echo, e.g. max_height -> 00 8A 23 71 03 78 00. So reads here should be built on 0xF9 read-after-write and/or the untested 0xFB (Read Params By Hash, multiple), not 0xF7/0xF8.

[andreapianidev]

TODO / status after the v1.1 hardware run:

• Prove 0xF7/0xF8 return nothing across sender 0x82/0x02, cmd_type 0x20/0x40, dst 0x03/0x92
• Find the working read channel: the 0xF9 write reply carries status + hash + stored value
• Decode 0xF9 replies inline in the log (v1.1), so an apply is self-documenting
• Try the whole-table read 0xFB (Read Params By Hash, multiple) for a true read-only path, needed to read the speed params (Unlock max speed to ~60 km/h on Sport (attitude range) #3) without writing them
• If 0xFB is also dead, document 0xF9 read-after-write as the only channel on this firmware