Onderwerp: RPI als boordcomputer

Nog even de laatste stand van zaken:

OpenCPN is nu versie 5.13.4-1. Versie 5.14 zal nu snel verscijnen.
Signalk-server 3.24.0

De nieuwste Lunux OS voor de RPI4:

RaspiOS64 = Debian Trixie
Fedora 44
Ubuntu

Wil je serieele poorten gebruiken. Dan deze toegang verlenen: sudo usermod -a -G dialout "gebruiker". En het systeem herstarten.

Flatpak O werkt prima. Echter een aantal plugins ontbreken nog.

Wil je de flatpak versie updaten: flatpak update org.opencpn.OpenCPN (zonder sudo)

Laatste SignalK-server versie is 2.24.0.

github.com/SignalK/signalk-server/releases

Sorry voor de typefout.

Google Ai heeft mij ook geholpen waar chat gpt je glashard de mist in stuurt en dat volhoudt, zelfs wanneer je tegen chat get zegt dat met de tips van Google Ai het wel werkte... Bij mij ging het om een paar hardnekkige conflicten in de victron software van mijn 3 fase thuis batterij installatie.

Wat is het nut van het hier melden van de laatste SignalK-versie? Wie SignalK gebruikt kan zelf wel op de overzichtspagina zien wat de versie is. En ook of er een nieuwe versie beschikbaar is. En voor wie SignalK niet gebruikt is het al helemaal niet interessant.

Als je het zelf niet gebruikt hoef je ook geen commentaar te leveren.

je ontwikkelingen gaan in snel tempo verder. Voor gebruikers mogelijk interesaant. Met veel verbeteringewn.

brambo schreef :
Maar ik gebruik het wel, intensief zelfs, en daarom mag ik best commentaar geven. Jij hebt niet het alleenrecht om iets over SignalK te zeggen.

Ik vind ook het nodige van Signal K hoor!

Dat is je goed recht, Andre! Of je het nou gebruikt of niet.

Er is nogal wat weerstand tegen SignalK. Als ik vraag naar het waarom, krijg ik geen antwoord. Hebben we eindelijk een open standaard, wordt er weer tegenaan geschopt.
Ik zag laatst een YT-video van Boating with the Baileys, waarin Matt Bailey mooie digitale klokjes demonstreert op basis van kleine vierkante en rondje schermpjes van Waveshare met een ESP32-bordje achterop, dat de benodigde info uit SignalK haalt. Prachtig! Het meest gegeven commentaar: "kan dat ook zonder SignalK?"

Eclips schreef :
Ik heb geen enkel alleenrecht. Ik probeer van alles de laatste stand van de techniek toe te passen en weer te geven. Reden ? Omdat er zo veel verbeteringen verschijnen zonder vervanging van de hardware.

Als je interessante toepasingen signaleert, dan graag hierop een bericht.

Bram

Eclips schreef :
Inderdaad, ziet er productieklaar uit. Die zit te wachten op iemand die zijn source code van github jat en er geld mee gaat verdienen. Maar ja, SignalK he?

Eclips schreef :
Ja dat kan. Met SPD.

Baasklusje schreef :
Daar ging het niet om, het ging om de onverklaarbare weerstand tegen SignalK. Overigens heb ik even bij SPD gekeken, en wat hierboven beschreven wordt, namelijk ESP32-klokjes voeden met data uit SPD kan niet, voor zover ik zag. Wat niet wil zeggen dat het niet mogelijk is, maar het is nog niet gebouwd.
Wat ik ook zag:

"The eighth output:

SailingPD is able to send all available data over a websocket to listening browsers or other apps. Signal K is an obvious target."

Die ontwikkelaar is dus een stuk minder SignalK-foob dan sommigen hier.

De reaguurders op die video zitten trouwens ook niet op SPD te wachten. Die willen het rechtstreeks uit N2K halen.

De keuze voor javascript en typescript hebben als consequentie dat het geheugen en processor gebruik erg hoog is voor wat het hoeft te doen. Ook die talen zijn niet erg populair bij de software devellopers.

Ik mag er over praten want wij misbruiken Signalk

Voor een goed klokje is de goede hardware vinden en concurrerend produceren het lastigste, maar we doen ons best:



Hardware moet voldoen aan: zonlichtleesbaar, dimbaar voor nachtzicht, waterdicht en temperatuur bestendig in alle klimaat zones.

Eclips schreef :
Het is nogal wat ondergesneeuwd in de eindeloosheid van dit verhaal. Maar bij deze mijn ervaringen. Het was er mij dus om begonnen om een boordcomputer te bouwen op basis van RPi. Niks meer. Geen extra klokjes, geen slimme links naar tablets buiten, niks. Een kaartplotter waar ik instrumenten op kan uitlezen, en die een route naar de stuurautomaat kan sturen.

Al dit kan OpenCPN zonder SignalK.

Ik heb me vooral in het begin door Bram en andere enthousiastelingen laten overreden om SignalK te gebruiken daarvoor.

Maar daarbij ben ik tegen een paar dingen aangelopen. Ik heb niks tegen SK an sich. Maar;

1: Ik had onmiddelijk een dataloop. Alle info die de instrumten SK binnen brengen, worden naar OpenCPN gebracht via de speciaal daarvoor bestemde poort in OpenCPN. Maar al die data wordt onmiddelijk weer teruggestuur naar SK. Duurde efkes voor ik dat door had. En: waarom? Op een dedicated koppeling, hoort dit niet te gebeuren.
2: Er is een en ander nodig om de USB poorten vast te prikken, en niet meer te laten verschuiven. Gedoetje.
3: Wat ik niet aan de gang heb gekregen, gewoon niet, nul, is de RMB zin voor de AP naar de seriele poort van AP te laten sturen. Binnen OpenCPN was dat een makkie, maar in SK is het me gewoon niet gelukt.
4: De manual documentatie is matig bij elkaar te vinden. Nergens een complete manual als OpenCPN wel heeft.
5: En dan is het een laag extra software/complexiteit die ik niet strikt nodig heb.

Nu blijkt dat laatste alsnog wel zo te zijn: Namelijk om de klok van de RPI gelijk te zetten.

Dus nu zit het er als piggy bag bij, via een éénrichtingspoort. ALLEEN om de klok gelijk te zetten.

Punten 1, 2 en 3 vind ik rechtstreeks ergelijk.

Zeilprutser schreef :


survey.stackoverflow.co/2025/t...es-language-language

www.techzine.nl/nieuws/devops/...-willen-ze-dat-niet/

Het is ook niet mijn favoriet.

Puntje 1 heb je helemaal gelijk zou niet moeten gebeuren. In de nieuweste versie van OpenCPN kán dat ook niet meer.
2. Ja maar dat moet je ook als je ze direkt in OpenCPN gebruikt. Alleen in jouw geval ga je ze in de praktijk nooit verplaatsen en kom je er mee weg om het niet te doen.
3 Signal-K was één richting, Je kan natuurlijk je uitgaande RMB via SignalK laten lopen door daar een extra 'RMB' input te maken en een extra 'RMB' output waar je dan nema $xxRMB uit laat komen. Maar rechtstreeks RMB vanuit OpenCPN naar buiten kan natuurlijke ook gewoon. (Persoonlijk ben ik een groot tegenstander van je stuurautomaat aansturen vanaf je plotter. Dan kan je dus koers veranderingen krijgen die je niet verwacht. Ik ben degene die de koers instelt en niemand anders!)
4 Kan/geen mening
5 Helemaal eens, al is dit natuurlijk wel een gevolg van JOUW keuze voor een Rpi

rooiedirk schreef :
1: Ja, maar jongens. Zelfs als ik OpenPlotter installeerde, zat daar integraal de data-loop al in. Dat kun je mensen toch niet aandoen? Hoe t nu is, weet ik niet: Ik gebruik de poort 3000 niet, maar een éénrichtings UDP op 2000.

3: De AP stuurt nooit op track. Dat zeilt sowieso niet lekker. Maar het is voor mij een soort communicatiemiddel van binnen naar buiten. Ik gebruik buiten wel de Bearing to Waypoint en XTE voor mezelf om in te schatten hoe fout alles gaat. Dus eens met je commentaar. Daarbij vind ik het een behoorlijke sof dat een stuk software dat zich presenteert als de universele data server dit niet kan. Of tenminste, nogmaals, ik heb t ondanks veel hulp niet aan de gang gekregen.
5: Als backup heb ik een kleine laptop. Daar heb ik helemaal geen SK nodig. Ik zou niet weten waarom.

Puntje 2 is helemaal geen probleem als de het device op de poort "by id" invult en niet by-path:


bijvoorbeeld:
:/dev/serial $ ls
by-id by-path

pi@Relexed:/dev/serial $ ls by-id
usb-CustomWare_ShipModul_MiniPlex-3Wi_33000166-if00-port0
usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_f6df48671c27ee119df18fc1f49e3369-if00-port0
usb-VictronEnergy_BV_VE_Direct_cable_VEABZUBL-if00-port0

ironman schreef :
Ik vind het bijzonder dat je nog steeds geen of vrijwel geen schermpjes ziet met E-ink technologie. Dat is in fel zonlicht juist perfect leesbaar

Joop66 schreef :
In een laptop zit een ingebouwd klokje en een batterij. Dat heeft een rpi niet. Dat laatste ken met de prijs van een rpi te maken hebben. Je krijgt voor wat je betaalt.

Het is al vaker op ZF geschreven maar toch weer een keer. Een Raspberry Pi is niet de ideale hardware om een plotter van te bouwen. Tenzij je echt zo goedkoop mogelijk wilt. Maar dan lever je dus in op andere dingen. Zoals een klokje.
Verder het weigeren om iets van programmeer vaardigheden op te doen werkt bij opensource in je nadeel.

XanderB schreef :
De belangrijkste reden daarvoor is de beeldverversing. E-ink schermen knipperen meerdere keren om een nieuw beeld te genereren. Dat is enorm onrustig en ongeschikt voor metertjes en andere constant veranderende visuele toepassingen. Verder verbruikt een e-ink scherm geen energie als er niets gebeurt, maar juist wel bij iedere refresh. Dus ook dat voordeel valt weg. En dan is e-ink (zeker kleur) ook nog prijzig in vergelijking met LCD of OLED.

Zeilprutser schreef :
Valide punt, maar dan vooral dankzij de aantekening "voor wat het hoeft te doen". Want in absolute zin is er heel weinig nodig om een SignalK-server te draaien. In een wereld waarin honderden Ah's gevoed door zonnepanelen aan boord van boten getild worden is het verbruik van een SBC met SignalK verwaarloosbaar. En je krijgt er een toegankelijke open standaard voor terug.