Cuando algo “no cuadra” en una estación meteorológica, lo peor es ir a ciegas. Este artículo es una lista de pasos para revisar rápido y bien (en 10–20 minutos) si el problema viene del sensor, la instalación, el entorno o el software/pipeline. Incluye ejemplos reales (especialmente con lluvia convectiva) para no borrar picos auténticos pensando que son errores.

Este artículo forma parte del tema Datos de calidad en WikiMeteo.es, donde reunimos conceptos y guías prácticas para entender mejor el tiempo y el clima.

1. Qué es y por qué importa

Un buen checklist evita dos errores caros: publicar basura (por no detectar un fallo creíble) o borrar un episodio real (por aplicar filtros agresivos). Si revisas siempre en el mismo orden, reduces sesgos y ganas confianza en tus datos.

2. Idea clave en 30 segundos

• En una frase: primero valida tiempo (UTC/DST/drift), luego integridad (duplicados/gaps), después forma (spike/step/stuck), y por último coherencia y contexto
• Señal típica: patrones repetidos (a la misma hora o cada X minutos) suelen ser pipeline, no meteorología
• Confusión común: “el radar no lo ve” o “el vecino no lo tiene” no significa automáticamente error

3. Preparación (2 minutos)

• Define el periodo sospechoso: ¿desde cuándo pasa?
• Anota condiciones: sol/calma, lluvia fuerte, noche húmeda, viento fuerte.
• Identifica qué producto falla: dato instantáneo, acumulado, máximas/mínimas, medias diarias.
• Ten una referencia externa: radar/satélite/red cercana (solo como ayuda, no juez único).

4. Checklist de tiempo (UTC, cambio de hora y drift)

• ¿Están los datos en UTC? Si guardas en local, marca la regla del “día” y cómo manejas DST.
• ¿Hay duplicados o huecos en el cambio de hora? días de 23/25 h → revisa si el pipeline duplica o elimina registros.
• ¿Hay desfase vs radar/vecinos? si el episodio parece “desplazado”, sospecha drift del logger.
• Prueba rápida: compara el pico principal del episodio con una referencia temporal (p.ej. inicio de lluvia) y estima el offset (minutos).

5. Checklist de integridad (antes de calcular nada)

• Orden temporal: no debe haber timestamps fuera de orden.
• Duplicados: deduplicar antes de medias/sumas.
• Gaps: si faltan datos, evita calcular productos diarios sin cobertura mínima.
• Resolución y muestreo: confirma el intervalo (1 min, 5 min, 10 min) y que no cambió.

6. Checklist de forma de la serie (diagnóstico visual)

• Spikes finos (pico aguja): ruido eléctrico, parsing, cableado.
• Valores clavados (stuck): sensor bloqueado/driver/fallo de alimentación.
• Escalón persistente (step): cambio de ubicación, altura, entorno o recalibración.
• Dientes de sierra: redondeo/agregación, reinicios o alternancia de fuentes.

7. Checklist específico de lluvia (convectiva vs error)

La lluvia convectiva real puede producir picos muy altos y concentrados. Para no confundirla con error, usa estas pruebas:

• Duración: convectiva real suele tener fase intensa corta + cola; un tick aislado en seco es sospechoso.
• Coherencia: si llueve de verdad, normalmente sube HR y baja T (no siempre, pero ayuda).
• Contexto: ¿había tormentas cerca? ¿hubo rayos? ¿eco en radar aunque sea desplazado?
• Patrón repetido: ticks idénticos cada noche a la misma hora → típico de falso basculado.
• Acumulado que baja: casi siempre reinicio del totalizador o cálculo mal hecho.
• Prueba rápida: mira el pluvio: nivelado, embudo limpio, insectos, vibración, anclaje.

8. Checklist de agregación y productos (día/mes/extremos)

• Día meteorológico: define si es UTC o local (y cómo manejas DST).
• Cobertura mínima: no publicar medias/lluvia diaria si falta mucha muestra.
• Redondeo: redondear después de integrar, no antes.
• Reinicios: si el acumulado se resetea, recomputa desde incrementos/raw.
• Outliers: no los borres por “raros”; marca con flag y valida con coherencia/contexto.

9. Checklist físico rápido (instalación y entorno)

• Abrigo de T/HR: ventilación, distancia a paredes/pavimento, reflectancias, sombra a distintas horas.
• Anemómetro: libre de obstáculos, altura adecuada, sin rozamientos; dirección no debe quedarse fija siempre.
• Pluviómetro: nivelado, embudo limpio, sin obstáculos, anclaje firme.
• Entorno: árboles más altos, nuevas construcciones, cambios de superficie (pinturas, tejados, pavimentos).

10. Checklist de coherencia multivariable (para decidir si “es real”)

• T–HR–Td: cambios compatibles entre sí (si sube mucho HR, Td suele acompañar).
• Viento–presión: episodios ventosos a menudo coinciden con gradiente/cambios de presión.
• Lluvia–HR/T–nubosidad: apoyo contextual: no es prueba única, pero suma.
• Radiación–nubes: radiación alta con cielo cerrado suele indicar problema (sensor sucio o inclinación).

11. Errores comunes

• Aplicar un único umbral fijo para todo el año y todas las situaciones
• Concluir “es error” solo porque una estación cercana no lo vio
• Corregir datos publicados sin registrar qué cambiaste y por qué
• Olvidar UTC/DST y romper extremos diarios/mensuales

12. Buenas prácticas

• Guardar raw en UTC y publicar productos derivados reprocesables
• Usar flags de calidad en vez de borrar (OK/SOSPECHOSO/MALO)
• Metadatos siempre: cambios físicos y de software con fecha
• Mantenimiento preventivo sencillo (limpieza, nivelado, revisión abrigo)

13. Resumen y claves finales

• Empieza por tiempo (UTC/DST/drift) antes de culpar al sensor
• Deduplica y controla gaps antes de calcular productos
• Clasifica por forma: spike/step/stuck/dientes de sierra
• En lluvia convectiva, protege extremos: valida con coherencia y contexto, no con reglas rígidas
• Marca con flags y documenta: reproducible > “arreglo rápido”

14. Mini-glosario

• UTC: hora estándar sin cambio estacional
• DST: cambio de hora (día 23/25 h)
• Drift: deriva del reloj del logger
• Outlier: valor extremo (puede ser real o error)
• Flag: etiqueta de calidad asociada al dato

15. Referencias y lecturas recomendadas

• WMO: guías de instrumentación, exposición y control de calidad
• NOAA: recursos de observación y estaciones
• AEMET: documentación y guías de observación