Hi, im Moment gleiche ich mein Heimnetz über einen openntp-Server in der raspian-Standardkonfiguration und 20 peers. Man kann da noch diverse andere Sensoren (nennt die Konfig das) einbinden. Einen ollen GPS-Bluetooth habe ich noch, den könnte ich also auf die Fensterbank legen. Aber mal ehrlich, bringt mir das irgendwas ausser dass ich nicht mehr Stratum 3 sondern 2 bin :-)
Oliver S. schrieb: > Aber mal ehrlich, bringt mir das irgendwas ausser dass ich nicht mehr > Stratum 3 sondern 2 bin :-) Welche besonderen Anforderungen hast du denn an deine Zeitbasis?
Oliver S. schrieb: > Aber mal ehrlich, bringt mir das irgendwas Für den normalen Betrieb eines Heimnetzes nicht. Auch wenn mal das Internet ausfällt gehen ja nicht gleich die Uhren falsch. Ich habe auch noch einen DCF77-Empfänger auf dem Serverschrank montiert, der blinkt auch noch tapfer vor sich hin, ist aber längst überflüssig. Der verdankt seine Existenz nur noch meiner Bequemlichkeit. Georg
georg schrieb: > DCF77-Empfänger auf dem Serverschrank DCF am ServerSCHRANK ist bestimmt gut abgeschirmt und sammelt alle Störungen ein? Den Fehler hatte ich auch mal gemacht vor Jahren. Das Ende vom Lied war eine ganz tolle Systemzeit wie 44:66:$$ die mir eine Access-DB total durcheinandergebracht hat. Gut, daß ich noch ein brauchbares Backup hatte.
Oliver S. schrieb: > Einen ollen GPS-Bluetooth habe ich noch... > Aber mal ehrlich, bringt mir das irgendwas ausser dass ich nicht mehr > Stratum 3 sondern 2 bin :-) Aus der Bluetooth Werbung: bis zu Stratum 2 :) Das bringt aber trotzdem viel, weil du 2 (ziemlich) unabhängige Quellen bekommst. Genauso wichtig finde ich, dass der ntpd vor allem der eigenen Systemuhr vertraut und die niemals verstellt (slew statt step). Dann gibt's nicht solche Überraschungen wie bei oszi40.
Oliver S. schrieb: > Einen ollen GPS-Bluetooth habe ich noch, den könnte ich also > auf die Fensterbank legen. > Aber mal ehrlich, bringt mir das irgendwas ausser dass ich nicht mehr > Stratum 3 sondern 2 bin :-) Nen Bluetooth-GPS bringt tastsächlich nicht viel, da das für solche Anwendungen eigentlich wichtigste Feature fehlt: das 1 PPS Signal. Das sollte vom GPS-Empfänger per direktem Kabel (und nicht per Funk) an den ntp-Server geführt werden. Bei einem RasPi sollte es auf ein GPIO geführt werden, bei einem PC direkt an eine echte serielle Schnittstelle (nicht über USB) und dort dann ans DCD-Pin gebracht werden. USB oder ähnliche Protokollwandlungen fügen dem Signal nicht zu vernachlässigende Latenz und Jitter hinzu. Wenn Du dafür ein GPS neu kaufst, dann nimm am besten eines, welches für Timing-Anwendungen optimiert ist. Z.B. LEA-M8T oder NEO-M8T von u-blox.
:
Bearbeitet durch User
Ist aber immer noch die Frage offen, wer das benötigt.
oszi40 schrieb: > DCF am ServerSCHRANK ist bestimmt Deshalb schrieb ich "auf"... In Innenräumen ist im übrigen DCF77 immer noch besser zu empfangen als GPS. Georg
Gerd E. schrieb: > eigentlich wichtigste Feature fehlt: das 1 PPS Signal. Nach meinen Tests klappt auch das nur, wenn die Antenne draußen ist, freie Sicht. Auf der Fensterbank innen kommen zwar Daten, aber keine Signalisierung vom GPS-Chipsatz, dass die Zeit zuverlässig sei. Kleiner Spaß am Rande: Ein Kunde rief an, weil sein System merkwürdige Fehler macht. Das ist auf einen hochstabilen Takt angewiesen, der von einem per GPS synchronisierten Frequenznormal geliefert wird. Meine Erfahrung sagt, dass es an dieser Ecke klemmt. Der Elektromeister ging dann mal gemäss meiner Anleitung gucken: Wir haben Dacharbeiten, die Dachdecker haben einen Wetterschutz über die Antenne gebaut :-) georg schrieb: > In Innenräumen ist im übrigen DCF77 immer noch besser zu empfangen als GPS. Ja, und in Innenräumen taugt GPS nichts, selbst wenn mal Empfang gegeben ist. Was ich bislang vergeblich gesucht habe, ist eine Arduino-Implementierung als DCF-Zeitserver im Netzwerk, hat das wirklich noch niemand gebaut?
Manfred schrieb: > Was ich bislang vergeblich gesucht habe, ist eine > Arduino-Implementierung als DCF-Zeitserver im Netzwerk, > hat das wirklich noch niemand gebaut? Warum sollte man sich das antun? Auf einem Server oder Raspberry Pi ist das viel einfacher umzusetzen. Immer schön an die Entwicklungskosten denken. Ich gehe ja auch nicht hin und wasche meine Wäsche im Kochtopf nur weil die Waschmaschine technisch gesehen unnötig komplex ist.
Manfred schrieb: > Was ich bislang vergeblich gesucht habe, ist eine > Arduino-Implementierung als DCF-Zeitserver im Netzwerk Wozu, das erledigt ein vorhandener Server im Tiefschlaf nebenher. Oder hast du bisher ein völlig serverloses Netzwerk? Georg
georg schrieb: > Manfred schrieb: >> Was ich bislang vergeblich gesucht habe, ist eine >> Arduino-Implementierung als DCF-Zeitserver im Netzwerk > > Wozu, das erledigt ein vorhandener Server im Tiefschlaf nebenher. Oder > hast du bisher ein völlig serverloses Netzwerk? Wenn der denn läuft... Nach einem Stromausfall bootet ein "großer" Server eher langsam, auch gerne mal langsamer als ein Client. Und dann dauert es noch, eher Minuten als Sekunden, bis er sich selbst synchronisiert hat und eine gültige Zeit liefern kann. Bis dahin kann man froh sein, wenn er nichts liefert und nicht irgendwas aus seiner CMOS-"Uhr". Ein Zeitserver mit uC hat den großen Vorteil, dass er praktisch sofort eine Zeit mit minimalem Fehler liefern kann. Und er braucht als einziger im Netzwerk eine Batterie (moderne Mainboards funktionieren auch ohne Batterie = eine üble Fehlerquelle weniger). Und er wird normalerweise eine RTC mit TCXO haben, auf welchem Mainboard gibt's denn sowas? Damit kann er ganz entspannt auf guten Empfang/mehr Satelliten warten. Und weil er von Haus aus echtzeitfähig ist, ist es einfacher, einen guten DCF-Dekoder zu programmieren. Naja, ein wenig.
> Nach einem Stromausfall bootet ein "großer" Server eher langsam, Das lässt sich einfach beheben indem man ein Linux oder ein Unix installiert. Winböld ist halt blöd, nicht nur für Server. > Und dann dauert es noch, eher Minuten als Sekunden, bis er sich selbst > synchronisiert hat und eine gültige Zeit liefern kann. Das dauert maximal ein paar Sekunden. > Bis dahin kann man froh sein, wenn er nichts liefert und nicht irgendwas > aus seiner CMOS-"Uhr". Die kan man jederzeit auf dem aktuellen Stand halten, dann ist die bei weitem genau genug, auch direkt nach dem Starten. > Ein Zeitserver mit uC hat den großen Vorteil, dass er praktisch sofort > eine Zeit mit minimalem Fehler liefern kann. Viel zu aufwändig. Schau Dir mal die HP 59309a an, die sind für genau sowas gemacht. Die hängst Du dann an Dein Cäsium-Normal (Rubidium ist für selbsternannte Experten viel zu ungenau), dann kannst Du von der jederzeit die aktuelle Uhrzeit holen. Oder man nimmt doch einfach die weit verbreiteten vorhandenen und locker hinreichend genauen Mechanismen.
Wenn deine Programme mit ein paar Sekunden Abweichung nicht klar kommen, solltest du das Problem dort lösen, nicht bei den Uhren. Absolut synchron werden deine Server nie laufen und spätestens wenn du sie mit anderen Servern außerhalb des Hauses kombinierst hast du gar keine andere Wahl.
Manfred schrieb: > > Was ich bislang vergeblich gesucht habe, ist eine > Arduino-Implementierung als DCF-Zeitserver im Netzwerk, hat das wirklich > noch niemand gebaut? schau nach bei www.LeoBodnar.com, der hat sowas, aber nicht mit Arduino.
Manfred schrieb: > Was ich bislang vergeblich gesucht habe, ist eine > Arduino-Implementierung als DCF-Zeitserver im Netzwerk, hat das wirklich > noch niemand gebaut? https://www.google.com/search?q=arduino+based+ntptimeserver ergibt etliche Treffer...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.