Plotter Update Drama

Zugegeben, die Überschrift ist etwas reißerisch, aber ich habe mich ziemlich (auch über mich) geärgert und entsprechend viel Zeit in die Behebung investiert.

Mein Salon-Plotter (Raspi 5) ist eigentlich ein Server zum Zusammenführen der Bord-Daten und da der Rapberry-Pi aus historischen Gründen auch einen Bildschirm hat, gleichzeitig mein Reserver-Plotter. Der lief letzte Saison mit Debian 13 (Trixie) und mit einer Beta-Version von AvNav, während der eigentliche Cockpit-Plotter mit Debian 12 (Bookworm) und einer Release-Version von AvNav arbeitet. Das lief halbwegs während der (zu kurzen) Saison. Zurück im Winterlager habe ich dann versucht, ein Update beim Salon-Plotter einzuspielen, anschließend war die Benutzerführung geändert (das war aber im Segeln-Forum für die Beta angekündigt) und der WLAN-Client funktionierte nicht mehr. Letzteres war ziemlich unangenehm, da sich der Plotter damit im Winterlager in das heimische Netz verbindet und ich aus dem warmen Büro remote auf den Plotter mitsamt angeschlossener Peripherie zugreifen kann. Die Aussicht im ausgeräumten Boot bei zunehmend frischen Temperaturen den Plotter zu konfigurieren war wenig einladend, also muss der WLAN-Client als erstes wieder laufen. Da sich abzeichnete, dass das Problem mehr Zeit in Anspruch nimmt, habe ich mich für eine komplette Neuinstallation mit einer Release-Version von AvNav entschieden (also Bookworm statt Trixie), damit die Benutzerführung zwischen Cockpit und Salon gleich bleibt, außerdem befürchte ich, bei der Beta-Version u.U. mit weiteren Fehlern konfrontiert zu werden, die noch mehr Zeit kosten.

Also Image herunter geladen, SD-Karte geschrieben und die vorab gesicherten Einstellungen zurück gespielt. Dann das böse Erwachen – auch hier funktioniert der WLAN-Client nicht. Auffällig war, dass der USB-Pfad des Netzwerkadapters sich auch geändert hat. Der ist an einem externen Hub angeschlossen und es sah so aus, als ob es den Hub im System zwei mal gibt für einige Anschlüsse. Damit AvNav diesen Adapter als WLAN-Client konfiguriert, muss eine passende UDEV-Regel konfiguriert sein, die jetzt nicht mehr stimmte. Die Anpassung war schnell gemacht und damit wurde seitens AvNav der WLAN-Client wieder aktiv – aber leider immer nur für einige Sekunden oder manchmal auch Minuten. WLAN-Stick defekt? Nein, mit einem anderen WLAN-Stick trat das gleiche Verhalten auf. Zum Testen musste ich jedes mal ins Boot steigen, neu konfigurieren und im Büro dann feststellen, dass es wieder nur kurze Zeit funktionierte. Nach zweitägiger Suche fand ich dann den entscheidenden Hinweis bei Github. Die Ursache liegt in einer Änderung im Linux-Kernel, zwischen 6.11 und 6.12 scheint sich bzgl. USB3-Schnittstellen etwas geändert zu haben. Bisher war mein USB3-Hub auch an einem USB3-Port am Raspi 5 angeschlossen und der WLAN-Stick ist auch USB3-fähig (5.000 Mbit). Beim Kernel 6.11 wurden die angeschlossenen USB3-Geräte nur im USB2-Mode (480 Mbit) initialisiert und alles war bestens, jetzt existiert der USB3-Hub doppelt, einmal für USB2 und einmal für USB3 und die angeschlossenen Gerät werden entsprechend ihrer Kompatibilität zugewiesen. Deshalb die Änderung des USB-Pfads.

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M

USB3 ist eigentlich zu begrüßen, beim Raspi verursachen schnelle USB-Geräte aber WLAN- und Bluetooth-Störungen (bekannt von SSDs). Also müssen die USB3-Geräte auf den langsamen USB2-Modus gebracht werden. Beim aktuellen Kernel ist der Schnittstellen-Treiber „rtw_8822bu“ in der Version 27 integriert, auf Github ist aber die Version 30 verfügbar, die einen Schalter zum Beibehalten von USB2 enthält (switch_usb_mode). Eine Möglichkeit wäre, den Treiber per DKMS einzubinden und entsprechend zu konfigurieren (switch_usb_mode=n). Ich habe statt dessen den USB3-Hub beim Raspi 5 an einen USB2-Anschluss eingestöpselt. Danach musste ich zwar alle USB-Pfade in der Plottersoftware (AvNav, signal-k) neu konfigurieren, aber seit dem arbeitet der WLAN-Client wieder stabil.

Frischzellenkur für 10-Zoll Plotter

Vor kurzem ist es mir gelungen, ein Compute Module 4S (CM4S) zu erwerben. Das war in der Vergangenheit gar nicht so einfach, da diese Variante nur an Industriekunden verkauft wurde. Aber der Reihe nach. Mein alter Plotter auf Basis des Compute Module 3+ (CM3) hat mir gute Dienste geleistet, bis er zu träge wurde, da aktuelle Software immer mehr Ressourcen verlangt. Prinzipiell könnte man die Software auf einem alten Stand belassen, wäre da nicht die Anforderung, aktuelle Seekarten zu verwenden. Die Darstellung der Seekarten erfolgt über ein Software-Plugin des Kartenherstellers und der entwickelt Karten und Plugin ständig weiter, was dann eine Abhängigkeit zu aktuellen Betriebssystemen bedingt. 

Der Vorteil eines Compute Moduls ist, dass man es relativ leicht austauschen kann unter Beibehaltung der Basis-Platine. Das CM3 verwendet als Steckplatz das SODIMM-Format, welches seit einigen Jahren kaum noch verwendet wird und in der Beschaffung einen Engpass darstellt. Deshalb hat die Raspberry Pi Ltd das Format beim CM4 gewechselt auf ein anderes Steckformat. Um Industriekunden nicht zu verprellen, wurde dann noch der CM4S mit SODIMM-Anschluss verkauft, der für Endkunden aber nicht verfügbar war. 

Lange Rede, kurzer Sinn: Ich habe jetzt die Chance, den alten Plotter vom BCM2837 Prozessor mit 1GB RAM aufzurüsten zum BCM2711 quad-core 64-bit Cortex-A72 (Arm v8) bei 1.5GHz Takt mit 4GB RAM. Damit ist der Plotter wieder fit für aktuelle Software – dachte ich und der Beitrag könnte hier zu Ende sein. 

Den Plotter hatte ich seinerzeit mit Debian 9 (Stretch) und OpenCPN betrieben und später auf Debian 10 (Buster) aktualisiert und zum Schluss sogar mit Debian 11 (Bullseye) und AvNav betrieben. Mit dem CM4S und der Wiederbelebung erfolgte der Sprung nach Debian 13 (Trixie). In einer relativ steilen Lernkurve musste ich erfahren, dass sich einiges geändert hat: 

• Seit Debian 12 (Bookworm) gibt es diverse HDMI-Einstellungen in der Konfigurationsdatei (config.txt) nicht mehr. Statt dessen kann die Bildschirmauflösung in der cmdline.txt vorgegeben werden (video=HDMI-A-1:1280x800M@60D vc4.force_hotplug=1).
• Die Adressierung der GPIO-Anschlüsse wurde geändert (besser abstrahiert), die bisher verwendeten Bibliotheken zur Kommunikation mit der Hardware und den Tasten waren abgekündigt, so dass die Software zur Tastenemulation und zur Abschaltung des Plotters angepasst werden musste.
• Die Benutzeroberfläche wurde von X11 auf Wayland umgestellt, was zur Folge hatte, dass Software zur Mausansteuerung zwar noch lief, aber die Maus nicht angezeigt wurde. Auch hier waren Softwareanpassungen notwendig, da eine Umschaltung auf X11 für eine Fehlansteuerung des Bildschirms sorgte. Da die Gefahr bestand, den Bildschirm zu beschädigen, wurde Wayland beibehalten.
• Das CM4 und auch das CM4S deaktivieren standardmäßig den USB 2.0 Controller. Deshalb fiel das WLAN (per USB-Stick) immer nach wenigen Minuten aus, Bluetooth erkannte keine Geräte und die Touch-Funktion des Bildschirms fehlte. Es war nur möglich, mit einem USB 3.0 LAN Adapter auf den Plotter zuzugreifen. Es hat etwas gedauert, den magischen Befehl für die config.txt zu finden, um dieses Problem zu lösen: dtoverlay=dwc2,dr_mode=host
• Nach Aktivierung des USB 2.0 Controllers liefen WLAN sowie Bluetooth und die Hardware war angenehm performant (vorher wirkte sie überlastet). Die Touch-Funktion war weiterhin träge und hatte ein Eigenleben (Fenster öffneten sich selbstständig und schlossen sich auch wieder). Ursache waren diesmal keine Änderungen im Raspi OS, sondern der Service der Navigationssoftware AvNav mit der Eigenart, sich sämtliche seriellen (USB-)Schnittstellen zu schnappen und zu initialisieren. Dazu gehörte die Touch-Schnittstelle und nachdem ich AvNav angewiesen hatte, die Finger vom Touch zu lassen, funktionierte auch die Touch-Bedienung wie gewohnt.

Der Lohn der Mühe ist jetzt ein weiterer Plotter (auf der Reservebank) mit aktueller Software und ergonomischen Reaktionszeiten bei der Bedienung.

 Zwei kleine Baustellen sind offen, die aber keine Showstopper sind: 

• Beim Herunterfahren wird die Hintergrundbeleuchtung des Bildschirms nicht ausgeschaltet. Vermutlich noch ein Problem mit der GPIO-Ansteuerung.
• Wird die Maus per Tastatur bedient und ein Klick ausgelöst, passiert nichts. Vermutlich stimmen optische Mausposition und interne Mausposition nicht überein.

Ich bin gespannt wie sich der neue alte Plotter während der Saison schlägt.