Die nachfolgende Beschreibung wurde mit größter Sorgfalt erstellt. Trotzdem erfolgt der Nachbau auf eigene Gefahr und wir übernehmen weder Verantwortung noch Haftung für eventuell entstehende Schäden jedweder Art.

Einleitung

Januar 2013. Man sollte meinen ich hätte alle Möglichkeiten die PC-Unit zu ersetzen durch, aber nein - einen hab ich noch .

Es gab schon einmal einen WiFi Dongle, aber dieser unterstützt WebSockets, so dass man von jedem "neueren" Browser mit ihm kommunizieren kann. Und dann bräuchte man jede Software nur einmal schreiben und könnte sie mit PCs, Macs, SmartPhones und Tablets verwenden - einer für alle - halt. Und weil es auch noch meine vierter PC-Unit Ersatz ist, erklärt sich auch der Name recht schnell.

Warum WebSockets ?

Das einfachste wäre es CU/Rundenzähler mit einem Webserver zu verbinden. Diese verwenden als Protokoll HTTP. Für die reine Rundenzähleranbindung wäre das auch hinreichend, aber ich will natürlich mehr. Ich würde halt gerne auch die Bahndaten damit protokollieren können.

Bei einer normalen HTTP Anfrage wird jedesmal der Header mitübertragen, dass sind schon mal 250 bis 400 Byte. Und das ganze um dann eine Antwort von 20 Byte zu erhalten.

Bei einem PC als Webserver und Bildern im 100KB Bereich und Antwortzeiten um die halbe Sekunde ist das ganze nicht tragisch, aber ich möchte keinen PC, ich möchte einen Dongle und da sind 400 Byte bei 20 Nutz-Byte zusammen mit dem Verbindungsaufbau in 7.5 ms schon eher problematisch.

Man könnte theoretisch die Verbindung stehen lassen und die Daten pollen (zyklisch abfragen), was dann aber leider doch nicht geht, da sich zeigt, dass bei einigen Browsern eine Abfrage nur innerhalb der selben Domain statt finden darf. Eine andere Methode zum Abfragen der Daten ohne Cross-Domain-Probleme, schließt allerdings nach jeder Übertragung die Verbindung. Satz mit X.

Eine weitere Einschränkung ist, dass ich keinen offensichtlichen Weg gefunden habe Daten zu jeder Zeit in beide Richtungen zu übertragen, ohne jedesmal eine neue Verbindung aufzubauen.

WebSockets, so sie denn vom Browser unterstützt werden, haben diese Probleme nicht. Sie unterstützen Cross-Domains, haben nur einmal einen etwas längeren Header und benötigen danach bei jedem Packet nur 2 bzw. 6 zusätzliche Bytes je nach Datenrichtung und während die Verbindung besteht, können Daten in beide Richtungen übertragen werden und auf Browser Seite muss man nicht pollen, sondern wird über ein Events benachrichtigt, wenn Daten vorliegen.

Klingt ja schon mal ganz toll.

Umsetztung

Es gibt zwar verschiedene Embedded Webserver, aber ich habe keinen gefunden der WebSockets unterstützt. Also einen kaufen und neu programmieren oder etwas eigenes machen ?

Ich habe mir einen OpenPicus besorgt und die Änderungen für die Abfrage des Rundenzähler und die Datenübertragung mit HTTP waren sehr einfach zu realisieren. Eine Überprüfung der Resourcen ließen allerdings eine schnelle Beurteilung über die Komplexität des Hinzufügen des WebSocket Protokolls und des Lesens der Bahndaten nicht zu.

Also statt mich Stunden lang einzuarbeiten, habe ich einfach einen kleine Server entworfen. Als WiFi Modul habe ich das vom bLap Projekt verwendet.

Es hat grob eine Woche gedauert alles zusammenzubauen und die HTTP und WebSocket Protokolle zu implementieren. Funktioniert gut - allerdings kann das WiFi Modul nur eine Verbindung gleichzeitig aufrecht erhalten. Deshalb werde ich noch eine zweite Version mit einem anderen Modul, das bis zu 16 Verbindungen gleichzeitig erlaubt, bauen.

Und zum Schluss noch ein Gehäuse d gebaut und das Ganze sieht dann so aus:

Video

Es gibt auch ein Video, dass den vierten Musketier gemeinsam mit dem Lauscher im Einsatz zeigt.