Onderwerp: RPI als boordcomputer

brambo schreef :
fout

3Noreen schreef :

Joop66 schreef :
Goed besluit. “If it ain’t broke, don’t fix it”

Ik heb alweer een hele tijd een navigatiesysteem op RPi, gebaseerd op een kaartje gekregen van Bram.
Zal ondertussen wel versie-stenen-tijdperk zijn. Maar so what. Enige wat ik hoef te doen ff elke maand nieuwe ENC kaarten erop van RWS, en that’s it.
Verder geen geklooi aan de plotter, blijft ie het gewoon doen (nee, nog steeds geen vastgelopen usb…)

Het trouwens ook een Asus EEE mini laptopje met opencpn. Draaide prima op Windows 7. Ik zo stom om te upgraden naar Windows 10….PC-tje werd ineens supersloom, open cpn draaide voor geen meter meer…

Dus: formatteren, en weer Windows 7 erop. Ja, wordt niet meer ondersteund door Microsoft. Lekker boeiend, gewoon niet aan internet hangen, niks aan het handje.

Het helpt om jezelf te beheersen door niet alles opties te willen, niet alles aansluiten, niet de laatste upgrades, niet internetten op een plotter, en dan voldoet (bijna) alles…

Hou je jezelf niet aan die regels, dan wordt het uiteindelijk vaak uitzoeken en knutselen… ook leuk, maar dan wordt je geduld wel af en toe op de proef gesteld…

sjoerd1981 schreef :
Veel beter kun je het niet onder woorden brengen. Als je het onderste uit de kan wil....

Dat is ook zo. Maar ondertussen worden ook bugs opgelost...
En nieuwe bugs gemaakt.

3Noreen schreef :
Gezien je bij een flatpack juist de software bibliotheken bundelt bij de applicatie, krijg je dus geen vergelijkbare situatie als een DLL-hell. Dit geeft natuurlijk wel het gevolg dat je goed de applicaties bijgewerkt moet houden ivm mogelijk veiligheidsfouten in die software bibliotheken.

Sandboxing wordt wel degelijk ondersteund waarbij de toegang tot het host-omgeving wordt beperkt:
Is flatpack de toekomst? Het heeft wat voordelen, maar distro’s worden gekozen vanwege verschillende redenen, waaronder de package manager. Flatpack lijkt in die markt een alternatief te willen bieden, vooral voor applicatieontwikkelaars en gebruikers, maar weinig voor de distro’s.

MacOS heeft iets vergelijkbaars al >20 jaar, concept is nog ouder en komt van NeXTSTEP. Daar worden applicaties altijd gebundeld/gepackt (sinds 10.0). Tevens kunnen daarmee Intel, x64, ARM, ARM64 en vroeger PowerPC varianten in geplaatst worden en dus op elk systeem runnen. Het was zelfs enige tijd mogelijk om MacOS applicaties te runnen onder OpenSTEP.

Wat ben ik blij dat ik niet hoef na te denken over flatpacks, software bibliotheken, DLL-hells, Sandboxing, host-omgeving, NeXTSTEP, Intel, x64, ARM, ARM64 en OpenSTEP.

Palomine schreef :
Ik weet niet wat je gebruikt als plotter, maar ook bij een off-the-shelve plotter heb heb je mogelijk zitten nadenken of het een B&G/Simrad, RayMarine of Garmin moet worden. Hoger level en waarschijnlijk meer op functionele eisen ipv technische oplossingen zoals flatpacks.

Maar dit soort details (flatpacks etc, who cares) zijn waar je normaal met een plotter niet mee bezig wilt zijn, dat ding moet het gewoon doen. Fabrikanten maken keuzes voor je waardoor jij ze niet hoeft te maken. Jij conformeert aan de voor jouw gemaakte keuzes, en daar is helemaal niet mis mee. Dat heet gebruiksgemak.

Als je wel een mening hierover hebt voor je plotter systeem, dan heet dat ‘hobby’

Orange Sunset schreef :
In het verleden heb ik hier op ZF al laten zien dat OpenCPN met de Oesenc plugin in een flatpack opzet een memory leak had. Waardoor het hele systeem na ongeveer een week vast liep. Wat niet op te lossen was met de herstart van de flatpack applicatie maar de hele machine moest herstart worden. Kortom sandbox van lik me vestje. Flatpack belooft iets wat het niet waar kan maken. Waar is mijn IT bullshit spray? Het voegt een complicerende laag toe inclusief bugs zonder een wezenlijk voordeel in de richting van een stabieler systeem.
Bovendien een computer die uitsluitend als plotter gebruikt wordt heeft geen voordeel bij een virtualisatie van de plotter applicatie. ALS de sandbox al zou werken. Het maakt namelijk dan niet uit of je de hele machiene moet herstarten of alleen de plotter applicatie.
Het hele idee dat je een plotter in een virtualisatie zou moeten zetten is compleet van de pot gerukt, dom. Het host systeem is de plotter, snappie ?
Het uitbrengen van de plugins voor OpenCPN in een flatpack komt voort uit gemakzucht.
Gewoon wachten totdat het de heren belieft om updates van hun plugins voor de rasbarry uit te brengen. Tot die tijd met het oude uit te zingen.
Of wat de meesten hier op ZF gedaan hebben een mini computertje kopen waar windows op kan draaien en Raspberry hell achter je te laten.

3Noreen schreef :
Is het dus eigenlijk een Fatplack?

Tussen de stoorzenders door sluit ik me graag aan bij de tevreden "RPI als boordcomputer" gebruikers. Al gebruik ikzelf geen OpenCPN als plotter ik lees graag mee met het volgende probleem van Joop



Gepost met de officiële Zeilersforum-app

@ 3 Noreen,

ongelofelijk wat een onzin. Die flatpak OpenCPN is pas recentelijk ontwikkeld.

Ik ga er maar niet meer op in. Want het slaat werkelijk nergens op.

OpenCPN kan op de standaard manier worden geinstalleerd of met het nieuwe systeem op basis van flatpak.

Ook voor de nieuwe, nog uit te komen Oesenc plugin maakt het niets uit.

Het enige verschil is dat het aanpassen van de plugings, die door derden worden vervaardigd, voor bepaalde release veel meer tijd vergt dan het uitbrengen van een nieuwe OpenCPN versie.

Het "lek" zit ergens anders, maar niet in de software.

Bram

Effies schreef :
Ik hoop dat je geduld hebt. Die komen volgende winter pas weer.

Weet je, de hele reden voor het hele spel, efkes terug naar de eerste bladzijde van het spec-document: Customer Intent. Wat wil die persoon er mee???

De allereerste reden was: Stabiel, en energiegebruik. Elke windows mogelijkheid trekt minstens 2 keer zoveel stroom. Dus tot zover. Als t me te bar wordt, gaat de rpi er uit en komt er een latte panda.

Mijn reden voor het willen proberen van 5.6, was de belofte dat 5.6 de rpi klok zelf recht kan zetten, en dat ik daar een SK voor nodig heb. Maar t is dus nog niet af.

Voor diegen die de ontwikkelingen willen volgen:

www.cruisersforum.com/forums/f134/

Wachten is nu op de Oesenc plugin setup nieuwe stijl.

De ontwikkelingen gaan continue door.

brambo schreef :
Ze kunnen al bijna de klok gelijkzetten

@ Joop, wat moet ik me bij die scheefstaande klok voorstellen??

Joop66 schreef :
Ik weet dat jij het niet wil horen maar ik schrijf het toch. Een intel NUC gebruikt niet meer stroom dan een Raspberry. Dat komt omdat i.t.t. een Raspberry een NUC een energie managment heeft. Als hij niets hoeft te doen gebruikt hij minimaal stroom.
Joop66 schreef :
Iets wat je met een simpel scriptje ook voor elkaar kan krijgen daar hoef je niet het gehele ding voor te updaten.
In telegram stijl omschreven.
-Kijk of je kplex al geïnstalleerd hebt. Zo niet als nog installeren.
-Kplex instelling zo wijzigen dat er een nmea poort komt waar je scrip gebruik van kan maken.
-Een van de op ZF aangeboden scriptjes die de klok gelijk zet aan de gps tijd installeren.
-Een cron job aanmaken die het scriptje laat draaien.

De tactics-T plugin is nog niet voltooid. Maar is al prima te gebruiken. Echter nog een beta plugin sectie en niet in de master versie.

Je kunt die beta plugins al gebruiken, rekening houdend dat er nog wijzigingen kunnen optreden.

Je moet hiervoor in OpenCPN de beta plugins aanzetten. Hoe dat te doen heb ik al eerder aangegeven. Gewoon een regel toevoegen aan de opencpn.conf.

Maar goed het is in ontwikkeling net zo als de vele andere plugins. Nogmaals de plugins komen niet van OpenCPN zelf maar van derden ontwikkelaars.

Anjo schreef :
RPi heeft geen klok die doorloopt als de RPi uit staat. Als er geen internet verbinding is, aan boord altijd dus, staat die klok ergens.

De reden waarom dat belangrijk is, is dat de traces, VDI, en OTcurrent-plugins alleen naar de systeem klok en datum kijken.

De enige bron van juiste tijdinformatie is dus de GPS. Of een tijdelijke internet verbinding uit een telefoon hotspot. Maar dat moet dan elke opstart van de computer gedaan worden, en mag dan dus niet vergeten worden.

is er geen HAT voor de framboos met een RTC en een supercapje?
Het blijft wel behelpen zo. (persoonlijke mening, geen reactie noodzakelijk)

Kleine vergissing van mijn kant. De Tactic-T plugin zit al in de master catalog van versie 5.6.

Je moet deze wel aanzetten en kiezen wat je er op wilt hebben. Deze geeft ook desgewenst de tijd van de GPS aan.

Data invoer vanuit SignalK direct in het SignalK formaat naar de standaard open CPN 5.6. Dus hier niet de flatpak versie, waar het uiteraard ook in werkt.

Kan er dan op een of andere manier niet een knoopcel o AAAA batterijtje op t mobo van die Framboos gefröbeld worden voor die klok??

Anjo schreef :
Of een videokaart, met daaraan een camera.
Beetje software om het patroon van een klok te herkennen, digitaal of analoog.
Even je horloge voor de camera houden, en dan weet zelfs een Pi hoe laat het is!

Ik zie wel waarom alles hier moeilijk wordt. Sommige mensen zien in alles een uitdaging..


www.kiwi-electronics.nl/nl/pi-rtc-ds1307-3932

5.50 euro om te weten hoe laat het is???