android time gps ntp

android - GPS: cómo funciona la inyección de tiempo NTP



time (3)

Recientemente he tenido conocimiento de un archivo gps.conf en el directorio /system/etc/ . Parece que ajustar los valores NTP_SERVER a servidores NTP más cercanos a la ubicación habitual mejora el TTFF.

Al leer el código fuente en la clase LocationProvider , parece que en el arranque, el tiempo se recupera del servidor NTP y se "inyecta" en los cálculos. AFAIK cada GPS sat tiene un reloj atómico muy preciso, y cada uno en la constelación se sincroniza con el llamado "tiempo de GPS". Una vez que el receptor tiene 4 o más satélites, resuelve (por algún método) una ecuación donde hay cuatro incógnitas: x, y, z, b; donde (x, y, z) es la ubicación del receptor, y b es la diferencia de tiempo entre el reloj interno del receptor y el tiempo GPS (correcto). Una vez que tiene una solución, el reloj del receptor se sincroniza con la hora correcta. (Por favor corrígeme si estoy equivocado).

Hasta ahora, tengo algunas preguntas sobre la forma en que funciona la inyección de tiempo NTP:

  1. El tiempo del GPS es aproximadamente TAI (Tiempo atómico internacional) más un desplazamiento. Esas dos veces no dependen de la rotación de la Tierra, sin embargo, UTC sí. Dado que los servidores NTP devuelven la hora UTC, ¿es posible inferir el tiempo del GPS a partir de la hora UTC?
  2. ¿De qué manera la recuperación del tiempo NTP de un servidor más cercano mejora la "calidad" de la aproximación de tiempo del GPS?
  3. Suponiendo que tenemos un valor de tiempo de GPS inicial (inferido a partir del tiempo de NTP de alguna manera), ¿de qué se trata la inyección? ¿Se toma este valor de tiempo como correcto para resolver la ecuación con solo x, y, z como incógnitas? Si es así, entonces la primera solución también es solo una aproximación, ¿no es así?
  4. ¿Cómo mejora la TTFF una aproximación inicial de mayor calidad para el tiempo del GPS? ¿Es porque con un tiempo NTP de menor calidad, las primeras soluciones se consideran no aceptables y descartadas?
  5. ¿Tener una posición inicial aproximada ayuda a recuperar la siguiente solución correcta (como escuchar solo un subconjunto de sats)?

Bueno explorando un poco de wikipedia y algunas otras fuentes, permítanme tener algunas conjeturas.

  1. Sí, puede deducir la hora del GPS a partir de la hora UTC. Solo tiene que saber el desplazamiento, que se transmite cada 15 segundos y cambia una vez en aproximadamente 18 meses. Fuente: Wikipedia

  2. NTP no te da la hora exacta. Mide el tiempo que pasa el mensaje de un cliente a otro y el momento en que la respuesta llega de un servidor a otro. Estos tiempos se usan para calcular el retraso de la conexión. Que luego se aplica como un desplazamiento al tiempo recibido. Esto funciona para rutas simétricas. Si las rutas son asimétricas, hay un error. Tan cerca del servidor, menor es la posibilidad y el nivel de asimetría, por lo tanto, disminuya el error. Fuente: Wikipedia otra vez

  3. La señal NTP no se usa directamente para obtener la corrección de GPS. Pero para una solución precisa necesita relojes muy precisos. Estamos hablando de nanosegundos aquí. Los satélites GPS transmiten la hora actual del GPS, pero incluso mientras viaja a la velocidad de la luz, hay algo de retraso. El receptor GPS no tiene forma de saber cuál es la demora, por lo que debe aproximarse a partir de varias señales recibidas. Con cada transmisión recibida, el reloj se vuelve más preciso. Así que cuanto mejor sea el tiempo que tiene al principio, menos señales de tiempo tiene que recibir para tener un reloj preciso. Fuente: Wikipedia

  4. Bien explicado en 3. - el error de reloj menor las menos señales necesarias para aproximar el tiempo correcto.

  5. Estoy adivinando aquí, pero tener una ubicación aproximada puede ayudarlo a aproximarse mejor a la distancia del satélite y, por lo tanto, a la demora. (No estoy seguro de si realmente se usa).

Espero que tenga al menos un poco de sentido ;-)

Ian tiene razón en su comentario de que las respuestas tienen que ver con cómo funciona realmente un receptor de GPS. El receptor llegará más rápidamente a una solución si tiene una estimación más precisa del sesgo del reloj del receptor. Muchos receptores implementan una solución iterativa que se basa en una estimación inicial de la posición del receptor y el sesgo del reloj. Si estas estimaciones ya están cerca del valor verdadero, se necesitarán menos iteraciones. Esta es solo una parte de la razón por la que TTFF será menor. También hay otros factores importantes. Si la posición inicial y el tiempo estimado son buenos, entonces el proceso de búsqueda para adquirir las señales del satélite tomará mucho menos tiempo porque el receptor puede calcular qué satélites deben ser visibles y también puede estimar el desplazamiento Doppler aproximado experimentado por cada una de las señales relativas al marco de referencia del receptor.

Mi respuesta se enfocará más en el lado NTP de su pregunta. Para GPS, he estudiado este documento PDF mencionado en un comentario de Mirabilos.

De acuerdo con ese documento, para el inicio en caliente del receptor GPS, necesita saber el tiempo dentro de los 20 s, la posición dentro de los 100 km, la velocidad dentro de los 25 m / sy los datos de almanaque a las pocas semanas de antigüedad. Aún necesita descargar los datos de ephemiride de cada satélite, lo que demora entre 30 segundos y 3 minutos según el tipo de receptor GPS.

Para el arranque en caliente , también necesita los datos de efemérides (son válidos por 4 horas). También están disponibles a través de A-GPS (ver a continuación).

El protocolo NTP usa una jerarquía de servidores que comienza con la fuente de tiempo original: GPS, reloj atómico, ... Esto se llama fuente de estrato-0. El servidor NTP conectado directamente a esta fuente se llama stratum-1. El servidor que usa esto como su servidor ascendente es stratum-2 y así sucesivamente. Necesita un hardware sintonizado especial para lograr menos de 1 ms de error incluso para los servidores de nivel 1 (debido a las latencias de interrupción de la CPU, las latencias del puerto serie, los cambios del oscilador de temperatura).

Con HW normal en la red normal (enlace DSL no saturado, por ejemplo) puede lograr una precisión de aproximadamente 10 ms. Por ejemplo, el grupo NTP considera que sus servidores son válidos y lo suficientemente buenos si tienen un tiempo preciso dentro de los 100 ms. La precisión del tiempo de NTP no depende de la posición geográfica entre usted y el servidor NTP, sino más sobre el estrato, la calidad de ese servidor y la medida en que el servidor se basa en la topología de la red.

Los teléfonos con Android generalmente conocen el tiempo con al menos 1 segundo de precisión. Ya sea a través de la sincronización periódica de tiempo a través de la red GSM o si está disponible la conexión de datos (wifi o celular), también a través de NTP.

Para la aplicación mencionada, FasterGPS : cambiar su servidor NTP a uno mejor no lo ayudará a tener un TTFF más rápido. Para eso, necesitaría tener tiempo con precisión dentro de nanosegundos, lo cual no es posible a través de NTP. Solo el chip GPS en sí mismo puede hacer un seguimiento del tiempo con esa precisión. Lo que ayuda a Android a tener un TTFF más rápido es:

  • Ya tienes un buen tiempo dentro de los 20s en tu teléfono Android
  • Tener una posición aproximada ya sea a través de WiFi o de la red GSM (dentro de unos pocos kilómetros en base a las torres de transmisión)
  • Usando A-GPS , descarga una nueva copia de almanaque y efemérides para todos los satélites GPS a través de Internet, por lo que no es necesario descargarlo de los satélites GPS (que tarda 30 segundos para las efemérides y 15 minutos para el almanaque). Con A-GPS, puede usar el inicio en caliente y tener TTFF por debajo de 10 segundos.