Sur que ce serait moins pratique ! c'est sympa de pouvoir estimer une heure d'arrivée.
Bug des GPS le 6 avril ?
- Démarrée par DannyCC
- Date de début
Sur que ce serait moins pratique ! c'est sympa de pouvoir estimer une heure d'arrivée.
David, je suis d'accord.
Ce que je veux dire. C'est que je ne vais pas aller voir le cc pour avoir des renseignements avant.
Si jamais je vois courant avril (car je vais pas testé le 6...) que je n'ai plus ces fonctions. J'irai voir mon cc, et je lui demanderai de trouver la solution.
No stress de mon côté. Dans le sens je ne vais pas crier avant d'avoir mal
Ce que je veux dire. C'est que je ne vais pas aller voir le cc pour avoir des renseignements avant.
Si jamais je vois courant avril (car je vais pas testé le 6...) que je n'ai plus ces fonctions. J'irai voir mon cc, et je lui demanderai de trouver la solution.
No stress de mon côté. Dans le sens je ne vais pas crier avant d'avoir mal
Pour les RTx et le SMEG+, pas trop de risque à ce niveau là.
Ce n'est pas le GPS qui donne/mémorise l'heure et encore moins la date.
On peu au mieux la synchroniser (et encore, juste les minutes sur les RTx) avec le GPS.
Et cette synchro est optionnelle. Alors le numéro de la semaine, quelle importance ?
Je ne crois pas.
Depuis 2005, les nouveaux satellites GPS IIR-M émettent en effet le numéro de semaine sur 13 bits au lieu de 10.
Mais... il le font sur une bande de fréquence appelée L2C. Bande de fréquence que ne reçoivent pas les puces SiRF II (RT6) ni les puces SiRF IV (SMEG+) qui sont limités à la L1.
Même la dernière puce SiRFstar V 5e de Qualcom ne traite pas cette bande L2C, donc elle lit encore le numéro de semaine sur 10 bits. Je me demande même si une seule puce GPS grand public traite la L2C (cf https://wiki.openstreetmap.org/wiki/GPS_Chipset)
La correction est toute autre.
Les puces GPS ont besoin de la date et de l'heure pour être en mesure de savoir ou se trouvent les satellites dont ils reçoivent les données et en déduire leur propre position.
Pour les puces SIRF, la correction est décrite dans l'interface depuis 2005 et les puces SIRF IV.
Il faut donner l'heure et la date réelle à la puce GPS au moins une fois. Ensuite, son processeur et ses algorithmes se démerderont pour ajouter les bits qui manquent au numéro de semaine s'il est autonome et dispose d'une mémoire non volatile. Sinon, il faut lui redonner la date et l'heure à chaque boot.
L'interface de la SiRF II des RTx est différente. Il semble que le firmware de la puce force le 11ème bit à 1 sans se préoccuper de la date réelle Mais même ça ne signifie pas que le GPS ne fonctionnera plus ou mal après le 6 avril
Pour être complet, le numéro de semaine sur 13 bits est également transmis sur la fréquence L1 reçue par les GPS grand public.
C'est dans le message de navigation CNAV du signal L1C.
Le premier, et pour l'instant unique satellite à broadcaster ce signal a été lancé le 19 décembre 2018.
La documentation d'interface des SiRF jusqu'en 2008 ne parle pas de ce signal. Je ne sais pas si ces puces peuvent le traiter (l'ancien signal L1 avec les semaines sur 10 bits est toujours émis).
Mais ça ne change pas la manière dont le problème a été traité, donner à la puce GPS la date correcte au moins une fois.
C'est dans le message de navigation CNAV du signal L1C.
Le premier, et pour l'instant unique satellite à broadcaster ce signal a été lancé le 19 décembre 2018.
La documentation d'interface des SiRF jusqu'en 2008 ne parle pas de ce signal. Je ne sais pas si ces puces peuvent le traiter (l'ancien signal L1 avec les semaines sur 10 bits est toujours émis).
Mais ça ne change pas la manière dont le problème a été traité, donner à la puce GPS la date correcte au moins une fois.
La "remise à 0" aura lieu le 6 avril, pas en juillet.Pourquoi jusqu'au 7 avril alors que d'autres sources estiment l'éventualité du bug en juillet 2019 ?
En effet, 10 bits permettent de conserver 1024 semaines. Et on sera 1024 semaines après l'apparition précédente de ce bug, qui était en juillet 1999 (peut-être est-ce là l'erreur pour toi sur cette histoire de juillet)
Non, pas du tout ! L'erreur est déjà tienne puisque le dernier bug a eu lieu le 20 août 1999
Tous les fabricants conseillent de procéder -si disponible- à une mise à jour de GPS avant le 6 avril 2019, certains précisant néanmoins que le WNRO (le "bug" qui n'en est pas un) n'arrivera pas forcément à la date anniversaire du GPS, le calcul de la date de leurs appareils contenant un offset basé sur la date de leur fabrication
60 millions de consommateurs donne la position de Peugeot :
- Peugeot : pas de dysfonctionnement sur les GPS embarqués proposés depuis 2015. Pour les modèles plus anciens, des conseils pour rétablir l’affichage de la date seront proposés.
C'est le proposé depuis 2015 qui me fait peur. A cette époque devais se côtoyer plusieurs systèmes dans la gamme. SMeg, Smeg + et peut etre Nac.
Quand on nous dit que le "bug" n'affectera pas la navigation, et en particulier le positionnement du véhicule, c'est que l'horloge interne du GPS se sera correctement synchronisée au système par le 4ème satellite nécessaire à la triangulation
Donc, dès que la fonction horaire fonctionne on ne devrait pas redouter d'erreurs dans les durées de trajet effectué le même jour, d'autant plus que toute puce de GPS conserve toutes les données des 30 derniers jours
NOTE pour info : les dates possibles de bug des GPS
28 07 2019
12 07 2025
14 09 2025
28 02 2027
29 12 2029
Il n'y a donc pas que le "6 avril 2019"
Donc, dès que la fonction horaire fonctionne on ne devrait pas redouter d'erreurs dans les durées de trajet effectué le même jour, d'autant plus que toute puce de GPS conserve toutes les données des 30 derniers jours
NOTE pour info : les dates possibles de bug des GPS
28 07 2019
12 07 2025
14 09 2025
28 02 2027
29 12 2029
Il n'y a donc pas que le "6 avril 2019"
Comme expliqué ici : https://www.spirent.com/blogs/positioning/2018/january/gps-rollover-week, le bug est susceptible de se produire à n'importe quelle date après le 7 avril (E3).
Tout dépend de la manière dont est codée la date pivot, qu'il faut fournir au GPS puisqu'il ne peut pas l'obtenir des satellites GPS comme je l'ai expliqué dans un post précédent.
Au fait, le calcul d'un trajet et de sa durée sont des fonctions de la cartographie, pas du GPS.
Si le véhicule est bien positionné, le trajet et sa durée seront corrects. Il n'y a pas de conditionnel et ça n'a rien à voir avec le jour même ou je ne sais quelle mémorisation d'information.
Au fait, le calcul d'un trajet et de sa durée sont des fonctions de la cartographie, pas du GPS.
Si le véhicule est bien positionné, le trajet et sa durée seront corrects. Il n'y a pas de conditionnel et ça n'a rien à voir avec le jour même ou je ne sais quelle mémorisation d'information.
hello à tous,
tiens je viens de me taper tout le brol....
à part les dérives habituelles .... moi je dis ça .... on connait la suite ....
perso avec mon vieux RT4 qu'est ce que je risque réellement ????
au fait NAC c'est koi cette bêbêtte
edit:merdum je n'avais pas lu la deuxième page,pardon à Janvi ( et Leon) toujours aussi pointu à ce que je vois
tiens je viens de me taper tout le brol....
à part les dérives habituelles .... moi je dis ça .... on connait la suite ....
perso avec mon vieux RT4 qu'est ce que je risque réellement ????
au fait NAC c'est koi cette bêbêtte
edit:merdum je n'avais pas lu la deuxième page,pardon à Janvi ( et Leon) toujours aussi pointu à ce que je vois
C'est le modèle de "GPS" installé depuis environ 3 ans chez PSA (et maintenant dans quasiment toute la gamme)au fait NAC c'est koi cette bêbêtte
Pour rajouter à la réponse de W13 avant la cartographie été géré par HERE ou anciennement NAVTEQ toujours le cas pour SMEG puis RT6 maintenant sur les dernières NAC = navigation connectée géré par TOMTOM
Discussions similaires
