J'ai besoin de vérifier la simultanéité de 2 événements physiques. Pour ce faire j'ai besoin que 2 arduinos (MKR wifi 1010) puissent effectuer des mesures à 1kHz et dater précisément les échantillons (à la milliseconde près). Les 2 arduinos ne peuvent pas être reliés directement, seule une liaison sans fil est possible.
La mesure dure environ 5 seconde, puis chaque arduino envoie ses données par wifi à un système collecteur.
J'ai donc besoin que mes 2 arduinos soient synchronisés pour avoir exactement la même heure (j'aimerais que les horloges des arduinos ne soient pas désynchronisés de plus de 5ms). Je pense que la synchronisation NTP sera suffisamment précise, mais ensuite il faut que mes systèmes gardent l'heure.
J'aimerais utiliser le RTC inclus dans le SAMD21 (le MCU du MKR Wifi 1010) pour me donner l'heure à la milliseconde, et mon problème est là.
Selon le datasheet, le RTC peut soit se comporter comme une horloge/calendrier (qui est précis seulement à la seconde, pas à la milliseconde), soit comme un compteur dont la fréquence est un sous-multiple de 32 768 Hz ! Donc par exemple je peux avoir un compteur qui s'incrémente à 1024Hz (en réglant correctement le prescaler), mais comment faire une horloge avec ça ? Y a-t-il une astuce simple ?
Je poste aussi ma question sur le forum anglophone des fois qu'ils aient des idées, je suis vraiment bloqué...
PS : Je vous ai raconté l'histoire complète pour éviter les problèmes XY. Si vous avez d'autres idées pour synchroniser précisément 2 arduinos je suis aussi intéressé !
gtsi:
PS : Je vous ai raconté l'histoire complète pour éviter les problème XY. Si vous avez d'autres idées pour synchroniser précisément 2 arduinos je suis aussi intéressé !
Bonjour
une solution relativement abordable techniquement/financierement est d'utiliser de la datation "GNSS disciplined" , utilisation du front montant 1PPS des recepteurs pour recaler les "esclaves"
Je n'ai jamais utilisé NTP en décortiquant au delà de la seconde, mais j'ai jeté un œil à la structure d'un paquet NTP.
Après les secondes (octets 40 à 43) la fraction de seconde (octets 44 à 47) fonctionne ainsi :
bit de poids fort : 1/2 seconde
2ème bit de poids fort : 1/4 de seconde
etc.
Donc il te faut les 10 bits de poids fort pour descendre à la ms. L'unité sera bien entendu le 1/1024ème de ms.
Ensuite pour savoir si avec le WIFI ce sera suffisamment fiable, à toi de tester.
hbachetti:
...
Donc il te faut les 10 bits de poids fort pour descendre à la ms. L'unité sera bien entendu le 1/1024ème de ms.
Ensuite pour savoir si avec le WIFI ce sera suffisamment fiable, à toi de tester.
Autant utiliser quelques bits fractionnaires supplémentaires pour des arrondis plus justes à la milliseconde.
Mais le vrai problème est le temps de transmission aller-retour du packet udp, entre l'arduino et le serveur NTP.
Normalement en travaillant "proprement", on récupère 4 timestamp dans la réponse NTP
le ts d'émission de la trame UDP aller par le client
le ts de réception de cette trame aller par le serveur
le ts d'émission de la trame réponse par le serveur
le ts de réception de la réponse par le client (selon son horloge avant mise à jour)
Et à partir de là, en prenant les points milieu des ts émission-reception de chaque côté, on peut calculer de manière fiable l'écart entre les deux horloges (et donc recaler celle du client) en s'affranchissant des temps de transport réseau.
Ca c'est la théorie, qui suppose que le temps de transmission aller est le même que le temps de transmission retour, c'est-à-dire que le réseau va aussi vite dans les deux sens.
Ce qui est rarement le cas chez nous, et donc cela occasionne des biais qui ne permettent pas de garantir la précision à la milliseconde.
De toute manière si j'ai bien compris là il n'y a pas besoin d'avoir l'heure, mais de synchroniser deux arduino à la milliseconde près. Cela peut se faire en local.