Naming what a USB device reports back: rpm, flags and modes from the vendor app's screen

Description and use

usb-rea now maps raw USB reply bytes to meaningful names (rpm, temp, mode, flags) by leveraging vendor app observations, producing a fully named status reply for a synthetic fan controller.

Problem

USB gadgets expose raw bytes that need meaningful names for driver development.

Outcome

usb-rea now maps raw USB reply bytes to meaningful names (rpm, temp, mode, flags) by leveraging vendor app observations, producing a fully named status reply for synthetic fan controller captures.

Workflow

• Capture USB traffic while interacting with the vendor app.
• Use usb-rea mark "seen …" to record observations of values shown on the app screen.
• usb-rea pairs each marker with the nearest reply frame and searches for bytes that explain every observation.
• For numeric values it checks identity (raw equals observed) or linear fit (raw = value*scale+bias).
• For on/off states it identifies bits that toggle between 1 and 0 across observations.
• For mode words it matches contiguous bits that change between different words.
• After analysis, usb-rea generates a driver that returns named fields such as rpm, temp, mode, and flags.
• The driver can be tested with usb-rea demo --device fan to verify the mapping.

Evidence

usb-rea pairs every host query with the reply the device sends back and decodes the parts it can explain: constants, echoed command ids, sequence numbers, checksums.

Source

A seen marker is an observation, not an action. It doesn't end the action you're labelling and it's never diffed.

Source

For numbers there are two checks: identity and linear fit.

Source

A name seen as two or more different words, in three or more observations, is matched to the reply byte whose raw value is the same every time the app showed one word and different between words.

Source

All 7 bytes of the status reply are explained now. The report backs each name with the frames it came from.

Source