DJI FPV (WM170) DUML communication & vision module binding

[neurosls25]

DJI FPV (WM170) - DUML communication protocol & vision module binding

Problem

Replaced the visual sensor module on a DJI FPV (WM170). After replacement, cameras are not detected. DJI Assistant 2 shows "Calibration" as an option but it never starts (infinite loading). The module is physically connected and responds in some capacity, but is UNPAIRED (encryption state = UNPAIRED).

What we've tried

We built a Python tool using pyusb + libusb that implements the DUML protocol based on dji-firmware-tools.

Hardware setup

DJI FPV USB descriptor (VID 0x2CA3, PID 0x001F):

Interface 0-1: RNDIS (network)
  EP 0x82 IN / EP 0x01 OUT / EP 0x81 IN

Interface 2: Mass Storage
  EP 0x83 IN / EP 0x02 OUT

Interface 3: BULK Interface (Class=0xFF, SubClass=0x43)
  EP 0x03 OUT / EP 0x84 IN

Interface 4-5: CDC ACM (Virtual COM Port = COM6)
  EP 0x86 IN / EP 0x04 OUT / EP 0x85 IN

Communication attempts

1. Via COM6 (serial): Only receives one-way telemetry. Drone streams 4 packet types:

   • cmd_set=0x02, cmd_id=0x80 (telemetry, ~10Hz, 73 bytes)
   • cmd_set=0x03, cmd_id=0x43 (telemetry, ~5Hz, 81 bytes)
   • cmd_set=0x00, cmd_id=0x81 (FC version broadcast "WM170", ~1Hz, 77 bytes)
   • cmd_set=0x00, cmd_id=0xF1 (status, ~2Hz, 17 bytes)
   • Commands sent via COM6 (0xDF, 0xE0, etc.) are silently ignored.

2. Via BULK Interface (EP 0x03 OUT / EP 0x84 IN):

   • Writes to EP 0x03 succeed
   • EP 0x84 returns zero data (timeout on all reads)

3. Via CDC ACM direct (EP 0x04 OUT / EP 0x85 IN) using libusb:

   • Writes to EP 0x04 succeed
   • EP 0x85 has telemetry data but no responses to commands

4. Combined BULK OUT + CDC IN: Same result, no command responses

USB capture analysis (DJI Assistant 2 + USBPcap/Wireshark)

Successfully captured a session where DJI Assistant 2 FPV was connected. Key findings from the pcap:

DJI Assistant 2 handshake sequence:

1. cmd_set=0x00, cmd_id=0x37 payload=23 05 00
2. cmd_set=0x00, cmd_id=0x01 payload=(empty)
3. cmd_set=0x00, cmd_id=0x51 payload=01
4. cmd_set=0x00, cmd_id=0x32 payload=00  → then payload=31 31 00 00 00 ("11")
5. cmd_set=0x00, cmd_id=0x4A payload=ea 07 06 0d 14 11 3a (timestamp: 2026-06-13 20:17:58)
6. cmd_set=0x03, cmd_id=0xDF payload=01 00 00 00  ← UNLOCK (not empty payload!)
7. cmd_set=0x03, cmd_id=0xAF payload=04 8a 51 02 54 bd b7 00 cf (auth)
8. cmd_set=0x07, cmd_id=0x19 payload=(empty)
9. cmd_set=0x00, cmd_id=0x81 payload=64 bytes handshake
10. cmd_set=0x00, cmd_id=0x82 payload=00 (ACK)

FC parameter access (after handshake):

• cmd_set=0x03, cmd_id=0xE0 payload=00 00 → FC responds with 00 00 00 00 c7 3c 13 c3 98 05 00 00 (0x0598 = 1432 params)
• cmd_set=0x03, cmd_id=0xE5 → extended param info
• cmd_set=0x03, cmd_id=0xE1 payload=00 00 XX 00 → param info query with index
• cmd_set=0x03, cmd_id=0xE2 payload=idx(2)+value(4) → param read/write
• cmd_set=0x03, cmd_id=0xE6 → status/telemetry group query (payloads include ASCII names like "g_status.rc.current_mode_switch")
• cmd_set=0x03, cmd_id=0xE9 → progress/status indicators (countdown from 0xFF to 0x00)

FC responses in the capture include ASCII parameter names:

F_CHL_F1, F_CHL_D_FREQ, F_CHL_D1_MAX_WIDTH, F_CHL_MODE,
F_CHL_SHUTTER_ACTIVE_OUTPUT, basic_gain_roll_usr, basic_gain_pitch_usr,
gyro_FF_gain, atti_gain, multi_esc_type, vps_func_en,
disable_tof_if_close_vps, is_locked, vo_fdi_open_vel_large_in_static, ...

Questions

1. How does DJI Assistant 2 actually establish bidirectional communication with the FPV? It seems to use a proprietary initialization that bypasses standard DUML.
2. Is there a known handshake/authentication sequence for WM170 that enables the command channel?
3. The capture shows all traffic on "EP 8" (via USBPcap), but no USB descriptor shows EP 8. Could this be a kernel-level virtual endpoint?
4. Does the WM170 require a custom USB driver beyond WinUSB/libusb?
5. Any known documentation on the vision module binding protocol for FPV-era drones?

Environment

• Windows 11, Python 3.12, pyusb 1.2, libusb 1.0
• DJI FPV WM170 with replaced visual sensor module
• Firmware version: 0x00000802 (all modules report same FW)
• WinUSB via Zadig on BULK and CDC ACM interfaces

[eterry1388]

Ground-side companion data: DJI FPV Remote Controller 2 (rc150), same USB stack, same wall

I've been mapping the ground side of this exact problem — the DJI FPV Remote
Controller 2 (rc150, same 0x2CA3 vendor, PID 0x001F) over its USB CDC port —
and I hit the same "commands silently ignored / bulk endpoint writes succeed but
reads time out" wall you describe. Posting my findings because they seem to be
the RC-side complement to your WM170 air-side data, and I have the same open
question about how Assistant establishes a real command channel.

TL;DR: on this RC firmware, the USB CDC port does not expose a control uplink
or a transparent DUML route to the aircraft through any documented command shape,
and the vendor bulk interface (the goggles-video-shaped one) will not accept host
data in the state I can reach.

Device

• Product: DJI FPV Remote Controller 2, reports device id rc150
• USB: VID 0x2CA3, PID 0x001F, iProduct = "DJI FPV Remote Controller"
• Firmware (from General / Get Cfg File): formal 01.00.0606; modules
  0600 = MCU150 and 1301 = the DM36x/SDR ground image
• Module identity strings (0x00/0xff Query Device Info):
  • 0x0e -> WM220 SDR_HDVT_GND 20151116|01 (Mavic-era SDR naming)
  • 0x1f, 0x2d -> RC150 PIGEON RC Jun 23 2020|04:47:31
  • 0x0e -> DJI P1 HDVT (0x00/0x01 Version Inquiry)
  • 0x06 -> MCU150 Ver.A

USB topology (pyusb enumeration of the live RC)

Intf	Class	Role	Endpoints
0	0xe0/01/03	Wireless controller (RNDIS ctrl)	IN 0x82 int
1	0x0a	CDC Data (secondary)	bulk 0x01/0x81
2	0x08/06/50	Mass Storage (SCSI)	bulk 0x02/0x83
3	0xff/43/01	Vendor — same shape as the goggles video endpoint	bulk OUT 0x03 / IN 0x84
4	0x02/02/01	CDC ACM control	IN 0x86 int
5	0x0a	CDC Data — DUML serial (cu.usbmodem*)	bulk 0x04/0x85
6	0x03	HID gamepad	int OUT 0x05 / IN 0x87 (1024B)

This lines up with what you saw on WM170: interface 3 bulk (0x03/0x84) writes
"succeed" but IN reads time out, and the CDC path only carries telemetry/identity.

What DJI Assistant 2 actually sends to the RC (Windows sniff)

Sniffed DJIService.exe by hooking NtWriteFile/NtReadFile/NtDeviceIoControlFile
in ntdll — hooking at kernel32 was not enough (it sees ReadFile but zero
WriteFile, and never SetCommState; DJIService reaches the port through a
wrapper that bypasses those exports, so ntdll is the single funnel).

Assistant's entire vocabulary on the CDC port is: Version Inquiry,
Activate Config (0x00/0x32), Set Date/Time, Set Country Code (0x00/0x63),
0x00/0x37 (see below), Get Cfg File (0x00/0x4f), plus the RC's 0x06/0x1e
battery heartbeat. Zero simulator (0x0b) traffic, and nothing in set 0x06
beyond the heartbeat — no 0x06/0x24, no 0x06/0x26, no channel commands. So
capturing Assistant is not a route to stick-injection commands on this RC.

A couple of commands missing from the current dissector tables

• General 0x00/0x63 = Set Country Code. Absent from GENERAL_UART_CMD_TEXT
  (table jumps 0x62 -> 0xef). Assistant sends it once at startup with a 2-byte
  ASCII region code; RC ACKs status 0.

  TX 550f04a22aa616274000 63 5553      payload "US"
  RX 550e0466a62a1627c000 63 00        status 0
  

• General 0x00/0x4f Get Cfg File payload format (named but no payload
  dissector). Request = [u8 op=1][u32 LE offset][u32 LE max]; reply =
  [u8 status][u32 LE chunk_len][u32 LE remaining_after_chunk][data]. Device
  picks a 256-byte stride regardless of the 1000 requested. Data concatenates to
  a DJI package (IM*H @0, PRAK @40, CNFG @96, then the device-table XML).
• General 0x00/0x37, unidentified, correlates with Assistant logging
  DOI Auth Failed (step-1 timeout). Constant 3-byte payload 23 05 00, sent
  6x each to two modules, never answered by this firmware. Looks like the first
  step of an auth/entitlement handshake the RC doesn't implement. (Note 0x37 is
  taken in the RC set as Enter App Mode Request; this is the General set.)

Negative results that might save someone time

1. The RC is not a transparent DUML router to the aircraft. With the aircraft
   powered and linked, I swept Version Inquiry across all device types 0-31 x
   index 0-7 (248 addresses, 2 source addrs x 2 request types). Only ground-side
   modules answer (0x06 MCU150, 0x0e HDVT, 0x1f/0x2d RC150, 0xa6 serial).
   No air-side device replied at any address — not FC (type 3), not air HD
   link/DM36x (9/8), not gimbal/cam/ESC/batt/IMU. A passive listen shows only the
   RC's own 0x06/0x1e push. So you can't reach the FC by addressing it and
   letting the RC forward.
2. DJI P1 HDVT (0x0e) does not implement HD Link set 0x09. 24 argument-
   free getters: 20 return 0xe0 (unsupported), 4 silent. Clean rejection (it
   answers Version Inquiry and returns explicit error codes), just no 0x09
   support — consistent with the table describing the Lightbridge/OcuSync-era
   stack, not this SDR.
3. Classic injection writers all fail on CDC, aircraft linked, props off:
   0x06/0x24 Sim Flight Mode, 0x06/0x26 AETR Push, Center Virtual RC
   0x05/0x00+0x01, Special 0x01/*, FlyC App Joystick 0x03/0x8E. Every one
   is silent or 0xe0, against MCU150, HDVT, 0xa6, RC150, FC and Center Board.

Warning: MCU150 (0x06) 0x60–0x6c is a soft-brick range

There's an undocumented cluster on MCU150 (0x06/0x60..0x6c) that ACKs and
makes the RC beep / flash its LEDs. It's a trap: repeated writes there (and the
empty-payload form of 0x06/0x19 Control Mode Set, and empty GETs on
0x6d–0x6f) wedge MCU150 — it stops answering while every other module
still replies 3/3, the power button and the four white LEDs go dead, and the USB
gadget re-enumerates. Recovery is a power cycle; nothing persisted (stick
calibration 0x06/0x38 came back byte-identical). Once wedged, 0x06 returns
SILENT to everything, which is easy to misread as "not implemented" — interleave
a liveness check when probing that address.

My open questions (same as yours, from the RC side)

1. What state or sequence unlocks the vendor bulk interface (intf 3,
   0xff/43/01, 0x03/0x84)? It's the same descriptor shape as the goggles
   video endpoint; the goggles start streaming after an RMVT write, but on the
   RC every write to 0x03 (including RMVT) times out and IN stays quiet. Is
   there a known enable/handshake, or does it require a specific device mode
   (e.g. Assistant-connected, or a prior control-transfer)?
2. You mention all Assistant traffic showing on "EP 8" in USBPcap with no
   matching descriptor — is that the RNDIS/interface-0..1 path, and does
   Assistant's bidirectional command channel actually run over RNDIS/IP rather
   than the CDC ACM DUML port?
3. Is there a known handshake/auth that opens the command channel on this
   generation, and is General 0x00/0x37 ("DOI Auth") the gate?
4. Does WM170/rc150 need a custom USB driver beyond WinUSB/libusb for that
   vendor interface to accept data?

Happy to share raw captures / the pyusb probing tools if useful. Everything above
is a single rc150 unit on firmware 01.00.0606; command labels for 0x63/0x37
are inferred from payload + Assistant logs, not firmware disassembly.