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?
Odpowiedzi:
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.
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.
źródło
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.
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.
źródło
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.
źródło
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ą.
źródło