60 min de análisis + 30 de design doc. La sesión abre con datos reales del coche y se evalúa con el dataset determinista, para que todos compitan contra lo mismo.

Paso 0 · Apertura con dato real (10 min)

Se proyecta una vuelta real: ruido, huecos, un sensor saturado. En grupo, solo mirando, listar tres cosas que se ven mal. No analizar todavía — la idea es que el ojo se calibre antes que la herramienta.

Paso 1 · Caza de bugs (20 min)

Síntoma: el script de detección reporta ~400 eventos en una vuelta. Es evidentemente falso.

Bug raíz (uno solo): el umbral no tiene histéresis y la señal es ruidosa — cada cruce cuenta como evento nuevo.

Procedimiento:

1. Graficar la señal con la línea del umbral encima. Hacer zoom a un tramo con "eventos". Se ve el problema de inmediato.
2. Contar a mano cuántos eventos hay realmente en ese tramo. Ese es el número contra el que se calibra.
3. Hipótesis por escrito.
4. Meter dos umbrales y un tiempo mínimo de permanencia. Barrer la banda muerta y anotar cuántos eventos da cada valor. Elegir donde el conteo se estabiliza.
5. Bitácora con el barrido completo, no solo el valor final.

Paso 2 · Verificación de sincronía y aliasing (15 min)

1. Revisar los timestamps: buscar huecos, duplicados y saltos hacia atrás. Reportar cuántos de cada uno.
2. Estimar la frecuencia real de muestreo a partir de los deltas y compararla con la nominal. Si difieren, decir por qué (jitter de S4, buffer de S5).
3. Sobre la señal de suspensión, verificar si hay contenido cerca de la mitad de la frecuencia de muestreo. Si lo hay, hay sospecha de aliasing y debe declararse en el informe.
4. Alinear dos sensores de frecuencias distintas en una rejilla común y documentar el método.

Paso 3 · Mini-informe (15 min)

Una sola página, esta estructura fija:

1. Qué corrida es — fecha, duración, sensores, frecuencias reales medidas