AvNav - neue Version 20220421

Die Packete in Repository sind aktualisiert.

Neue Image ist jetzt auch fertig und wurde hochgeladen

Changelog:

- Basiert auf Debian Bullseye

- Kernel 5.15.x

- AvNav Release 20220421

- SignalK 1.42 ( NodeJS 16)

Download: Link

im Openplotter ist ein Update über Openplotter vermutlich sinnvoller oder?

Und Andreas sind die Karten und alles z. B. diese Kartenlayer die wir zusammen eingebaut haben dann noch vorhanden oder muss ich die wieder neu einbauen genauso wie die Instrumenten Panele die ich modifiziert habe?

erstmal openplotter-avnav mit openplotter mitteln aktualisieren ( seit gestern ist 3.0.5 online)

Danach mit openplotter-avnav weitermachen

Zumindest so ist die Openplotter Logik

Backaup von $HOME/avnav ist immer wünschenswert

Kleine Ergänzung:

Image für arm64 Architektur ist jetzt auch verfügbar

Interessant vor allem für Besitzer von Raspis mit 4/8 GB RAM

Link: https://www.free-x.de/raspbian…4-23-avnav-arm64-lite.zip

Moin allerseits,

vorab einen großen Dank für das neue Update.

Leider entsteht wohl durch die neue Anbindung von AvNav an SignalK ein Problem mit der bisherigen Verknüpfung von AvNav zu Pypilot (Tinypilot-Version).

Bisher ist der Datenverkehr zu Pypilot über einen SocketWriter in AvNav und eine DataConnection in SignalK gelaufen, die über Port 28628 kommuniziert haben.

Nach dem Update kommt im SignalK-Dashboard zur Connection -ID "fromAvNav" nun die Fehlermeldung "connect ECONNREFUSED 127.0.0.1:28628"

Und so kommt nun in Pypilot keine Route mehr an....habvt ihr Ideen,. wie man das Problem beheben könnte?

Das Update habe ich über AvNav-Update eingespielt.

In der AvNav config habe ich nichts geändert.

Der SocketWriter ist eingerichtet auf Port 28628 wie vorher auch.

Das Problem ensteht m.E. in der Data-Connection im SignalK-Server. In den bisherigen AvNav-versionen sollte dort eine Data-Connection "from AvNav" eingerichtet werden als TCP-Client mit ebenfalls Port 28628. Diese Verbindung wird nun im SignalK-Servier zurückgewiesen.

Habe es nun hinbekommen, indem ich noch einmal von einem sauberen Image ausgegangen bin, das ich mir im Januar gebaut hatte.

Dort hat die Verbindung von Pypilot und AvNav über Port 28628 funktioniert.

Nach dem Update von AvNav und Pypilot auf die November21-Version sind offensichtlich zwei Dinge zusammen gekommen:

Auf Port 28628 überträgt AvNav zwar Daten, aber Pypilot mag sie nicht mehr nutzen, auch wenn der Port wie vorher auch auf 28628 eingestellt ist.

Wohl aber mag Pypilot den Standard-SignalK-Port 10110, wo die Daten von AvNav (APB) ebenfalls auflaufen. Mit diesem Port in Pypilot eingestellt läuft es nun.

Auffällig ist, dass die AvNav-Dataconnection "fromAvNav" in SignalK, die über Port 28628 Daten von AvNav abholt, eingeschaltet bleiben muss. Man könnte denken, dass AvNav eigentlich nun über seine direkte SignalK-Verbindung die Daten für APB sendet, aber Pypilot versteht diese nicht. Ich vermute, es liegt an der unetrschiedlichen Zuordnung zu den SignalK-Paths:

"fromAvNav":

navigation.courseRhumbline.bearingOriginToDestinationTrue

navigation.courseRhumbline.bearingToDestinationTrue

usw.

Die "direkte" SignalK-Verbindung:

navigation.courseGreatCircle.bearingTrackTrue

navigation.courseGreatCircle.nextPoint.bearingTrue

usw....

Unter Umständen "versteht" Pypilot die "courseGreatCircle"-Paths nicht. Die Werte sind identlisch.

Aber das ist nur eine vage Vermutung meinerseits, da stecke ich bei weitem nicht tief genug im Thema.

Ich versuche das mal zu verifizieren mit dem signalk-pathmapper-plugin. Damit müsste ich die SignalK-Paths umbiegen können und hätte ne Erklärung.

Habe mir ein wenig Zeit genommen zum Forschen...

Ergebnis: Die Übersetzung der SignalK-Paths ändert leider nichts. Pypilot erhält nur Kursdaten, wenn die SignalK-Dataconnection "fromAvav" per Port 28628 eingeschaltet ist.

Ich habe dann mal deinem Vorschlag folgend den Datenverkehr auf Port 10110 verfolgt. Dieser Port enthält m.W. alles an Daten, die der SignalK-Server in NMEA0183-Telegramme umwandeln kann. Mit dem Port arbeitet auch OpenCPN vorzugsweise.

Und siehe da, nur wenn in AvNav der Socketwriter für Port 28628 und im SignalK-Server die "fromAvanav"-Connection angeschaltet sind, tauchen APB-Telegramme im Datenstrom auf Port 10110 auf.

Schalte ich nur die "fromAvNav"-Connection ab, kommen keine APB-Telegramme mehr durch, obwohl alle relevanten Einstellungen zum Senden von Daten im neuen SignalK-Handler angeschaltet sind.

Für mich ist das so erstmal ok, aber wäre ja schon ne schöne Kleinigkeit, im SignalK-Server eine Connection einsparen zu können und alles direkt über die SignalK-Verbindung zu bekommen.

Wenn ich noch weitere Tests unternehmen soll, kann ich das gern machen. Sagt mit einfach, was ich wie tun soll. Auf meinem Schreibtisch zu Haus steht ein Test-Pypilot mit angeschlossenem UrAlt-Autohelm1000-Motor, ich muss also nicht immer erst zum Schiff, um das zu testen....

Quote from wellenvogel

(1) Du meintest ja, das pypilot keine Daten mehr direkt von AvNav empfangen kann... Hast Du das nochmal probiert?

Ja, das Verhalten, wenn man Pypilot auf Port 28628 stellt, ist folgendermaßen: Der Kurs zum Wegepunkt wird übernommen, aber der Modus springt zurück auf "Kompass" und bleibt nicht bei "GPS". Wenn man Pypiulot dann auf Port 10110 stellt, läuft es, wie es soll.

Quote from wellenvogel

(2) Wenn Du die NMEA Verbindung von AvNav zu SignaK trennst, dann müsste SignalK die APB selbst erzeugen - hast Du das dort (plugin) aktiviert?

Ja, das SignalK2NMEA0183-Plugin war durchgängig aktiviert und dort auch APB explizit zum Übersetzen angeschaltet. Trotzdem taucht im Datenfluss kein APB auf, siehe oben. Was ich noch nicht probiert habe, ist, Port 10110 zu checken, wenn ich in OpenCPN eine Route aktiviere. Die Variante funktioniert allerdings mit Pypilot ohne Probleme, ich gehe also davon aus, dass ich auf Port 10110 dann APB zu sehen kriege.

Quote from wellenvogel

Aber am Ende hast Du ja alle Optionen....

Pypilot direkt NMEA von AvNav, NMEA von AvNav über SK an pypilot oder NMEA von SK erzeugt zu pypilot.

Richtig, und mindestens eine funktioniert schon mal. Gibt ja hier ein paar Leute, die Pypilot auch nutzen, da ist es u.U. von Belang, dass die Zusammenarbeit mit AvNav gut funktioniert.

In OpenCPN ist das ne feine Geschichte durch das dortige Pypilot-PlugIn. So weit muss man ja gar nicht gehen. Aber auf einem System AvNav für die schöne Bedienung zu fahren und parallel OpenCPN, um von dort Routen mit dem Pyloten abzufahren, find ich suboptimal....

Moin Andreas wellenvogel

versuche gerade für einen Kollegen ein neues System mit Openplotter unhdf AvNav zusammen zu bauen. Auf verschiedenen Wegen kommt immer wieder diese Fehlermeldung bei der Installation von AvNav, egal ob über die Openplotter-App oder händisch:

>>Die folgenden Pakete haben unerfüllte Abhängigkeiten:

avnav-ocharts-plugin : Hängt ab von: avnav-ocharts soll aber nicht installiert werden

E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Failed to enable unit: Unit file avnav.service does not exist.

Failed to restart avnav.service: Unit avnav.service not found.

'/usr/lib/python3/dist-packages/openplotterAvnav/data/avnav-avahi.service' -> '/etc/avahi/services/avnav-avahi.service'

Failed to restart avnav.service: Unit avnav.service not found.<<

Folgende Installationswge sind wir gegangen:

1. neuestes Openplotter-Image geladen und versucht AvNav zu isntallieren

2. Nur neuestes Buster-Image geladen, danach Openpölotter-Settings händisch installiert, mit apt update vorbereitet, gleiche Fehler wie oben wieder...

Immer will der avnav.service nicht starten, weil nicht gefunden:

pi@raspberrypi:~ $ sudo systemctl enable avnav

Failed to enable unit: Unit file avnav.service does not exist.

Hast du eine Erklärung?

Moeritsen

Das liegt an geänderten Abhängigkeiten von avnav-ocharts-plugin. Probier mal jetzt mit

sudo apt update
sudo apt upgrade
bzw.
sudo apt install openplotter-avnav