J'ai récemment entendu parler d'un gps.conf
fichier dans le /system/etc/
répertoire. Il semble que l'ajustement des valeurs NTP_SERVER à NTP serveurs 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 un très précis horloge atomique, et chacun dans la constellation est synchronisé avec le soi-disant "heure 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 point fixe, l'horloge du récepteur est synchronisée avec l'heure correcte . (Corrigez-moi si j'ai tort, s'il-vous plait).
Jusqu'à présent, j'ai quelques questions concernant le fonctionnement de l'injection de temps NTP:
Eh bien, explorant un peu de wikipedia et d'autres sources, laissez-moi avoir quelques hypothèses.
Oui, vous pouvez déduire l'heure GPS à partir de l'heure UTC. Il vous suffit de connaître le décalage, qui est transmis toutes les 15 secondes et change une fois tous les 18 mois environ. Source: Wikipedia
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 décalage par rapport au temps reçu. Cela fonctionne pour les itinéraires symétriques. Si les itinéraires sont asymétriques, il y a une erreur. Donc, rapprochez le serveur, réduisez les chances et le niveau d'assymétrie, diminuez ainsi l'erreur. Source: Wikipedia encore
Le signal NTP n'est pas directement utilisé pour obtenir la position GPS. Mais pour une correction précise, vous avez besoin d'horloges très précises. Nous parlons ici de nanosecondes. Les satellites GPS transmettent l'heure GPS actuelle, mais même lorsqu'ils se déplacent à la vitesse de la lumière, il y a 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. À chaque transmission reçue, l'horloge devient plus précise. Donc, mieux vous avez au début, moins vous devez recevoir de signaux horaires pour avoir une horloge précise. Source: Wikipedia
Eh bien à peu près expliqué en 3. - plus l'erreur d'horloge est faible, moins il faut de signaux pour approximer l'heure correcte.
Je suis peu en train de deviner ici, mais avoir une position approximative peut vous aider à mieux estimer 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 NTP côté de votre question. Pour le GPS, j'ai étudié ce PDF papier mentionné dans un commentaire de mirabilos.
Selon ce document, pour démarrage à chaud du récepteur GPS, vous devez connaître le temps dans les 20 secondes, la position dans les 100 km, la vitesse dans les 25 m/s et l'almanach. données au plus de quelques semaines. Vous devez toujours télécharger les données d'éphémiride de chaque satellite, ce qui prend entre 30 secondes et 3 minutes selon le type de récepteur GPS.
Pour démarrage à chaud , vous avez également besoin des données d'éphéméride (elles sont valables 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. NTP le serveur directement connecté à cette source est appelé stratum-1. Le serveur l'utilisant comme son serveur amont est stratum-2 et ainsi de suite. Vous avez besoin d'un matériel spécialement réglé pour obtenir une erreur inférieure à 1 ms même pour les serveurs de la couche 1 (en raison des latences d'interruption du processeur, des latences du port série, des changements d'oscillateur de température).
Avec un matériel normal sur un réseau normal (liaison DSL non saturée par exemple), vous pouvez atteindre une précision d'environ 10 ms. Par exemple pool NTP considère ses serveurs valides et suffisamment bons s'ils ont un temps précis dans les 100 ms. La précision du temps à partir de NTP ne dépend pas de la position géographique entre vous et NTP serveur, mais plus sur la strate, la qualité de ce serveur et dans quelle mesure le serveur est basé sur la topologie du réseau.
Les téléphones Android connaissent généralement l'heure avec une précision d'au moins 1 seconde. Soit via une synchronisation horaire périodique 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 NTP pour un meilleur ne vous aidera pas à avoir un TTFF plus rapide. Pour cela, vous aurez besoin d'avoir du temps avec précision dans les nanosecondes, ce qui n'est pas possible via NTP. Seule la puce GPS elle-même est capable de suivre le temps avec cette précision. Ce qui aide sur Android pour avoir un TTFF plus rapide est:
Ian a raison dans son commentaire que les réponses ont à voir avec le fonctionnement réel d'un récepteur GPS. Le récepteur parviendra plus rapidement à une solution s'il dispose d'une estimation plus précise du biais d'horloge du récepteur. De nombreux récepteurs mettent en œuvre 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 réelle, alors moins d'itérations seront nécessaires. Ce n'est qu'une partie de la raison pour laquelle le TTFF sera inférieur. Il existe également d'autres facteurs importants. Si la position initiale et l'estimation de temps sont bonnes, alors le processus de recherche pour acquérir les signaux satellites prendra beaucoup moins de temps car 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 relatifs. au cadre de référence du récepteur.