La synchronisation de plusieurs systèmes embarqués

1. Pourquoi est-ce utile ?

Dans de nombreuses applications industrielles et scientifiques, la maîtrise précise des délais de transmission est critique.
Par exemple, dans les systèmes automatisés, une coordination parfaite entre les différentes machines est souvent nécessaire. Il est donc nécessaire que toutes les machines partagent le même temps machine et/ou pouvoir compenser le temps nécessaire à la transmission.

De même, dans le cadre de l'acquisition de données distribuées, imaginez plusieurs modules effectuant des mesures accélérométriques par exemple, à 1 000 Hz. Une erreur de 100 microsecondes entre les dispositifs correspond déjà à une différence de phase de 36°, une déviation significative qui peut compromettre l’analyse des données.

Ces applications démontrent que, si les solutions matérielles dédiées ne peuvent pas être utilisées (typiquement le GPS :les modules GPS sont équipés pour la plupart d’une broche dédiée à la synchro externe qui bat la seconde) ne sont pas applicables (par exemple en l’absence d’éclairage des antennes GPS), la synchronisation est un vraie enjeu. Il est donc pertinent de rechercher une solution accessible et économique.

Les informaticiens sont confrontés à des problématiques similaires pour les réseaux. La synchronisation précise des horloges est en effet une problématique majeure dans le domaine des réseaux informatiques. Pour assurer une cohérence temporelle entre les systèmes, des protocoles spécifiques ont été développés.​

Network Time Protocol (NTP) :

Le NTP est largement utilisé pour synchroniser les horloges des ordinateurs et des périphériques réseau sur des réseaux TCP/IP. Il permet de maintenir une précision suffisante pour de nombreuses applications générales

Precision Time Protocol (PTP) :

Pour les applications nécessitant une synchronisation plus fine, le PTP (IEEE 1588) est privilégié. Ce protocole asymétrique, fonctionnant en mode maître-esclave, diffuse des horodatages à travers le réseau pour assurer une synchronisation des équipements avec une précision de l'ordre de la nanoseconde.

Le NTP utilise un principe de synchronisation assez similaire à celui que je vais exposer ici.

2. Solutions Matérielles Dédicacées et Choix de l’Approche

Les Solutions Matérielles Dédicacées

Des dispositifs tels que les modules GPS, offrant une synchronisation précise basée sur des signaux satellites (mais il faut avoir accès à un environnement éclairé par les satellites). Il existe des horloges atomiques MEMS, fournissant une stabilité et une précision de l'ordre de la nanoseconde (https://safran-navigation-timing.com/product/mmac-10-mems-micro-atomic-clock/), mais ce sont des solutions souvent très onéreuses et relativement peu disponibles.

Choix de l’ESP32

Pour explorer une solution plus accessible, j'ai choisi d'utiliser des microcontrôleurs largement répandus, l'ESP32. Ce choix s'explique par un atout pour une problématique de synchronisation : L'intégration dans le SOC de l'ESP du Wi-Fi et du Bluetooth permet une communication directe et rapide entre le microcontrôleur et sa partie radio.

3. Les Problèmes et Défis Rencontrés

La mise en œuvre d’une telle synchronisation doit surmonter plusieurs obstacles.

Latence et Gigue de la Partie Radio

Les communications sans fil introduisent inévitablement des variations de latence et de gigue. En fait la gigue pour le WiFi est même nécessaire car elle permet de déterminer si un canal est occupé avant d'émettre. Cela signifie que les délais de transmission peuvent fluctuer en fonction des interférences et de l’encombrement du spectre radio, rendant la synchronisation plus difficile à obtenir par ce biais.

Environnement FreeRTOS

L’ESP32 fonctionne sous FreeRTOS, un système multitâche. Cela permet l’exécution simultanée de plusieurs tâches en divisant le temps CPU, ce qui est généralement très bien, mais n’est pas toujours adapté pour des opérations critiques en temps réel, surtout lorsqu’il s’agit de synchroniser des événements sur l’ordre de la microseconde.

Dérive de l’Oscillateur

Les oscillateurs internes, qui définissent la précision de l’horloge d’un microcontrôleur, ont une dérive typique de 10 à 20 ppm pour l’ESP32. Une dérive aussi faible puisse paraître négligeable, elle représente déjà une dérive de 10 à 20 microseconde/s. Une solution potentielle serait d'utiliser un oscillateur à compensation thermique (TCXO) qui peut réduire la dérive jusqu’à 0,1 ppm. Cependant, même avec un TCXO, la synchronisation devra être régulièrement réajustée.

4. Approche Adoptée

La synchronisation repose sur l’échange de messages horodatés. L’offset temporel entre deux unités est estimé en comparant les horodatages locaux et distants lors de ces échanges.

Pour garantir une mesure précise de cet offset, la méthode a été implémentée dans un cadre logiciel optimisé afin de réduire au maximum le jitter, c’est-à-dire les variations de latence pouvant affecter la précision de l’horodatage. Des efforts particuliers ont été portés à deux niveaux :

• Au niveau radio : la pile de communication est configurée pour minimiser les délais de traitement et assurer une transmission le plus déterministe possible.

• Au niveau système : l’environnement multitâche (sous FreeRTOS) est organisé de façon à prioriser les tâches critiques liées à la synchronisation, en limitant les interruptions ou les blocages dus à d’autres processus concurrents.

Filtrage et Traitement des Mesures

Pour stabiliser la synchronisation, plusieurs approches ont été testées.
L'approche la plus efficace est l'utilisation d'un filtre de Kalman, qui permet d’estimer l’état du système en tenant compte du bruit et des incertitudes. Dans ces conditions, la précision de l'estimation des offsets fonctionne avec des écarts type de l’ordre de 11 micro seconde après un temps d'acquisition de l'ordre de la minute (le temps d'avoir assez d'itérations pour que le filtre converge).

5. Validation Expérimentale et Matérielle

Pour tester la synchronisation, un circuit intégré de la série 7400N a été utilisé comme driver entre une des broches du microcontrôleur et le câble RG58. Ces circuits TTL (Transistor-Transistor Logic) ne sont plus fabriqués mais ils sont utiles dans ce contexte : ils ont des temps de monté rapide et ils délivrent des courants élevés (de l'ordre de 10 mA par sortie) : Le temps de montée des portes logiques 7400 se situe entre 10 et 20 ns (instantanée à l'échelle de notre mesure) et le courant permet de bien charger le câble RG58 utilisé pour relier les microcontrôleurs à l’oscilloscope permettant de mesurer la différence de synchronisation des deux boitiers. Deux sorties du 7400N ont été reliées en parallèle pour obtenir une impédance de 50 ohms (la sortie du 7400N est d'environ 100 ohms), adaptée au câble RG58 (50 ohms). Bien qu’un driver spécifique, par exemple un 74LS240, aurait été idéal, la solution utilisée est suffisante pour la distance testée, environ 10m (et c’est tout ce que j’avais sous la main).

6. Synchronisation des Sorties GPIO

L’objectif final était de lever une broche de manière synchronisée sur les deux microcontrôleurs. En théorie, connaître l’écart (offset) entre les deux horloges permettrait de déclencher une impulsion en même temps sur chaque dispositif

En pratique, malgré une estimation plus précise de l'offset, l'écart type obtenu est d'environ 60 microsecondes. Cette différence résulte de la difficulté à générer une impulsion synchronisée, notamment en raison des limitations inhérentes à l’ESP32 qui, orienté multitâche, ne privilégie pas les opérations strictement temps réel. J’ai testé plusieurs stratégies :

Stratégies Testées pour commander la levée de la broche :

• Timers en Cascade : Pour minimiser l'impact sur le processeur, plusieurs timers ont été utilisés en cascade. Le dernier timer, proche de l'échéance, utilisait une attente active (busy wait) pour garantir la précision, tandis que les autres utilisaient esp_timer pour planifier les événements. Cette méthode évite de bloquer entièrement le processeur sur l'attente active. Cependant, esp_timer est optimisé pour des délais à l'échelle de la milliseconde, ce qui limite la précision à des échelles inférieures. Mais on peut pas rester 1seconde en busy wait, au risque de rendre le microcontrôleur inopérant (charge CPU).

• Module RMT : Le module Remote Control (RMT) de l’ESP32 permet de générer des séquences temporelles précises, mais il est limité par une capacité de 32 768 valeurs, ce qui ne permet pas de générer des séquences très longues avec une résolution de l’ordre de la microseconde (environ 32 ms). Conçu à l’origine pour des télécommandes, il montre ses limites pour des applications de synchronisation fine sur des temps long.

• Module LEDC : Destiné à la génération de signaux PWM pour le contrôle de LED, ce module n’est pas conçu pour être mis à jour en continu avec une précision extrême, ce qui introduit de la gigue lors de la redéfinition des délais. Pas top non plus….

Un retard de 64 micro seconde sur les fronts, ce qui représente le décalage temporel typique entre les deux événements.

Le dispositif, réalisé deux fois, permettant de générer le signal dont le temps d'arrivé est comparé à l'oscilloscope.

On voit le décalage estimé entre les deux horloges internes des ESP32 : 75735360 micro seconde. D'autres tests ont été conduit avec 4 esclaves.

7. Perspectives et Conclusion

La synchronisation sans fil des horloges internes de microcontrôleurs fonctionne très bien. La levée de la broche pour la validation expérimentale intoduit de la gigue, ce qui dégrade un peu la validation expérimentale. Mais la synchronisation des levées de broches se fait avec un ecart type de l'ordre de 60 µs alors que la détermination de l'offset s'effectue avec un ecart type de l'ordre de 10 µs. La synchronisation fonctionne même durant plusieurs heures de fonctionnement continues.

Quoi qu’il en soit, les limites matérielles, telles que la dérive de l'oscillateur interne et les limitations des modules de communication et de génération de signaux (RMT, LEDC), freinent la précision absolue. De plus, les contraintes logicielles, notamment l’environnement FreeRTOS, bien que performant pour le multitâche, ne sont pas optimales pour des opérations strictement temps réel, ce qui complique la synchronisation à l’échelle de la microseconde. L’ESP32, c’est bien pour travailler à la ms. Pas à la micro seconde. C'est peut être un frein pour synchroniser des actions dans le cadre d'une commande sans fil, cela l'est moins pour l'acquisition de données déportées : la connaissance des écarts temporels entre les deux horloge permet d'envisager une interpolation pour corriger les dérives.

Pistes d’Amélioration :

• Utilisation d’un oscillateur externe haute précision : Remplacer l’oscillateur interne par un TCXO pourrait considérablement réduire la dérive, permettant une synchronisation plus stable sur le long terme. Mais c’est impossible avec l’ESP32 : l’oscillateur est sous le capot métallique.

• Optimisation du code : Réduire les interruptions et les interférences dans le système multitâche. Par exemple, l’utilisation d’attentes actives (busy wait) uniquement sur le dernier timer critique permet de minimiser les latences pour la montée de la broche de sortie. On pourrait faire du busy wait pendant toute la seconde, en accrochant un des deux cœurs pour cette tâche uniquement. Mais ce n'est pas une utilisation très optimale du CPU...

• Exploration d’autres microcontrôleurs : Tester des plateformes orientées temps réel de manière plus stricte pourrait offrir de meilleures performances pour des applications nécessitant une synchronisation ultra précise. Des microcontrôleurs plus « indus » et orienté temps réel comme la série des TM de Texas Instruments par exemple.

• Amélioration des algorithmes de filtrage : Le recours à des filtres de Kalman avec plus de paramètres (la température par exemple) pourrait aider à compenser les imprécisions inhérentes aux mesures et aux communications.

Ce projet de synchronisation sans fil a démontré qu’il est possible d’atteindre une synchronisation fine des horloges internes, avec une précision de l’ordre de la dizaine de microsecondes, même sans hardware spécifique. Les résultats obtenus ouvrent ainsi la voie à de nouvelles applications dans le domaine de l’acquisition synchronisée sur plusieurs boîtiers.

Une méthode pragmatique, adaptée à nos contraintes, a été développée en interne. Nous en dévoilerons les détails à l'occasion d'un prochain billet, pour un contexte applicatif précis : l'analyse modale d'une poutre modèle. Plusieurs boitiers sont en charge de l’acquisition des données d'accélérométrie et ils sont synchronisés par radio...

Note : En finissant d'écrire ce billet, en parcourant la doc d'Espressif, je vient de voir qu'il est possible d'utiliser deux timers TG0 et TG1 via l’API ESP-IDF. Il faudrait reconduire des tests avec ces timers pour voir si cela améliore la synchro pour la levée des broches.... Mais ce n'est pas mon application cible : il s'agit plutôt de faire correspondre les horloges internes des différents microcontrôleurs pour pouvoir dépouiller correctement les mesures expérimentales en provenance de différents boitiers.