Comment synchroniser deux microcontrôleurs avec une précision micro-seconde?

Je dois synchroniser deux micro-contrôleurs afin qu'ils puissent mesurer la vitesse des ondes qui se propagent. Les mesures de retard doivent avoir une précision de l'ordre de la microseconde (erreur inférieure à 1/2 seconde).

J'ai deux micro-contrôleurs ( ATmega328 ) qui utilisent un cristal de 12 MHz.

Ils sont tous deux équipés d'émetteurs-récepteurs Bluetooth. Les émetteurs-récepteurs Bluetooth envoient et reçoivent des paquets avec une gigue d'environ 15 millisecondes.

J'espère pouvoir synchroniser les micro-contrôleurs à l'aide des émetteurs-récepteurs Bluetooth, ou d'une autre méthode créative.

J'ai essayé de les synchroniser en les touchant ensemble, mais j'ai besoin qu'ils restent synchronisés pendant environ 10 minutes et que leurs horloges dérivent trop rapidement. Peut-être que s'il était possible de prédire avec précision la dérive de l'horloge, cette méthode fonctionnerait.

Comment dois-je m'y prendre pour réaliser cette synchronisation?

Je ne veux pas pleuvoir sur votre défilé sans fil. Vous avez rencontré une exigence difficile mais inattendue. Quelque chose comme ça mérite une réévaluation de la conception du système dans son ensemble.

La première chose qui me vient à l’esprit est de synchroniser les deux unités d’un oscillateur. Vous avez une communication Bluetooth, ce qui laisse à penser que la portée est de l’ordre de 10 m. Vous pouvez connecter vos unités avec un câble coaxial RG174 ou une fibre optique, qui transporterait l’horloge.

2ème , il y a des oscillateurs de précision. Par ordre croissant de précision et de coût.

• TCXO (oscillateur à cristal compensé en température). Dérive de 1 à 3 ppm, généralement.
• OCXO (oscillateur à cristal contrôlé par le four). Dérive de l'ordre de 0,02 ppm. Certains OCXO ont baissé jusqu'à 0,0001 ppm.
• Horloge atomique ( standard Rubidium , par exemple). Je parle de l'horloge atomique principalement pour donner un cadre de référence. Plus à ce sujet ici .

3ème , oscillateur de précision entraîné avec GPS. Chaque satellite GPS a plusieurs horloges atomiques à bord. Habituellement, de nombreux satellites GPS sont en vue. GPS est utilisé pour chronométrer de précision beaucoup (utilisation moins connue par rapport à Sat Nav). La plupart des récepteurs GPS ont une sortie 1PPS (une impulsion par seconde), qui fournit une synchronisation précise à 50 ns.
Pour avoir une dérive de 0,5 μs sur 600 s (10 min), votre horloge (celle de 12 MHz dans votre conception actuelle) devrait avoir une dérive inférieure à 0,0008 ppm. Mais si vous pouvez corriger l'erreur de synchronisation de temps en temps à partir d'une source externe à faible dérive, l'exigence de la dérive dans l'horloge peut être plus souple. Si vous pouvez corriger chaque seconde, votre horloge pourrait avoir une dérive de 0,5 ppm.

Les modules GPS avec sorties 1pps sont facilement disponibles et peu coûteux.

Il n'est pas vraiment nécessaire de discipliner l'oscillateur de la CPU sur le GPS (par exemple, avec une PLL). Tant que vous pouvez "horodater" des événements externes par rapport à l'horloge de la CPU, il est relativement simple d'interpoler l'heure de transmission et de réception des événements entre deux événements PPS quelconques.

Vous pouvez souvent utiliser la combinaison d’un temporisateur matériel sur le microcontrôleur et d’un compteur logiciel pour ses événements de dépassement de capacité afin de créer un compteur de cycle de processeur d’une largeur arbitraire. Il peut être difficile de gérer correctement les événements de basculement, à la fois du compteur matériel et du compteur logiciel, mais au final, vous pouvez avoir un compteur 32 bits qui compte au rythme de l’horloge de la CPU (donnant une résolution élevée. ) et survole une période plus longue que les intervalles que vous essayez de mesurer (par exemple, 429 secondes à 10 MHz).

Vous pouvez utiliser ce compteur pour horodater différents événements externes. Si l'un de ces événements correspond à des impulsions de 1 pps provenant d'un récepteur GPS, la précision de base à long terme de l'horloge du processeur devient alors inutile. La seule chose qui compte est sa stabilité à court terme. Vous pouvez enregistrer les horodatages GPS dans une mémoire tampon FIFO et comparer les horodatages d'autres événements aux valeurs de cette mémoire tampon. Puisque vous savez que les impulsions GPS sont à une seconde d'intervalle, vous pouvez trouver l'heure exacte de tout autre événement en interpolant.

$GPS_n$$GPS_{n+1}$$Time_n$$Time_{n+1}$$Ext$$GPS_n$$GPS_{n+1}$

Enfin, si cette configuration fonctionne sur deux systèmes distincts, chacun avec son propre récepteur GPS, vous pouvez comparer les temps calculés pour différents événements sur les deux systèmes avec une grande précision (généralement de l’ordre de ± 100 ns), même si le Les horloges de la CPU des deux systèmes ne sont pas synchronisées.

J'ai déjà implémenté une synchronisation d'horloge sans fil pour les microcontrôleurs, mais uniquement avec une précision d'une milliseconde, suffisante pour l'application. D'après mes lectures, cet article explique très bien la synchronisation en microsecondes: http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdf

Essentiellement, si vous connaissez l'événement de transmission et l'événement d'arrivée d'un paquet radio sur l'émetteur et le récepteur, vous avez un événement observable commun (en supposant que vous ignorez le temps de propagation de l'onde radio) entre les 2 systèmes pouvant être situés. utilisé comme référence. L’autre caractéristique intéressante mentionnée dans le document est l’estimation de l’horloge en utilisant une régression linéaire.

Consultez le protocole CSP (Bluetooth Clock Synchronization Protocol), élément facultatif du profil de périphérique de santé (HDP). Les sections de ce document qui concernent le protocole CSP sont les sections 2.1 et 8.

Je n'ai pas encore eu l'occasion de l'essayer moi-même mais, à ce que je sache, BlueZ (la pile de protocoles officielle Bluetooth de Linux) vient d' ajouter un support pour le HDP , y compris le support pour CSP. Par conséquent, même si cela ne vous semble pas fonctionner sur une plate-forme prenant en charge la pile BlueZ, le code fournira peut-être au moins une bonne implémentation de référence.