Jak zsynchronizować dwa mikrokontrolery z dokładnością do mikro sekundy?

37

Muszę zsynchronizować dwa mikrokontrolery, aby mogły zmierzyć prędkość fal rozchodzących się. Pomiary opóźnienia czasowego muszą mieć dokładność mikrosekundową (błąd mniejszy niż 1/2 mikrosekundy).

Mam dwa mikrokontrolery ( ATmega328 ), które używają kryształu 12 MHz.

Oba są wyposażone w nadajniki-odbiorniki Bluetooth. Urządzenia nadawczo-odbiorcze Bluetooth wysyłają i odbierają pakiety z fluktuacją wynoszącą ~ 15 milisekund.

Mam nadzieję zsynchronizować mikrokontrolery za pomocą nadajników-odbiorników Bluetooth lub innej kreatywnej metody.

Próbowałem je zsynchronizować, dotykając ich razem, ale potrzebuję, aby pozostały zsynchronizowane przez około 10 minut, a ich zegary dryfowały zbyt szybko. Być może, gdyby można było dokładnie przewidzieć przesunięcie zegara, ta metoda zadziałałaby.

Jak powinienem przejść do osiągnięcia tej synchronizacji?

Kevin
źródło
2
Czy możesz nam powiedzieć, co próbujesz zrobić i dlaczego jednostki muszą być zsynchronizowane? Być może specyfika aplikacji może wskazywać rozwiązanie. Zasadniczo nie jest to bardzo łatwy problem, zwłaszcza w przypadku małych urządzeń bezprzewodowych.
Nick Alexeev
2
Synchronizacja oparta na Bluetooth jest niemożliwa. Jitter 15 ms to po prostu za dużo, aby uzyskać synchronizację 0,5 us. Potrzebujesz czegoś o bardzo niskim jitteru i ustalonym opóźnieniu, które można poprawić. Byłoby łatwiej, gdyby można uzyskać jeden zegar dla obu z nich i buforować zegar, aby zrównoważyć opóźnienia.
travisbartley
Przepraszam za spóźnienie. Celem projektu jest usunięcie przewodów z istniejącej konstrukcji ręcznych cyfrowych narzędzi pomiarowych. Użytkownik chciał mieć konstrukcję bezprzewodową, ponieważ uszkadzały one obecne przewody. Jednostki mierzą propagację fal w drzewach stojących, które są wystarczająco szybkie, aby potrzebować synchronizacji 0,5us między obydwoma czujnikami.
Kevin
Tani-bezprzewodowy: podczerwień. Jeden impuls podczerwieni może wystarczyć do ponownej synchronizacji zegarów, gdy nieco się od siebie oddalą.
JimmyB 21.04.16
1
W artykule zaproponowano system Bluetooth 4.0 z synchronizacją ~ 10uS z testem eksperymentalnym.
user2943160,

Odpowiedzi:

23

Nie chcę padać na twoją bezprzewodową paradę. Wpadłeś na trudne, ale nieoczekiwane wymaganie. Coś takiego wymaga ponownej oceny całego projektu systemu.

Pierwszą rzeczą, która przychodzi na myśl, jest wyłączenie obu jednostek z jednego oscylatora. Masz komunikację Bluetooth, która sugeruje, że zasięg jest rzędu 10 m. Możesz podłączyć swoje urządzenia za pomocą kabla koncentrycznego RG174 lub światłowodu, który przenosi zegar.

Po drugie , są precyzyjne oscylatory. W celu zwiększenia precyzji i kosztów.

  • TCXO (oscylator kwarcowy z kompensacją temperatury). Dryft od 1 do 3 ppm, zazwyczaj.
  • OCXO (oscylator kwarcowy sterowany przez piekarnik). Dryfuj rzędu 0,02 ppm. Niektóre OCXO spadły do ​​0,0001 ppm.
  • Zegar atomowy ( na przykład standard Rubidium ). Wspominam o zegarze atomowym głównie po to, aby podać ramy odniesienia. Więcej na ten temat tutaj .

Trzeci , precyzyjny oscylator przeszkolony z GPS. Każdy satelita GPS ma na pokładzie kilka zegarów atomowych. Zazwyczaj widać wiele satelitów GPS. GPS jest często używany do precyzyjnego pomiaru czasu (mniej znane użycie w porównaniu do nawigacji satelitarnej). Większość odbiorników GPS ma wyjście 1PPS (jeden impuls na sekundę), co zapewnia czas z dokładnością do 50ns.
Aby uzyskać dryft 0,5 μs w ciągu 600 sekund (10 minut), zegar (zegar 12 MHz w obecnym projekcie) powinien mieć dryft mniejszy niż 0,0008 ppm. Ale jeśli możesz poprawić błąd taktowania co jakiś czas z zewnętrznego źródła o niskim znoszeniu, wymóg dotyczący znoszenia w zegarze może być bardziej zrelaksowany. Jeśli potrafisz korygować co sekundę, twój zegar może mieć dryft 0,5ppm.

Nick Alexeev
źródło
Kiedyś pracowałem nad projektem, w którym musieliśmy uzyskać tego rodzaju dokładność na serwerach działających w centrach danych na całym świecie. Tam najłatwiej było użyć GPS. Okazało się, że nie wszystkie maszyny / centra danych mogły uzyskać dostęp do GPS, więc nasze rozwiązanie było sporym wyzwaniem. Robienie tego za pomocą mikrokontrolerów będzie jeszcze trudniejsze.
NomadAlien
4
+1 za „uzasadnienie ponownej oceny całego projektu systemu”.
1
W zależności od budżetu możesz kupić urządzenia GPS, które generują programowalną częstotliwość (0-10 MHz), która jest wyrównana fazowo z sygnałem GPS za około 150 USD rocznie. Spójrz na uBlox LEA-6T. Twierdzą, że wyjściowy sygnał czasowy błędu 30 nS RMS, 99% <60 nS.
Connor Wolf,
9

Moduły GPS z wyjściami 1pps są łatwo dostępne i niedrogie.

Nie jest konieczne dyscyplinowanie oscylatora procesora względem GPS (np. Za pomocą PLL). Tak długo, jak można „znacznik czasu” zdarzeń zewnętrznych w stosunku do zegara procesora, stosunkowo łatwo interpolować czas nadawania i odbierania fali między dowolnymi dwoma zdarzeniami PPS.

Często można użyć kombinacji timera sprzętowego mikrokontrolera wraz z licznikiem oprogramowania dla jego zdarzeń przepełnienia, aby utworzyć licznik cykli procesora o dowolnej szerokości. Właściwe radzenie sobie ze zdarzeniami najazdu, zarówno licznika sprzętowego, jak i licznika programowego, może być trudne, ale w końcu możesz mieć, powiedzmy, 32-bitowy licznik, który liczy się z częstotliwością zegara procesora (dając wysoką rozdzielczość ) i przewija się z okresem dłuższym niż interwały, które próbujesz mierzyć (np. 429 sekund przy 10 MHz).

Możesz użyć tego licznika do znacznika czasu różnych zdarzeń zewnętrznych. Jeśli jednym z takich zdarzeń są impulsy 1pps z odbiornika GPS, podstawowa długoterminowa dokładność zegara procesora staje się nieważna. Jedyne, co się liczy, to jego krótkoterminowa stabilność. Możesz zapisać znaczniki czasu GPS w buforze FIFO i porównać znaczniki czasu innych zdarzeń z wartościami w tym buforze. Ponieważ wiesz, że impulsy GPS są dokładnie w odstępie jednej sekundy, możesz znaleźć dokładny czas każdego innego zdarzenia, interpolując.

GPSnGPSn+1TimenTimen+1ExtGPSnGPSn+1

Timen+ExtGPSnGPSn+1GPSn

Wreszcie, jeśli ta konfiguracja działa na dwóch oddzielnych systemach, każdy z własnym odbiornikiem GPS, możesz z dużą precyzją porównać czasy obliczone dla różnych zdarzeń w dwóch systemach (zwykle rzędu ± 100 ns), nawet jeśli Zegary procesora dwóch systemów nie są zsynchronizowane.

Dave Tweed
źródło
Czy mógłbyś powiedzieć coś więcej o tym, jak to by działało? Mam problem ze zrozumieniem na podstawie obecnego wyjaśnienia.
NickHalden,
@NickHalden: OK, gotowe.
Dave Tweed
Hmmm ok, czy to nie zależy od tego, czy częstotliwość procesora jest stała między dwoma 1-sekundowymi impulsami? Weźmy na przykład szczególnie okropny obwód oscylatora kwarcowego, w którym 99% impulsów występuje między 0,00 a 0,05 sekundy, a następnie końcowy 1% występuje między 0,05 a 1,00 s. Czy ten patologicznie skonstruowany przykład nie spieprzyłby tego, czy wciąż czegoś mi brakuje?
NickHalden,
Tak, to właśnie oznacza „stabilność krótkoterminowa”.
Dave Tweed
Och, to było tam, kiedy skomentowałem? Haha, to żenujące. W każdym razie dzięki za wyjaśnienie +1 ode mnie.
NickHalden
8

Wcześniej zaimplementowałem bezprzewodową synchronizację zegara dla mikrokontrolerów, ale tylko z dokładnością do milisekund, co było wystarczające dla aplikacji. Z mojego czytania ten artykuł dość dobrze wyjaśnia synchronizację w mikrosekundach: http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdf

Zasadniczo, jeśli masz wiedzę o zdarzeniu transmisji i zdarzeniu nadejścia pakietu radiowego odpowiednio na nadajniku i odbiorniku, masz wspólne obserwowalne zdarzenie (zakładając, że zignorujesz czas propagacji fali radiowej) między dwoma systemami, które mogą być używane jako odniesienie. Inną ciekawą cechą wspomnianą w artykule jest estymacja skosu zegara przy użyciu regresji liniowej.

Keene
źródło
Precyzja 1,5 μs w scenariuszu z pojedynczym przeskokiem i średnia precyzja 0,5 μs na przeskok w przypadku z wieloma przeskokami zostały przedstawione poprzez dostarczenie wyników eksperymentalnych. Miły.
Li-aung Yip
1
Może to również być interesujące: Protokół synchronizacji czasowej dla sieci czujników
Nick Alexeev
3

Sprawdź protokół synchronizacji zegara Bluetooth (CSP), który jest opcjonalną częścią profilu urządzenia zdrowia (HDP). Sekcje tego dokumentu, które dotyczą CSP, to 2.1 i 8.

Nie miałem jeszcze okazji tego spróbować, ale o ile wiem, BlueZ (oficjalny stos protokołów Linux Bluetooth) właśnie dodał obsługę HDP , w tym obsługę CSP. Nawet jeśli nie brzmi to tak, jakbyś działał na platformie obsługującej stos BlueZ, ale może kod zapewni przynajmniej dobrą implementację referencyjną.

nocnokneo
źródło