Ich habe eine Stoppuhr mit Groß-Display und Bedienterminal, beide sind über Wifi verbunden und selber gebaut. A) Das Display wird nur über WiFi gesteuert. Im Display ist dafür ein Raspberry zuständig auf dem ein entsprechender WEB Server läuft. Über das Web Interface lässt sich alles erdenkliche einstellen, auch START/STOP. B) Über das Bedienterminal (ESP8266) soll die Uhr elektronisch gestartet und gestoppt werden (über WiFi). Das Bedienterminal zeigt die Zeit auch auf seinem Display an. Problem: Die Latenzen über die WiFi Verbindung schwanken stark und daher können die START/STOP Befehle nicht einfach als html Kommandos geschickt werden. Eine Lösungsidee: Auf beiden Geräten läuft ein Timer mit ms Auflösung. Anstatt eines START Kommandos schickt das Terminal seinen ms Counter zum Startzeitpunkt zum Display, und beim STOP schickt es seinen ms Counter zum Stoppzeitpunkt. Das Display ermittelt mit seinem lokalen ms-Counter daraus die Anzeigewerte. Damit zeigt das Groß-Display die korrekte Stop-Zeit an, aber durch die Wifi-Latenz läuft das Groß-Display dem Terminal-Display immer etwas hinterher. Ich hätte jetzt gerne eine Idee, wie man die beiden ms-Timer im Display und Terminal synchronisieren kann, so das die auf dem Groß-Display und die auf dem Bedienterminal angezeigte Zeit exakt gleich ist. Oder vielleicht eine andere Idee wie man die beiden Uhren über Wifi synchron laufe, starten und stoppen kann...
Wifi ist Netzwerk, und im Netzwerk gibt es das dafür seit langem erprobte (S)NTP-Protokoll. Das kann Laufzeitunterschiede kompensieren, dafür ist es da. Alle beteiligten Geräte (Dein Raspberry und Deine ESP8266-basierten Geräte) holen sich via (S)NTP die aktuelle Zeit von einem Zeitserver (im Internet u.a. pool.ntp.org, oder Deine Fritzbox ...). Wenn das ganze autark laufen soll, ist der Raspberry Pi selbst der Zeitserver. https://de.wikipedia.org/wiki/Network_Time_Protocol
Christian K. schrieb: > Oder vielleicht eine andere Idee wie man die beiden Uhren über Wifi > synchron laufe, starten und stoppen kann... Wieso überhaupt? Nur die gestoppte Zeit ist wichig, und die wird vom Bedienterminal gemessen und nach dem Stopp-Befehl ans Display übertragen. Der Timer im Display dient nur dazu, die ablaufende Zeit fürs Publikum anzuzeigen, aber ob die vom Timer des Bedienterminals abweicht sieht ja niemand, solange die Abweichung nur einen Bruchteil einer Sekunde beträgt. Auf jeden Fall: massgebend für die Zeitnahme kann nur ein Timer sein. Und wegen der manuellen Bedienung ist das eben der im Bedienterminal. Georg
Du hast dir ja einen ganz schönen Stapel an Protokollen für recht wenig Action angelacht. Wenn du wirklich die Hose weiterhin mit der Kneifzange anziehen musst, vergiss den folgenden Absatz. Statt des hohen Aufwands bis in die obersten Schichten solltest du vielleicht auf etwas Kleineres umschwenken. Neben HTTP gibt es tief, tief darunter noch TCP. Auf derselben Ebene läuft UDP. Wenn es dir wirklich um Einfachheit und Echtzeit-Verhalten geht, nutze UDP direkt und schicke darüber deine Kommandos. UDP ist noch viel einfacher als TCP, geht im Heimnetzwerk garantiert nicht verloren und ist mit Perl oder Python machbar. Damit sparst du dir nicht nur die Verarbeitungsebenen, sondern entlastest auch den Prozessor wesentlich: nur noch ein einfaches Skript.
georg schrieb: > Wieso überhaupt? Nur die gestoppte Zeit ist wichig, und die wird vom > Bedienterminal gemessen und nach dem Stopp-Befehl ans Display > übertragen. Das hat was mit Psychologie zu tun... Am Bedienterminal sitzen misstrauische Zeitnehmer, die verlieren das Vertrauen in die Uhr wenn die Anzeigen nicht übereinstimmen. Boris O. schrieb: > Du hast dir ja einen ganz schönen Stapel an Protokollen für recht wenig > Action angelacht. Bisher wurde die Uhr über Handy-Browser bedient und auf längeren Strecken mit nur einer Sekunde Auflösung eingesetzt. Jetzt kommt das elektronische Starten- und Stoppen dazu und die Auflösung muss 1/100'tel Sekunde sein. Aber UDP werde ich mir mal anschauen, die Genauigkeit muss ja auch nur so gut sein dass man es nicht sieht...
Rufus Τ. F. schrieb: > Wifi ist Netzwerk, und im Netzwerk gibt es das dafür seit langem > erprobte (S)NTP-Protokoll. Laut Wiki: NTPv4 kann die lokale Zeit eines Systems über das öffentliche Internet mit einer Genauigkeit von 10 Millisekunden halten, in lokalen Netzwerken sind unter idealen Bedingungen sogar Genauigkeiten von 200 Mikrosekunden und besser möglich. Das scheint ja tatsächlich brauchbar, da die Systeme nicht im Internet sind, müsste dann der raspberry der NTP "Stratum 0" Server sein. Das schaue ich mir auf jeden Fall mal näher an. Danke
Völlig falsches Konzept. das ist doch dann klar das sowas passiert. Wieso eine Stoppuhr die korrekte "absolute Zeit anzeigen" soll ist eh etwas rätselhaft. Was funktioniert; habe ich gebaut,: Eine "Steuerzentrale" mit NTP Zeit (Dein Raspi) In der Anzeige sitzt ein kleiner Controller welcher die Anzeige regelt und dieser bekommt via WIFI (UDP/TCP) einfach serielle Strings in denen die Daten zur Anzeige stehen. Das sind dann ein paar Byte und Du hast keine sichtbaren Differenzen...
Ich habe mir jetzt NTP angeschaut und ich denke das wird es. Den NTP server auf dem RPI habe ich schon entsprechend eingerichtet, SNTP client open source software für ESP8266 gibt es auch. Dazu werde ich die Start/Stop Zeit vom Terminal an das Display schicken und das Display wird mit seiner lokalen Zeit in 1/100'tel Sekunden die Zeit dazwischen anzeigen. Danke für die ganzen Vorschläge!
Christian K. schrieb: > Am Bedienterminal sitzen misstrauische Zeitnehmer, die verlieren das > Vertrauen in die Uhr wenn die Anzeigen nicht übereinstimmen Und du glaubst ernsthaft, die sehen einen Zeitunterschied von einigen Millisekunden? Und das noch wenn sie zwischen Terminal und Display hin- und herschauen müssen? Das ist doch reine Theorie und völlig unrealistisch. Es müsste schon jemand mit einer Kamera eine Aufnahme machen, auf der beides zu sehen ist, aber wer soll ausser dir so bescheuert sein? Georg
Wifi ist dem Thema voellig unangemessen. Da koennte Mann auch versuchen Atomuhren ueber GSM zu synchronisieren... 6 setzen.
P.S.:
1 | ntpd: sending query to 192.53.103.103 |
2 | ntpd: reply from 192.53.103.103: offset:-3.798570 delay:0.692222 status:0x24 strat:1 refid:0x00425450 rootdelay:0.000000 reach:0x01 |
3 | ntpd: sending query to 192.53.103.103 |
4 | ntpd: reply from 192.53.103.103: offset:-4.115222 delay:0.072047 status:0x24 strat:1 refid:0x00425450 rootdelay:0.000000 reach:0x03 |
5 | ntpd: sending query to 192.53.103.103 |
6 | ntpd: reply from 192.53.103.103: offset:-5.116167 delay:2.214129 status:0x24 strat:1 refid:0x00425450 rootdelay:0.000000 reach:0x07 |
7 | ntpd: sending query to 192.53.103.103 |
8 | ntpd: reply from 192.53.103.103: offset:-4.101902 delay:0.275046 status:0x24 strat:1 refid:0x00425450 rootdelay:0.000000 reach:0x0f |
9 | ntpd: sending query to 192.53.103.103 |
10 | ntpd: reply from 192.53.103.103: offset:-5.660306 delay:3.377152 status:0x24 strat:1 refid:0x00425450 rootdelay:0.000000 reach:0x1f |
11 | ntpd: sending query to 192.53.103.103 |
12 | ntpd: reply from 192.53.103.103: offset:-4.108971 delay:0.283374 status:0x24 strat:1 refid:0x00425450 rootdelay:0.000000 reach:0x3f |
13 | ntpd: setting time to 2018-05-27 18:45:35.107592 (offset -4.108971s) |
Christian K. schrieb: > SNTP client > open source software für ESP8266 gibt es auch. Aufpassen: die meisten machen kein echtes NTP ("Rücksprache" mit Laufzeitschätzung) sondern holen nur ein paarmal die Zeit. Bei mir 15 s Fehler. Wenn du eine Bibliothek hast, die es richtig macht, sag bitte Bescheid.
Info schrieb: > Aufpassen: die meisten machen kein echtes NTP Das "S" in SNTP steht für "simple" NTP, wie der eingangs verlinkte Wikipedia-Artikel auch erklärt.
Christian K. schrieb: > Am Bedienterminal sitzen misstrauische Zeitnehmer, die verlieren das > Vertrauen in die Uhr wenn die Anzeigen nicht übereinstimmen. Du glaubst doch nicht ernsthaft, daß jemand 10ms Unterschied erkennen kann und nach dem Stop stimmen doch die Zeiten. Man sollte nicht Probleme suchen, wo gar keine sind. Außerdem, welche Updaterate erlaubt überhaupt das Großdisplay? Ich würde für ergonomisches Ablesen nur alle 100ms updaten und während der Messung in der 10ms-Stelle eine "8" anzeigen.
Rufus Τ. F. schrieb: > Das "S" in SNTP steht für "simple" NTP, wie der eingangs verlinkte > Wikipedia-Artikel auch erklärt. Aufpassen: die meisten machen kein echtes SNTP.
Mal angenommen, du hast Uhren die exakt synchron laufen. Im WLAN sind Latenzen von einigen 100ms durchaus üblich, es sind sogar mehrere Sekunden möglich. Wie willst du das Start/Stop Signal so schnell übermitteln, dass niemand die Latenz bemerkt? Wenn eine Uhr 200ms zu spät startet oder zu spät stoppt, wird man das deutlich sehen. Auch wenn die Angezeigte Zeit trotzdem stimmt. Meinst du so eine Anzeige weckt Vertrauen? Bei mir jedenfalls nicht. Ich nehme an, es geht um einen Ort, an dem sich viele Menschen aufhalten werden. Viele Smartphones, die das Funknetz mit WLAN und Bluetooth zumüllen.
Stefanus F. schrieb: > die das Funknetz mit WLAN und Bluetooth zumüllen. Evtl. ist auf 5 GHz nicht so viel los, aber die erreichbare Entfernung geringer. Man sollte das mal gründlicher testen. Allerdings ist es ein Unterschied, ob man auf einer einsamen Insel oder einer gut besuchten Computermesse sich befindet.
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.