Onderwerp: RPI als boordcomputer

Yazz schreef :
Ok, Je bedoelt het vast oprecht hoor, maar een conclusie kan je pas echt trekken denk ik nadat Joop het systeem 1 of 2 seizoenen gebruikt heeft.
Net geïnstalleerd werkt alles, windows of linux, welke hardware dan ook. Interessant wordt de review na een jaartje ofzo. Vandaar mijn vraag aan Joop of hij bereidt is om ons nog een keer terug te koppelen hoe het bevalt na een tijdje...En dan kan je een goede conclusie trekken...

Tot die tijd wordt een opmerking als die van jou helaas gelijk aangegrepen door een aantal mede ZF’ers om hun gal te spuwen of windows of linux. Maar goed, daar kan jij niks aan doen...

Nachtvlinder schreef :
Die 200MB en 20k files is gedeeltelijk het gevolg van de gekozen programmeertaal/omgeving (Node.js/NPM). De standaard library van Node.js is niet zo groot, en er wordt daardoor veel via packages gedaan die als source verspreid worden via NPM. Die packages zijn vaak afhankelijk van andere packages, en voor sommige taken zijn meerdere packages beschikbaar die een vergelijkbare functie uitvoeren. Bij een wat groter project loopt dat al snel op in een hele boom van packages die van elkaar afhankelijk zijn. Als daar goede keuzes in gemaakt worden hoeft dat overigens niet per se een probleem te zijn.

Als het was geschreven in een gecompileerde programmeertaal was er 1 executable uitgekomen, maar dat wil niet zeggen dat het daarmee minder buggy of nerdware zou zijn.

Menno schreef :

Dat is dan in tegen spraak met de minimaal 3 x eenvoudig per bericht die zeer regelmatig te lezen valt

Je moet niet alles geloven wat er geschreven staat

Al was ‘moeilijk’ misschien niet helemaal goed verwoord. Het komt er vooral op neer dat je tijd moet willen investeren in kennis over een ander OS (zoals brambo regelmatig noemt is de RPi bedoeld als tool voor het onderwijs) en als je dat niet wilt kan je er beter niet aan beginnen.

Beste NV,

het is geen commercieel market-ready product. Het is doorgaande open bron ontwikkeling.

Je kunt op internet alle mogelijke informatie vinden en ook in SignalK staat bij elke applicatie een mogelijkheid om te zien hoe of wat. Met veelal een verwijzing naar de betreffende Git-hub site.

Ik ga geen dingen voor je opzoeken, die je zelf ook kunt vinden. Maar als je SignalK er onmiddelijk weer afsmijt en klaagt dat er geen uninstaller is en dat je het "handige klant vriendelijk registery" moet gebruiken.

Dan wil je het gewoon niet. Ja, dan houdt voor mij de zaak op.

Ik wil iederen met plezier helpen, zover ik het zelf weet. Maar een vraagsteller moet wel een positieve benadering tonen. Daarbij mag er best kritiek worden geuit.

Dat ik voor ZF leden een SD kaartje maak, doe alleen om ze direct op weg te helpen en daar zet dan ook tegelijk wat kaarten bij. Plug en Play en direct de zeekaart op je scherm.

Maar dat wil je ook niet.

Maar goed zelf dingen ontdekken is ook prima, zelfs beter. Maar dan niet direct klagen als je het niet snapt.

Enige kennis van Linux is uiteraard ook wel handig.

De RPI is ontstaan op de UNI van Cambridge, omdat studenten eerder alleen maar een programma konden installeren. Met een RPI gaat men zelf aan de slag om toepassingen te maken, te programmeren en kennis op te doen van de werking van computer systemen. En dat blijkt een enorm succes.

Waarbij 30% voor bedrijfmatige toepassingen wordt gebruikt. Ook allemaal Nerdy en beta gedoe zeker.

Het idee met de navigatie software, waaronder OpenCPN en de Oesenc kaarten is, dat kaartplotter systemen voor iedereen bereikbaar komen voor een geringe investering. Gewoon een kaartplotter voor iedereen.

Bram

Tis goed zo Bram...

brambo schreef :
Ook dat is al zo oud als de wereld.
In 1976 heb ik heel wat geprogrammeerd (in hexadecimale opcodes en data) op een KIM-1
Let op het hexadecimale toetsenbord.
Opcode intikken, store op een adres, naar het volgende adres, weer iets erin zetten, enzovoorts.
1kByte geheugen, 1 Mhz CPU.



Daarna wat jaren op mijn eigen Commodore PET 2001 (ik heb hem nog!), in Basic en in hex 6502-assembler. Zelfs een RS232-interface gesimuleerd op 2 pennen van de parallele poort, met een 9V batterijtje en een op-ampje om de PET aan een modem te hangen. Heeft als terminal gewerkt op de CDC Cyber van SARA (tegenwoordig surfSARA), ZONDER RS232-kaart. COMpoort gesimuleerd met een batterijtje, dat waren nog eens nerd-tijden (het woord nerd was nog niet in de mode)



En in de 30 jaar daarna is iedereen vergeten hoe zo'n computer nou eigenlijk werkt, dank zij Apple en Microsoft (behalve de mensen die eraan bouwen en ontwikkelen).
Het is leuk dat dat weer terugkomt, en dat er weer mensen zijn die willen snappen hoe het werkt.
Maar dat is natuurlijk geen reden om er serieus gebruik van te gaan maken, voor navigatie, AIS en andere zaken van levensbelang
Ik heb in die jaren al genoeg tijd verprutst met moeizaam programma's aan de gang krijgen
Nu gewoon lekker kant-en-klaar, en af en toe een modern programma'tje schrijven waar informatie uit komt ipv ruwe data (sneer naar SK )

Voor diegene die de werking willen zien is hier een filmpje, dat ik net opgenomen heb.

Het is gemaakt met de Screencast optie in Ubuntu. Tegelijk opnemen vertraagt uiteraard de werking wel wat.

De data communicatie loopt geheel via SignalK. Ook de AIS ontvangst van de RTL-DSR usb dongle kun je zien in het SignalK dashboard.

Het OS is de Ubuntu Hirtute Hippoo 64 bits versie voor de Raspberry Pi.

Nachtvlinder schreef :

Ik zal je even helpen. SignalK is het platform. Dat werkt met plugins en webapps. Als je wilt weten hoe de conversies werken moet je zoeken naar de plugins. Via google kom je dan al snel bij de desbetreffende githubs. Daarna wordt het al snel technischer. Je moet de plugins zoeken die al doen wat je wilt.

Voor een beschrijving van Nmea2000 naar SignalK:
github.com/SignalK/n2k-signalk hier lees je dat voor de vertaling gebruik gemaakt wordt van de Canboat functionaliteit. Volg het linkje: github.com/canboat/canboat/wiki/CANboat
De gehele NMEA2000 db wordt ingelezen en naar SignalK geconverteerd.

Zo heb je het ook van signalK naar NMEA183:
github.com/SignalK/signalk-to-...lob/master/README.md

Als je bij de webapps kijkt in Signalk kun je bij de betreffende applicatie informatie, direct de verwijzing verkrijgen naar de betreffende web site. Je hoeft niet eens te gaan zoeken.

Wees zelf supporting door te weten hoe dingen werken en kies voor een modulaire toepassing. Je kunt een slecht functionerend onderdeel eenvoudig vervangen. Als je een systeem hebt met een ingebouwde HD en het ding crasht, wat dan ?. Bij de RPI steek je er een back-up kaartje in en je hebt direct weer een werkend systeem.

Joop66 schreef :
Kan iemand me hier een serieus en onderbouwd antwoord op geven?

Ik zou t namelijk echt willen weten.

SignalK heeft alleen meerwaarde als je NMEA2000 apparatuur aan boord hebt en deze gegevens wilt gebruiken in een programma dat SignalK begrijpt, zoals OpenCPN. Daar is het voor ontwikkeld.

Eventueel kun je NMEA2000 via SignalK ook naar NMEA183 vertalen, maar dit is wel een extra conversieslag met de mogelijkheid van fouten. Het is hiervoor niet ontwikkeld, maar is een toegevoegde functionaliteit.

Signalk is data aggregatie software, single source of truth. Je aggregeerd al je signals en besluit vanuit daar wat je er mee wil. Ik zie de meerwaarde wel eigenlijk. Vooral omdat je makkelijk kan filteren en zelfs berichten aanpassen voordat je consumers (opencpn, laptop, tablet) er iets mee gaan doen. Het maakt de data veel inzichtelijker.

mithras schreef :
Het spijt me, maar dit is een "het is beter omdat t beter is" statement. Single source of truth is relevant als je van diverse bronnen naar diverse doelen wilt.

Ik wil van NMEA0183 naar OpenCPN, en weer terug voor de autopilot. Verder niks.

Is t dan nog immer beter?

Overigens ben ik exact in dat filteren vastgelopen. Blijkbaar is t zo makkelijk niet.

In jouw geval Joop is er geen enkele meerwaarde. Er is voor wat jij wel al een prima oude standaard oplossing. Daar hoeft niks extra’s tussen.

Andere doen alsof SignalK in het geheel een K.U.T. Oplossing is. Dat is het imho zeker niet. De berekeningen in BKs knutselwerk, zouden bijvoorbeeld ook prima in een plugin voor SignalK gestopt kunnen worden en vervolgens bijvoorbeeld beschikbaar gesteld via een dashboard.

Wel leuk dat je Bk met voorbeelden komt uit 1980, maar we leven in 2021. CPU, bandbreedte en geheugen zat, bovendien hebben we het dan nog steeds over datastromen die niks voorstellen.

Joop66 schreef :
Het filteren van OpenCPN uitgaande doe je op de onderste regel van OpenCPN. De twee puntjes aanklikken alles wissen en alleen aangeven wat je wilt ontvangen. RMB, RMC en XTE bijvoorbeeld. De uitgaande verbinding is al eerder aangegeven.

Is toch niet zo moeilijk ?

Je moet natuurlijk wel in OpenCPN een uitgaande verbinding aanmaken.

Beste Joop, eindelijk iets dat echt simpel is
Je kunt Signalk gebruiken als je een functie wenst die SignalK ondersteund, zo niet waarom zou je het dan toevoegen?
In jouw geval gebruik je het alleen voor de tijd en datum, prima gebruik het dan verder niet.
Zodra die klok functie beschikbaar is in OpenCPN gooi je Signalk er weer af.

Koop je bijvoorbeeld morgen een Victron lader met VE-Direct protocol en wil je de status kunnen zien op je pi dan zet je Signalk er weer op.

mithras schreef :
Het bovenstaande is een stuk makkelijker te begrijpen als je i.p.v. aggregatie, wat een verbastering is van het engelse aggregation, verzamelen leest.
Dan opeens begrijp je dat BK zijn software ook iets dergelijks doet.
Maar in Joop zijn toepassing is er geen reden om de data eerst te verzamelen om het vervolgens door te sturen naar de enige gebruiker in zijn geval van de data namelijk OpenCPN. Dan kan de ingang (nmea0183) beter direct aan de uitgang (OpenCPN) aangesloten worden. Het wordt anders als die data voor meer toepassingen gebruikt worden. Metertjes of het internet op gestuurd o.i.d.

Zoals aangegeven kun je uitgaande data filteren. Meer heb je ook niet nodig voor het stuurapparaat. Alhoewel nmea183 vanuit OpenCPN naar NMEA2000 ook nodig kan zijn.

Het is natuurlijk wel erg handig dat je de richting naar een waypoint, de afstand naar het waypoint op je route en de XTE afwijking eenvoudig op een display kunt aflezen.

Je wilt het zelf niet proberen, maar een data server waar alle data samenkomt en kan worden verwerkt en omgezet in andere formaten is zeker een aanwinst.

En in principe heb je geen multiplexer nodig, dat is SignalK zelf.

Bram

brambo schreef :
Heb ik niet. Alleen 1083.
brambo schreef :
Dat kan ik. Een van de redenen om routes aan te maken en te activeren: XTE en BTW zichtbaar buiten op de AP. Dat werkt nu al. Zonder SK.
brambo schreef :
Je verwart hier (weer) willen en kunnen. Ik heb het geprobeert, en er niet uit gekomen, ook niet met jouw hulp. Ook heb ik niet de juiste informatie (makkelijk genoeg) op internet kunnen vinden. 3 weken geleden was ik totaal bereid het te proberen. Maar door (voor mij) onduidelijke of onvolledige informatie is dat dus gestrandt. Daarbij is mijn doel: zeilen en daarvoor ondersteunende computer te hebben. Ik heb nog niet ervaren wat SK daar aan toevoegt. Aan de posts hier verder te zien, en ook de voor mij irrelevante argumenten, gaat dat dus ook niet meer gebeuren. Wellicht wordt het anders als mijn eerste N2K instrument moet aanschaffen. We gaan t meemaken.
brambo schreef :
Alleen het software deel. De reden om een multiplexer te kopen is, voor mij, de hardware kant er van: NMEA 0183 vergt een (hardware) seriele poort per isntrument. Probleem met vrijwel alle MUX-en is dat ze slechts 4 ingangspoorten hebben.brambo schreef :

Zeilprutser schreef :
Zoiets dacht ik inderdaad te doen. Niet dat ik behoeft heb aan een VE-direct lader. Maar wie weet.

Only Fools Rush in schreef :
Efkes naar zitten staren.

Kan daar geen chocola van maken zonder er veel te veel studie aan te wijden.

Joop66 schreef :
Wat hang je er allemaal aan dan?

En als je echt meer wil:
hang er een mux voor. Daarvan dan een talker op een listener van de echte mux.
Als je dat 4 keer doet kun je 16 apparaten muxen

Baasklusje schreef :
13