Skip to content

APEX_Device_Classes.md

Latest commit

 

History

History
53 lines (35 loc) · 3.3 KB

APEX_Device_Classes.md

File metadata and controls

53 lines (35 loc) · 3.3 KB
Raw

APEX — Device Classes

APEX — Adaptive Payload EXchange

Status: Draft | Scope: Registry of device classes (traffic types)

1. Overview

This document is the registry of APEX device classes. Each device class corresponds to a traffic_type value in the APEX V0 outer header (see APEX — Core §3.1.1) and is fully specified in its own companion document. The core spec is class-agnostic; the per-class docs define both the Host role and the Device role (APEX — Core §1) — including the messages each side sends, state machines, and any class-specific timing.

Class assignment happens during discovery: the device declares its desired class via device_class_req in DEVICE_INFO, and the host accepts or rejects via CONFIG_REPLY (Core §3.2). Once accepted, frames carrying traffic_type equal to that class value are routed to the class-specific handler on both sides.

2. Registry

traffic_type Name Description Spec
0 CONFIG Core control traffic: discovery, configuration, and the implicit heartbeat. Not a device class — defined by the core spec. APEX — Core
1 ACTIVATION Devices that progress through enable and trigger phases. APEX Device Class — Activation
2 ANALOG_HMI Analog HMI: control packets (CRSF / MAVLink 2) in, CVBS video out. APEX Device Class — Analog HMI
3 WAYFINDING Devices that produce directional cues — "point me there" updates for the operator, from any source. APEX Device Class — Wayfinding
4 REPEATER RF relay node: extends C2 and video links between ground and a distal drone. APEX Device Class — Repeater
5 USB_FS_HUB Full-Speed USB passthrough traffic. (TBD)

3. Reserved & Custom Traffic Types

traffic_type values not enumerated above are reserved for future device classes. Vendor- or platform-specific extensions should be coordinated through this registry rather than reusing CONFIG message IDs or values from another class.

Open: Whether to formally allocate a high range of traffic_type values (e.g., 0x80–0xFF) for vendor-custom classes, analogous to the prior spec's 0x80–0xFF MSG_ID range.

4. Authoring a New Class Spec

A device-class spec should cover, at minimum:

  1. traffic_type value assigned in the registry above.
  2. Roles — what the Host and Device each do in this class.
  3. Message set — the inner payload format(s) carried under this traffic_type, distinguished by an in-class message ID where applicable.
  4. State machines — for both host and device, if any.
  5. Timing — heartbeat cadence beyond the core implicit heartbeat, command-response timeouts, etc.
  6. Failure handling specific to the class.