Onderwerp: RPI als boordcomputer

Zal het extra stroomgebruik met en zonder Signalk wel eens opmeten. Stroomgebruik zegt meer dan temperatuur verschil.

Stroom gebruik meting uitgevoerd:

Raspberry Pi 4. Tussen meter en het net de RPI voeding.

Aangesloten op de RPI 4 een draadloos toetsenbord.

GPS muis 9600 voeding uit de usb.

HDMI naar de monitor aangesloten. Niet de voeding van het beeldscherm.

OS Fedora 42 voor de RPI. (aarch64)

1. OpenCPN 5.12 met GPS muis 9600 invoer serieel. > Gebruik 5.0 watt

2. OpenCPN 5.12 met invoer Signalk-server werkend. SignalK server opgestartm > Gebruik > 4,4 watt

Verder dezelfde configuratie. Alles uiteraard met de laatste software versies.

Bram

Goede meting, Bram.

Dit Bevestigt t inderdaad ongeveer. En dan doet SK nog maar nauwelijks wat. 14% voor iets wat ik niet nodig heb...

Zoals je weet, Bram, heb ik t geprobeerd. Uiteindelijk, if memory serves correctly, kreeg ik de communicatie vanuit SK naar de AP niet voor elkaar.

Vanuit OpenCPN is dat appeltje eitje.

Joop66 schreef :
Hé, dat is interessant, zij het een beetje off-topic. Wat voor AP? Want bij mij werkt SignalK naar AP wél en OpenCPN naar SignalK ook, maar OpenCPN via SignalK naar AP niet. En daar puzzel ik al een tijd mee om.

Eclips schreef :
Zie een hele discussie eerder hier in dit spul.

Binnen OpenCPN kun je gewoon com poorten aangeven en daar NMEA informatie heen sturen.

Options> Connect> Add connection (serial)

Dan gaat t verder afhankelijk van N2K of 0183 architectuur.

SK is niet nodig voor OpenCPN. Wel voor allerlei tablet achtige instrumenten. MXTommy en zo.

Maar dat wil ik niet. Hoogstens ooit nog een keer een kaart bij de stuurstand.

brambo schreef :
Mijn nieuwe RPI 5 met MacArthur HAT en ICM-20948 module draait (nog) op een SD kaartje. Kan ik daar gewoon een kopie van maken op een USB3 USb stick? Dat moet ik waarschijnlijk wel eerst ergens instellen dat de Pi in het vervolg van USB opstart?

Je hebt kunnen zien. De Signalk-server gaat efficienter met de data om dan in OpenCPN.

Dat is ook logisch OpenCPN is navigatie software en de SignalK-server is er voor alloe data en tegelijk ook een multiplexer.

Neem vooral de laastse versie. Omzetting nmea183>NMEA2000 en andersom werkt probleemloos.

Instrumenten met verschillende baud rates. De lijst van plugins is teveel om op tenomen.

Je kunt de data vanuit OpenCPN zo naar SK voeren en daar omzetten naar NMEA2000 netwerk of een bepaalde poort met NMEa183 voor een autopilot.

Het is toch volstrekt logisch om data en navigatie te scheiden. Ook al staat OpenCPN uit dan werkt de SK server nog steeds om andere systemen te bedienen.

Je moet je er wel even in verdiepen en niet direct zeggen het werkt niet.

De techniek gaat maar door. In MXTommy is nu ook een applicatie voor autopilot.

brambo schreef :
Ik heb helemaal niks gezien! Jij claimt alleen iets!
Wij zijn hier juist druk bezig het hele Signalk uit elkaar te rukken omdat het als geheel te veel performance vraagt voor onze commerciële toepassing. De hele toepassing is al klaar maar door Signalk vertraagd de boel te veel voor wat het voor ons hoeft te doen dus....

Zeilprutser schreef :
Een Signal-K bericht (dat is in XML uitgedrukt) is tot 600 keer zo lang als het NMEA0183-equivalent.
Tel uit je winst.

Zeilprutser schreef :
Beste ZP,

ik ben geen man van zomaar beweringen. Als je goed had gekeken heb ik aangekondigd het stroomgebruik te meten en heb daar verslag van uitgebracht. SignalK data en dan de data in SK formaat naar OpenCPN (5.12) gebrukt minder stroom dan dezelfde serieele invoer direct in OpenCPN.

Alles verder in dezelfde opzet op RPI4 met Fedora 42.

Meten is weten. Het is steeds hetzelfde liedje. Nieuw ontwikkelingen zijn niets, gebruikt teveel stroom etc.

brambo schreef :
Zo efficient dat ie 15% meer stroom gaat gebruiken met dezelfde data-load, volgens jezelf.

Sjetonneke schreef :
Als je de laaste Eeprom op je systeem hebt staan, start je systeem op van een USB stick of een SSD. In de het menu raspi-config kun je de boot volgorde instellen, maar het hoeft.

Je SD kaartje kun je met de SD kopieer optie eenvoudig naar de USB kopieren in het RaspiOS.

Wel een snelle USB 3 stick gebruiken. Ik gebruik zelf de Samsung Fit Plus 64GB leessnelheid tot 300 mb/s. Werkt bijna net zo snel als een USB3 HD.

Joop66 schreef :

Ik denk dat je de post met meetdata even opnieuw moet lezen.
Daar staat namelijk het omgekeerde van wat je nu schrijft.

Namelijk:

1. OpenCPN 5.12 met GPS muis 9600 invoer serieel. > Gebruik 5.0 watt

2. OpenCPN 5.12 met invoer Signalk-server werkend. SignalK server opgestartm > Gebruik > 4,4 watt


Dus met SK minder verbruik, niet meer.

Blijft wel het feit dat instellen van SK niet altijd even logisch en eenvoudig is.

Tony2920 schreef :
Ow..... Oeps.

Zit er dan wel ook de GPS muis aan?

Sorry Bram.

brambo schreef :
Misschien een domme vraag, is een USB stick memory niet een SD kaart in een andere behuizing? Wat maakt dat dit meer device meer bestand is tegen veel schrijfacties?

Hoe het inwendig werkt weet ik ook niet. Het is in ieder veel robuuster dan zo'n dun SD kaartje.

En de leessnelheid is hoger. Ik gebruik die dingen al geruime tijd en nooit een uitval gehad.

Een nadeel is wel dat je een usb poort minder beschikbaar hebt.

En voor de kosten hoef je het niet te laten. In mijn instrumenten paneel een usb3.1 stopcontact waarmee is de gewenste OS versie kan gebruiken.

Bram

Het is wel logisch want Linux is een op diverse servers gebaseerd OS. Zo is er de grafische server, de printer server en wel meer. Als er daarnaast ook nog de SK server draait onafhankelijk van OpenCPN dan is dat logisch een betere toepassing dan de applicatie ermee te belasten.

Bram

SD, micro-SD (=TF), USB-sticks en eMMC zijn meestal Flash geheugen.

Als je simpelweg intikt bij Google "256GB micro SD vs 256GB usb-stick", dan geeft de AI jou het antwoord dat een USB-stick sneller is en door de USB-plug betrouwbaarder is bij vaak verwisselen.

Ik waag te betwijfelen of de USB-stick nog lang een concurrent van de micro-SD kaart blijft, omdat de laatste wordt doorontwikkeld voor foto- en filmcamera's (en drones). En veel data-uitwisseling gaat via internet tegenwoordig dus de behoefte aan USB-sticks neemt af.

Reuver2 schreef :
Anders dan USB stick, kun je (heb ik gedaan op aanraden van Bram en testen) de zaak ook opbouwen met een SSD (Solid State Disc drive) Wat daarmee het precies het verschil met een eMMC weet ik niet, die laatste term ken ik niet.

De reden voor mij was: de gevoeligheid voor corruptie na een power down. Dat doet een SD kaartje echt niet heel lekker. Ook heb ik er tijdens het bouwen een paar echt stuk gemaakt. Wel vervangen onder garantie, maar het geeft aan dat er iets niet helemaal lekker robuust is.

Met SSD nergens problemen mee. Wel eens de plugins van OpenCPN kwijt, maar dat was t dan wel weer. OM dit op te vangen, maak ik een backup van de .opencpn folder na elke wijziging die ik aangebracht heb. Die zet je in 20 seconden weer terug.

De MacArthur HAT met power module heeft de speciale optie die bij uitschakelen de Pi automatisch correct afsluit. Dus geen kans op beschadiging van de microSD kaart. De power module heeft hiervoor een dubbele + aansluiting. Wordt de extra + verbroken dan zorgt de normale voedingsaansluiting voor een correcte shut down. Ik heb het getest en dat werkt prima.

Sjetonneke schreef :
Da's mooi. Toen ik de mijne bouwde was die er nog niet. Ik heb wel een andere powerHAT geprobeerd, maar die werkte niet ok. Kreeg ook geen support bij de fouten. Dus weg.

Joop66 schreef :
Een SSD is wat Reuver2 een NVME noemt.

Joop66 schreef : Als je het simpel houdt is het verschil tussen SD(TF), eMMC en NVME de controller.

Net als TF heeft NVME een beperkt aantal schrijfcycli, daarna sudden-death. Maar ht gebruikt vaak betere wear leveling algoritmes en de restlevensduur is uit te lezen (nvme => smartmontools. Niet dat ik smart ooit heb zien werken met een usb-nvme adapter.

Daarna heb je nog veel abstracte ideeen bij mensen dat NVME sneller is (niet relevant), betrouwbaarder (slechts meer schrijf-cycli) of universeel toepasbaar met een USB-casing (waarmee naar mijn mening alle slechte eigenschappen van nvme versterkt naar boven komen).

In vergelijking is een USB-stick lomp maar wel enigszins betaalbaar en robuust. Een USB-stick vervang je binnen een minuut. En je hebt geen adapters nodig om ze te bewerken (hoewel je ze misschien niet met Windows kan lezen en schrijven).

Volgens mij kwam Bram met de USB-stick omdat je voor de prijs van 1 nvme met usb case meerdere usb-sticks kunt kopen. En omdat de RPI4 kan starten vanaf USB. Zelf kies ik eerder voor onboard nvme, waarbij je wel alle voordelen van nvme hebt en je niet tegen een beperkt aantal usb-poorten aanloopt (niet alle systemen hebben 4x USB).

Bedankt voor de heldere uitleg Reuver2. Ik haal vandaag de geadviseerde SAMSUNG USB stick op.

brambo schreef :
brambo schreef :
Echt logisch vind ik het niet. in scenario 1 had OpenCPN 1 verbinding, met NMEA0183, en scenario 2 OpenCPN nog steeds 1 verbinding (met Signal-K). Signal-K is een minder efficiënt protocol dan NMEA0183 (JSON is wel makkelijker te lezen voor een mens, maar niet per se voor een computer). In CPU-cycles voor OpenCPN verwacht ik geen significant verschil tussen de twee scenario's. Maar in scenario 2 is er nog een ander programma (signalk-server) daar ook CPU-cycles gebruikt.

Hoe lang heb je in beide scenario's gemeten? Was het verbruik de hele periode constant?