Supongamos que tengo varios registradores de datos que reciben datos de sensores, ¿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 como solucionarías esto?
Para relojes precisos independientes, puede probar los receptores GPS o los receptores de tiempo de onda larga, como 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 actual y las marcas de tiempo del registrador de datos. Si conoce la hora absoluta de la última carga, podría intentar distribuir cualquier error que encuentre de manera uniforme durante el último intervalo.
Puede poner una medición de tiempo relativo razonablemente decente en cada registrador de datos. Por ejemplo, los cristales de "reloj" de 32768 Hz son baratos, de baja potencia y están disponibles con buena precisión. Puede obtener fácilmente uno bueno a 20 ppm.
Digamos que los datos se cargan desde cada unidad aproximadamente una vez al mes. Entre cargas, la unidad marca la hora de cada registro de datos de su reloj local. Estas marcas de tiempo no están sincronizadas en tiempo real, pero tienen un error de acumulación de 20 ppm como máximo entre sí. 20 ppm durante 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 retrocediendo. 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 el error de 1 minuto es aceptable, entonces poco más se necesita hacer.
Sin embargo, al almacenar el tiempo real del evento de carga y, por supuesto, marcarlo como de costumbre, el peor de los casos puede reducir significativamente el error. 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. Entonces, en cada carga, conoce el tiempo absoluto al comienzo y al final de la carga de datos. El peor de los casos se desvía de un tiempo conocido ahora en la mitad del período de carga, que está a solo medio mes de una referencia, o solo a medio minuto de diferencia.
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. Dado que conoce el tiempo real al principio y al final de la carga de datos, puede determinar qué tan rápido o lento corrió el reloj local durante ese tiempo y contabilizarlo. Por ejemplo, si el oscilador local fue exactamente 20 ppm rápido todo el tiempo, las marcas de tiempo mostrarán un período de 1 minuto más que el tiempo conocido entre el inicio y el final de los datos. Si proporciona linealmente el error de marca de tiempo para que los extremos encajen (ya que se conocen), los datos en el medio serán exactos siempre que el oscilador local no cambie. A mediados de mes, restas alrededor de medio minuto, etc.
Los cristales a menudo se especifican para un error absoluto y un error relativo a lo largo del tiempo. Con el segundo esquema, el error absoluto se cancela. Cualquier error de tiempo restante es solo una función de cuánto cambió el cristal durante el último mes, que puede ser significativamente menor que su error absoluto promedio.
usuario3624
olin lathrop
usuario3624