Supongamos que tengo varios registradores de datos que reciben datos del sensor, ¿cómo puedo sincronizar esas señales después? La forma más obvia sería agregar marcas de tiempo a los datos, pero tienen relojes independientes, por lo que realmente no puedo sincronizar las señales, incluso con esas marcas de tiempo.
¿Sería posible usar un pequeño chip de tiempo satelital para esto, de modo que todos los sellos provengan de la misma fuente? ¿O cómo resolverías esto?
Para relojes precisos independientes, puede probar los receptores GPS o los receptores de onda larga como los de WWVB.
Otra opción es colocar osciladores de cristal razonables en cada unidad y sincronizarlos como parte del proceso de carga de datos. El sistema que recibe los datos conoce la hora absoluta actual y extrapola hacia atrás utilizando la hora y las marcas de tiempo actuales del registrador de datos. Si conoce el tiempo absoluto de la última carga, podría intentar propagar cualquier error que encuentre uniformemente en el último intervalo.
Puede colocar una medición de tiempo relativa razonablemente decente en cada registrador de datos. Por ejemplo, los cristales de "reloj" de 32768 Hz son baratos, de baja potencia y disponibles con buena precisión. Fácilmente puede obtener uno bueno a 20 ppm.
Digamos que los datos se cargan desde cada unidad aproximadamente una vez al mes. Entre subidas, la unidad marca la hora de cada registro de datos de su reloj local. Estas marcas de tiempo no están sincronizadas con el tiempo real, pero tienen un error acumulado de 20 ppm como máximo entre sí. 20 ppm en un mes es aproximadamente un minuto.
La computadora que recibe los datos cargados conoce el tiempo real y el tiempo actual del registrador de datos y, por lo tanto, puede determinar cómo trabajar hacia atrás para encontrar el tiempo real de cada uno de los registros de datos con un error de hasta 20 ppm hacia atrás. Por ejemplo, los datos más antiguos de hace un mes solo se conocen en aproximadamente 1 minuto. Los datos desde hace medio mes hasta dentro de medio minuto, etc. Si un error de 1 minuto es aceptable, es necesario hacer un poco más.
Sin embargo, al almacenar el tiempo real del evento de carga y, por supuesto, marcarlo como es habitual, el error en el peor de los casos puede reducirse significativamente. Esto solo requiere escribir un solo evento en el registro después de cada carga. Este será el primer evento en el registro en la próxima carga. En cada carga, entonces, usted sabe el tiempo absoluto al inicio y al final de los datos de carga. El caso más desfavorable de una hora conocida se encuentra ahora en la mitad del período de carga, que es solo la mitad de un mes a partir de una referencia, o solo un medio minuto libre.
Aún mejor es que el error ahora es independiente del error absoluto del reloj local. Los errores de tiempo solo dependen de los cambios en la frecuencia del reloj local. Ya que conoce el tiempo real al principio y al final de los datos de carga, puede determinar qué tan rápido o lento funcionó el reloj local durante ese tiempo y dar cuenta de ello. Por ejemplo, si el oscilador local fue exactamente 20 ppm rápido todo el tiempo, entonces las marcas de tiempo mostrarán un período de 1 minuto más largo que el tiempo conocido entre el inicio y el final de los datos. Si proporciones linealmente el error de marca de tiempo para que los extremos se ajusten (como se conocen), los datos en el medio serán exactos siempre que el oscilador local no cambie. A mediados del mes, restas aproximadamente medio minuto, etc.
Los cristales a menudo se especifican para un error absoluto y un error relativo en el tiempo. Con el segundo esquema, el error absoluto se anula. Cualquier error de tiempo restante es solo una función de cuánto ha cambiado el cristal durante el último mes, lo que puede ser significativamente menor que el error absoluto promedio.
Lea otras preguntas en las etiquetas rtc wireless clock datalogger