Un peu de technique glané chez les voisins plus séreux du Lion
En prévention du bug, la MàJ corrective des constructeurs fait passer le protocole de RAZ de l'horloge des GPS de 10 bits (19 ans) à 13 bits (157 ans)
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.
La "remise à 0" aura lieu le 6 avril, pas en juillet.
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)
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
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"
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.
Mais toutes ces informations ne me disent pas encore, comment mon Carminat se comportera après le 6 avril.
..... ça me rappelle le bug du passage à l'AN 2000 
