Fernbedienung für den Pinnenpilot - Teil 3

Nachdem letzten Winter der Nachbau einer Fernbedienung für einen Raymarine Pinnenpiloten erfolgreich war, erfolgte jetzt der Einbau ins Boot und die Implementierung einiger Erweiterungen. Da die Fernbedienung über den Seatalk1-Bus kommuniziert, fällt so nebenher auch eine kleine Brücke von Seatalk1 nach NMEA0183 ab. Die will ich nutzen, um die Datensätze des Tiefenmessers, der Logge und des Pinnenpiloten für Openplotter verfügbar zu machen.

Eine zweite Idee dehnt die Nutzung der Fernbedienung aus. Wenn schon fernbedient werden kann, warum dann nicht auch andere Dinge. Als erstes steht die Deckbeleuchtung auf dem Wunschzettel. Es wäre doch angenehm, wenn man Abends im Dunkeln zum Boot kommt und vom Steg aus schon die Deckbeleuchtung einschalten kann. Ein weiteres Einsatzszenario wäre ein Fernbedientes Nebel- bzw. Signalhorn. Einmal eingeschaltet, gibt es automatisch alle 2 Minuten einen langen Ton ab. Durch die Kopplung mit dem Tiefenmesser kann auch der Tiefenalarm über das Signalhorn erfolgen. Der im Tiefenmesser integrierte Alarm ist so leise, dass der bei Motorfahrt nicht zu hören ist. Allerdings hat die Fernbedienung nur 4 Tasten, die auch nicht kombiniert werden können. Pinnenpilot und andere Funktionen werden wohl voraussichtlich nicht parallel genutzt werden. Deshalb sollte die Steuerung erkennen ob der Pinnenpilot aktiv ist oder nicht.

 

Relaisplatine montiert

Da passt die Platine gerade noch rein

Aber der Reihe nach. Zunächst hat die Fernbedienung ein kleines Gehäuse bekommen und es wurde noch eine Relaisplatine mit 4 Relais angeschafft. Die Relaisplatine hat noch Platz im Verteilerkasten mit den Sicherungen gefunden. Zum Pinnenpiloten und zum Tiefenmesser wurden die entsprechenden Leitungen gezogen und angeschlossen. Dann erfolgte der erste Test mit nahezu unmodifizierter Software. Damit lief die Fernsteuerung des Pinnenpiloten auf Anhieb (das hatte ich im Winter ja schon testen können). Jetzt habe ich erst einmal die Software um eine „Dump-Routine“ erweitert, um mir anzusehen was alles an Datensätzen auf dem Seatalk1-Bus unterwegs ist. Hier ein Ausschnitt der Beute (hexadezimal):

18:11:15.065 -> 184 C6 6A 1F 2 0 20 0 4 !
18:11:15.580 -> 19C C1 2E 0 !
18:11:15.674 -> 120 F1 92 10 !
18:11:15.956 -> 104 F2 64 0 ?
18:11:16.096 -> 184 C6 6A 1F 2 0 0 0 4 !

Der Anfang eines Datensatzes ist immer am gesetzten 9. Bit erkennbar, deshalb sind in der ersten Spalte immer dreistellige Folgen, die mit „1“ beginnen. Danach kommt der Typ des Datensatzes (84, 9C, 20, …). Die Bedeutung der eigentlich nicht öffentlichen Details wurde entschlüsselt und kann hier nachgeschlagen werden. Auf dem Seatalk1-Bus senden mehrere Geräte gleichzeitig, deshalb kann es zu Kollisionen und fehlerhaften Datensätzen kommen. Die Dump-Routine überprüft die allgemeine Konsistenz und gibt am Ende ein Okay aus als „!“ oder einen Fehler als „?“. Aus den Daten konnte ich die Tiefe, die Logge und vom Pinnenpiloten den Magnetkompass und den gewünschten Kurs auslesen (bei Kurskorrekturen sogar den Ruderwinkel). Kompassdaten gibt es aber über GPS und den Lagesensor im Plotter wesentlich genauer, deshalb sind die nicht so interessant. Wie oben bereits erwähnt ist die aktuelle Betriebsart des Pinnenpiloten interessant und kann auch ausgelesen werden. Wirklich neu und im Plotter noch nicht bekannt ist die aktuelle Tiefe und die Fahrt durchs Wasser. Viel hilft viel dachte ich und habe dann entsprechende Auswerteprogramme für die Datensätze geschrieben mitsamt einer Umsetzung nach NMEA0183. Als ich das dann in Betrieb nehmen wollte, ging erst einmal gar nichts mehr im Pro Micro Controller. Nach vielen Versuchen stellte sich dann heraus, dass der Speicher wohl zu knapp bemessen ist und es Konflikte mit dem Pufferspeicher des Displays gibt obwohl der Compiler noch ausreichend Platz für Variablen ausgewiesen hat. Vermutlich alloziert das Display den Pufferspeicher dynamisch zur Laufzeit und prüft nicht ob Speicher frei ist – sehr befremdlich. Durch etliche Versuche habe ich herausgefunden, dass knapp 1.400 Bytes frei bleiben sollten. Das hieß aber wiederum, den Code zu kürzen und auf einige Auswertungen zu verzichten. Deshalb habe ich mich auf Tiefe und Pinnenpilotstatus konzentriert. Die Fahrt durchs Wasser wurde erst einmal auskommentiert. Notfalls werde ich das (kleine) Display außer Betrieb setzen und lieber mehr auswerten.

19:07:51.163 -> $IIDBT,0.5,f,0.2,M,0.1,F,*3b
19:07:51.364 -> $IIHDT,0.0,T*22
19:07:56.127 -> $IIDBT,0.0,f,0.0,M,0.0,F,*3d
19:07:57.384 -> $IIHDT,0.0,T*22
19:07:59.392 -> $IIHDT,0.0,T*22
19:07:59.994 -> $IIVHW,0.0,T,0.0,M,20.0,N,10.8,K*5e
19:08:02.402 -> $IIHDT,0.0,T*22

Nachdem die neuen Sensordaten vom Seatalk1-Bus jetzt als NMEA0183 am USB-Anschluss des Controllers anliegen, war noch die entsprechende Einbindung in Openplotter (Signal K) erforderlich – darin habe ich aber mittlerweile etwas Übung und nach kurzer Zeit wurden die Daten angezeigt. Spannend wird es noch einmal, wenn das Boot tatsächlich im Wasser liegt, da der Tiefenmesser im Trockenen keine sinnvollen Daten liefert.

Die automatische Umschaltung der Fernbedienungssignale auf die Relaisausgänge funktioniert auch wie gewünscht. Sobald der Pinnenpilot auf Standby geschaltet ist, werden die Signale auf die Relais gegeben. Nur verdrahten muss ich die Relaisausgänge noch und ein Signalhorn anschaffen. 

Hier das Zusammenspiel in einem kurzen Video (leider hat Google das Video so stark komprimiert, dass die Anzeigen kaum lesbar sind).

Das Hintergrundgeräusch ist die Dieselheizung, ohne die das Arbeiten im Boot nach dem aktuellen Wintereinbruch kaum möglich gewesen wäre - die Außentemperaturen liegen zwischen 2 und 6 Grad.

Peripherieprobleme mit dem neuen Kartenplotter

Da hatte ich hier so lapidar davon gesprochen, dass nur noch die Peripherie angeschlossen werden muss. Nun, dieser Beitrag würde nicht existieren wenn es einfach so funktionieren würde. Der alte Plotter läuft auf der Basis eines Raspberry Pi 3B+ und der neue Plotter verwendet das Compute-Modul CM3. Beide Prozessoren sind vergleichbar, das Compute-Modul ist nur etwas langsamer getaktet. Also hatte ich keine Probleme erwartet.

Ein Großteil der Peripherie hängt an einem USB-Hub (CSL - USB Hub 3.0, 7 Ports) mit eigener 12V / 3A Spannungsversorgung, damit die Spannungsversorgung des Raspberry Pi nicht überlastet wird. Extern angeschlossen sind folgende USB-Geräte:

• Tastatur mit Trackball
• Serielle Schnittstelle(NMEA0183) für Funkgerät
• Serielle Schnittstelle(NMEA0183) für Pinnenpilot
  
• Serielle Schnittstelle(NMEA0183) für Tochteranzeige Windmesser
• WLAN Adapter mit externem Antennenanschluss (Dootoper WiFi Adapter, 802.11 ac/n/g/b/a)
  
• Windmesser (Arduino Nano)
• DVB-T Stick, ein SDR zum Empfang von AIS

Also habe ich einfach den Hub an eine USB-Buchse des neuen Plotters angeschlossen und dachte, das war's. Leider Fehlanzeige. Die Tastatur wurde gar nicht erkannt (power cycle am Port) und beim DVB-T Stick und dem WLAN-Adapter blinkten die LEDs am Hub (leider schweigt die Hub-Beschreibung über die Bedeutung des Blinkens). Der WLAN-Adapter funktioniert und der DVB-T Stick funktioniert nur teilweise. Im neuen Plotter hatte ich am internen USB-Port noch einen Bluetooth-Stick (LogiLink BT0015) angeschlossen, über den ich mittels Bluetooth-Tastatur den Plotter wenigstens bedienen konnte. Der Plotter lief relativ instabil und "fror" zwischendurch einfach ein (war nicht bedienbar). CPU-Überlast bzw. -Überhitzung konnte ich ausschließen und ohne DVB-T Stick wurde es deutlich besser. Ich vermute daher den Flaschenhals auf dem USB-Bus, vielleicht mag der interne USB-Hub des Plotters die gesamte Peripherie nicht. Jetzt habe ich mich erst einmal entschlossen, den alten Plotter parallel weiter zu betreiben.

Der neue Plotter mit hellem Display ist vom Cockpit aus einsehbar und erhält erst einmal eine Minimalausstattung (WLAN-Stick, GPS-Maus, oeSENC-Dongle). Mit dem oeSENC-Dongle lassen sich die lizenzierten Karten anzeigen. Eigentlich sollte der Plotter in der Karte auch AIS-Daten anderer Schiffe anzeigen und über gesetzte Wegpunkte den Pinnenpiloten ansteuern. Die Winddaten wären auch nett gewesen, sind aber nicht unbedingt notwendig.

Auf beiden Plottern läuft eine Signal K Instanz von denen sich die Kartenanzeige (OpenCPN) jeweils die Daten holt. Warum also nicht beide Plotter vernetzen und auf den entfernten Signal K Server des alten Plotters auch zugreifen? Der alte Plotter diente mir in der Vergangenheit bereits als Access-Point (interner WLAN-Adapter des Pi), der war also bereits eingerichtet und der neue Plotter benötigte nur noch das Kennwort für das Bord-WLAN.

Nun hatte ich aber ein Zugriffsproblem. Beide Plotter sind im Boot an die Peripherie angeschlossen und können für Tests nicht einfach mit ins warme Haus genommen werden. Die Temperaturen in der Scheune und im Boot liegen aber derzeit im einstelligen Bereich, da ist konzentriertes Arbeiten schwierig. Die Dieselheizung läuft zwar wieder, der Geräuschpegel stört mich aber auf Dauer. Deshalb greife ich via VNC auf die Plotter zu und kann im warmen Büro am großen Bildschirm arbeiten. An den neuen Plotter (hinter dem Access-Point) komme ich von außerhalb des alten Plotters nicht heran, was auch so gewollt ist. In einem Hafen-WLAN sollte auch niemand auf meine lokalen Geräte zugreifen dürfen. Hier benötige ich aber einen Zugang und deshalb muss ich noch die Routing-Tabelle des alten Plotters erweitern.

sudo iptables -t nat -A PREROUTING -p tcp -i wlan0 \
    --dport 55900 -j DNAT --to-destination 10.10.10.102:5900
sudo iptables -t nat -A POSTROUTING -p tcp \
    --dport 5900 -j MASQUERADE

Damit wird der VNC-Port 5900 des neuen Plotters (IP-Adr. 10.10.10.102) auf dem Router über den Port 55900 abgebildet und ich kann die weitere Detailkonfiguration in Ruhe aus dem Büro vornehmen.

Neuer Plotter via VNC und Winddaten vom alten Plotter

So, das war heute viel Text ohne Bilder aber ich bin zufrieden mit dieser Lösung. Der Nachteil ist ein erhöhter Stromverbrauch durch zwei Plotter. Das Konzept mit einem Server für die Peripherie gefällt mir aber und wenn es trägt, wird aus dem Server mittelfristig ein Raspberry Pi ohne Bildschirm.