60 min: lab packet-designer + Wokwi + 10 de entregable. Esta es la única sesión del Avanzado con código corriendo — la serialización sí se simula honestamente.

Paso 0 · Inventario de señales (10 min)

Listar todo lo que el coche puede mandar, con su rango físico real y la frecuencia a la que cambia de verdad. Marcar cada una como ruta (5 Hz) o status (1 Hz). Justificar en una línea: mandar la temperatura del CVT a 5 Hz es desperdiciar aire, porque no cambia a esa velocidad.

Paso 1 · Diseño del paquete en el lab (20 min)

En packet-designer, armar los dos paquetes. Por cada campo: nombre, tipo, escala, offset, unidad física.

El lab muestra en vivo: bytes totales, el hex de ejemplo, el ToA y el % de aire ocupado. Iterar hasta cumplir las tres reglas:

1. ≤ 30 % de aire ocupado con ambos paquetes sumados
2. ToA ≤ 400 ms (dwell)
3. Ninguna señal pierde resolución útil

Si no cierra, documentar qué se sacrificó y por qué. Un diseño que cierra tirando datos sin decirlo vale menos que uno que no cierra y lo explica.

Paso 2 · Serialización en Wokwi (20 min)

1. Escribir la función que arma el arreglo de bytes: escalas, endianness, offsets, número de secuencia, CRC al final.
2. Imprimir el paquete en hex por el serial.
3. Verificación cruzada: intercambiar el hex con otra pareja y decodificar el suyo usando solo su spec escrita, sin preguntarles nada. Si no se puede decodificar, la spec está incompleta — y ese es el hallazgo más valioso de la sesión.
4. Corromper un byte a propósito y confirmar que el CRC lo detecta.
5. Hacer rodar el contador de secuencia hasta el wrap (65535 → 0) y verificar que el receptor no interprete el salto como 65 mil paquetes perdidos.

Paso 3 · Tabla de ToA por SF (10 min)

Con el tamaño final de ambos paquetes:

Cruzar con el margen de enlace de la Sesión 1: el SF elegido debe cumplir ambas hojas. Si la S1 pide SF10 y la tabla de aquí dice que a SF10 no cabe, el paquete se reduce — no se ignora una de las dos.