Correcciones de tiempo y reloj de efemérides en archivos de navegación RINEX

que son exactamente$T_{SV}$y$T_{OC}$?

El primero es cualquier momento (por ejemplo, el momento en que se transmitió el mensaje) expresado en el sistema de tiempo mantenido por un satélite particular (vehículo espacial). El segundo es el tiempo de referencia para la corrección del reloj, expresado en el mismo sistema horario. La corrección es necesaria para que cualquier hora anunciada por cualquier satélite se pueda convertir a un sistema de hora GPS común (también llamado GPST). Por lo tanto, la ecuación. 2 de la especificación de referencia de GPS (IS-GPS-200M, página 95, que mencionó en los comentarios anteriores) permite que un receptor corrija los errores de reloj en un SV en particular , a partir de los datos de navegación transmitidos por este SV, para llegar al común referencia de tiempo. Estos datos de transmisión son calculados por el Centro de Operaciones GPS y actualizados regularmente por él. Esta explicación de la especificación GPS (IS-GPS-200M, Sección 20.3.3.3.3.1) es más clara:

¿Podría expandirse la fórmula para incluir un término cuadrático, algo como$af_2 * (T_{SV} - T_{OC})^2$, dónde$af_2$¿Cuál sería la tasa de deriva del reloj, también incluida en la primera línea de cada mensaje?

Podría, ya que el campo existe en las especificaciones. Es posible que este término cuadrático rara vez se use. Su valor distinto de cero significaría que el reloj integrado también se está desviando en frecuencia. Probablemente, cambiarían al reloj atómico de repuesto (a menos que ambos relojes sufran esto).

¿Se requerirían también correcciones relativistas para obtener correctamente una hora UTC?

Creo que la corrección relativista depende de la aplicación. Para fines de localización, creo que no necesita UTC, solo para sincronizar 4 deltas de tiempo medidos con la misma referencia de tiempo común (GPST).

• Fórmula en el documento RINEX

La fórmula en el documento RINEX, Sección 5.4.1 (reproducida aquí) es un poco desconcertante.

Parece que es una fórmula incompleta, con términos omitidos reemplazados por "..." (puntos de suspensión que no reprodujiste en tu pregunta). La especificación GPS, Sección 20.3.3.5.2.4 es mucho más clara. Se lee:

Entonces, A0 y A1 tienen un papel similar al de af0 y af1. Junto con los segundos intercalares, sirven para corregir la deriva de GPST con respecto a UTC, de manera similar a como af0, af1 (y posiblemente af2) sirven para corregir la deriva de$T_{SV}$con respecto al GPST.

Tenga en cuenta que el tiempo de referencia para calcular el término de corrección para$T_{UTC}$es$T_{OT}$(y no la referencia$T_{OC}$para el término de corrección de$T_{SV}$)

No he leído las especificaciones de GLONASS pero creo que todas las correcciones de reloj GNSS (Galileo, Beidou,...) siguen el mismo enfoque, con solo diferencias en notaciones de términos. Un buen ejercicio sería leer las mismas secciones en sus especificaciones (¡soy demasiado perezoso para eso!).

Gracias a la explicación muy perspicaz de @NgPh, creo que finalmente pude descubrir cómo realizar correctamente las correcciones de reloj a UTC para los archivos de navegación GPS y GLONASS RINEX. Ahora he completado mi propia implementación, y pensé que sería una buena idea dejar un resumen del proceso, ya que creo que es correcto aquí. Tenga en cuenta que los procesos descritos aquí se refieren a cómo corregir el tiempo de las efemérides (para decirlo en palabras simples, el tiempo en el que el vector de estado proporcionado del satélite es válido).

GPS

Hay 2 pasos involucrados aquí: conversión de tiempo de satélite GPS individual a GPST de todo el sistema, y ​​conversión de GPST a UTC.

1. Recuperar$T_{OC}$, que, como se describe en IS-GPS-200M, Sección 20.3.3.3.3.1, es el tiempo de referencia para realizar la corrección del tiempo de GPS individual al GPST de todo el sistema. Esto viene dado por los campos 2 a 7 (Época Año, Mes, Día, Hora, Minuto y Segundo) de la primera línea de cada mensaje (nota: un solo archivo RINEX contiene un encabezado y múltiples mensajes), como se describe en la tabla A4 aquí
2. Convertir lo recuperado$T_{OC}$a la semana del GPS y los segundos de la semana del GPS actual, calculando a cuántos segundos le corresponde desde la medianoche del 5 al 6 de enero de 1980. El resultado puede someterse al módulo 604800 para obtener segundos de la semana GPS actual, y su división entera por 604800 será la semana GPS actual (en escala continua, es decir, no módulo 1024, que es de todos modos cómo parecen distribuirse los archivos de navegación GPS RINEX GPS semanas)
3. Recupere la semana GPS actual y los segundos actuales de la semana GPS para la hora de las efemérides. Estos se almacenan, respectivamente, en el campo 3 de la línea 5 y en el campo 1 de la línea 3 de cada mensaje. Tenga en cuenta que la semana del GPS para el tiempo de las efemérides está en escala continua, no en módulo 1024.
4. Calcular los segundos de diferencia entre el tiempo de las efemérides y$T_{OC}$. Tenga en cuenta que, para tener en cuenta los posibles cruces de semanas de GPS, los segundos de diferencia deben llevarse a un rango entre -302400 y +302400.
5. Calcule un término de corrección relativista. La fórmula también se puede encontrar en IS-GPS-200M, Sección 20.3.3.3.3.1. Tenga en cuenta que la tipografía en el archivo al que pude acceder puede generar confusión, ya que parece mostrar que la raíz cuadrada del semieje mayor parece ser el exponente de la excentricidad, mientras que en realidad es solo otro factor multiplicativo. . Además, tenga en cuenta que el cálculo de dicho término relativista requiere el cálculo de la anomalía excéntrica. Esto se puede realizar siguiendo los pasos descritos en la Tabla 20-IV del documento IS-GPS-200M.
6. Reste del tiempo del satélite individual los segundos calculados previamente de diferencia entre el GPST y el tiempo del satélite individual y el término relativista.
7. Calcular una corrección de GPST a UTC. Esta es otra corrección polinomial, con tiempo de referencia$T_{OT}$que se proporciona en el encabezado como un número de semana GPS/segundos del par de semana GPS. Los términos de orden 0 (sesgo) y de primer orden (deriva) para la corrección también se proporcionan en el encabezado, denominados parámetros A0 y A1, como se describe en la tabla A3 de este documento . También necesitamos restar los segundos intercalares introducidos desde el 6 de enero de 1980. Estos también se dan en el encabezado del archivo.
8. Aplicando las correcciones anteriores, obtenemos un número corregido de segundos de la semana GPS actual, que se puede sumar al número de segundos calculados a partir de la semana GPS actual para obtener el número de segundos desde la medianoche del 5 al 6 de enero de 1980 Esto se puede convertir directamente a una fecha y hora UTC.

GLONASS

La situación parece más fácil para los archivos GLONASS, aunque todavía hay un par de cosas de las que no estoy 100% seguro. Debe tenerse en cuenta que la hora GLONASS está vinculada a la hora UTC, y solo habrá una pequeña desviación en un momento dado (generalmente en el rango de unos pocos cientos de nanosegundos y, en cualquier caso, siempre por debajo de 1 ms, como se indica en la página 15 de las especificaciones de GLONASS ). Además, los archivos de navegación RINEX GLONASS proporcionan efemérides directamente en coordenadas cartesianas en el marco ECEF. Creo que el procedimiento correcto para obtener la hora UTC más precisa es:

1. Obtenga el tiempo de efemérides en tiempo GLONASS del satélite GLONASS individual. Cabe señalar que parece que esto viene dado por los parámetros de tiempo en la 1ra línea de cada mensaje en el archivo para el caso de los archivos RINEX GLONASS. Esta es una diferencia clave con los archivos GPS, que proporcionan en los campos correspondientes$T_{OC}$, el tiempo de referencia para realizar la corrección desde el tiempo de GPS del satélite individual hasta el GPST de todo el sistema. Esto está respaldado por el hecho de que la tabla A11 en la descripción de los formatos RINEX establece que dichos parámetros de tiempo en la primera línea de cada mensaje son la "época de las efemérides". Compare esto con la tabla A4 del mismo documento, correspondiente a archivos GPS, donde los parámetros de tiempo se describen como "Epoch: Toc - Time of Clock".
2. La sección 8.2 de la descripción mencionada de los formatos RINEX establece que la corrección de tiempo para los satélites GLONASS debe calcularse como:$T_{UTC} = T_{SV} + Tau_N - Gamma_N * (T_{SV} - T_b) + Tau_C$. Entiendo$T_{SV}$es la hora del vehículo satelital que se corregirá a UTC, pero estaba confundido en cuanto a qué exactamente$T_b$es. No hay otra mención de$T_b$en la descripción de los formatos RINEX. Sin embargo, revisando en detalle las especificaciones del sistema GLONASS, parece que$T_b$define el instante de tiempo para el cual los parámetros de efemérides son válidos. Esto se sustenta en el hecho, por ejemplo, de que la tabla 4.6 de dicho documento utiliza una notación para la posición, velocidad y aceleración del satélite que las define como funciones de$T_b$. Por lo tanto, asumo que$T_b$en la fórmula que se encuentra en el documento que describe los formatos RINEX es, de hecho, el tiempo de las efemérides. Entonces, para el caso de corregir el tiempo de las efemérides,$T_{SV} = T_b$, y por lo tanto el producto con$Gamma_N$también es 0, lo que reduce la conversión a la aplicación de un sesgo de reloj al tiempo GLONASS de todo el sistema (proporcionado por$Tau_N$, que se proporciona en el campo 8 de la primera línea de cada mensaje), y luego un desplazamiento a la hora UTC (proporcionado por$Tau_C$, que se da en el encabezado de cada archivo, y se aplica a todos los mensajes en el archivo correspondiente).
3. Hay un parámetro de tiempo más en los archivos de navegación RINEX GLONASS,$t_k$, dado en el décimo campo de la primera línea de cada mensaje. Parece estar definido en la página 22 de las especificaciones del sistema GLONASS , pero todavía no entiendo completamente su significado. No estoy seguro de cómo/si se debe usar para realizar correcciones de reloj. ¡Sería genial si alguien pudiera aclarar esto!
4. Además, no existe una corrección relativista explícita para los tiempos de GLONASS. Esto se debe a que está implícitamente incluido en$Tau_N$y$Gamma_N$, como se describe en la página 18 aquí .