Cuente los ciclos del reloj del oscilador para obtener el tiempo

primera vez en stackexchange, espero estar en el lugar correcto. Estoy trabajando en un proyecto en el que necesito marcar la hora de un evento (que se detectará a partir de un pulso eléctrico) hasta unas pocas decenas de nanosegundos y sincronizarlo con GPS (porque habrá un par de esos módulos que deben sincronizarse entre sí ). Busqué una solución simple de arduino/frambuesa, pero parece que no funcionará mejor que 1-2 nosotros, lejos de ~ 30 ns.

Estaba pensando en usar la salida de 1PPS (1Hz) del GPS para obtener un tiempo muy preciso y luego encontrar el intervalo de tiempo entre este pulso y el pulso del sensor contando los ciclos de un reloj externo de alta precisión. He encontrado un reloj que me dará menos de 30 ns de inexactitud sobre 1 s PPS (40 MHz, 10 ppb, jitter de 1 ps).

Ahora, el problema es ¿cómo hago para contar estos ciclos de reloj? Mi experiencia en el tema es muy cercana a 0 y la de mi compañero también. Cualquier ayuda es muy apreciada.

EDITAR: Parece que esto es muy complicado para alguien que solo tiene experiencia con el microcontrolador y envía datos a través de la serie. El producto perfecto para mi aplicación sería algo como esto: http://www.ti.com/product/TDC7201/description Simplemente conecte los dos pulsos a los pines START y STOP y devolverá el intervalo de tiempo. La única diferencia es que necesitaría una medición de 1 s (frente a 8 ms) pero con una precisión de 10-50 ns (frente a 50 ps). Básicamente, una medición 1000 veces más larga con una precisión 1000 veces menor.

Un ATmega328 (el microcontrolador en un arduino uno) puede cronometrar eventos hasta una resolución de 62,5 ns, no "1 o 2 microsegundos".
Creo que lo que quiere hacer es ejecutar su procesador desde el reloj de 40 MHz y usar un temporizador interno para medir el intervalo. La señal 1PPS puede no ser precisa cuando el GPS no está sincronizado con los satélites. Además, la señal de 1 pps puede tener un tiempo de subida o bajada lento, y esto podría generar cierta incertidumbre de tiempo si su umbral de voltaje de conmutación no es muy estable. Si no recuerdo mal, el 1pps es estable a largo plazo, pero puede tener fluctuaciones de ciclo a ciclo. Entonces, la solución ideal podría ser algún tipo de PLL digital.
El GPS tiene jitter (11 ns para el que tengo en mente). El GPS es imprescindible ya que necesitamos 5 módulos sincronizados separados unos 10km. ¿Puede dar más detalles sobre "ejecutar su procesador desde el reloj de 40 MHz y usar un temporizador interno para medir el intervalo"? He leído sobre la resolución de 62,5 ns de ATmega contando los ciclos de la CPU, pero no he logrado encontrar cómo contarla. Incluso entonces, el reloj integrado no tiene la precisión requerida (perderá/avanzará mucho más de 30 ns en 1 s).
@jms, OP significa un error absoluto de 30 ns en un intervalo de tiempo de 1 s. Es probable que el reloj arduino chatarra sea de 50 ppm, lo que le dará un error de 50 us.
Primero, desea un "oscilador disciplinado de GPS", a menos que intente emularlo en el software aplicando correcciones de la cantidad de relojes que ha medido por GPS Hz. Sus requisitos de resolución de tiempo pueden hacer hincapié en los límites típicos del reloj periférico del contador/temporizador de MCU, tanto porque los relojes internos altos se multiplican internamente desde una entrada más baja como porque, a menudo, los periféricos no pueden funcionar a la velocidad máxima. Pero mire varias partes modernas de ARM Cortex M4 para tener una idea de lo que sería fácil. Para ir más rápido, puede considerar un FPGA para la marca de tiempo y MCU para informar.
Lo que quiero decir es que si el procesador funciona con un oscilador de alta precisión, como su reloj de 40 MHz, entonces los otros relojes dentro del procesador tendrán la misma precisión, incluso si la frecuencia es diferente debido a PLL y conversión arriba/abajo usando divisores/multiplicadores, etc. Muchos procesadores tienen funciones de captura de tiempo incorporadas, donde un determinado evento inicia el temporizador y otro evento lo detiene. Entonces es solo cuestión de leer el registro después de que ocurra el evento. No estoy seguro de que pueda alcanzar su objetivo, pero si no, es posible que necesite un FPGA.
@ChrisStratton "trate de emular eso en el software aplicando correcciones de la cantidad de relojes que ha medido por GPS Hz" Si entiendo correctamente, esto es lo que estoy tratando de hacer. La pregunta sigue siendo, ¿cómo cuento la cantidad de ciclos de reloj entre 2 eventos (o pulsos eléctricos)?
Usas el periférico contador/temporizador en una MCU mejor que un ATmega, o si necesitas ir más rápido que eso, usas un FPGA pequeño o un chip de sincronización dedicado; parece que quieres un temporizador de eventos registrado a 100 MHz más o menos. La idea de las correcciones del software sería medir también el intervalo del GPS 1pps y aplicar cualquier desviación de un segundo medido allí a los tiempos medidos de los eventos de interés, bajo algún modelo simple del error del reloj local rápido. Eso será tosco, pero más barato que usar una fuente de laboratorio de 100 MHz disciplinada por GPS.
Si está utilizando un código, obtiene el conteo de un temporizador de ejecución libre cuya frecuencia se conoce. Si está utilizando registros de captura, los configuró correctamente, luego simplemente lea el tiempo transcurrido del registro apropiado después de que haya ocurrido el evento. No soy programador, pero a veces trato con este tipo de cosas.
Algunos conjuntos de chips GPS tienen un pin de entrada de pulso, el módulo le indica la hora en que cambia de estado. Explore la gama de productos uBlox. Para que el GPS llegue de forma fiable a menos de 100 ns, se necesitará un largo tiempo de medición o un elegante receptor libre de iones. Para la calibración, necesitará acceso a una mejor unidad de referencia y un contador de intervalos de tiempo. Puede que tengas suerte con varias unidades de un mismo modelo, fáciles de probar.
@tomnexus El GPS que tenía en mente era de uBlox en realidad ( u-blox.com/sites/default/files/products/documents/… ). Me hiciste notar que presenta "Marca de tiempo de entradas de eventos externos". ¿Será esto confiable? Afirman que la precisión RMS es de 30 ns, ¿debería ser válido para marcar un evento en la entrada?
@ user126881 esa es la función a la que me refería. Creo que no lo harás mejor que eso. Para la precisión, 30 ns está justo en el límite de lo que un simple GPS puede hacer de todos modos, el tiempo a ese nivel está dominado por la ionosfera. Y ahorra todo ese dolor de diseño de circuitos.
@ user126881 aún tendrá muchos problemas con una entrada tan rápida. Por ejemplo, tengo una raspberry pi que mide algo usando una salida GPS PPS como disparador. Encuentro que a menudo se activa en falso por ruido eléctrico. Entonces encuentro 11 o 12 pulsos cada 10 segundos. Necesitaré una tierra mucho mejor y un blindaje para detener esto.
@tomnexus Me comuniqué con u-blox hoy y todos los miembros de su módulo pueden hacerlo, incluso si no siempre se menciona como una característica. Para las personas que se pregunten, los módulos u-blox pueden marcar el tiempo de un evento una vez cada época, es decir, una vez por segundo para una frecuencia de actualización de 1 Hz. Si ocurren dos eventos en una época, solo se marcará el último.
@tomnexus Ese ublox puede funcionar a 5 Hz, por lo que te lleva a 1 evento cada 200 ms. La otra opción si necesita eventos más frecuentes es ejecutar el PPS a un ritmo más rápido. Todos los ublox pueden hacer al menos 1kHz en el PPS. Eso reduce el tiempo máximo que necesita para contar con un reloj diferente a 1 ms como máximo, lo que debería reducir los errores. Conocer el tiempo absoluto para cada pulso PPS requiere algo de juego durante la inicialización, pero es factible.

Respuestas (3)

Contar ciclos entre pulsos PPS no es un buen enfoque. Incluso usando relojes con una estabilidad de 10 ppb, aún necesita evaluar el sesgo entre diferentes unidades.

El uso de un receptor GPS integrado con marca de tiempo es un buen enfoque. Sin embargo, tenga en cuenta que no será fácil obtener esta precisión RMS de 30 ns en condiciones de la vida real. 30 ns se traducen en una precisión de posición de solo 9 m. Si bien la mayoría de los receptores alcanzan esto fácilmente para la posición filtrada de kalman, verá más perturbaciones en sus marcas de tiempo (donde el receptor no puede emplear un modelo de Markov oculto ) a menos que también promedie varios eventos.

La recepción multitrayecto es su principal adversario (para unidades separadas por decenas de kilómetros y eventos en fracciones de segundo). El multipath será mitigado de alguna manera por el receptor, pero lo mejor que puedes hacer es usar una buena antena (choke ring o similar) y elegir un buen lugar. Ponerlo en un trípode también puede ayudar.

La calibración de retardo de grupo normalmente no será necesaria durante 30 ns si todos sus módulos usan una configuración similar (la longitud del cable de la antena es importante, también los amplificadores o similares).

Se puede lograr una precisión mucho mejor si puede medir el evento en banda con las señales GPS, es decir, a través de la interfaz de RF del receptor . Esto relacionará el tiempo directamente con las señales recibidas y ofrece la oportunidad de cancelar varias fuentes de error. Si no necesita el resultado casi en tiempo real, puede grabar señales de GPS junto con su disparador y procesarlas posteriormente. Esto dará una alta precisión de posición relativa y tiempo (GPS diferencial).

No estoy familiarizado con Arduino Uno, pero probablemente tenga un módulo de contador que puede medir intervalos. Pero estará limitado a la frecuencia del reloj, que probablemente sea demasiado baja para lo que desea. Será mejor que cambie a un Arduino Due, seguramente tiene esta capacidad y puede funcionar a 96 MHz. Estudie el periférico contador/temporizador (hoja de datos). Úsalo para capturar

  • el intervalo entre los pulsos de 1s
  • el intervalo entre el último pulso de 1s y el evento

A partir de estas cifras, puede calcular el intervalo exacto entre el último pulso y el evento.

Tenga en cuenta que programar el periférico no es fácil. Y si su experiencia en la programación de microcontroladores es nula, primero tendrá que llevarla a un nivel razonable. Eso no es algo que se aprende en una semana. Si tiene habilidades básicas de programación y un buen instructor, un mes puede ser una buena suposición. Y entender que el temporizador viene después de eso...

Trabajé con una empresa de I+D. que una vez tuvo una red con requisitos similares para TDM síncrono en una red compartida. El multiplexor ascendente midió el error de fase de un pulso angosto de cada "remitente" de modo que no solo los objetivos descendentes pudieran bloquearse en fase con el flujo de bits compartido en su propio intervalo de tiempo, sino sincronizar la fase debido a la "construcción de línea" o latencia o cualquier otro error de fase. Luego, el repetidor envió comandos de corrección de fase a cada remitente cuando fue necesario para garantizar que el punto central recibiera todo en perfecta sincronización.

Para lograr algo como esto, su detector de error de fase debe tener una resolución mayor que el error requerido y la desviación en el tiempo de cualquier transmisor no sincronizado debe traducirse en un intervalo de tiempo que pueda corregirse dentro del intervalo del detector de fase de +/- xx ns. El uso de la detección de fase ULF/VLF proporciona una mayor amplitud de fase, pero cuando se multiplica hasta una resolución de frecuencia que proporciona una sincronización de fase en la región de 10 ns, se requiere un reloj de ruido de fase bajo muy estable o un ancho de banda de canal alto.

WWVB es muy estable <1e-12 en f pero el ancho de banda es inadecuado para corregir mejor que unos pocos ms debido a la portadora de 60 kHz con unos pocos kHz Bw. Traduzca esto a ns y el ancho de banda de su red para corregir los errores de fase debe ser 1e6 más alto en frecuencia.

Comience con especificaciones precisas sobre los requisitos para cada ubicación y determine la precisión de fase que puede lograr al detectar el error de fase en ns. Dudo que Arduino pueda resolver esto sin un hardware de interfaz especializado para medir el error de fase en nanosegundos.

He diseñado muchos instrumentos Doppler diferentes, desde VLF hasta UHF, por lo que aquí solo estoy tratando con generalidades.

Estoy de acuerdo en que los nanosegundos estarían fuera de discusión (eso requeriría un reloj de ~ 1 GHz), pero un Due de 96 MHz debería poder alcanzar decenas de nanosegundos.
Creo que un Cortex de 500 MHz podría ser más adecuado.
Tal vez sea más fácil, pero podría ser excesivo y no tan fácil de conseguir. (El Due tiene un Cortex-M3).
Cuente los ciclos del reloj del oscilador para obtener el tiempo
RespuestasAquíPolítica de privacidad1y, 0v