Suchen

Synchronisation WiLink8 als Referenz für das Network Time Protocol

| Autor / Redakteur: Iain Hunter * / Sebastian Gerstl

Wenn Embedded Systeme in einem Netzwerk synchronisiert werden müssen, Ethernet aber keine Option ist, stellt WiLink8 eine Alternative für Echtzeit-Synchronisation per WiFi dar.

Firmen zum Thema

Beispiel einer Clock-Time-Synchronisation unterschiedlicher Geräte via NTP-Prtotokoll mit Hilfe einer WiLink8-gestützten WiFi-Verbindung.
Beispiel einer Clock-Time-Synchronisation unterschiedlicher Geräte via NTP-Prtotokoll mit Hilfe einer WiLink8-gestützten WiFi-Verbindung.
(Bild: Texas Instruments)

Eine der Herausforderungen, denen sich Embedded-Systems-Entwickler im Zusammenhang mit drahtlos vernetzten Geräten gegenübersehen, betrifft die Aufrechterhaltung einer gemeinsamen Clock Time zwischen allen Geräten in einem Netzwerk. Das Network Time Protocol (NTP) kommt hierfür häufig zum Einsatz.

Es handelt sich um ein Standard-Hilfsmittel, das in Rechnerplattform jeglicher Art zur Aufrechterhaltung der Systemzeit eines Geräts verwendet wird. In dem folgenden Artikel geht es um einen neuen Referenztakttreiber für NTP. Dieser nutzt die Zeitinformationen, die die WiLink8-Familie von Texas Instruments vom WiFi Access Point (AP) empfangen kann. Dieses Zeitsynchronisations-Feature eignet sich dafür, einen gemeinsamen Takt für alle an den AP angeschlossenen Stationen bereitzustellen – mit einem Fehler von weniger als 100 µs zwischen den Geräten.

Auseinanderdriftende Geräte wieder in Gleichschritt bringen

Dass die Geräte eines Systems mit der Zeit auseinanderdriften, liegt daran, dass ihre Taktfrequenzen meist geringfügig voneinander abweichen. Zwar sind die Quarze, die das Haupt-Taktsignal erzeugen, sehr präzise; dennoch weisen sie immer noch eine im ppm-Bereich (Parts Per Million) liegende Toleranz auf. Selbst wenn sich die Frequenzen zweier Quarze nur um 1 ppm unterscheiden, ergibt sich nach nur einer Stunde Betrieb eine Abweichung von 3,6 ms zwischen den Zeiterechnungen der beiden Geräte.

Die Funktion des NTP beruht darauf, dass die aktuelle Echtzeit durch Abfragen hochpräziser NTP-Server im Internet ermittelt wird. Über die Zeit nutzt der NTP-Daemon im Gerät die periodischen Zeit-Updates aus dem NTP-Server zum Aktualisieren der vom Betriebssystem vorgenommenen Berechnungen der lokalen Gerätezeit. Dies geschieht auf zweierlei Weise:

  • Sprunghafte Änderung der Gerätezeit, damit diese mit der Serverzeit übereinstimmt. Diese eher seltene Maßnahme dient zur Korrektur größerer Zeitabweichungen.
  • Überwachung der Drift zwischen Gerätezeit und Serverzeit, da die Quarze der einzelnen Geräte geringfügig abweichende Eigenschaften (und damit auch Frequenzen) aufweisen. Hier werden viele Proben zum Erheben einer Statistik der empfangenen Zeitstempel genutzt, um die Auswirkungen des Jitters zu minimieren, zu dem es bei der Paketübertragung zwischen Server und Gerät kommt. Da hier der Genauigkeit der Vorzug vor der Schnelligkeit der Konvergenz gegeben wird, kann es mehrere Stunden dauern, bis der Gleichlauf erreicht ist. Der Linux-Kernel enthält spezielle APIs für NTP, die zum Aktualisieren der Systemuhr im Gerät auf der Basis der berechneten Drift zwischen Geräte- und Server-Quarz dienen.

Ist ein Gerät per Ethernet angeschlossen, schwankt die Zeit, die die Uhr-Aktualisierungen bis zum Eintreffen im Embedded-Gerät benötigen, nur sehr wenig. NTP kommt hier auf eine Genauigkeit von unter einer Millisekunde. Wird stattdessen eine WiFi-Verbindung genutzt, variiert die Übertragungszeit der Pakete dagegen deutlich stärker als bei einer Ethernet-Verbindung, was die Genauigkeit der Uhr-Aktualisierungen beeinträchtigt. In einigen Anwendungen reicht die Genauigkeit der Uhr deshalb nicht mehr aus. Die Verwendung von WiFi-Verbindungen im System ist dann ausgeschlossen.

NTP bietet Geräten ebenfalls eine Möglichkeit, ihre Zeit von einer lokalen Referenzuhr zu beziehen anstatt per Internet von einem Server. Auf diese Weise lässt sich das Problem der variablen Übertragungszeiten vermeiden. Bei diesen Referenzuhren handelt es sich meist um Funkempfänger, die ihre Zeitinformation per GPS oder von nationalen Zeitreferenz-Sendern beziehen.

Jeder vom AP gesendete WiFi-Beacon enthält einen TSF-Wert (Time Synchronization Function), der als Zeitstempel für den Beacon dient. Auch wenn es sich dabei nur um die Zeit seit dem Einschalten des AP handelt, stellt der TSF-Wert doch eine gemeinsame Zeitbasis für alle angeschlossenen Stationen dar, sodass er als Basis für eine Referenzuhr genutzt werden kann. In diesem Szenario haben die Geräte keine präzise Echtzeit gemeinsam mit der übrigen Welt, sondern eine gemeinsame Taktreferenz, bei der es sich um den Takt des AP einschließlich aller Drifts oder Fehler handelt, mit denen dieser behaftet ist. Die Host-Prozessoren, die an die AP-bezogenen WiLink8-Bausteine angeschlossen sind, lassen sich damit synchronisieren.

(ID:44498636)