Raspberry mit Openplotter und OpenCPN, Ais, GPS und Nmea

[Coal]

Zitat von Der mit dem Boot tanzt

Aber da viel es mit wieder ein

Wie gut dass es dit wieder einvalte.

[Der mit dem Boot tanzt]

Manchmal fällt mir viel ein

[CarCode]

Zitat von gninneh

Naja, nen richtigen seriellen Port hat heute wie du ja schon selbst schriebst auch kaum noch ein Rechner, also zumindest kein portabler, den man aufs Boot bauen würde. Und das CAN-Interface ist halt genauso ein USB-Gerät wie der USB-Seriell-Wandler auch. Oder halt beim Pi das Aufsteckboard. Ist nichts besonders anderes. Ok, die Hürde von 70€ (Korlan) bis 220€ (Peak) statt 7€ für nen USB-Seriell-Wandler ist schon etwas höher und da wird dann lieber auf 0183 zurückgegriffen.

Ich möchte jetzt nicht wie ein Oberlehrer auftreten und irgendwelche Weisheiten verkünden. Bekanntlich führen ja viele Wege nach Rom, wie man sagt.
Ich verwende jedoch schon seit mindestens über 10 Jahren Bluetooth zum Anschluß von diversen Datenquellen an den Laptop. Erstens weil ein Laptop ein Laptop bleiben sollte und nicht mit zig zusätzlichen Kabeln belastet und zweitens weil Bluetooth nicht die vor allem bei Windows üblichen Probleme mit USB/Seriell Treibern macht.
Bluetooth unterstützt über 20 (glaube ich) verschiedene Übertragungsprotokolle und so u.a. auch das sog. SPP (seriell port protocol). Es läuft auf allen bekannten Betriebssystemen und braucht nicht diese unseeligen Updates, die immer alles kaputt machen. Meine erste GPS Bluetooth Maus von vor über 10 Jahren funktioniert noch immer mit allen seit dem vorgekommenden Betriebssystemen und wurde inzwischen nur ersetzt, weil sie nur das US GPS konnte und noch nicht Glonass, Galileo etc. Sie hat ihren festen Platz im Boot, wo sie auch mit Strom versorgt werden kann, weil die eingebaute Batterie eben nur für einen Tag reicht. Dann kann ich den Laptop im Umkreis von gut 10 m mit mir herum tragen. AIS kommt bei mir vom UKW Seefunkgerät und ist ebenfalls über Bluetooth kabellos mit dem Laptop verbunden.
Denkbar wäre es, das auch über WiFi zu machen. Ich habe ja auch ein WLAN Netzwerk an Bord. Aber zur Zeit habe ich noch ein altes analoges Radar, für das es eh keine Lösung am Computer gibt. Erst wenn ich mal ein moderneres digitales Radar bekomme, das ja den Ethernetkabel Anschluß hat und auch weniger Strom verbraucht, werde ich über die Umrüstung auf WiFi für alle Geräte nachdenken.

[Tobaran]

So eine Bluetooth GPS Maus habe ich auch noch von Jentro. Da war ich zu Windows Zeiten sehr zufrieden mit. Allerdings wurden irgendwann keine Treiber mehr zur Verfügung gestellt. Und 10 Jahre mit einem alten Rechner- das ist etwas, was schlicht in der heutigen Zeit unrealistisch ist.

Ich hab am Raspberry einen USB Glonass GPS Empfänger (Ublox-7). Er läuft, könnte aber etwas genauer sein bei langsamer Fahrt.
Das hier
https://www.ebay.de/itm/193658125019 (PaidLink)

Wie man den aber umschaltet von Glonass auf GPS und ob das nötig ist und vor allem, was besser ist- keine Ahnung [emoji848]

[justme]

Moin moin,

Zitat von CarCode

Mir ist da leider keine OpenSource Software bekannt, die das kann. Grund ist: Die arbeiten alle noch mit NMEA0183 und noch nicht mit NMEA2000, weil es keinen Computer gibt, der direkt mit einem CAN Bus verbunden werden kann. NMEA2000 ist ja bekanntlich CAN. Das alte und immer noch weit verbreitete NMEA0183 ist ja seriell, genauer RS422, das problemlos auch mit RS232 verbindet, dem üblichen seriellen Protokoll bei Computern. Da man heute kaum noch Computer mit dem 9-poligen RS232 Stecker findet, wird allgemein ein sogenannter virtueller COM-Port verwendet, der von den bekannten USB/Seriell Adaptern geliefert wird.
Man müßte also noch einen weiteren Adapter haben, der die Umsetzung auf CAN macht.

der Grund dafür, daß das nicht geht ist idR ein anderer - CAN-Interfaces gibt es diverse, speziell für den Bootsbereich als NMEA2k z.B. fix und fertig von YachtDevices.
Speziell die Funktion, ein über AIS identifiziertes Ziel mit einem DSC-Funkanruf vom Plotter aus initiiert anzurufen ist aber proprietär bei den einzelnen Herstellern implementiert - das funktioniert noch nicht mal zwischen echten Plottern und Funkgeräten unterschiedlicher Hersteller (sprich, an einem Garmin-Plotter kann man das mit einem Garmin-VHF machen, mit einem ICOM-VHF dagegen nicht).

lg, justme

[CarCode]

Zitat von Tobaran

So eine Bluetooth GPS Maus habe ich auch noch von Jentro. Da war ich zu Windows Zeiten sehr zufrieden mit. Allerdings wurden irgendwann keine Treiber mehr zur Verfügung gestellt. Und 10 Jahre mit einem alten Rechner- das ist etwas, was schlicht in der heutigen Zeit unrealistisch ist.

Ich hab am Raspberry einen USB Glonass GPS Empfänger (Ublox-7). Er läuft, könnte aber etwas genauer sein bei langsamer Fahrt.
Das hier
https://www.ebay.de/itm/193658125019 (PaidLink)

Wie man den aber umschaltet von Glonass auf GPS und ob das nötig ist und vor allem, was besser ist- keine Ahnung [emoji848]

Für Bluetooth gibt es keine Treiber. Das Betriebssystem muß lediglich einen sogenannten Bluetooth Stack haben. Das heißt, der Rechner hat also Bluetooth Hardware an Bord und natürlich die entsprechende Software zur Ansteuerung, genannt Stack, keine Treiber.
Wenn Du die richtige Navi-Software verwendest, muß Du nichts umschalten. Wenn Dein GPS auch Glonass unterstützt, wird automatisch zwischen beiden Systemen umgeschaltet. Siehe die Bilder auf dem Beitrag #25.
https://www.boote-forum.de/showthrea...5&#post5107395
Die Genauigkeit hängt auch nicht von Deiner Fahrtgechwindigkeit ab. Es gibt jedoch GPS Mäuse, die für den Kfz Bereich gedacht sind und diese schalten automatisch ab, wenn das Auto steht. Für ein Boot also vollkommen ungeeignet.

[CarCode]

Zitat von justme

Moin moin,
der Grund dafür, daß das nicht geht ist idR ein anderer - CAN-Interfaces gibt es diverse, speziell für den Bootsbereich als NMEA2k z.B. fix und fertig von YachtDevices.
Speziell die Funktion, ein über AIS identifiziertes Ziel mit einem DSC-Funkanruf vom Plotter aus initiiert anzurufen ist aber proprietär bei den einzelnen Herstellern implementiert - das funktioniert noch nicht mal zwischen echten Plottern und Funkgeräten unterschiedlicher Hersteller (sprich, an einem Garmin-Plotter kann man das mit einem Garmin-VHF machen, mit einem ICOM-VHF dagegen nicht).
lg, justme

Da muß ich Dir leider widersprechen, das stimmt so nicht. Propriertär ist nur deren Software und sonst nichts. Der empfangene AIS Datensatz enthält auch die MMSI Nummer und die wird verwendet, um über DSC anzurufen. Also kein Hexenwerk.
Problem ist nur, daß die freie Software wie OpenCPN auf dem installierten Rechner zusätzlich ein CAN Bus Interface braucht, um das Seefunk Gerät ansprechen zu können. Richtig ist, daß es viele solcher Interfaces gibt, die aber alle nur einen fest programmierten Satz an PGNs haben. Die Umsetzung NMEA0183/NMEA2K geht daher nur teilweise. Da sich nun die freien Software Programmierer bisher nicht auf ein Interface festlegen konnten, gibt es das also bisher nicht. Zudem ist es auch etwas komplexer, da man ja ein jungfräuliches CAN Interface nehmen müßte, weil wie gesagt die am Markt befindlichen nur einen eingeschränkten PGN Satz können.

[Sigi S.]

Zitat von CarCode

Da muß ich Dir leider widersprechen, das stimmt so nicht. Propriertär ist nur deren Software und sonst nichts. Der empfangene AIS Datensatz enthält auch die MMSI Nummer und die wird verwendet, um über DSC anzurufen. Also kein Hexenwerk.
Problem ist nur, daß die freie Software wie OpenCPN auf dem installierten Rechner zusätzlich ein CAN Bus Interface braucht, um das Seefunk Gerät ansprechen zu können. Richtig ist, daß es viele solcher Interfaces gibt, die aber alle nur einen fest programmierten Satz an PGNs haben. Die Umsetzung NMEA0183/NMEA2K geht daher nur teilweise. Da sich nun die freien Software Programmierer bisher nicht auf ein Interface festlegen konnten, gibt es das also bisher nicht. Zudem ist es auch etwas komplexer, da man ja ein jungfräuliches CAN Interface nehmen müßte, weil wie gesagt die am Markt befindlichen nur einen eingeschränkten PGN Satz können.

Deshalb verwende ich auch das Actisense Gateway, weil es ein gewisser Standard bei NMEA2000 ist, das Protokoll offen liegt und somit für jeden Programmierer/Entwickler leicht ist, NMEA2000 einzubinden.
Damit werden auch die eigenen Projekte NMEA2000 zertifiziert.

Habe mit OpenSkipper, das auch auf das Actisence Protokoll setzt, ein komplettes Instrumentendisplay für Motoren und vielen anderen Daten erstellt.
Bei OpenSkipper kann man sich nicht vorhandene PGN Datensätze selbst dazuprogrammieren (C#)

[Der mit dem Boot tanzt]

Habe mir das nochmal angeschaut. Ich glaube Justme hat da recht. Bei den N2K gibt es standardisierte Telegramme für die AIS Daten. Also jeder Plotter bekommt von jedem AIS die Daten auch mit der MMSI. Möchte ich jetzt ein selektiv Ruf machen muss die MMSI aber ja ins Funkgerät. Und da gibt es keine Standards im N2K für. Da nutzen die Hersteller dann ihre im Standard vorgesehen Hersteller eigenen Telegramme für.
Da mussten dann in der Open Software wie beim Radar unterschiedliche Bibliotheken eingeführt werden, wenn die Telegramme mal geknackt sind.

[justme]

Moin moin,

Zitat von CarCode

Da muß ich Dir leider widersprechen, das stimmt so nicht. Propriertär ist nur deren Software und sonst nichts. Der empfangene AIS Datensatz enthält auch die MMSI Nummer und die wird verwendet, um über DSC anzurufen. Also kein Hexenwerk.
Problem ist nur, daß die freie Software wie OpenCPN auf dem installierten Rechner zusätzlich ein CAN Bus Interface braucht, um das Seefunk Gerät ansprechen zu können. Richtig ist, daß es viele solcher Interfaces gibt, die aber alle nur einen fest programmierten Satz an PGNs haben. Die Umsetzung NMEA0183/NMEA2K geht daher nur teilweise. Da sich nun die freien Software Programmierer bisher nicht auf ein Interface festlegen konnten, gibt es das also bisher nicht. Zudem ist es auch etwas komplexer, da man ja ein jungfräuliches CAN Interface nehmen müßte, weil wie gesagt die am Markt befindlichen nur einen eingeschränkten PGN Satz können.

dann solltest Du Dir das nochmal etwas genauer anschauen - die Funktion, einen DSC-Call von extern auszulösen ist im NMEA2k-Standard genau nicht spezifiziert (im Gegensatz zur Übermittlung der empfangenen MMSI aus AIS- oder DSC-Emergency-Calls). Da kocht jeder Hersteller mit proprietären Erweiterungen sein eigenes Süppchen, weshalb das grundsätzlich nur zwischen Geräten eines Herstellers funktioniert. Man könnte die entsprechenden Herstellerspezifischen Funktionen jetzt in einer OpenSource-Lösung nachbauen, was aber vermutlich an mangelnder Dokumentation derartiger Funktionen scheitern dürfte - gerade solche Funktionen will man idR nicht per Reverse Engineering realisieren.

Und welche PGNs man mit einem NMEA2k-Interface sendet hängt in allererster Line davon ab, welche Software man auf dem PC laufen läßt. Was Du beschreibst sind eher Wandler für festgelegte Werte, die haben dann natürlich nur einen funktionsabhängigen eingeschränkten Satz an PGNs verfügbar. Man muß aber nicht gleich ein Vector CANoe verwenden, wenn man mehr machen möchte...

lg, justme

[Sigi S.]

Doch! mit PGN 129808 (DSC Callinformation) ist alles enthalten um einen Ruf auszulösen

https://www.nmea.org/Assets/20130720...ndum%20v1..pdf

[CarCode]

Zitat von Sigi S.

Deshalb verwende ich auch das Actisense Gateway, weil es ein gewisser Standard bei NMEA2000 ist, das Protokoll offen liegt und somit für jeden Programmierer/Entwickler leicht ist, NMEA2000 einzubinden.
Damit werden auch die eigenen Projekte NMEA2000 zertifiziert.

Habe mit OpenSkipper, das auch auf das Actisence Protokoll setzt, ein komplettes Instrumentendisplay für Motoren und vielen anderen Daten erstellt.
Bei OpenSkipper kann man sich nicht vorhandene PGN Datensätze selbst dazuprogrammieren (C#)

Du wirfst hier einiges durcheinander. Diese Interfaces haben alle einen fest programmierten Satz an PGNs, die einen mehr, die anderen weniger. Es gibt einen NMEA2000 Standard, aber kein Interface, das bei NMEA2000 Standard sein sollte. Es gibt auch kein "Actisence Protokoll", das ist ein programmierter Chip, der die beiden Welten übersetzt. Das Protokoll ist CAN und das kann auch ein Chip wie der ELM329. Eigene Projekte für NMEA2000 zu zertifizieren geht schon mal überhaupt nicht, wenn Du nicht das nötige Kleingeld hast. Selbst die Dokumentation für NMEA2k kann schon kaum jemand bezahlen. Eigene PGN Datensätze zu erfinden ist auch illusorisch.
Unterhalte Dich bitte mal mit einem Programmierer, der auf diesem Gebiet arbeitet. Mit Halbwissen kann man schnell an irgendwelche Grenzen kommen.

[Sigi S.]

Zitat von CarCode

Du wirfst hier einiges durcheinander. Diese Interfaces haben alle einen fest programmierten Satz an PGNs, die einen mehr, die anderen weniger. Es gibt einen NMEA2000 Standard, aber kein Interface, das bei NMEA2000 Standard sein sollte. Es gibt auch kein "Actisence Protokoll", das ist ein programmierter Chip, der die beiden Welten übersetzt. Das Protokoll ist CAN und das kann auch ein Chip wie der ELM329. Eigene Projekte für NMEA2000 zu zertifizieren geht schon mal überhaupt nicht, wenn Du nicht das nötige Kleingeld hast. Selbst die Dokumentation für NMEA2k kann schon kaum jemand bezahlen. Eigene PGN Datensätze zu erfinden ist auch illusorisch.
Unterhalte Dich bitte mal mit einem Programmierer, der auf diesem Gebiet arbeitet. Mit Halbwissen kann man schnell an irgendwelche Grenzen kommen.

Nein, da bringe ich nichts durcheinander!
Das Actisence z.b. macht die komplette NMEA2000 Anmeldung (ISO-AdressClaim) selbstständig und konform.
Dann ist das Gateway still und wartet auf selbst generierte Datensätze im Actisence Protokoll und empfängt auch umgekehrt.
Ich habe schon viele NMEA2000 Sachen für diese Gateways Programmiert.

Hab hier schon mal ein Tool für die Kalibrierung von Bennett Trimklappen veröffenlicht, das mit proprietären PGN´s arbeitet und komisch... ich kann sie durchreichen

Warum sollen eigene Projekte nicht zertifiziert werden können? und die Dokus kosten Geld, aber das war es mir wert
Eigene PGN´s braucht nicht zu erfinden, es gibt ja schon fast alles und für Vorschläge ist die NMEA auch offen.

[justme]

Moin moin,

Zitat von Sigi S.

Doch! mit PGN 129808 (DSC Callinformation) ist alles enthalten um einen Ruf auszulösen

https://www.nmea.org/Assets/20130720...ndum%20v1..pdf

diese PGN könnte das zwar vermutlich theoretisch, aber die wird praktisch offenbar von allen Herstellern nur für die gegenteilige Richtung verwendet - damit kriegen Plotter, Drucker, etc. die Daten eines vom Funkgerät empfangenen DSC-Anrufs. Die gesamte PGN scheint eher auch nicht vollumfänglich und sicher von Anfang an spezifiziert gewesen zu sein (meine Vermutung: die sollte ursprünglich nur für Distress Alerts tun), wie man an den mehreren dafür nachgereichten Corrigenda sieht. In der Praxis haben das offenbar alle Hersteller mit proprietären PGNs realisiert, der Entwickler von CANboat hat da wohl einiges schon eingebaut.

lg, justme

[Sigi S.]

Wenn ich mal wieder aufs Boot darf, mache ich einen Log der Kommunikation zwischen meinen Plottern (Simrad Evo3/ Lowrance HDS) und dem Link8 und poste das dann hier

[justme]

Moin moin,

Zitat von Sigi S.

Wenn ich mal wieder aufs Boot darf, mache ich einen Log der Kommunikation zwischen meinen Plottern (Simrad Evo3/ Lowrance HDS) und dem Link8 und poste das dann hier

das wär echt mal interessant. Hast Du evtl. auch noch eine Möglichkeit, sowas mal bei einer Garmin-Kombination zu machen? Ich glaub ich muß mir doch noch mal eine J1939-Lizenz für mein CANoe besorgen... ich hab eigentlich alles da, was man zum CAN-Bus-loggen und simulieren bräuchte, bis auf die Erweiterungslizenz.

lg, justme

[Sigi S.]

Zitat von justme

Moin moin,
das wär echt mal interessant. Hast Du evtl. auch noch eine Möglichkeit, sowas mal bei einer Garmin-Kombination zu machen? Ich glaub ich muß mir doch noch mal eine J1939-Lizenz für mein CANoe besorgen... ich hab eigentlich alles da, was man zum CAN-Bus-loggen und simulieren bräuchte, bis auf die Erweiterungslizenz.

lg, justme

Leider nicht, monentan habe ich an Geräten nur Simrad, Lowrance, B&G, Raymarine, C-Zone, Fusion und Navman da.

[justme]

Moin moin,

Zitat von Sigi S.

Leider nicht, monentan habe ich an Geräten nur Simrad, Lowrance, B&G, Raymarine, C-Zone, Fusion und Navman da.

hättest Du einen Raymarine-Plotter? In den Datenblättern der Ray-VHFs ist PGN 129808 auch immer nur als 'Send' aufgeführt, die Funktion können die, wenn sie an einem Lighthouse-MFD hängen allerdings auch.

lg, justme, auch nur mit Navico-Komponenten unterwegs.

[Sigi S.]

Öhm jo

Raymarine nicht im Boot, nur auf der Teststation, da aber wiederrum keinen Funk, aber das lässt sich ja schnell simulieren wenn ich den Log habe

[Tobaran]

Zitat von CarCode

Für Bluetooth gibt es keine Treiber. Das Betriebssystem muß lediglich einen sogenannten Bluetooth Stack haben. Das heißt, der Rechner hat also Bluetooth Hardware an Bord und natürlich die entsprechende Software zur Ansteuerung, genannt Stack, keine Treiber.
Wenn Du die richtige Navi-Software verwendest, muß Du nichts umschalten. Wenn Dein GPS auch Glonass unterstützt, wird automatisch zwischen beiden Systemen umgeschaltet. Siehe die Bilder auf dem Beitrag #25.
https://www.boote-forum.de/showthrea...5&#post5107395
Die Genauigkeit hängt auch nicht von Deiner Fahrtgechwindigkeit ab. Es gibt jedoch GPS Mäuse, die für den Kfz Bereich gedacht sind und diese schalten automatisch ab, wenn das Auto steht. Für ein Boot also vollkommen ungeeignet.

Die richtige Navi Software? Naja, Open CPN eben.
Also Du sagst, ich muss den genannten Gps Empfänger nicht umschalten?

Das heisst, die Systeme GPS und Glonass sind kompatibel? An dem Beitrag 25 kann ich nicht wirklich erkennen, wie da was umgeschaltet wird. Da fehlen mir die Hintergrund Kenntnisse für. Die Protokolle die dort im Bild sind, heißt das dass das grundsätzlich von jedem empfangenem Datensatz pauschal verwertet wird, egal ob Glonass oder GPS?

Du sagst Empfänger fürs Fahrzeug - woher weiss ich das, ist ja nur ein kleiner USB Stecker ?

Wenn ein externes GPS (speziell Marine) da besser ist, dann besteht für mich die Folge-Frage ob man dies direkt auf einem Raspberry anschliessen kann. Ich vermute mal, das ist möglich - über das interne IO Interface?

[stenner]

Zitat von Tobaran

Wenn ein externes GPS (speziell Marine) da besser ist, dann besteht für mich die Folge-Frage ob man dies direkt auf einem Raspberry anschliessen kann. Ich vermute mal, das ist möglich - über das interne IO Interface?

Warum nicht per USB? Z.B so ein Empfänger von Navilock? Einstecken und geht:

stenner@columbus:~ $ lsusb 
....
Bus 001 Device 003: ID 1546:01a8 U-Blox AG [u-blox 8]

Er nutzt GPS, GLONASS, BEIDOU, GALILEO. OpenCPN nutzt ihn entweder direkt (/dev/TTY*) oder per gpsd (meine Lösung), dann kriegt auch mein Link8 per ShipModul Miniplex die GPS-Daten.

[CarCode]

Zitat von stenner

Warum nicht per USB? Z.B so ein Empfänger von Navilock? Einstecken und geht:

stenner@columbus:~ $ lsusb 
....
Bus 001 Device 003: ID 1546:01a8 U-Blox AG [u-blox 8]

Er nutzt GPS, GLONASS, BEIDOU, GALILEO. OpenCPN nutzt ihn entweder direkt (/dev/TTY*) oder per gpsd (meine Lösung), dann kriegt auch mein Link8 per ShipModul Miniplex die GPS-Daten.

Stimmt, wenn Du gpsd verwendest, kannst Du mehrere Geräte mit den GPS Daten versorgen. Bei USB oder serieller Verbindung geht immer nur ein Gerät.

[CarCode]

Zitat von Tobaran

Die richtige Navi Software? Naja, Open CPN eben.
Also Du sagst, ich muss den genannten Gps Empfänger nicht umschalten?

Das heisst, die Systeme GPS und Glonass sind kompatibel? An dem Beitrag 25 kann ich nicht wirklich erkennen, wie da was umgeschaltet wird. Da fehlen mir die Hintergrund Kenntnisse für. Die Protokolle die dort im Bild sind, heißt das dass das grundsätzlich von jedem empfangenem Datensatz pauschal verwertet wird, egal ob Glonass oder GPS?

Du sagst Empfänger fürs Fahrzeug - woher weiss ich das, ist ja nur ein kleiner USB Stecker ?

Wenn ein externes GPS (speziell Marine) da besser ist, dann besteht für mich die Folge-Frage ob man dies direkt auf einem Raspberry anschliessen kann. Ich vermute mal, das ist möglich - über das interne IO Interface?

Neuere GPS Empfänger können eben mehrere Systeme empfangen. Umgeschaltet wird da nichts, das geht bei diesen Dingern automatisch und die Sequenz GSV zeigt Dir an, welches System gerade verwendet wird.
Welche GPS Empfänger genau das sind, die nur für Kfz vorgesehen sind, müßte ich mal nachsehen. Ich hatte damals nur Berichte darüber gesehen, die das automatische Abschalten des Empfängers beschrieben, wenn der Empfänger nicht bewegt wird, und erneut senden, wenn das Fahrzeug wieder Fahrt aufnimmt. Im übrigen senden fast alle GPS Mäuse im alten NMEA0183 Protokoll, sind also vom Menschen lesbar. Die Mäuse mit USB Stecker haben dann noch einen Adapterchip der von seriell nach USB wandelt entweder von Prolific, von FTDI oder anderen Firmen.
Ich arbeite mit Apple Laptops (MacBook Pro) und kenne daher Raspberry nicht. Ich würde aber vermuten, daß man daran sowohl Geräte mit USB als auch mit Seriell anschließen kann.

[CarCode]

Zitat von Sigi S.

Nein, da bringe ich nichts durcheinander!
Das Actisence z.b. macht die komplette NMEA2000 Anmeldung (ISO-AdressClaim) selbstständig und konform.
Dann ist das Gateway still und wartet auf selbst generierte Datensätze im Actisence Protokoll und empfängt auch umgekehrt.
Ich habe schon viele NMEA2000 Sachen für diese Gateways Programmiert.

Hab hier schon mal ein Tool für die Kalibrierung von Bennett Trimklappen veröffenlicht, das mit proprietären PGN´s arbeitet und komisch... ich kann sie durchreichen

Warum sollen eigene Projekte nicht zertifiziert werden können? und die Dokus kosten Geld, aber das war es mir wert
Eigene PGN´s braucht nicht zu erfinden, es gibt ja schon fast alles und für Vorschläge ist die NMEA auch offen.

Ich bin ja schon einige Zeit im Ruhestand und weiß daher nur noch, was früher mein Geschäft war, nämlich auf Grundlage von SAE J1939 Diagnose Interfaces herzustellen. Für die zugehörige Software hatte ich einige Programmierer beschäftigt. Früher konnte sich jeder dafür vorgesehene Chip mit dem CAN Netzwerk verbinden und handelte seinen Platz im Bus dann selber aus. Ich denke, da wird sich wohl nicht viel verändert haben. Es gibt allerdings verschiedene CAN Protokolle, solche mit 11 Bit, solche mit 29 Bit und auch mit unterschiedlicher Geschwindigkeit. Das können Chips wie z.B. ELM329 dann auch selbstständig aushandeln, ohne daß jemand irgendwas programmieren muß.
Wenn Du nun irgendwas zertifizieren möchtest, solltest Du erstmal wissen, wer zertifiziert und was zertifiziert werden soll. Wenn Du Mitglied im NMEA Gremium bist, bekommst Du die Standards zwar geringfügig preiswerter, zahlst dafür aber einen saftigen Jahresbeitrag. Dann steht es Dir auch frei, Vorschläge für eigene PGN dort zu machen.
Spannend wird es, wenn wir mal einen Mitschnitt aus dem CAN Protokoll zu sehen bekämen, wo z.B. ein VHF zur Verbindungsaufnahme mit einer bestimmten MMSI aufgefordert wird.
Übrigens mein Nickname CarCode stammt noch von meiner alten Firma.

[justme]

Moin moin,

Zitat von CarCode

Wenn Du nun irgendwas zertifizieren möchtest, solltest Du erstmal wissen, wer zertifiziert und was zertifiziert werden soll. Wenn Du Mitglied im NMEA Gremium bist, bekommst Du die Standards zwar geringfügig preiswerter, zahlst dafür aber einen saftigen Jahresbeitrag. Dann steht es Dir auch frei, Vorschläge für eigene PGN dort zu machen.

dann weißt Du aber sicher auch noch, was Bestandteil der NMEA2k-Zertifizierung ist:

What does NMEA2000® CERTIFIED mean?
NMEA 2000® Certified means that the product has been tested to meet specific critical safety criteria and to correctly implement network management and messaging. A product is not certified until NMEA verifies the test results.
Certification involves a suite of more than 100 tests that a product must pass, including but not limited to;

- Priority Messaging, so the highest priority message always gets through
- Auto Addressing, plug and unplug products without network interference
- Product Information, understanding of products on the network
- EMI and Noise Immunity Requirements,
- Electrical Isolation, assures that products do not disrupt the network

Why is certification important? It provides the dealer and end user a level of assurance that NMEA 2000 Certified products will all integrate (behave) together on an NMEA 2000 network. NMEA 2000 Certified products are listed on the NMEA website.

NMEA does not test for data. That means we do not test whether or not product ABC will actually see data from product XYZ. The testing verifies that they will work together, what they will actually transmit or receive in terms of data is up to the manufacturers.

Was für PGNs man sendet oder ob man da eigene PGNs im Netzwerk verwendet interessiert für die Zertifizierung überhaupt nicht, das ist der Nutzdatentransport.
Mal davon ab, daß man die Zertifizierung auch weglassen kann und sein Produkt dann einfach als 'NMEA compliant' oder 'compatible' verkaufen kann. Wenn man ein zugelassenes Diagnose-Interface bauen will sieht das natürlich ganz anders aus - insbesondere wenn das dann auch noch KFZ-Anforderungen und womöglich UDS als Diagnoseprotokoll implementieren soll, da gibt es dann u.U. deutlich weitergehende Anforderungen.

lg, justme