Myślę, że ten rodzaj ledwo mieści się w przepisach, ale jest na tyle interesujący, że sądzę, że i tak go opublikuję.
Precyzyjny, synchronizowany GPS generator znaczników czasu do celów akwizycji danych.
Jest to dość interesujący projekt, którego celem jest zapewnienie łatwego sposobu synchronizacji wielu niezależnych systemów akwizycji danych.
Zasadniczo pracuję w laboratorium badawczym i często mamy instrumenty, które mają wiele niezależnych systemów akwizycji danych, które można fizycznie oddzielić nawet o 50 stóp. Musimy być w stanie skorelować czas, w którym pobierano próbki z każdego systemu, co może być trudne, jeśli chcesz rozwiązać czasy próbkowania z dużą dokładnością. Używając czegoś w rodzaju systemu akwizycji danych USB, tylko opóźnienie USB może wprowadzić kilkaset milisekund nieznanego opóźnienia, które może różnić się w zależności od akwizycji.
Poprzednim rozwiązaniem był 24-bitowy licznik równoległy, który był po prostu przewożony wszędzie, wymagający ogromnej wiązki przewodów i stanowił rodzaj bólu w tyłku.
Ten system wykorzystuje wyspecjalizowany moduł pomiaru czasu GPS, który może syntetyzować dowolne zegary częstotliwości, które są fazami i częstotliwościami zablokowanymi na zegarach atomowych w satelitach GPS.
MCU jest odpowiedzialne za wiązanie wiadomości danych GPS (musiałem znacznie rozszerzyć i zoptymalizować istniejący parser protokołów dla danych GPS). GPS jest skonfigurowany do używania zastrzeżonego protokołu binarnego i wszystko jest analizowane przez analizator składni, który napisałem.
Projekt przeszedł szereg zmian (na zdjęciu poniżej).
Projekt
Rewizje!
Rev 1: Nigdy nie działałem, ponieważ początkowo miałem nadzieję, że użyję oprogramowania dPLL ze znacznie tańszego GPS, aby zsyntetyzować zegar o wyższej częstotliwości tylko z wyjścia 1 PPS. Prawdopodobnie jest możliwe, aby działało, ale inwestycja czasu po prostu sprawiła, że nie warto. (a ja jestem zbyt kiepski koderem)
Zastosowano MCU śmigła paralaksy. Ważnym problemem był również brak przyzwoitych języków kompilowanych.
Rev 2: Przeniesiono do ATmega2560. Pracował, miał wiele funky projektowania odziedziczonych po pierwszej wersji. Przede wszystkim dalsze stosowanie rejestrów przesuwnych dla wyjścia 32-bitowego, pomimo wystarczającej liczby IO w ATmega2560.
Pierwsza płyta, na której działał Optiboot, a właściwie została całkowicie zaprogramowana przy użyciu standardowego zestawu narzędzi Arduino, zanim zirytowałem się nim i zacząłem modyfikować zestaw narzędzi, aby lepiej pasował do moich celów.
Rev 3: Działa również. Okablowane okablowanie jest spowodowane tym, że ta płyta zawiera wbudowany koncentrator USB w celu zmniejszenia liczby wymaganych portów USB (interfejs FTDI wymaga 1 USB, a GPS ma również interfejs USB). Niestety GPS nie wyliczył poprawnie, chociaż urządzenie FTDI działało dobrze, a ja korzystałem z tego hubu gdzie indziej bez problemu. Dziwne.
Nie mam odpowiedniego debugera USB, więc po prostu całkowicie upuściłem koncentrator USB, zamiast próbować rozwiązać problem. Usb GPS nie jest tak naprawdę często używany poza konfiguracją.
Rev 4: Półfinałowa wersja ATmega2560. Dodano wyświetlacz LCD z informacją o stanie GPS, skrzypnął diodami LED i tak dalej. Również lepsze ślady dla możliwych superkondensatorów do utrzymywania statusu GPS, gdy nie są zasilane.
To jest ostatnia wersja Optiboot.
MStime
to MSTOW
lub tydzień w milisekundach, czyli nazwa wartości danych GPS, która jest wyprowadzana na wyjściu znacznika czasu. Jest to 32-bitowa zmienna, która zwiększa się raz na milisekundę i przewija się co tydzień. Jest to bardziej niejasna część standardu GPS.
ITOW
to kolejna wartość związana z GPS, będąca wartością odpowiadającą sygnałowi 1PPS. Korelacja między tymi dwoma nie jest poprawnie odzwierciedlona na ekranie LCD, ponieważ nie mam czasu procesora na aktualizację wyświetlacza LCD w tempie, które chciałbym. To była właściwie jedna z głównych rzeczy, które poprawiły się w aktualizacji do urządzeń Xmega.
Rev 5: Kompletna zmiana architektury. Teraz używa procesora ATxmega128A1U. Nie jest już tak naprawdę „Arduino”, ale możliwość posiadania wielu poziomów przerwań w procesorach xmega pozwoliła mi znacznie poprawić strukturę kodu.
Te dwa druty są ode mnie podczas eksperymentów, bez nich również płyta działała dobrze.
Patrząc w przyszłość:
Rev 6!
Dodaj możliwość korzystania z różnych rozmiarów LCD, większą ochronę przed wyładowaniami elektrostatycznymi w połączeniu z anteną GPS (to był problem), możliwość użycia baterii CR2032 do utrzymywania zegara GPS zamiast superkondensatorów.
Znacznie lepsze oznakowanie diod LED debugowania i statusu.
I bonus Nyan-Cat!
(Te tablice są obecnie w fazie produkcji. Kiedy je zdobędę, dodam zdjęcia prawdziwej planszy.)
Przeprowadziłem kilka długotrwałych testów między dwiema płytami ATmega2560 i przez 72 godziny błąd czasu RMS między dwiema jednostkami wynosił ~ 20 μS. Dotyczyło to również dwóch całkowicie niezależnych anten. Mój cel projektowy to <1 ms, więc jestem z tego bardzo cholernie zadowolony.
Ogólnie rzecz biorąc, myślę, że dobrze to ilustruje, w jaki sposób Arduino może być użytecznym narzędziem do wczesnego prototypowania „prawdziwych” produktów / systemów. Używam go do uruchomienia początkowej wersji testowej przy minimalnym wysiłku, a kiedy jestem pewien, że pomysł zadziała, w rzeczywistości wkładam pracę w migrację do całkowicie niestandardowej, specyficznej dla celu implementacji.
Pliki projektowe:
https://fake-server.no-ip.org/svn/FPGAStuff/DAQ%20systems/
(w serii katalogów „GPS Timestamp”).
(UWAGA: Pliki są z Altium Designer są. Nie plików orzeł).
Kod źródłowy:
https://fake-server.no-ip.org/svn/Programming/Code/AVR/
Znowu w serii katalogów „gpsTimeStamp”.
Przepraszam za kiepskie zdjęcia z telefonu komórkowego.