Pregunta

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

Leer el código fuente en el LocationProvider La clase parece que al 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 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 (correcto) GPS. Una vez que tiene una solución AA, 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 GPS es más o menos TAI (tiempo atómico internacional) más un desplazamiento. Esas dos veces no dependen de la rotación de la Tierra, sin embargo, UTC lo hace. Dado que los servidores NTP devuelven el tiempo UTC, ¿es posible inferir el tiempo GPS desde el tiempo de UTC?
  2. ¿Cómo mejora el tiempo de NTP de un servidor más cercano la "calidad" de la aproximación de tiempo GPS?
  3. Suponiendo que tenemos un valor de tiempo GPS inicial (inferido del tiempo 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?
  4. ¿Cómo mejora una aproximación inicial de mayor calidad para el tiempo GPS TTFF? ¿Es porque con un tiempo NTP de menor calidad, las primeras soluciones no se consideran aceptables y descartadas?
  5. ¿Tener una posición inicial aproximada ayuda a recuperar la próxima solución correcta (como escuchar solo a un subconjunto de SAT)?
¿Fue útil?

Solución

Bien explorando un poco de Wikipedia y algunas otras fuentes, permítanme tener algunas conjeturas.

  1. Sí, puede inferir el tiempo GPS desde la hora de UTC. Solo tiene que conocer el desplazamiento, que se transmite cada 15 segundos y cambia una vez en aproximadamente 18 meses. Fuente: Wikipedia

  2. NTP no le da tiempo exacto. Mide el mensaje de tiempo obtiene del cliente al servidor y la hora en que la respuesta obtiene del servidor al cliente. 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. Así que más cerca del servidor, disminuya la oportunidad y el nivel de asimetría, por lo que reduzca el error. Fuente: Wikipedia otra vez

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

  4. Bueno, se explica más o menos en 3. - El error del reloj inferior menos señales necesarias para aproximar el tiempo correcto.

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

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

Otros consejos

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

Según ese documento, para arranque en caliente Del receptor GPS, debe conocer el tiempo dentro de los años 20, su posición dentro de los 100 km, la velocidad dentro de los 25 m/s y los datos de AlmanaC en la mayoría de las semanas. Todavía necesita descargar datos de efemirida de cada satélite, que toma entre 30 segundos y 3 minutos según el tipo de receptor GPS.

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

El protocolo NTP utiliza una jerarquía de servidores que comienzan con la fuente de tiempo original: GPS, reloj atómico, ... esto se llama fuente Stratum -0. El servidor NTP conectado directamente a esta fuente se llama Stratum-1. El servidor que usa esto como su servidor aguas arriba es Stratum-2, etc. Necesita un hardware ajustado especial para lograr menos de 1 ms de error incluso para los servidores Stratum-1 (debido a latencias de interrupción de CPU, latencias de puerto serie, cambios en el oscilador de temperatura).

Con HW normal en la red normal (no un enlace DSL saturado, por ejemplo), puede lograr una precisión de aproximadamente 10 ms. Por ejemplo Piscina NTP considera que sus servidores son válidos y buenos si tienen 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 en el estrato, la calidad de ese servidor y hasta qué punto el servidor está en función de la topología de la red.

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

Para la aplicación mencionada FastasterGps - Cambiar su servidor NTP para mejorar uno no lo ayudará a tener TTFF más rápido. Para eso, necesitaría tener tiempo con precisión dentro de los nanosegundos, lo que no es posible a través de NTP. Solo el chip GPS en sí puede realizar un seguimiento del tiempo con esa precisión. Lo que ayuda a Android a tener TTFF más rápido es:

  • Ya lo pasas bien dentro de los 20 años en tu teléfono Android
  • Tener una posición aproximada a través de WiFi o de la red GSM (en pocos km en función de las torres de transmisión)
  • Usando A-gps - Descarga una copia fresca de AlmanaC y Ephemerides para todos los satélites GPS a través de Internet, por lo que no necesita descargarla de los satélites GPS (que toma 30 segundos para Ephemerides y 15 minutos para AlmanaC). Con A-GPS, puede usar Hot Start y tener TTFF por debajo de 10 segundos.

Ian tiene razón en su comentario de que las respuestas tienen que ver con cómo funciona realmente un receptor 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, entonces 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 la estimación de tiempo son buenos, entonces el proceso de búsqueda para adquirir las señales satelitales tomará significativamente menos tiempo porque el receptor puede calcular qué satélites deben ser visibles y también puede estimar el cambio de doppler aproximado experimentado por cada una de las señales relativas al pariente al marco de referencia del receptor.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top