Protocolo

everything-imu habla dos protocolos UDP: el protocolo de tracker SlimeVR (bridge → servidor) y el protocolo remote-hub de eimu (teléfono → escritorio).

Formato de cable SlimeVR

UDP, big-endian. Cada datagrama comienza con un header de 12 bytes: [u32 BE tag][u64 BE seq]. El tag es el packet ID; el número de secuencia es por tracker y monótonamente creciente, y el servidor lo usa para descartar packets fuera de orden.

Packet IDs (tracker → servidor)

ID	Nombre	Notas
0	Heartbeat	Tracker id final de 1 byte (siempre 0)
1	Rotation	Obsoleto - usa el ID 17 en servidores modernos
3	Handshake	Conexión inicial (versión de protocolo 19)
4	Acceleration	Aceleración lineal en m/s² (no g)
5	Magnetometer	Lecturas del mag (µT) cuando la fusion 9-DOF está activa
10	Ping/Pong	Desafío del servidor, el tracker responde con eco
12	Battery level	[f32 voltage][f32 level 0..1]
15	Sensor info	Descripción del tracker (una por tracker lógico)
17	Rotation data	Rotación moderna - quaternion en orden (X, Y, Z, W)
21	Calibration action	Eventos de reset del usuario (yaw / full / mounting)
22	Feature flags	Bidireccional (ver abajo)
100	BUNDLE	Datagrama por lotes, gated por las feature flags del servidor

Reglas clave

• La aceleración es m/s², no g. Multiplica g por 9.80665. Nota que el tracker id es el último byte de un packet de accel (a diferencia del primero en un packet de rotación).
• El orden de bytes del quaternion de rotación es (X, Y, Z, W), es decir (i, j, k, w).
• Estado del sensor: envía 1 (OK) en el packet 15 para poner en verde el tracker del dashboard. La bitmask sensor_config reporta el estado del magnetómetro - 0x0003 habilitado, 0x0002 soportado-pero-deshabilitado, 0x0000 no soportado.

Auto-fallback de BUNDLE

BUNDLE (packet 100) solo es usable si la respuesta de feature flags del servidor anuncia PROTOCOL_BUNDLE_SUPPORT. En servidores sin él, los datagramas de tipo 100 se descartan silenciosamente, así que el bridge recurre a enviar rotación (17) y luego aceleración (4) como datagramas separados - la rotación primero, porque enviar accel primero producía un jitter visible de un frame. El puñado de muestras que llegan antes de la respuesta de feature flags toman la ruta de fallback automáticamente, así que no se pierde ningún dato.

Invariante de compatibilidad de cable

Cualquier cambio al encoder debe pasar pruebas de referencia byte por byte contra capturas conocidas como buenas. SlimeVR-Server rechaza silenciosamente los packets mal formados, y las fallas silenciosas son extremadamente costosas de depurar.

Protocolo remote-hub de eimu

Un segundo protocolo UDP, separado. La app móvil actúa como un hub: reenvía su propia IMU y cualquier control BLE que posea al bridge de escritorio, que ejecuta la fusion y registra cada dispositivo reenviado como un tracker normal.

Envelope

[4 bytes] magic "EIMU" (45 49 4D 55)
[1 byte]  version = 1
[1 byte]  message type
[ ...   ] payload, LITTLE-endian (opposite of the SlimeVR protocol)

El hub enlaza 0.0.0.0:9320 por defecto. Los datagramas con un magic o una versión incorrectos se descartan.

Tipos de mensaje

ID	Nombre	Dirección	Propósito
0x01	HELLO	phone → desktop	Anuncia el hub (uuid + nombre, clock opc.)
0x02	HELLO_ACK	desktop → phone	Ack, hace eco del clock para el RTT
0x03	ANNOUNCE	phone → desktop	Registra un dispositivo reenviado (un handle)
0x04	REMOVE	phone → desktop	Da de baja un dispositivo reenviado
0x05	IMU	phone → desktop	Ráfaga de muestras para un handle
0x06	BATTERY	phone → desktop	Fracción de batería + carga
0x07	BUTTON	phone → desktop	Solicitud de reset (yaw / full)
0x08	RUMBLE	desktop → phone	Intensidad de rumble para un handle
0x09	IMU2	phone → desktop	Como IMU, más un seq con wraparound para pérdidas

handle es un u16 elegido por el teléfono; cada par (hub, handle) mapea a un tracker en el escritorio. Una ráfaga de muestras IMU lleva, por muestra: un timestamp de 8 bytes en µs, gyro (3× f32, rad/s), accel (3× f32, m/s²), un byte has_mag, y mag (3× f32, µT) que siempre está en el cable pero se ignora cuando has_mag es 0.