Los errores en datos meteorológicos no aparecen por magia: casi siempre responden a mecanismos concretos (físicos, eléctricos o de software) que dejan una huella reconocible en la serie. Entender “qué se rompe y por qué” te ayuda a no perseguir fantasmas, y sobre todo a no confundir meteorología real con artefactos (muy típico en picos de lluvia convectiva o en máximas de temperatura por mala exposición).

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é se rompe (y por qué importa)

Un dato meteorológico pasa por una cadena: fenómeno → sensor → electrónica → registro → transmisión → procesamiento → publicación. Un fallo en cualquier eslabón cambia el número final. Lo importante no es solo detectar el error, sino saber si afecta decisiones: alertas, verificación, climatología, o un simple gráfico en una web.

2. Idea clave en 30 segundos

• En una frase: cada mecanismo de error deja una huella típica (forma, repetición, coherencia física) y casi siempre es reproducible
• Señal típica: saltos imposibles, repetición periódica o incoherencia entre variables
• Confusión común: culpar al sensor cuando el problema es hora (UTC/DST) o exposición (abrigo)

3. Mapa rápido de mecanismos (de más común a más traicionero)

• Exposición/abrigo (T/HR): sobrecalentamiento por radiación, falta de ventilación, humedad atrapada.
• Interferencias / contacto eléctrico: spikes y lecturas corruptas.
• Alimentación: microcortes, brownouts, reinicios, paquetes duplicados.
• Tiempo (timestamp): UTC vs local, cambio de hora, drift del logger.
• Agregación: medias/rachas/acumulados mal definidos o reseteados fuera de hora.
• Entorno cambiante: sombras estacionales, vegetación, isla de calor, superficies reflectantes.
• Limitaciones del instrumento: saturación, subcaptación por viento, resolución/quantización.

4. Mecanismos del sensor: por qué “miente” sin estar roto

• Deriva: el sensor envejece, se contamina o cambia su respuesta con el tiempo. Resultado: sesgo lento (a veces estacional) que se nota al comparar con referencias.
• Condensación/humedad: afecta mucho a HR y puede producir lecturas pegadas o muy altas durante periodos incoherentes.
• Resolución y redondeo interno: algunos sensores cuantizan (saltan en escalones). Puede parecer “raro” pero es limitación.
• Saturación: radiación/UV pueden saturar; en lluvia muy intensa el pluviómetro puede perder eficiencia; en viento muy turbulento el anemómetro puede subestimar.
• Bloqueo mecánico: anemómetro con suciedad/hielo, pluviómetro con embudo sucio.

5. Mecanismos de instalación: el abrigo y la geometría mandan

La instalación crea un microclima artificial. Lo que se rompe aquí no es “el dato”, sino la representatividad:

• Abrigo (T/HR): si está mal ventilado o mal expuesto, el sensor mide el aire calentado dentro del abrigo, no el aire ambiente.
• Altura y proximidad: paredes, suelos calientes, tejados, maquinaria. Pequeñas distancias importan muchísimo.
• Viento y obstáculos: edificios/árboles crean turbulencia y sombra de viento: el sensor deja de ser representativo.
• Pluviómetro: nivelado, fijación y exposición al viento. El viento puede sacar gotas del embudo (subcaptación) o provocar ticks espurios por vibración.

6. Mecanismos del entorno: cambios lentos que nadie ve venir

• Sombras estacionales: el sol de invierno vs verano cambia sombras; aparecen sesgos en máximas/minimas por horas concretas.
• Vegetación: crece y modifica viento, radiación y humedad del entorno.
• Isla de calor: cambios en pavimento, obras, tráfico, nuevos aparatos de climatización cerca.
• Superficies reflectantes: paredes claras o suelos pueden aumentar radiación y calentar el abrigo indirectamente.

7. Mecanismos del software/pipeline: el número se rompe después

• Parseo y unidades: se confunden unidades o factores (mm vs in, km/h vs m/s). Resultado: series coherentes pero “mal escaladas”.
• Agregación mal definida: máximas/rachas por ventana distinta a la esperada; acumulados que se reinician cuando reinicia el logger.
• Duplicados y reintentos: si la red cae y reenvía, puedes sumar dos veces lluvia o repetir máximas.
• Redondeo temprano: redondear antes de agregar crea escalones artificiales y distorsiona extremos.
• Huecos: datos faltantes que se rellenan sin marcarlo (peligroso para verificación).

8. Timestamps: UTC, cambios de hora y drift del logger

Este es el mecanismo que más “parece meteorología” siendo software. Tres trampas típicas:

• UTC vs hora local: si mezclas series en distinta base, verás máximas/mínimas “desplazadas” y acumulados diarios raros.
• Cambio de hora (DST): aparece un salto de 1 hora (duplicación o hueco). Si tu pipeline no lo gestiona, verás dientes de sierra en derivados o acumulados diarios mal cerrados.
• Drift: el reloj del logger deriva minutos u horas con semanas/meses. Resultado: desalineación progresiva con radar/satélite y con estaciones cercanas; en eventos rápidos (convectiva) te confunde mucho.

Señal rápida: si un pico de lluvia “no coincide” con radar/rayos por 15–30 min de forma sistemática, sospecha drift antes que “pluviómetro loco”.

9. Ejemplos y casos típicos (con explicación del mecanismo)

• T máxima “demasiado alta” en días soleados y calma: abrigo mal ventilado + radiación directa/indirecta.
• HR pegada al 99–100% muchas horas sin niebla/nube: sensor mojado/condensación o abrigo que atrapa humedad.
• Lluvia de 0,1–0,2 mm repetida cada hora en día seco: vibración/insectos en el pluviómetro o redondeo/agregación en el pipeline.
• Rachas raras sin coherencia: turbulencia por obstáculo o definición de racha/ventana mal implementada.
• Serie desplazada 1 hora justo en marzo/octubre: cambio de hora mal manejado.
• Evento convectivo desalineado con radar: drift del logger o timestamps mezclados (UTC/local).

10. Errores comunes

• Arreglar el dato sin arreglar la causa (volverá a pasar)
• Invalidar extremos reales por “parecer demasiado bruscos”
• No separar raw de QC y perder trazabilidad
• Ignorar UTC/DST y culpar al sensor

11. Buenas prácticas

• Metadatos de cambios: cualquier intervención deja marca (fecha, qué se tocó).
• Regla de coherencia: antes de declarar “error”, busca coherencia entre variables y, para lluvia, apoyo externo (radar/rayos).
• QC por flags: marca sospecha en vez de borrar; conserva raw.
• Tiempo bien definido: documenta si publicas en UTC o local; gestiona DST; monitoriza drift.

12. Resumen y claves finales

• Los mecanismos más frecuentes: abrigo/exposición, timestamps, agregación y alimentación
• Un error suele dejar huella: escalón, aguja, pegado, repetición o desfase
• UTC/DST/drift pueden simular meteorología: revísalo pronto
• Convectiva: picos bruscos pueden ser reales; valida antes de filtrar
• Calidad de datos sana = raw + flags + metadatos + reglas reproducibles

13. Mini-glosario

• Timestamp: marca temporal asociada a una medición
• DST: cambio de hora estacional (horario de verano/invierno)
• Drift: deriva del reloj del logger
• Agregación: cálculo de medias/rachas/acumulados a partir de datos base
• Trazabilidad: capacidad de reconstruir cómo se obtuvo y procesó el dato

14. Referencias y lecturas recomendadas

• WMO: guías de instrumentación, exposición, observación y metadatos
• NOAA: materiales educativos y documentación de observación y datos
• NASA: recursos y documentos sobre mediciones ambientales y calibración (según producto/sensor)