Precisión de tiempo de GPS (SIM808 o similar): proceso entre sentencias NMEA y respuesta de comando AT

En un chip SIM808 o similar puedes obtener la información del GPS con este comando AT:

AT+CGNSINF
+CGNSINF:1,1,20150327014838.000,31.221783,121.354528,114.600,0.28,0.0,1,,1.9,22,1.0,,8,4,,,42,,

la hora UTC está en el tercer campo de datos como: yyyyMMddhhmmss.sss

Sin embargo, en el manual, la función de AT+CGNSSEQse describe como: Definir la última oración NMEA que se analizó.

Mi pregunta es en general:

  • ¿Qué tan preciso es este tiempo cuando lo recibo de la interfaz serial del chip?

Sub-preguntas:

  • ¿Debo suponer que el tiempo entre la respuesta del comando AT y el último mensaje NMEA recibido por la unidad GPS es variable?
  • ¿Puedo compensar los retrasos en los sistemas y cómo?

Retrasos que espero:

  • ¿Diferencia entre la entrada de la sentencia NMEA y el comando AT?

  • Tiempo para procesar la sentencia NMEA

  • Hora de leer el comando AT y preparar la respuesta

  • tiempo de comunicación en serie

Respuestas (2)

El mensaje que informa la hora emitida por un receptor GPS generalmente sale unos cientos de milisegundos después de la hora real indicada dentro del propio mensaje. Ese tiempo informado es en realidad el comienzo del ciclo de medición actual, y si el receptor tiene una salida de 1PPS, correspondería al borde de ataque de ese pulso.

A menos que tenga especial cuidado, el sondeo que realiza con sus ATcomandos se ejecuta de forma asíncrona con respecto al tiempo del GPS y los tiempos en los que el receptor emite los mensajes. Por lo tanto, siempre tendrá una incertidumbre equivalente a su período de votación sumado a cualquier otro retraso de comunicación que haya en el sistema.

Por lo tanto, si está sondeando una vez por segundo, el tiempo que finalmente verá en el mensaje será "obsoleto" entre 0,1 segundos y 1,1 segundos. Puede reducir el límite superior sondeando con más frecuencia y prestando atención a cuándo cambia el valor del tiempo de un resultado al siguiente.

El SIM808 tiene una salida de 1 pps en el pad 37, por lo que para una mayor precisión podría capturar esto en una interrupción y usarlo para disciplinar el sentido interno del tiempo de su MCU.

Basado en la sugerencia de Dave de que la información de tiempo en serie está "obsoleta", parece que es posible que desee hacer algo como tomar ese valor, podar la fracción, agregar 1 segundo y almacenarlo en caché para que la próxima interrupción sepa qué segundo está siendo marcado.

O si puede configurar un temporizador de hardware MCU para que se reinicie en la entrada externa de la señal PPS y cuente de lo contrario, puede hacer una consulta y reemplazar los segundos fraccionarios en el resultado con una conversión a segundos fraccionarios del conteo actual del temporizador .

En cualquier caso, es probable que desee tener cuidado si emite una de estas consultas cerca del final de un segundo, donde podría ser ambiguo si la respuesta que obtiene informa los segundos completos antiguos o los nuevos. Guardar el sentido interno del tiempo desde el momento en que se emite la consulta podría funcionar: si la respuesta que calcula es "anterior" al tiempo que solicitó, probablemente necesite agregar un segundo para solucionarlo.