Mostrar Mensajes
16
Atmos.cat / Problemática general con las Fine Offset, clónicas y parecidas
« en: 03 de Marzo del 2023, 18:16:24 pm »
Una estación meteorológica se compone de unos sensores que transmiten los datos a una unidad central que los procesa archivándolos de alguna forma para que sean accesibles para su utilización.
Esto que parece tan fácil en realidad es bastante complejo. Los propios sensores son unos transductores con sus problemas de linearidad, precisión, granularidad. A esto se le añade el sistema de transmisión, que si la estación es de calidad utilizará el Frequency Hopping Spread Spectrum (FHSS), y el procesamiento y almacenamiento de los datos en un datalogger (unidad de almacenamiento de datos). A partir de aquí las opciones son diversas: guardar los datos, o hacerlos disponibles para su descarga, o incluso mandarlos a servidores remotos.
Una estación de calidad posee diversos sistemas y algoritmos para garantizar que los datos sean correctos. Desde un protector de radiación bien diseñado para eliminar su influencia en el transductor termométrico, hasta un sistema de integración de múltiples valores medidos en un corto espacio de tiempo para eliminar los errores derivados de la granularidad del sensor, o como puede ser la integración por intervalos variables de tiempo de las revoluciones de las cazoletas para obtener respectivamente los valores de racha, velocidad del viento y velocidad media (10minutal, 2minutal, 1minutal y horaria).
La unidad central es entonces la encargada de recoger estos valores e irlos integrando en una base de datos con todas las variables y también los valores extremos por períodos: horario, diario, mensual y anual, además de períodos de lluvia, de sequía, y demás características, cada uno de ellos con el timestamp (fecha y hora) correspondiente.
Todos estos datos se almacenan en un datalogger, que es el encargado de ponerlo a disposición para su ulterior procesamiento, sea transmitiéndolo a un ordenador, sea mandándolo a un servidor.
Así es como funcionan las estaciones como las Davis y demás estaciones de calidad, y es sobre esta base que se creó Meteoclimatic, que además cuenta, como elemento notablemente distintivo i parcialmente equivalente a los servicios oficiales, con herramientas para la validación de los datos - la detección de inconsistencias y la contabilidad de los días sin datos.
Todo muy bien, hasta que aparecen las Fine Offset. Lo que viene ahora creo que explica muchas cosas:
Para empezar en estas estaciones baratas se ha obviado por completo cualquier procesamiento en la adquisición de los datos. Se toman medidas individuales sin medida alguna de integración para eliminar errores de granularidad (o peor, se incluyen sistemas "trampa" para que los datos no parezcan demasiado disparatados, por ejemplo restando algún grado si la radiación solar es intensa, así a bulto). Para su transmisión tampoco se usa la FHSS (véase arriba) con lo que las interferencias son posibles (y aparecen, comprobado).
Para el viento es aún peor: la estación mide un intervalo de tiempo de 16 segundos cada minuto (los restantes 44 segundos se pierden, simplemente) y da el valor máximo producido durante estos 16 segundos como "velocidad del viento", así a secas, es decir, nada que se pueda comparar con una medida correcta de la velocidad del viento. Muy bonito para mostrar algo bonito en la pantallita, pero como dato tajantemente inservible.
Y con todo esto, simplemente ahorran el procesamiento de los datos y eliminan el datalogger - de ahí que sean tan baratas. Lo único que hace es ir mandando los datos momentáneos tal cual a los servidores definidos, y que sean los servidores que se encargan del resto. Es decir: no mandan valores extremos, ni máximas, ni mínimas, ni medias, y en ocasiones ni tan sólo la hora del envío sinó que sustituyen lo que debería ser fecha y hora por un simple palabro: now.
Lo que se hace en atmos es lo mismo que en wunderground o ecowitt: con los datos que van llegando se construye una base de datos de la cual, para generar la plantilla o lo que sea, a cada consulta hay que acudir e iterar por los datos para obtener los valores extremos de las variables deseadas. Para la lluvia es aún más complicado porque los distintos modelos hacen el reset de lluvia cuando se les antoja: muchas a las 23:00 (ignoro lo que pueda haber tras tal creativa idea), otras a las 0:00, otras a las 01:00 y algunas a las 9 de la mañana. Fue todo un reto programar algo que pudiese detectar estos resets casi aleatorios para crear una base de datos coherente.
Igualmente se creó una base de datos mensual y anual para la lluvia, con lo que se rellenaban los datos correspondientes en la plantilla de meteoclimatic.
Pero ahora hay una novedad: muchas estaciones, casi todas, han incorporado en el envío la lluvia mensual, y muchas, no todas, también la lluvia anual. Siendo que desde la ubicación de la propia estación se puede controlar mejor la lluvia que cae que desde un servidor remoto, a partir de ahora, siendo que el dato está mayoritariamente disponible, se toma este dato para la lluvia, y de aquí que las estaciones que no lo envían tengan la lluvia a cero (en un hilo en este mismo foro está explicado como hacerlo para recuperar este dato).
Este sistema de la Fine Offset tiene algunos problemas que las invalidan completamente como estaciones fiables: si el "datalogger" está en un servidor remoto para que funcione correctamente tiene que estar permanentemente conectado. Si se interrumpe la conexión a internet, o falla el suministro eléctrico, o simplemente el servidor se cuelga o no está en línea, todos los datos durante la interrupción se pierden irremediablemente. No se pueden recuperar. Y algo así invalida completamente la estación, si no se puede garantizar que los datos sean completos y exactos. Especialmente grave porque cuando hay fenómenos meteorológicos relevantes abundan los cortes de internet y suministro eléctrico: un desastre.
Por si esto fuera poco, las herramientas de validación de datos de Meteoclimatic (detección de inconsistencias) quedan de entrada anuladas. Puesto que las estaciones no almacenan registros extremos de ningún modo y se fía esto a un servidor que los elabora a partir de la iteración de los datos actuales recibidos (con sus posibles lagunas por lo descrito anteriormente), las inconsistencias van a desaparecer como por arte de magia. Pero no porque no existan, sinó por un error de concepto del tratamiento de los datos, o más bien haber obviado un tratamiento correcto en pro de eliminar costes en la producción: una hipoteca que se traslada al usuario y que éste sólo podrá eludir comprando accesorios más caros o, directamente, cambiando a una estación que merezca este nombre.
Espero que con esto queden explicadas las múltiples problemáticas de este tipo de estaciones, el porqué de lluvias desaparecidas, el porqué no se pueden obtener sellos de calidad con ellas, pues se crearía un agravio comparativo considerable por las estaciones de verdad que hay en esa red, además de eliminar la herramienta, única en Meteoclimatic para una red de aficionados, para la validación manual de los datos.
Esto que parece tan fácil en realidad es bastante complejo. Los propios sensores son unos transductores con sus problemas de linearidad, precisión, granularidad. A esto se le añade el sistema de transmisión, que si la estación es de calidad utilizará el Frequency Hopping Spread Spectrum (FHSS), y el procesamiento y almacenamiento de los datos en un datalogger (unidad de almacenamiento de datos). A partir de aquí las opciones son diversas: guardar los datos, o hacerlos disponibles para su descarga, o incluso mandarlos a servidores remotos.
Una estación de calidad posee diversos sistemas y algoritmos para garantizar que los datos sean correctos. Desde un protector de radiación bien diseñado para eliminar su influencia en el transductor termométrico, hasta un sistema de integración de múltiples valores medidos en un corto espacio de tiempo para eliminar los errores derivados de la granularidad del sensor, o como puede ser la integración por intervalos variables de tiempo de las revoluciones de las cazoletas para obtener respectivamente los valores de racha, velocidad del viento y velocidad media (10minutal, 2minutal, 1minutal y horaria).
La unidad central es entonces la encargada de recoger estos valores e irlos integrando en una base de datos con todas las variables y también los valores extremos por períodos: horario, diario, mensual y anual, además de períodos de lluvia, de sequía, y demás características, cada uno de ellos con el timestamp (fecha y hora) correspondiente.
Todos estos datos se almacenan en un datalogger, que es el encargado de ponerlo a disposición para su ulterior procesamiento, sea transmitiéndolo a un ordenador, sea mandándolo a un servidor.
Así es como funcionan las estaciones como las Davis y demás estaciones de calidad, y es sobre esta base que se creó Meteoclimatic, que además cuenta, como elemento notablemente distintivo i parcialmente equivalente a los servicios oficiales, con herramientas para la validación de los datos - la detección de inconsistencias y la contabilidad de los días sin datos.
Todo muy bien, hasta que aparecen las Fine Offset. Lo que viene ahora creo que explica muchas cosas:
Para empezar en estas estaciones baratas se ha obviado por completo cualquier procesamiento en la adquisición de los datos. Se toman medidas individuales sin medida alguna de integración para eliminar errores de granularidad (o peor, se incluyen sistemas "trampa" para que los datos no parezcan demasiado disparatados, por ejemplo restando algún grado si la radiación solar es intensa, así a bulto). Para su transmisión tampoco se usa la FHSS (véase arriba) con lo que las interferencias son posibles (y aparecen, comprobado).
Para el viento es aún peor: la estación mide un intervalo de tiempo de 16 segundos cada minuto (los restantes 44 segundos se pierden, simplemente) y da el valor máximo producido durante estos 16 segundos como "velocidad del viento", así a secas, es decir, nada que se pueda comparar con una medida correcta de la velocidad del viento. Muy bonito para mostrar algo bonito en la pantallita, pero como dato tajantemente inservible.
Y con todo esto, simplemente ahorran el procesamiento de los datos y eliminan el datalogger - de ahí que sean tan baratas. Lo único que hace es ir mandando los datos momentáneos tal cual a los servidores definidos, y que sean los servidores que se encargan del resto. Es decir: no mandan valores extremos, ni máximas, ni mínimas, ni medias, y en ocasiones ni tan sólo la hora del envío sinó que sustituyen lo que debería ser fecha y hora por un simple palabro: now.
Lo que se hace en atmos es lo mismo que en wunderground o ecowitt: con los datos que van llegando se construye una base de datos de la cual, para generar la plantilla o lo que sea, a cada consulta hay que acudir e iterar por los datos para obtener los valores extremos de las variables deseadas. Para la lluvia es aún más complicado porque los distintos modelos hacen el reset de lluvia cuando se les antoja: muchas a las 23:00 (ignoro lo que pueda haber tras tal creativa idea), otras a las 0:00, otras a las 01:00 y algunas a las 9 de la mañana. Fue todo un reto programar algo que pudiese detectar estos resets casi aleatorios para crear una base de datos coherente.
Igualmente se creó una base de datos mensual y anual para la lluvia, con lo que se rellenaban los datos correspondientes en la plantilla de meteoclimatic.
Pero ahora hay una novedad: muchas estaciones, casi todas, han incorporado en el envío la lluvia mensual, y muchas, no todas, también la lluvia anual. Siendo que desde la ubicación de la propia estación se puede controlar mejor la lluvia que cae que desde un servidor remoto, a partir de ahora, siendo que el dato está mayoritariamente disponible, se toma este dato para la lluvia, y de aquí que las estaciones que no lo envían tengan la lluvia a cero (en un hilo en este mismo foro está explicado como hacerlo para recuperar este dato).
Este sistema de la Fine Offset tiene algunos problemas que las invalidan completamente como estaciones fiables: si el "datalogger" está en un servidor remoto para que funcione correctamente tiene que estar permanentemente conectado. Si se interrumpe la conexión a internet, o falla el suministro eléctrico, o simplemente el servidor se cuelga o no está en línea, todos los datos durante la interrupción se pierden irremediablemente. No se pueden recuperar. Y algo así invalida completamente la estación, si no se puede garantizar que los datos sean completos y exactos. Especialmente grave porque cuando hay fenómenos meteorológicos relevantes abundan los cortes de internet y suministro eléctrico: un desastre.
Por si esto fuera poco, las herramientas de validación de datos de Meteoclimatic (detección de inconsistencias) quedan de entrada anuladas. Puesto que las estaciones no almacenan registros extremos de ningún modo y se fía esto a un servidor que los elabora a partir de la iteración de los datos actuales recibidos (con sus posibles lagunas por lo descrito anteriormente), las inconsistencias van a desaparecer como por arte de magia. Pero no porque no existan, sinó por un error de concepto del tratamiento de los datos, o más bien haber obviado un tratamiento correcto en pro de eliminar costes en la producción: una hipoteca que se traslada al usuario y que éste sólo podrá eludir comprando accesorios más caros o, directamente, cambiando a una estación que merezca este nombre.
Espero que con esto queden explicadas las múltiples problemáticas de este tipo de estaciones, el porqué de lluvias desaparecidas, el porqué no se pueden obtener sellos de calidad con ellas, pues se crearía un agravio comparativo considerable por las estaciones de verdad que hay en esa red, además de eliminar la herramienta, única en Meteoclimatic para una red de aficionados, para la validación manual de los datos.