GPS: comment fonctionne L'injection de temps NTP
J'ai récemment connu un fichier gps.conf
dans le répertoire /system/etc/
.
Il semble que peaufiner les valeurs NTP_SERVER sur les serveurs NTP plus proches de l'emplacement habituel améliore TTFF.
La lecture du code source dans la classe LocationProvider
, semble qu'au démarrage, le temps est récupéré à partir du serveur NTP et "injecté" dans les calculs.
AFAIK chaque gps sat a une horloge atomique très précise, et chacun dans la constellation est synchronisé à la soi-disant "temps GPS". Une fois que le récepteur a obtenu 4 satellites ou plus, il résout (par une méthode) une équation où il y a quatre inconnues: x, y, z, b; où (x, y, z) est l'emplacement du récepteur, et b est la différence de temps entre l'horloge interne du récepteur et L'heure GPS (correcte). Une fois qu'il a un correctif, l'horloge du récepteur est synchronisée avec l'heure correcte. (Veuillez me corriger si je me trompe).
Jusqu'à présent, j'ai quelques questions concernant le fonctionnement de L'injection de temps NTP:
- le temps GPS est approximativement TAI (International Atomic Time) plus un décalage. Ces deux les temps ne dépendent pas de la rotation de la Terre, mais UTC le fait. Étant donné que les serveurs NTP renvoient l'heure UTC, il est possible de déduire L'heure GPS de L'heure UTC?
- Comment la récupération du temps NTP à partir d'un serveur plus proche améliore-t-elle la "qualité" de L'approximation du temps GPS?
- en supposant que nous avons une valeur de temps GPS initiale (déduite du temps NTP en quelque sorte), de quoi parle l'injection? Cette valeur temporelle est-elle prise comme correcte pour résoudre l'équation avec seulement x, y, z comme inconnues? Si oui, alors le premier correctif est également juste une approximation, n'est-ce pas?
- Comment une approximation initiale de meilleure qualité pour le temps GPS améliore-TTFF? Est-ce parce qu'avec un temps NTP de qualité inférieure, les premières corrections sont considérées comme inacceptables et rejetées?
- le fait d'avoir une position initiale approximative aide-t-il à récupérer le correctif suivant (comme écouter uniquement un sous-ensemble de sats)?
3 réponses
Bien scouting un peu de wikipedia et d'autres sources, laissez-moi quelques invités.
Oui, vous pouvez déduire L'heure GPS de L'heure UTC. Il suffit de connaître le décalage, qui est transmis toutes les 15 secondes et change une fois dans environ 18 mois. Source: Wikipédia
-
NTP ne vous donne pas l'heure exacte. Il mesure l'heure à laquelle le message passe du client au serveur et l'heure à laquelle la réponse passe du serveur au client. Ces temps sont ensuite utilisés pour calculer le retard de la connexion. Qui est ensuite appliqué comme un décalage au temps reçu. Cela fonctionne pour les routes symétriques. Si les routes sont assymétriques, il y a une erreur. Donc plus près du serveur, abaissez la chance et le niveau d'assymétrie, abaissez ainsi l'erreur. Source: Wikipedia encore
Le signal NTP n'est pas directement utilisé pour obtenir le correctif GPS. Mais pour une solution précise, vous avez besoin d'horloges très précises. Nous parlons de nanosecondes ici. Les satellites GPS transmettent le courant GPS temps, mais même comme il se déplace à la vitesse de la lumière, Il ya un certain retard. Le récepteur GPS n'a aucun moyen de savoir quel est le retard, il doit donc se rapprocher de plusieurs signaux reçus. Avec chaque transmission reçue, l'horloge devient plus précise. Donc, le meilleur moment que vous avez au début, moins les signaux de temps que vous devez recevoir pour avoir une horloge précise. Source: Wikipédia
Eh bien à peu près expliqué dans 3. - l'erreur d'horloge inférieure moins les signaux nécessaires pour approximez l'heure correcte.
Je devine peu ici, mais avoir un emplacement approximatif peut vous aider à mieux approximer la distance du satellite et donc le retard. (Je ne sais pas si c'est vraiment utilisé.)
J'espère que cela fait au moins un peu de sens ; -)
Ma réponse se concentrera davantage sur le côté NTP de votre question. Pour le GPS, j'ai étudié ce document PDF mentionné dans un commentaire de mirabilos.
Selon ce document, pour démarrage à chaud du récepteur GPS, vous devez connaître l'heure dans les 20 S, La position dans les 100 km,la vitesse dans les 25 m / s et les données Almanach au plus quelques semaines. Vous devez toujours télécharger les données ephemiride de chaque satellite, ce qui prend entre 30 secondes et 3 minutes en fonction du récepteur GPS type.
Pour démarrage à chaud , Vous avez également besoin des données éphémérides (elles sont valables pendant 4 heures). Ils sont également disponibles via A-GPS (Voir ci-dessous).
Le protocole NTP utilise une hiérarchie de serveurs commençant par la source de temps d'origine-GPS, horloge atomique,... C'est ce qu'on appelle la source stratum-0. Le serveur NTP directement connecté à cette source est appelé stratum-1. Le serveur utilisant ceci comme serveur en amont est stratum-2 et ainsi de suite. Vous avez besoin de matériel spécial accordé pour atteindre moins de 1 ms erreur même pour les serveurs stratum-1 (en raison des latences d'interruption du processeur, des latences de port série, des changements d'oscillateur de température).
Avec HW normal sur un réseau normal (liaison DSL non saturée par exemple), vous pouvez obtenir une précision d'environ 10 ms. Par exemple NTP pool considère ses serveurs valides et assez bons s'ils ont un temps précis dans les 100 ms. La précision du temps de NTP ne dépend pas de la position géographique entre vous et le serveur NTP, mais plus sur la strate, la qualité de ce serveur et dans quelle mesure le serveur est basé sur la topologie du réseau.
Téléphones Android connaissent généralement le temps dans au moins 1 seconde précision. Soit par synchronisation périodique de l'heure via le réseau GSM ou si une connexion de données (wifi ou cellulaire) est disponible, également via NTP.
Pour l'application mentionnée FasterGPS - changer votre serveur NTP en un meilleur ne vous aidera pas à avoir un TTFF plus rapide. Pour cela, vous devez avoir du temps avec précision dans les nanosecondes, ce qui n'est pas le cas possible via NTP. Seule la puce GPS elle-même est capable de garder une trace du temps avec cette précision. Ce qui aide sur android à avoir TTFF plus rapide est:
- vous avez déjà du bon temps dans 20s sur votre téléphone android
- ayant une possibilité approximative soit via Wifi, soit à partir du réseau GSM (dans un rayon de quelques km basé sur des tours de transmission)
- En Utilisant A-GPS - il télécharge une nouvelle copie de l'Almanach et des éphémérides pour tous les satellites GPS via internet, vous n'avez donc pas besoin de le télécharger des satellites GPS (ce qui prend 30 secondes pour les éphémérides et 15 minutes pour l'Almanach). Avec A-GPS, vous pouvez utiliser le démarrage à chaud et ont TTFF sous 10 Secondes.
Ian a raison dans son commentaire que les réponses ont à voir avec la façon dont un récepteur GPS fonctionne réellement. Le récepteur viendra plus rapidement à une solution s'il a une estimation plus précise du biais d'horloge du récepteur. De nombreux récepteurs implémentent une solution itérative qui repose sur une estimation initiale de la position du récepteur et du biais d'horloge. Si ces estimations sont déjà proches de la valeur vraie, alors moins d'itérations nécessaires. Ce n'est qu'une partie de la raison pour laquelle TTFF sera moins. Y sont d'autres facteurs importants ainsi. Si la position initiale et l'estimation du temps sont bonnes, le processus de recherche pour l'acquisition des signaux satellites prendra beaucoup moins de temps parce que le récepteur peut calculer quels satellites devraient être visibles et il peut également estimer le décalage Doppler approximatif subi par chacun des signaux par rapport au cadre de référence du récepteur.