Skip to content

6. Research Status

Jump to bottom
Spb2005 edited this page Feb 17, 2026 · 4 revisions

Research Status

This section summarizes the current state of the T248 reverse engineering efforts, highlighting confirmed findings, partially understood elements, open questions, and future investigation areas.

Confirmed & Validated

Communication Protocol

The following elements of the T248 UART protocol are fully understood and validated:

  • UART configuration: 115200 baud, 8 data bits, even parity, 1 stop bit (8E1)
  • Master-slave architecture (wheelbase = master, wheel = slave)
  • Startup handshake sequence
  • Keep-alive frame cycle (D0–D3)
  • Keep-alive response timing (~5 ms)
  • Button frame format (B0 / B1) and immediate transmission of button states
  • General-purpose F3 data frame structure
  • Encoder bitfield encoding and decoding
  • Shutdown frame behavior

The RP2040-based wheel emulator reliably reproduces all runtime protocol behavior.

Emulator Stability

Validated on real hardware:

  • Startup synchronization with the wheelbase
  • Long-term runtime stability without errors
  • No phantom button inputs
  • Reliable detection of encoder actions
  • Proper handling of incomplete or corrupted UART frames
  • Synchronization with the wheelbase reset line

The V2.0 emulator version is considered stable and suitable for daily use.

Hardware Mapping

Confirmed:

  • STM32G030K6 pin usage on the wheel PCB
  • UART pin mapping to wheelbase
  • RESET line behavior and timing
  • I2C connections to the screen
  • Hall sensor wiring and input mapping
  • Button and encoder pin assignments

The wheel PCB has been fully reverse-engineered schematically.

Partially Understood

Screen Data Protocol

Known:

  • Frame prefix (0x2A)
  • Counter byte increments per frame
  • Variable-length payload
  • 12-byte response frame from the wheel

Unknown:

  • Exact mapping of telemetry values (RPM, gear, lap time, etc.)
  • Meaning of certain payload bytes
  • Purpose of most response bytes

Decoding of screen data remains incomplete.

Firmware Update Process

Known:

  • .tmf files contain binary firmware images
  • Likely a dual firmware structure (wheelbase + wheel)

Unknown:

  • Exact flashing sequence and protocol
  • Whether wheel firmware is also updated
  • Whether the wheelbase acts as a programmer or passthrough
  • Integrity validation mechanism and encryption/signature checks

Open Questions

PA14 Functionality

  • Used as SWCLK for SWD debug
  • Shared with the Mode button input
  • Connected to the wheelbase

Unclear whether:

  • It is required for flashing mode
  • It influences boot configuration
  • It enables debug access

Firmware Readout Protection

Unknown:

  • RDP (Readout Protection) level of the wheel MCU
  • Whether the debug interface can be re-enabled
  • Possibility to access bootloader via UART

Protocol Design Rationale

Open questions about the protocol:

  • Why a new UART-based protocol was introduced for the T248/T124
  • Why frame order rotates periodically
  • Why frames contain significant unused bytes
  • Why acknowledgments are so frequent

The protocol appears over-engineered relative to its functional needs.

Community Contribution – USB Display Frame Analysis (January 2026)

Additional research was contributed by GitHub user Lolig4, focusing on the USB/HID communication between the PC and the T248 wheelbase.

Key contribution:

  • Captured and analyzed USB display update frames
  • Confirmed strong structural similarity between USB display frames and UART display frames
  • Identified required multi-report sequence (rpt1, rpt2, rpt3) for display updates
  • Identified a short display-duration extension frame (rpt10)
  • Demonstrated successful character and bargraph injection via USB

This contribution provides important insight into the relationship between:

PC → USB → Wheelbase → UART → Wheel

The structural similarity between USB and UART display frames suggests that the wheelbase likely forwards display payloads with minimal internal reinterpretation.

Impact on research status:

  • Strengthens confidence in the current UART display frame analysis
  • Provides an additional capture layer for cross-verification

This contribution supports ongoing work on full display decoding and firmware behavior analysis.

For further technical details, see the corresponding
USB communication section in 3. Communication Protocol.

The complete research discussion with Lolig4 is available in
this GitHub Issue.

Future Work

  • Complete decoding of the screen telemetry and frame mapping

This project has achieved functional completeness regarding wheel emulation. Remaining work focuses on deeper understanding and documentation, rather than operational requirements.

Clone this wiki locally