Onderwerp: RPI als boordcomputer

Maarten-IW31 schreef :
Dat is inderdaad een ander punt van zorg van me: de ssd snoept wat van het toch al beperkte stroombudget van de USB-poorten op. Moet nog wel genoeg over hebben voor de usb hub en de ZP-mux.

Ja zeg....nog ruimte zat in dat hoofd
Kijk eens naar dit screenshotje maar e zijn nog tig meer opties om vanalles weer te geven!:

Hier nog even de test gedaan met mijn SSD PCI-e NVme USB3.

Deze SSD kaartjes kun je veel gebruikt krijgen. Ze zijn dan afkomstig van gevallen tablets etc.

Dan nog een een doosje erbij met een USB3 aansluiting. (Kosten maar weinig bij Ali-Dinges).

Deze SSD kaartjes gebruiken weinig stroom en zijn zeer compact. Al eens eerder een afbeelding hiervan getoond.

Even de instructie gedaan van Tom's hard ware. Eigenlijk niet eens nodig want mijn 64 bits software is al up-to-date.

In raspi-config de usb boot aangezet. Dan opstarten zonder SD kaartje. En dan werkt het niet !!

Er staat namelijk bij usb boot in raspi-config dat het een alternatief is als de SD kaart niet werkt.

De SD kaart eruit halen en starten werkt niet, want de Eeprom staat nu juist op het kaartje.

De oplossing ? SD kaartje zo instellen dat het niet werkt dan start het systeem vanzelf vanaf de SSD HD.

Wat heb ik gedaan ? Het config.txt bestand verandert in config.niks. Dan start het niet op.

En dan werkt het systeem geheel van af de SSD.

Met Piclone (SD kopieer software) vooraf de SD kaart kopieren naar de SSD.

Bram

Good Grief!!!!

Seriously????


Dit kàn bijna niet waar zijn, zo klungelig.

EDIT:
Geprobeerd.

En: De juiste config.txt wordt ook niet van de SSD gelezen. Daarom werkt het aangesloten display niet met de boot van SSD. Die heeft een aantal aanpassingen nodig daarin. De led van de SSD kabel knippert onregelmatig. Ten teken dat er wel vanalles gebeurt.

Daarbij komt nog het probleem wat Maarten aanhaalt. Dan vervang ik het ene probleem waarvoor ik SD kaarten moet wisselen voor t andere.

Dit is echt geen volwassen manier van een produkt maken!!!! Ja, Roos, ik hoor je gniffelen.

Conclusie: Geen SSD. Dat juice-pi ding er ook uit. Ik ga t er gewoon op wagen, en zorg dat ik als backup een laptop in de buurt heb. Bij de eerste SD crash trap ik dit hele project de vullisbak in. Te veel onvolwassenheden voor mij als niet diep-IT-er.

Ja, Joop het staat er gewoon bij in de raspi-config. Als het systeem om welke reden niet opstart dan start het systeem van een USB apparaat een stick of een USB HD.

De logica is dan eenvoudig. Het systeem niet laten opstarten vanaf de SD kaart. Door de config.txt uit te schakelen door deze andere naam te geven. Dan start het systeem wel van de SSD of USB stick. Hier met RaspiOS 64 bits.

Met de Piclone software kun je eenvoudig de image van het SD kaartje naar de SSD of USB stick kopieren.

Zo als je kunt zien is de SSD ext4 geformatteerd. Kan zo'n mini SSD aanbevelen vanwege compacte vorm in een alu huisje en een beperkt stroomgebruik.

Het draait hier al weer enige uren achter elkaar.

Ja, de mogelijkheden met RPI zijn vrijwel onbeperkt. Het is in principe bedoeld als automatisch backup van de SD kaart.

Groet, Bram

brambo schreef :
Ja, maar jongens.... Dan heb ik dus nodig:

Èn een SSD met mn hele junk er op,
Èn een SD met de juiste EEPROM, en een slechte config.txt,
Èn een goede SD om de SSD te kunnen fixen als die zich een keer verslikt heeft.

Wat heeft dit met betrouwbaarheid te maken?

Waarom kan die EEPROM toestand niet gewoon op de SSD staan? We gingen daar toch vandaan booten?

Ik snap alle logica, maar niet om t een of ander, als me dit op zee overkomt, dan hoor je kort daarna gewoon "plons" hoor!

Misschien efkes terug naar mijn beginvraag:

Wat heb ik nodig om op een RPI betrouwbaar en robuust OpenCPN te draaien?

Je hebt nog steeds niet begrepen. Die optie is bedoeld als extra zekerheid voor het geval de SD kaart niet zou werken. Je kunt dan gewoon met precies hetzelfde programma's doorgaan. Hetzij op een usb stick of (SDD) HD.

Uiteraard staat de Eeprom ook op de SSD. Echter de RPI heeft geen BIOS. Dat is de Eeprom.

Er zullen ongetwijfeld andere manieren zijn. Maar zo werkt het hier.

Aan alle kanten is er veiligheid beschikbaar met automatisch starten backup systemen zoals een USB stick of een USB SDD. De complete image hierop zetten is kinderlijk eenvoudig.

Dat kan met geen enkel ander computer systeem.

Ik begrijp ook niet waarom je SignalK niet toepast. Allemaal logische systemen.

Groet,

Bram

Met robuust en betrouwbaar bedoel ik: je zet m aan, hij doet t. Je zet hem uit. Je zet hem aan, hij doet t weer. Geen mitsen, geen maren. Zoals je van een plotter van bijv Raymarine zou verwachten.

Wat is dáár voor nodig?

SignalK heb ik niet aan de gang gekregen. Mogelijk werkt t. Maar ook werd de RPI veel heter met SignalK dan zonder. Warm=stroom. Zal best deels aan mij gelegen hebben. Maar zonder SingalK mis ik niks geen enkele functionaliteit.

Je zet de plotter aan en uit. En nu doet het ding met een heel netwerk het niet meer, wat met alle systemen kan gebeuren. Wat dan ? Waar is de back-up ? Waar is de monteur of de helpdesk als je op zee zit. Plons overboord gooien ? Dan heb je helemaal niets meer.

Kastje openmaken ?

Als je RPI systeem goed hebt opgezet en niet allemaal gaat zitten veranderen (kl...n), dan heb je een betrouwbaar modulair systeem. Met automatisch werkend nog een backup met een usb stick of een SSD.

Of wat backups met wat losse back-up SD kaartjes. Voor een paar tientje heb je ook nog een tweede systeem aan boord. Mocht je getroffen worden door zoiets als een blikseminslag.

Onderweg moet je problemen zelf op kunnen lossen en kennis hebben hoe dingen werken, zowel voor de navigatie als voor andere technische zaken.

Dat is een leerproces.

Bovendien doe je al doende kennis op hoe het werkt. Dat is ook het oorspronkelijke idee achter de RPI.

Het idee dat SignalK je stroomgebruik verhoogt is ook maar een idee. Als je leest hoe het werkt dan is dat ook logisch in te stellen. Dat alle in- en uitgaande data in een aparte server draait is ook een zeer goede opzet.

Zelfredzaamheid dat is het uitgangspunt.

Bram

brambo schreef :
Kijk, Dáár zijn we t over eens.

Alleen zie ik t niet als acceptabel om tijdens het varen, met een golfhoogte van 2 meter, onder een hoek van 30 graden te gaan lopen klooien met SD kaartjes, terwijl buiten de aanloop van de Maasmond links en rechts om me heen vliegt.

Dus dan blijft over de vraag:

Hoe lossen deze gabbers dit op?

pcnautic.nl/nl/producten/boatcontroller

columbusgoes.digital/

Hoi Joop, je gaat van de hak op de tak, lekker eigenwijs, heel veel geduld en bij de laatste loodjes geef je het soms ineens op!
Hoeveel moeite heeft het me wel niet gekost je aan die multiplexer te krijgen!

Laten we daar ff over beginnen:Laat er nu nog een powermodule op die "ZP-mux" kunnen! Die kan dan meteen de USB weer extra voeden. Ja ik heb nagedacht over dat soort zaken!
Nu je ook eindelijk overtuigd bent die juice-pi er uit te gooien zou je mijn manier van stroomvoorziening eens kunnen bekijken!
Joop66 schreef : Wil je nu een boordcomputer (topic titel) of een plotter?
Eigenlijk wil je beide met alleen de voordelen van beide systemen als dat simpel zou zijn......

Je wil een betrouwbaar systeem ik heb er meer dan 300 in boten liggen over de hele wereld met alleen een sd kaartje er in, kennelijk is dat betrouwbaar genoeg!
"je zet m aan, hij doet t. Je zet hem uit. Je zet hem aan, hij doet t weer." Deze worden hoofdzakelijk als data router gebruikt, gebruik je hem met OPenCPN als plotter dan moet je ze wel afsluiten.
Dat betekend niet dat jouw systeem betrouwbaar is (weet ik veel wat jij allemaal uitspookt) maar het kan wel.
Echter je hebt die ssd er toch al in liggen waarom zou booten van ssd dan niet betrouwbaar zijn?

Ik lees hierboven iets vaags over eeprom op ssd??? De eeprom zit alleen op de pi4 en daar staat gewoon het bestandje in dat verteld o.a. waarvan hij zijn besturingssysteem moet opstarten:
Dus Joop, gewoon ff de boel goed op een rijtje zetten en lekker doorgaan je komt er wel!

Joop66 schreef :
Beste Joop,

heeft de RPI tijdens het varen ooit geweigerd ? Dat ontstaat pas als je er mee gaat veranderen en prutsen.

Een door en door betrouwbare opzet maken met voor de zekerheid een paar back-ups.

Daarnaast een experimenteer opzet om nieuwe dingen uit te proberen. Die Sandisk SD kaartjes met 32 GB heb je al voor € 8,-.

Op de OpenPlotter site het bericht dat er iemand de wereld is rondgezeild in 3 jaar tijd met een RPI als navigatie systeem.

Met SignalK kun je diverse apparaten instellen zoals een GPSmuis. Die werkt dan pas als je de GPS muis aansluit.

Eerder aangegeven dat een GPSmuis is aan te raden als reserve. Voor een paar tientjes heb je een losse usb muis met GPS, Galileo, Glonass of Beidou. Ais kan uitvallen en dan heb je altijd nog een GPS die je zo kunt aansluiten.

Alle electronika blijft kwetsbaar. Reserve delen in een blikken doos opbergen.

Groet,


Bram

Zeilprutser schreef :
Ja, dat kostte even. Ik had een werkende oplossing voor dat moment. Alleen inderdaad zonder de nette optische poorten. Dat zat me nooit heel lekker, maar als er 1 ding is waar ik spits op probeer te zijn: kosten. In tegenstelling tot wat ik sommigen zie doen, kan ik me heel veel daarvan gewoon niet permiteren.
Zeilprutser schreef :
Geinig Idee. Alleen: bij de minste stroom vanuit de USB poort de RPi terug in, gooit hij de USB poort dicht. Einde verhaal. Had dit probleem met een extern gepowerde USB hub. Ik gebruik die hub nog immer alleen zonder power. Maar dan wordt dit wel een dingetje.

Of stel je voor de RPi en t scherm helemaal via de USB te voeden?
Zeilprutser schreef :
Goede opmerking: ik wil een robuust systeem waar OpenCPN op draait. De rest zijn franjes.

Zeilprutser schreef :
OpenCPN is dus de bottle neck? Waarschijnlijk omdat dat ook naar de SD kaart schrijft? Dan komt Rooie Dirk weer om de hoek kijken: Kan OpenCPN zo geprogrammeerd worden dat routes, logs, tracks op een door de gebruiker te bepalen plek worden opgeslagen? Zoals dat bijv met de kaarten al zo is?
Zeilprutser schreef :
Zie opmerkingen Maarten hier boven. Blijkbaar heeft hij de ervaring dat er toch nog wel eens wat mis gaat. Dan heb je toch weer een SD kaart nodig om de zaak te redden. En andere dan die er in zit, want die was onklaar gemaakt.
Zeilprutser schreef :
Ik ben nu een week aan het klooien geweest om de SSD aan de gang te krijgen. Zonder SD kaart. Maar dat is me dus gewoon niet gelukt. Ik ben prima bereid om met het inrichten van een systeem helemaal van scratch te beginnen, firm- en software-wise. Wat ik feitelijk ook gedaan heb. Maar hij doet t gewoon niet.

Het zou wel fijn zijn als ik mijn kastje en display kan houden.

Gewoon even naast je bestaande opzet en nieuwe opzet maken met de laatste inzichten.

Hier werkt het prima vanaf de SSD. Was in een half uur werkend. Speelt nu muziek af.

Er zijn ongetwijfeld andere manieren. Werken vanaf een SD kaart gaat ook prima. Bij de 32 GB van het kaartje heb ik nog de helft van de capaciteit over.

Bram

And what about de optie:

Boot op SD (Read only), en dan doorstarten op de SSD?
Hoef je zelfs de eeprom niet te updaten...
Zit alleen nog met een probleem dat heel af en toe de config van de OpenCPN weg is. Nou heb ik daar een kopie van op de SSD, dus een keer kopieren en hij doet het weer, maar irritant is het wel.

It Paradyske schreef :
In mijn idee de beste aanpak. Een read only besturingssysteem waar de log functies van linux naar een ram disk gaan en voor alle andere schrijf operaties een ander partitie,stick of ssd gebruiken. Wat van belang is dan om te zorgen dat na elke schrijf operatie de buffers ge-fflusht worden. Of een kernel maken die schrijf buffers op regelmatige basis wegschrijft.

3Noreen schreef :
Nou, zover gaat deze oplossing niet... Alleen de boot partitie op SD, en de gewone partitie op SSD.

Krijg de hele SSD niet werkend. Dus tot dat moment is de rest van de discussie nogal prematuur.

Mbt het flasen van SD-kaartjes en kopien ed:

Ik heb een net image gemaakt van de "Gouden" SD kaart waar ik afgelopen zomer mee heb gevaren. Probeer die nu op een identieke SD kaart te schrijven:



Pardon, reeds???

Toch maar een kale RPi OS er op en dan in de RPi opencpn er op.

Kaarten van O-charts even ophalen:



Echt waar?

Gelukkig werkt de "gouden" kaart nog wel.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Het begint er op te lijken dat ik de bedoeling heb om aan te tonen dat een rpi niet geschikt is voor een serieuze toepassing.

De waarheid is: Dat is niet zo. Ik wil echt HEEL GRAAG dat t betrouwbaar werkt.

Ik rapporteer wat ik tegenkom. Ik verzin dit echt niet. Sorry dat ik me verexcuseer, maar blijkbaar voelt t nodig.

Joop66 schreef :
Die fingerprint is bedoelt om kopiëren tegen te gaan. Dan lijkt me het toch niet zo verbazend dat een kopie niet werkt.
Er is voor wat jij wilt een oplossing in de vorm van een USB dongle.

3Noreen schreef :
Die usb dongle als kopieer beveiling werkt prima op de SSD. En ook op andere systemen met dezelfde kaartenset.

Je kunt een tweede kaartenset kostenloos verkrijgen voor de usb dongle. Je moet alleen een usb dongle aanschaffen bij O-charts. En dit neemt ook weer een usb poort in. Op een hub overigens werkt het ook. Wat ook het geval is met mijn usb SSD. Wel wat langzamer omdat de hub geen usb 3 is.

Bram

3Noreen schreef :
Het idee is dat die fingerprint ook op basis van je hardware wordt gemaakt. Een kopie in dezelfde RaspberryPi zou dus moeten werken, maar het SD-kaartje (kopie of origineel) in een andere RaspberryPi niet.

3Noreen schreef :
Het is geen kopie. Het kopieren werkt niet. Tweede SD kaart heeft ineens minder capaciteit.

Het is een frisse RPI OS, op dezelfde RPi. De fingerprint werkt op de RPI. Dat zou zo moeten zijn, tenminste.

brambo schreef :
Lezen Bram: SSD werkt Überhaupt niet.

Joop66 schreef :
Andere software kan ook een iets andere fingerprint geven, daar ging het hier blijkbaar mis.