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
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.
