muss. Eine Abfrage genau auf 100 oder 200ms geht nicht. Aktuell habe ich in der Software 80-120ms und 180-220ms, wenn ich das knapper mache, habe ich fast nur defekte Daten. Die Flankensteilheit des Signals und der
diese Schwankungen.
73, Tom
--
DARC OV I18|DL-QRP-AG #1186|G-QRP #14624|FISTS #15933|ARRL
http://dl7bj.org https://twitter.com/dl7bj
Auf der timenuts-liste bei febo.com lief gerade eine Diskussion zu dem Thema. Da hat wohl jemand recht beeindruckende Zahlen auf dem BeagleBoneBlack hinbekommen, und zwar im Userland.
Ausserdem kam zum Thema ntp letzte Woche ein wesentliches
Letzteres hat keinen Einfluss auf die Genauigkeit...
ntp-Treiber. Bei pps sagt der ntp nur dem Kernel, wo er den Sekundenimpuls herbekommt (beim Pi also, an welchem GPIO-Pin). Es findet keine Decodierung statt (die initiale Zeit muss also woanders her kommen), und Erfahrungen berichten, dass der eine fehlende Impuls bei 59 nicht
dass er die Quelle verwirft. (Den fehlenden 59er meldet er, aber rausfliegen tut er deswegen nicht.)
weil das ja hier angemerkt wurde, eine Scriptlaufzeit keine Rolle, weil der shm-Aufruf die decodierte Zeit und die zu diesem Zeitpunkt
relative Abweichung nimmt. Und ich behaupte mal, dass ein laufendes C-Programm, welches unmittelbar nach dem Auslesen des 00er Impulses an einem GPIO-Port einmal gettimeofday() aufruft, da keine nennenswerte
mittlere Jitterwerte von 15-20 ms.
mfg. Gernot
--
(Gernot Zander) *Keine Mailkopien bitte!*
Ein System-Administrator ist nur so gut wie sein letztes Backup.
(Horst Knobloch)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.