wltoys 244016 v2 1/24 buggy protocol

[AphinityAvali]

Hello!

A common car that many 1/24 offroad enthusiasts are trying is the very inexpensive wltoys 244016 for roughly $40 USD ($55 CAD). It comes with a very basic radio and a built-in receiver/ESC. It is essentially a cheap Losi Micro-B.

I have tried the KX and the older XK protocols that work on other wltoys receivers but these do not bind to this one.

This is an automatic bind receiver and I have verified it binds to any transmitter that powers on when the receiver is trying to bind.

The combo of transmitter and receiver/esc is available here for $20 USD: https://www.wl-toys.com/Wltoys-244016-Transmitter-with-Receiver-board-together-50222.html

Is it possible to make this work? What can I do to help? I am happy to try anything with what I have here - I have two.

[AphinityAvali]

[MRC3742]

@pascallanger I've done some captures on this model but I think it is a new protocol as I haven't found anything similar.

WlToys XK 244016 OTA Capture for review:
Startup_RxOn-TxOn-Bind.txt

Here is an AI review of my findings so far.
Thanks - Rich

---

Device & Hardware Profile:

• Brand / Model: WLToys / XK 244016 RC Buggy (Uses WLToys V9 Surface Transmitter)
• RF Silicon: Panchip XN297L (SOP16 form factor variant with a 16.000 MHz reference crystal oscillator)
• Over-the-Air Link Speed: 1Mbps GFSK (Hardware Scrambled)
• Default Capture Channel: Channel 62 (Observed via MPM XN297Dump on Auto)
• True Hardware Air Address: 21 D7 16 (Truncated from 5-byte sniffed address tracking 21 D7 16 CC CC)

---

1. Handshake & FHSS Initialization Lifecycle

The protocol utilizes a tight bidirectional handshake loop to finalize its internal state machine before allowing runtime telemetry transmission.

Step A: Dynamic FHSS Table Beacon (P18)

Upon initial boot, the TX broadcasts an 18-byte initialization configuration array. This payload dynamically updates across unique power sessions, indicating an underlying pseudo-random frequency-hopping map generation sequence.

Captured Startup Beacons across subsequent cold boots:

• Boot 1: 1B FA 7F FE FF F7 FF 4C 9F E9 8A F9 39 57 FF 9F DF 3F
• Boot 2: 1B B2 3F FE 7F F7 FF 4C 9E F9 8A F9 39 57 FF 97 D9 7E
• Boot 3: 1B FA 3F FE 7F F7 FF 4C 9E E9 8A F9 39 D7 FF 97 DB 7F
• Boot 4: 1B FA 3F FE 7F F7 FF 4C 9F E9 8A F9 39 D7 FF 97 DB 7F
• Boot 5: 1B 32 7F FE 7F F7 FF 4C 9E E9 8A F9 39 D7 FF 9F DB 7E
• Boot 6: 1B FA 3F FE 7F F7 FF 4C 9E E9 8A F9 39 57 FF 9F DB 7F

Step B: Receiver Acknowledgment (RX ACK)

Once the car's RX intercepts the startup beacon, it answers back on the initial frequency with a specific matching acknowledgment payload packet string:
00 00 00 21 D7 16 03 DB

Step C: Link Escalation States

Following the RX confirmation handshake, the transmitter cycles through incremental connection state steps tracking variables on Byte 2 and Byte 6 before releasing the logical loops into native runtime operation:

• 59 6E 01 21 D7 16 01 B1 -> (TX State 01, Link Flag 01)
• 59 6E 01 21 D7 16 03 A3 -> (TX State 01, Link Flag 03)
• 59 6E 01 21 D7 16 02 B2 -> (TX State 01, Link Flag 02)
• 59 6E 02 21 D7 16 03 A4 -> (TX State 02, Link Flag 03)

---

2. Active Runtime Telemetry Loop (Bidirectional Confirmation)

During standard runtime control mode, the protocol operates as a strict, interlocking transceiver-to-transceiver link. The main TX opens a very brief listening window immediately after firing a control packet. The car's RX intercepts the inputs and instantly responds with a telemetry/acknowledgment frame.

Captured Telemetry Packet (Interleaved at tight intervals):
RX: 1782us C=62 S=Y A= 21 D7 16 CC CC P(8)= 59 6E 00 21 D7 16 00 A3

Telemetry Architecture Breakdown:

• Timing Interlock (1782us): This packet breaks away from the standard ~8.5ms TX frame loop, firing exactly 1.7ms after a TX event inside the designated listening window.
• Payload Structure:
  • Byte 0-1 (59 6E): Fixed Vendor Header.
  • Byte 2 (00): Telemetry Identifier Flag (replaces the standard Throttle axis position).
  • Byte 3-5 (21 D7 16): The RX explicitly re-broadcasts the unique bound TX hardware address as a link-alive confirmation.
  • Byte 6 (00): Null spacing pad.
  • Byte 7 (A3): Fixed validation checksum for this static confirmation array.

Failsafe Behavior:
If either the TX or the RX is powered down, the entire link immediately goes dark and all over-the-air transmission stops instantly. The transmitter MCU requires this inbound 1782us confirmation frame to clock its runtime state machine forward.

---

3. Runtime Packet Telemetry Map (8 Bytes)

Once active channel communication is established, the payload shifts permanently to a tight, 8-byte control frame structure firing at roughly an 8ms execution window (approx. 8942us timing cycles from telemetry logs).

P(8)= 59 6E 32 32 1F 20 80 C7

• Byte 0 & 1: Fixed Protocol Header Prefix
  • Hardcoded to 59 6E (WLToys specific protocol brand stamp).
• Byte 2: Throttle / Brake Control
  • Linear 100-step proportional scale: 0x00 (Full Reverse/Brake) $\rightarrow$ 0x32 (Neutral Center) $\rightarrow$ 0x64 (Full Forward).
• Byte 3: Steering Axis Control
  • Linear 100-step proportional scale: 0x00 (Full Left) $\rightarrow$ 0x32 (Neutral Center) $\rightarrow$ 0x64 (Full Right).
• Byte 4: Steering (ST) Trim Potentiometer
  • Linear scale tracking configuration adjustment boundaries from 0x01 (Minimum) up to 0x3F (Maximum).
• Byte 5: Gyroscope (GY) Sensitivity Trim Potentiometer
  • Linear scale tracking integration adjustments from 0x01 (Minimum) up to 0x3F (Maximum).
• Byte 6: Multiplexed System Control Bitmask
  • Bits 1-0 (Speed Limit Step Controls):
    • 0x00 = Low Speed Rate
    • 0x01 = Medium Speed Rate (Transmitter momentarily triggers 0xA1 parameter shift on adjustment blip)
    • 0x02 = High Speed Rate (Transmitter momentarily triggers 0xA2 parameter shift on adjustment blip)
  • Bit 6 (Momentary DIY Light Trigger):
    • Flips to high configuration value 1 instantly when pressed, shifting the current active byte base value up from 0x80 to 0xC0.
  • Bit 7 (Hardware Sequencing Frame Mask):
    • Alternating 0x80 cyclical hardware mask flipping constantly across active runtime states.
• Byte 7: Validation Checksum
  • Non-linear hardware validation signature byte. Corresponds directly to an internal XN297 hardware-calculated CRC engine executing over the raw, obfuscated OTA bitstream layer prior to hardware descrambling processing.