Onderwerp: OpenCPN op een Raspberry 3 installeren - hoe?

Je kunt je de AIS direct aansluiten in OpenCPN. Beter is het om in OpenPlotter de NMEA multiplexer te gebruiken. Die het weer doorgeeft aan OpenCPN met eventuele andere "talkers".

Gewoon nieuwe verbinding toevoegen, naam geven en de baudrate. De ttyUSB verschijnt vanzelf.

Het kan met USB, maar beter is het om de serieele verbinding te gebruiken. Meestal een Langzame NMEA of een snelle NMEA. Daar moet dan nog een serieel/usb omvormer tussen.

Is meestal een kabeltje of een verloop stekkertje met een klein boardje ingebouwd.

brambo schreef :
Waarom is dat beter, Bram? Als je niet hoeft te multiplexen (of je hebt al een gemuxte stream) en alles wat je wilt is AIS en GPS, dan is OpenCPN meer dan voldoende.

brambo schreef :

Dankje, heb deze post ook (net) gelezen. Het lijkt dus "nog niet helemaal af" te zijn, althans niet geintegreerd in de functionaliteit zoals je (ook dit) in juist de OpenPlotter toevoegingen verwacht.

Ben bekend met CANboat - gebruik ik intensief bij PolarPlot. Blijkbaar is er nu wel een driver die de NGT-1 data aanbiedt/vraagt via de socketCAN standard in Linux. Dat is natuurlijk mooi.

Maar hoe wil OpenCPN de data nu aangeboden krijgen eigenlijk?? Ik begrijp dat Signal-K of de OpenPlotter add-ons een soort extra schil om OpenCPN vormen om verschillende databronnen en multiplexing te verzorgen?

Een socketCAN binaire stream is met wat pipes en std Linux socketCAN tools en tools uit het CANboat project in principe om te zetten naar een NMEA steam:
Kan OpenCPN hier direct mee overweg?

Een flowchart zou wel handig zijn om de architectuur zichtbaar te maken. Heeft iemand zoiets gezien, ben dus benieuwd hoe de datastromen eruit zien in een OpenPlotter systeem.

OpenCPN kan alleen overweg met de NMEA0183 stream

Voor zover ik heb kunnen ontdekken is openplotter alleen een grafische schil om de benodigde instellingen en configuraties te doen voor de onderliggende programma's.

Een Actisense NGT-1 is toch een interface tussen nmea 2000 en 0183. Er komt toch nmea 0183 aan de USB zijde uit ? OpenCpn ziet dat als een seriële poort waar data uitkomt. In hoe ver je er ook data heen kunt sturen is me onduidelijk.

3Noreen schreef : Nee dat is de NGW die vertaald naar nmea0183, de NGT maakt van Can/NMEA2000 er seriële data van.

Zeilprutser schreef :
Lekker vaag. nmea0183 zijn toch ook seriële data ? Maar goed ik begrijp dat er in dit geval over de hardware layer een andere taal layer dan nmea0183.

Voor mijn begrip zijn er dus 6 "talen = logische layers" waar onze bootjes data in verstuurd kunnen worden. Nadrukkelijk dus gaat het me dus niet over de hardware layer.

nmea2000 pgm's
nmea0183 zinnen
SignalK derivaat van Hypertext Markup Language
Deze Actisense NGT-1, waar ik niet snel een specificatie van kan vinden.
seatalk-I - Raymarine taaltje
Miniplex derivaat van 0183 in de vorm van $MXPGN zinnen rechtstreeks 1 op 1 relatie met nmea2000 pgn's

3Noreen schreef : Mijn omschrijving is niet helemaal correct maar wou het kort houden:
De data uit de NGT zijn raw ASCII messages, dat ziet er in putty (die dat zo niet kan lezen) er zo uit:


Om dat te kunnen lezen moet je het eerst vertalen naar readable ASCII format dan ziet het er zo uit:
38 44 59 0 0 0 0 1
Voor open cpn moet het dan nog vertaald worden naar een NMEA0183 sentence.
Het programma onderdeel Analyzer in CanBoat doet dat.

Zeilprutser schreef :
Heb nog wat meer gelezen hierover in het CANboat project.

actisence-serial vertaalt "on-the-fly" het (waarschijnlijk proprietery) formaat waarmee de NGT van/naar de USB poort leest/schrijft naar een tussenformaat wat ik herken en ook gebruik.

Lezen van NGT output naar tussenformaat:
Schrijven van tussenformaat naar NGT:
Dit is EXACT hetzelfde formaat als ik ook gebruik bij PolarPlot, echter ik lees van een PiCAN2 board, wat de binaire CANbus data leest/schrijft:
Wat er uit candump2analyzer komt is gelijk aan wat er uit actisense-serial komt:
Van links naar rechts, comma separated:
-timestamp
-prioriteit
-PGN
-source address
-destination address (255 is een broadcast)
-aantal databytes (hier 3)
-de databytes in HEX

Het lijkt dus consistent; wel jammer dat er nog steeds een NMEA0183 brug genomen moet worden.

PS: de NGT-1 werkt dus analoog aan de PiCAN2 (die slechts eur 40 kost):

interface	lezen	schrijven
Actisense NGT-1	actisense-serial	actisense-serial
Linux socketCAN	candump | candump2analyzer	socketcan-writer

Hoe er met de filtering in de NGT-1 om wordt gegaan weet ik niet. Via socketCAN kan ik naar de bus sturen wat ik wil, ook gebackengineerde proprietery PGN's om verlichting in te stellen etc.

Anyway wat ik wil gaat denk ik werken!

Nachtvlinder schreef :
die conclusie had ik ook getrokken. Behalve dan de optocoupler. Het enige wat je krijgt is de payload van de canbus frame.
Je blijft dus zitten met dat je via reverse engineering er voor opencpn begrijpbare nmea0183 van moet maken.

Inderdaad.

Bovendien is n2kd nog steeds in ontwikkeling; momenteel worden slechts een aantal PGN's vertaald naar NMEA0183:
Geen AIS, boatspeed of GPS data dus. Onbruikbaar om OpenCPN in een N2K netwerk te gebruiken.

Nachtvlinder schreef : Helaas dus: wat ik wil kan wel, maar hoe ik het wil (directe koppeling met het netwerk) niet!

Als alternatief kan ik de NMEA0183 server in het GoFree accesspoint gebruiken, echter ook die stream bevat lang niet alle N2K data (helling, roerstand, tankniveau etc)

Heb je niet een ander apparaat die ook omzet naar nmea? zoals een autopilot?

Er is aan boord al een TCP/IP NMEA0183 server aanwezig (het GoFree access point). Daar kan een Pi3 via WiFi mee verbinden.

Dat zal best werken, maar verdient (vind ik) niet de schoonheidsprijs. Hoewel, zolang OpenCPN niet native N2K ondersteunt, is de andere oplossing N2K > veel pipes > NMEA0183 ook nogal gekunstelt natuurlijk.

OpenCpn als opensourcesoftware en het gesloten en angstvallig bewaakte N2K zullen nooit echt vrienden worden. De enige hoop die je kunt hebben is dat in Europa reverse engineering niet door fabrikanten juridisch aangepakt kan worden. En dat iemand die dat voor zichzelf doet het lef heeft het openbaar te maken.
Veel hobbyisten zoals waar ik mij zelf toe reken zijn te lui of hebben het talent niet om hun software dusdanig te documenteren dat het voor openbaar maken geschikt is.

Eens. Overigens ondersteunt SignalK inmiddels wél een behoorlijk aantal PGN's. Het N2K naar SignalK deel gaat goed. Echter SignalK kan weer niet naar NMEA0183 en openCPN zélf accepteert alleen NMEA0183, geen SignalK

Voorlopig is SignalK niets meer dan een server die blind van OpenCPN draait - als een parallel universe. Leuk voor demo's van metertjes in een browser.

Heb Brambo eerder gehoord dat er een integratie aan komt: dat zou, qua interfacing architectuur het mooist zijn. Al je boordapparatuur communiceert dan van/naar de SignalK server en OpenCPN doet dat ook.

Ik verwacht dat Nmea2000 gewoon wordt omgezet in SignalK code. Daarmee is er geen beperking van de info.

De ontwikkelaar van Canboat, Kees Verruijt, is ook zeer nauw betrokken bij SignalK organisatie.

Er zijn al wat langer plannen om SignalK te kunnen toepassen als invoer en uitvoer in OpenCPN.

Allemaal werk in uitvoering, maar komen gaat het zeker.

Wil je een alleen maar een 1 op 1 vertaling van N2K naar NMEA183 en terug, dan is de Actisense NGW1-ISO goed bruikbaar.

canbus is in hoge mate geschikt voor real time toepassingen. SignalK bij uitstek niet.

Waar heb je realtime toepassingen nu voor nodig op een boot ?

Afgezien het feit dat verwerking via een NGT-1 ook tijd vergt.

We zitten niet op een straaljager, maar op een "slow-boat" to ???? Met een snelheid van 6-10 knopen.

Bram

brambo schreef :
Wind golf periodes liggen in de buurt van de 4 tot 7 seconden. Dus onze bootjes worden in die snelheid op en neer gesmeten. Stel dat je slechts vaart op water waar alleen maar een primaire golf aanwezig is, dan betekent een vertraging van een 500ms een fase verdraaiing van 30 graden. Je data signaal is dan volledig onbruikbaar om er een Fourier Transform op los te laten. Het wordt alleen maar erger als er ook nog een secondaire of tertiaire golf aanwezig is. Wil je echt leuk bezig dan is 10ms een streefcijfer. Vooral jitter wil je ten koste van alles tot het minimum beperken.

Maar misschien moet ik toegeven dat mijn eigen toepassing van mijn Raspberry niet zo vaak voorkomt. Maar ik ben er van overtuigd dat de "grote" jongens die stuurautomaten op de markt brengen hier wél óók mee bezig zijn.

Waar jij mee bezig bent dien je echt op een zo laag mogelijk (bijna electrisch) niveau te doen. Signal-K en al die andere applicatielagen barsten van de variabele en onvoorspelbare timedelays zoals je zegt. Voor een mooi uitziendf klokje in een browser maakt dat weinig uit.

In de automotive gebruikt men CAN om de ABS mee te regelen: daar géén ASCII strings in JSON, laat staan dat je die in een wachtrij van een TCP/IP server zet

@Brambo wat is de officiele link van je openplotter project? Ik kan het in je profiel niet vinden maar het lijkt me leuk om dit eens te gebruiken naast mijn ubuntu laptop.

edit: duh - deze waarschijnlijk, ergens een foutje gemaakt in google sailoog.gitbooks.io/openplotte...getting_started.html

Nog een vraagje betreft een headless installatie.

Enthousiast geworden over de eindelijk complete oeSENC kaartensets wil ik serieus hiermee aan de slag. De setup die ik in gedachte heb:

• Raspberry Pi 3 gevoed vanuit 50W DC/DC converter met naar 2.4A gelifte laadkabel
• N2K via Zeus 2 naar GoFree naar NMEA0183 TCP/IP streaming server
• Bluetooth trackball
• iPadPro 12.9" als scherm (via VNCviewer oid)

Mijn vragen:
1) Heb ik OpenPlotter nodig of volstaat OpenCPN?

2) Welke trackball is het beste (moet tegen een stootje kunnen en niet zomaar verschuiven)

3) iPad resolutie is native 2732 x 2048: Hoe zorg ik dat OpenCPN in deze resolutie draait en verschijnt op de VNCviewer remote desktop? Heeft de videokaart in de Pi hier überhaubt mee te maken? Kan ik meeliften op de video acceleratie van OpenGL?

4) Kan ik, ipv een toetsenbordje, de iPad ivm VNC gebruiken om een "soft" toetsenbordje onder in beeld te krijgen? Ik verwacht OpenCPN 95% met de trackball te kunnen bedienen, maar zal af en toe toch iets moeten kunnen typen...

Wat zijn de andere aadachtspunten?

Nachtvlinder schreef :
Beste NV,

je kunt alles zelf samenstellen. Linux en OpenCPN en ????????.

Maar in OpenPlotter zit alles er al in voor je. Is een Linux OS plus OpenCPN een veelheid aan opties.

Die hoef je natuurlijk te gebruiken.

Je moet ieder geval wel een VNC server hebben. Een Wifi Access punt, N2K Can mogelijkheden. SignalK enz, enz. Node red bijvoorbeeld om allerlei verbindingen te maken. Je kunt het gewoon eerst eens proberen met je nieuwe complete kaartje.

Persoonlijk vind ik een draadloos toetsenbord met een pad erg handig. Kun je overal gebruiken en kun je ook nog vastzetten met wat klittenband. Gebruik zelf een Logitech K400r. Er zijn veel van die compacte toetsenborden en je gebruikt maar een usb poort.

Je kunt met OpenPlotter ook OpenCPN direct laten opstarten.

VNC neemt de resolutie over van de Raspberry. Eerder heb ik site aangegeven waar alle resolutie mogelijkheden zijn aangegeven.


Je kunt alles zelf samenstellen. Linux en OpenCPN en ???????? Multiplexer bijvoorbeeld.

Maar in OpenPlotter zit alles er al in voor je. Is Linux en OpenCPN plus een veelheid aan opties.
Die hoef je natuurlijk te gebruiken.

Je moet echter wel een VNC server hebben. Een Wifi Access punt, Can mogelijkheden. SignalK enz, enz.

Als je kaartje ontvangen hebt, dan horen we het wel.

Groet,


Bram

Het gaat zeker werken hoor, heb het alleen het liefst zo simpel mogelijk Indien OpenPlotter het eenvoudiger maakt een standaard WiFi NMEA TCP/IP stream als ingang te gebruiken is dat prima!

RealVNC server zit stanaard in Debian (dus vast ook in Stretch) dacht ik?

Als het even mogelijk is, wil ik de desktop van de Pi in dezelfde resulutie draaien als het remote scherm (2732x2048). Dit voorkomt mapping/interpolatie tussen pixels en geeft het scherpste beeld: elke unieke bronpixel valt op één pixel van de iPad

Zit net wat te lezen over VNC: de server (op de Pi) kan blijkbaar ook in een virtuele modus draaien, wat dan volledig buiten de videokaart om gaat: je krijgt dan ook niet dezelfde desktop te zien zoals die naar de HDMI gaat, maar een virtuele desktop (één per aangemelde user). Dat kan dus een (voor de Pi) fantasieresolutie zijn.

Je kunt echter ook de primaire schermoutput (die naar de HDMI gaat) klonen naar de VNC server (dat is de default...) Buiten de 80 standaard hdmi_mode=xxx die je in config.txt kunt configureren, kun je met Custom HDMI modes werken: www.raspberrypi.org/forums/vie...hp?t=24679&start=150

Mijn vraag ging erover wanneer ik wel en niet van de OpenGL acceleratie profiteer...

De hardware (\ball en keyboard) is al in aanwezig en in gebruik (voor andere toepassingen)!