25 min. El presupuesto de aire de la Sesión 1 fija cuántos bytes caben. Esta sesión decide cuáles.
Un "rpm:3847,temp:92.4" en JSON o CSV cuesta 3–5× más bytes que el mismo dato en binario. En un enlace donde cada byte se paga en milisegundos de aire, el texto es un lujo que no existe. El costo del binario es que deja de ser autodescriptivo: sin la spec, el receptor no puede decodificar nada. De ahí que la spec sea el entregable.
Un float son 4 bytes; casi siempre sobran. Se elige la resolución físicamente útil y se escala:
| Señal | Rango | Resolución útil | Tipo | Escala | Bytes |
|---|---|---|---|---|---|
| Temperatura | −40…150 °C | 0.1 °C | i16 | ×10 | 2 |
| RPM | 0…8000 | 1 RPM | u16 | ×1 | 2 |
| Latitud | ±90° | ~1 cm | i32 | ×1e7 | 4 |
⚠️ La trampa: escalar con menos resolución de la que el sensor entrega tira información para siempre. Escalar con más desperdicia aire transmitiendo ruido. Hay que justificar el número con física, no con comodidad.
Elegir uno (little-endian, como el ESP32) y escribirlo en la spec. Un i16 leído al revés no da error: da un número plausible y falso. Además, no confiar en struct empaquetado automáticamente entre plataformas distintas — serializar campo por campo, con offsets explícitos.
MadRams manda route packet 0x55 a 5 Hz (ligero: posición, velocidad, RPM) y status packet 0xAA a 1 Hz (pesado: temperaturas, VBAT, banderas). Separar por urgencia deja el aire ocupado con lo que cambia rápido y no con lo que cambia despacio.
T_símbolo = 2^SF / BW
n_payload = 8 + max(ceil((8·PL − 4·SF + 28 + 16·CRC − 20·IH) / (4·(SF−2·DE))) · (CR+4), 0)
ToA = (n_preámbulo + 4.25 + n_payload) · T_símbolo
Es no lineal y escalonada: agregar un byte a veces no cuesta nada y a veces cuesta un símbolo entero. Por eso se calcula, no se estima.