Onderwerp: RPI/OpenPlotter betrouwbaar ?

brambo schreef :
Daar heb ik geen enkele noodzaak toe laat staan behoefte aan. OpenCPN ontvangt alles draadloos, gewoon via een 0183 server waarin alle beschikbare boorddata in gemultiplexed is (door een apparaat dat daar heel goed in is wel en plug&play is) (net als W10)

Dat Flirc kastje is nep. Die koel pilaar is namelijk hol. Je hebt daardoor een minimale doorsnede aan warmte afvoerend materiaal.

nobody schreef :

Nou ja, ik het nu verschillende installaties gedaan, verschillende os-sen, ook 32 bits en 64 bit maar bij mij blijft het onwerkbaar traag.
Ik verwacht geen wonderen maar als ik kijk hoe snel opencpn op een eenvoudige smartphone werkt kan ik mij niet voorstellen dat een rpi 4 dat niet ook moet kunnen.

Maar waarom het niet goed gaat na het volgen van de instructies op internet snap ik ook niet. Misschien doe ik iets bijzonders

lschip schreef :
Gebruik je toevallig VNC?

Geen idee waar dit aan ligt.

Ik vertrouw Openplotter niet helemaal.

Toen ik t er op had staan, werd de rpi heet.

Nu alleen opencpn. Prima goed.

Beste NV,

dan gewoon W10 blijven gebruiken. Als dingen niet mogelijk zijn, dan heb je er uiteraard geen behoefte aan.

De Raspberry Pi is ontwikkeld door de Uni van Cambridge om gebruikers kennis bij te brengen hoe je dingen kunt instellen en werken.

Dat is een wereld van verschil.

Groet,

Bram

Precies. Veel gebruiks die snel, goedkoop en makkelijk een navigatiesysteem in elkaar willen zetten lijken zich dit niet vooraf te realiseren. Het “snel” en “makkelijk” moet dan eigenlijk “leerzaam” worden. Leerzaam is het zeker!

Maar is het niet mogelijk een 8GB image op onedrive oid te zetten? Laat zich toch wel kleiner zippen ook? Hoewel ik er geen tijd meer in wil stoppen, ben ik wel benieuwd hoe snel het nu moet kunnen werken. Een 8 GB inage kun je ook op een groter kaartje zetten toch!?

Als dit niet duidelijk genoeg is, dan doe een voorstel het aan te passen?

nobody schreef :
Ik kan alleen de praktijk weergeven. In SignalK is een applicatie om de processor temperatuur af te lezen en deze te tonen in de MXTommy/Kip html display.

Hierbij het voorbeeld met de ronde display ingesteld voor de temperatuur.

Bram

brambo schreef :
Wat is dat nou weer voor redenering...

Beste Menno,

lijkt mij toch wel erg logisch. Als iets niet kan, dan leggen gebruikers zich er maar bij neer.

Evenals, iets na een update niet meer werkt, dan kopen ze andere hardware.

Bram

Nachtvlinder schreef :
Nachtvlinder heeft wel een punt vind ik.

Als je handig bent met windows, is een windows-based navigatie-systeem wel makkelijker..
Ik ben blij met de image van Bram, Daardoor ook een zorgeloos systeem op een rPi. (Maar mijn Linux kennis is niet goed genoeg om zelf zaken in te gaan stellen, toe te voegen... daarvoor moet ik echt gaan googlelen..)

Wil je het systeem enorm uitgebreid maken, dan is iets meer kennis van windows of linux (of de wil dat te leren) wel belangrijk.

Wil je echt snel en makkelijk. Koop dan een kant en klare plotter. Zelfde merk instrumenten erbij, en dan is het plug en play (kost wel iets meer..)

Het niet mijn bedoeling een discussie voor of tegen de RPi+OpenCPN aan te zwengelen. Het heeft absoluut een plaats. Omdat ik op ZF vele “performance” klachten zie en dat (zelfs met SSD) ook mijn ervaring is, heb ik voorgesteld of Brambo (die bijna standaard nacelke update zegt dat het “nu echt supersnel” is) een supersnelle image te delen. Dan kan men zelf ervaren wat “supersnel” is om te weten of daar zelf tijd en leermomenten in te stoppen om het voor iemand’s specifieke situatie aan te passen.

Dat ik ergens geen behoefte aan heb is omdat gerenommeerde hardware die ik al had in de multiplex functies voorzien. Het ging mij puur over OpenCPN.

Kan dat, een gezipte 8GB image delen?

Het is mij niet gelukt om een lekker vlot werkend systeem met OpenCPN, o-charts en radar op een Rpi4 werkend te krijgen. Nu heb ik voor dit seizoen een linux installatie op snellere hardware gezet. Het prijsverschil en stroom verbruik tussen een Rpi4 met 8Gb ram plus een ssd en een goede behuizing met actieve koeling is ook mijns inziens zo klein geworden om nog voor een Rpi te kiezen.
Uiteraard gebruik ik nog wel Linux als besturingssysteem.

Nachtvlinder schreef :
Mijn mage is inclusief diverse kaarten waaronder de bekende C???? kaartenset en een MBTiles kaarten set van Atlantisch kust met daarop de Google Earth beelden van het landschap.

Allemaal in 64 bits. Met de 64 bits plugin voor Oesenc kaarten. En uiteraard de laatste SignalK versie. De kaarten zou ik kunnen verwijderen.

Kan eens proberen om te kijken wat de uitkomst is na zippen.

Het is niet overdreven, dat er grote sprongen vooruit zijn gemaakt in de software en kernel ontwikkeling.

Dat is een SSD niet erg veel sneller werkt komt eenvoudig omdat deze in het algemeen gekoppeld wordt aan een USB3.1 poort. Daar ligt de limiet.

Zo'n PCIe NVMe SSD module is razendsnel, maar dan moet je wel een PCIe bus connector hebben. Het eerder aangegeven Tofu boardje voor professionele toepassingen, heeft die wel alsmede het Raspberry Pi CM4 boardje.

store.oratek.com/products/tofu

Zal eens kijken hoe het comprimeren uitvalt.

Je hebt zelf een Raspberry Pi 4 en een Actisense NGT-1. Wat let je om het gewoon eens te proberen.

Bram

Geen boot op dit moment, maar ben zeker benieuwd hoe vlot de kaarthandling thuis is. Maar steek hier svp alleen tijd in als (veel) meer mensen hier behoefte aan zouden hebben! Je hebt voor mij al eerder een kaartje gemaakt; dat heb ik ook zolang laten liggen tot het verouderd was. Mijn eigen “leermomenten” daarna hebben mij de trage ervaringen gegeven. Ook op de RPi 4 laatst.

Actisense NGT heb ik eenmalig gebruikt om een N2K apparaat te configureren met de Airmar PC software; NMEA kreeg ik aan boord gewoon via TCP/IP Wifi server binnen. Daarom (persoonlijk) ook geen belang bij de “Openplotter Extra’s”

Zonder Openplotter en signalK werkt t prima vlot.

Ook kaarten scrollen.

Toch is er inderdaad wel iets met display en RPI: De grafiek van de windgeschiedenis maakr te rpi trager naarmate die meer gevuld is.

Mensen die voor een Windows route kiezen, snap ik helemaal.

Alleen al de Serial applicatie waarbij je de usb apparaten een "alias" geeft, zodoende dat ze herkent worden ongeacht de usb poort waar je ze insteekt. Kan zelfs ook in een usb hub zijn.

In Windows moet je gaan zoeken in welke compoort het apparaat werkt en moet je deze poort ook weer gebruiken als je de dingen opnieuw aansluit. Ook op simpele dingen, als een GPS muis, moet ik wachten op drivers die moeten worden geinstalleerd.

De NMEA2K data kan ik zien in de OpenPlotter applicatie. Zo maar een paar punten.

Nu je toch boot-loos bent is de tijd aangebroken het allemaal eens te proberen.

Bram

ik heb totaal geen problemen met traagheid.
Pi4 4GB met een Sandisk Sdcz73-032G als opslag, ik heb bewust gekozen voor USB, kan ik snel een backup maken.

Openplotter, SignalK, SDR VHF, Pypilot, I2C Sensor, WireGuard, vnc ect.

Ik zie wel dat, SDR aardig wat CPU pakt, Maar ook weer niet heel veel




Wat zegt jou "taskmanager" ik gebruik htop ipv top


WireGuard samen met VNC gebruik ik voor remoteaccess.

jossie67 schreef :
Dit zegt htop:



Maar zodra ik in of uitzoom zie ik dit:



Maar Brambo gaat voor mij een sd kaartje vullen, ik neem aan dat het dan beter zal gaan...

Ff snel tussendoor: Als grafische zaken een probleem zijn (en met SSD wordt dat niet opgelost) staat OpenGL dan wel aan in OpenCPN??

Maarten-IW31 schreef :
Ja.

SSD lost t wel deels op, tov SD, vanwege de random open toegankelijkheid, maar niet helemaal.

Zie mijn klacht hier. (SisterMoon)

www.cruisersforum.com/forums/f...dash-t-226601-5.html

Ik snap de argumentatie niet helemaal: het bijhouden van dit soort grafieken in NavmonPC werkt fantastisch. Op Windows. Dat wel.

Maarten-IW31 schreef :
Ja, die staat aan...

Er is veel geroepen in dit draadje, maar waarom wil je eigenlijk RDP gebruiken?
Misschien dat het onder Windows sneller is, dat lijkt me geen garantie dat dat ook voor Linux en speciaal de RPI4 geldt.

Puur vanuit achtergrond zou ik verwachten dat meer gebruikers VNC gebruiken met een pi. Daarmee zal de kans groot zijn dat dat beter wordt ondersteund en uiteindelijk snellere software oplevert.

Ervaringen met Windows extrapoleren naar Linux is over het algemeen geen goed plan.

Mijn idee was om de RPi4 als blackbox te gebruiken met het iPadPro scherm in native resolutie als scherm. Daarbij werd OpenGL niet ondersteund. Maar dat was niet de reden van het traag zijn: met bedraad aangesloten monitor en OpenGL ingeschakeld was het ook traag. Beide met dezelfde 64 bit kernel.

Ik vermoed zo langzamerhand dat het subjectieve “snel” bij de RPi4 iets anders betekent dan onder een Windows m3 processor systeem. 99% van de tijd zijn beide systemen idle, maar als er iets grafisch moet gebeuren of kaartfragmenten van schijf moeten worden gelezen is presteert de m3 echt zonder zichtbare vertraging.

Mss kan iemand een filmpje maken van wat er mogelijk is bij de RPi4? Dat scheelt images downloaden en zelf uitvinden. Zeg maar voor diegenen die geen behoefte hebben aan “leerzame Linux momenten”...