Onderwerp: Installeren Nuc als plotter met Debian en OpenCPN

De packages en ook de flatpack worden in principe door OpenCPN zelf gemaakt en aangeleverd bij Debian/Ubuntu. In zo'n package zit in principe ook een lijst met 'depencencies' (Of ingeval van een flatpack de depencies zelf) Het kan wel eens gebeuren dat de ontwikkelaars van zo'n dependencie een funktie verwijderen of een andere naam geven in een nieuwere versie waar O dan niet mee uit de voeten kan.
De plugins voor O staan(stonden) inprincipe helemaal zelfstandig, waarbij de ontwikkelaar van de plugin zelf moe(s)t zorgen voor het installeren, onderhoud, dependencies etc. In de laatste versie van O is dit vervangen door een plugin-manager, die het zoeken van de juiste PI en het installeren/updaten verzorgd.
Voor de oudere versies van O staan de plugins ook nog gewoon als package op het internet. Deze kan je ook gebruiken in de nieuwste versie van O, al vindt de PI-manager dat niet fijn.

En hoe zit het dan als packages externe dependencies nodig hebben? Bijvoorbeeld als een plugin die GRIB-files wil weergeven afhankelijk is van libgrib-api of libeccodes?

rooiedirk schreef :
Het flatpack zelf had geen moeite met de dependencies net als OCPN zelf in Debian 11 die keurig met apt install OCPN installeert. Alleen de PI-manager vind behalve de vier meegeleverde plugins geen andere. Dus in mijn geval zit de PI-manager me gewoon in de weg. Mijn vermoeden is dat de architectuur verkeerd uit uname gehaald wordt. Er is tussen diverse packet installers wat conflict. dpkg die het uiteindelijke deb zal moeten installeren wil een amd64 package architecture De PI-manager "denkt" dat het x86_64 moet zijn. Afgezien dat een underscore nu in 11 geweigerd wordt in de package architecture aanduiding. Anders zo je ook dpkg kunnen vertellen toch een x86_64 package te installeren.

Menno schreef :
In de .deb file staan toch de dependencies ? Als je die eerst opzoekt en installeert dan is er niets aan de hand. dpkg -I package-name geeft een overzicht wat de vereisten zijn.

3Noreen schreef :
Dat werkt als de plugin als .deb komt. Als de plugin via de plugin-manager wordt geïnstalleerd heb je via dpkg alleen de dependencies van opencpn zelf geïnstalleerd, niet de eventuele dependencies van de plugin.

Menno schreef :
Als de plugin-manager van OCPN geen plugins vind dan is het niet aan de orde welke depenencies er voor een niet gevonden plugin zijn.
Die hele plugin-manager en de benodigde infrastructuur bevind zich nog wat mij betreft in een alpha stadium.

In middels wel uitgevonden dat mijn rubberband probleem bij het uitzetten van een route niet aan de gebruikte desktop environment ligt. Op een andere machine werkt het wel naar behoren. Nu gaan zoeken hoe het zit met de grafische drivers van de Nuc zit.

Een filmpje ter illustratie van mijn rubberband probleem bij het uitzetten van een route.
Het eerste stukje is zonder tussenkomst van de GPU van de NUC het tweede stukje met GPU van de NUC.
Sugestie's zijn altijd welkom. Ik heb inmiddels de non-free intel drivers geïnstalleerd.

Inmiddels de bios van de Nuc ge-flashed. Mocht niet baten. Misschien moet ik maar met deze eigenaardigheid leren leven.

JotM schreef :
Beetje een principe kwestie. Je omzeilt shared libraries van je systeem (die als het goed is veilig en up-to-date zijn) ten faveure van een complete kopie van de software en AL ZIJN DEPENDENCIES. En dat zijn er nogal wat.

Debian bewijst dat het ook anders kan (meestal) met een up-to-date ecosysteem van heel veel packages. Het vraagt wel dat de package manager zijn best een beetje doet om het pakket werkend te houden. Dat gebeurt hier blijkbaar niet (of niet goed genoeg).

[edit]Dirk legt uit waarom - het gaat hier om plugins met andere software auteurs. Ligt dus niet direct bij de OpenCPN auteurs maar meer bij het plugin concept.[/edit]

Als je dan toch naar een externe niet-debian beheer vorm gaat heb ik liever een PPA waar alleen de extra pakketten aangeboden worden en niet ook nog de hele rataplan aan libraries die al lang op mijn systeem aanwezig zijjn.

Om het PI verhaal even compleet te maken:
De 'oude' manier was dat iedere plugin als ppa gedistribueerd werd en waarbij iedere PI dus zijn eigen dependencies moet bijhouden. En het OS/gebruiker moet zorgen dat de juiste versie van de PI geinstalleerd wordt.
Op de 'nieuwe' manier worden de PI's geinstalleerd als onderdeel van OpenCPN (voor linux in ~/.opencpn), in user space dus. En OpenCPN zorgt dat de juiste versie geselecteerd wordt. Dit laatste gaat bij 3Noreen dus niet lekker.

Misschien wordt dit draadje voor een buitenstaander verkeerd begrepen. Het is absoluut niet zo dat ik me frustreer of erger aan OpenCPN of Debian. Ik vind het gewoon een leuke en leerzame uitdaging om een zo stabiel mogelijke installatie voor elkaar te krijgen. Niet tevreden zijn met iets wat "werkt". Een werkende versie waar een groot deel van de gebruikers tevreden mee zouden kunnen zijn had ik al een paar weken geleden.
Het is natuurlijk uiteindelijk ook plezierig om er straks een hele goede plotter er aan over te houden. Vorig jaar heb ik namelijk al aan de lijve mogen ervaren dat de geboden o-charts op het wad o.a. vele malen beter zijn dat mijn RM plotter en Navionics me voorschotelen.
Ooit tijdens mijn studie heb ik tegen een mede student uitgeroepen dat niet de kaas interessant is maar de gaten. Niet dat wat je al weet maar wat je nog niet weet. Zo zit ik als mens in elkaar. Dat gaat ook na 60 jaar ook niet meer veranderen.
Dit terzijde als kleine intermezzo om dit draadje te duiden.

Net een doorbraakje Zowel in minder complexe en beter te onderhouden installatie als dat de GPU beter aangestuurd wordt door OpenCPN. Mijn create route werkt nu perfect.
-Bois update van de nuc gedaan.
-Een nieuwe en schone Debian 11 netwerk installatie.
-Sudo geactiveerd
-contrib non-free toegevoegd aan sources.list
-Dan intel drivers geinstalleerd
Nu kan gewoon via de packet manager OpenCPN geïnstalleerd
Dat levert een perfect werkende OpenCPN op die ook prima routes maakt.
Helaas hetkent de interne PI manager nog niet de voor mij benodigde plugins.

Dus gebruik ik de door mij zelf al eerder van broncode gebouwde deb's

Voordeel van deze werkwijze is dat het een systeem oplevert wat op een normale manier geüpdatet kan worden en rock solid is.
Als in de toekomst de PI-manager wel gaat werken kunnen de plugin's ook geupdate.

Op verzoek nog even een uitleg hoe ik virtuele com poorten maak zodat meerdere programma's nmea data kunnen ontvangen. Bijvoorbeeld Opencpn en BK zijn software.
Hiervoor gebruik ik een programma wat kplex heet. Gelukkig staat dat tegenwoordig op github en is daardoor makkelijk te installeren.

Nu moeten de poorten die je wilt gebruiken nog beschreven worden.
Daarvoor bewerk je het voorbeeld bestand wat meekomt van github.

in de tekstverwerker (nano) verander je het volgende stukje tekst.

Ik heb daar zelf het volgende van gemaakt aan te passen aan de eigen wensen;

Hierna moet je dit bestandje zetten waar kplex het verwacht.

De volgende stap is zorgen dat al de computer opstart ook kplex automatisch start

Nu zorgen dat je als gebruiker toegang hebt tot de poorten. Voor elke virtuele com poort het volgende. In mijn voorbeeld

Je moet zelf ook tot de dialout groep aan behoren. Waarbij je in plaats van <user> je eigen inlognaam gebruikt

Nu zou alles moeten gaan werken als de computer opnieuw opstart.


Na herstart kun je in opencpn de connction /dev/ttyOpenCPN speed 38400
En soortgelijk in de andere software

Ik gebruik de netwerkpoort en dat ziet er zo uit.

3Noreen schreef :
P'cies wat ik nodig had. Dank!

Tot nu toe, in mijn idee, heeft dit project de "standaard" installatie doorlopen. Waarvan ik verwacht dat iedereen die van een linux computer een plotter wil bouwen zal doorlopen. Misschien met het verschil dat ik de installatie procedure zo veel mogelijk met een terminal venster uitvoer vanuit een andere computer via SSH. Het aangesloten scherm is het plotter scherm met een fullscreen OpenCPN. Het geklooi met linux gebeurt remote vanaf mijn laptop.

Maar nu heb ik ook een paar wensen die ik naar mijn idee beter zelf kan programmeren / bouwen dan daar al door anderen gemaakte open source software voor te gebruiken.
Het programma wat ik geschreven heb gedraagt zich als een man in the middle. Aan de ene kant bevinden zich de input bronnen van de nmea data. Aan de andere kant de gebruikers van de data.
De gebruikers zijn mijn stuurautomaat, NKE display, RM plotter, OpenCPN, Web server om aan boord met een browser zeil data schermen te tonen, een Data logger, En als laatste een alarm buzzer.
Mijn programma zorgt dus dat alle data gebruikers de juiste data krijgen.
Onderstaande schema geeft een overzicht hoe de data doorgegeven wordt.
Mijn "man in the middle" programma is nogal in de afgelopen jaren organisch gegroeid. Waardoor het niet bepaald de schoonheidsprijs voor gestructureerd programmeren verdient.
De komende tijd wil ik een poging doen om hier verbetering in aan te brengen.

Gisteren bracht de post mijn Akasa Plato X8 passief gekoelde behuizing voor de Nuc. Wel een flinke plak aluminium met een behoorlijk gewicht . 2350 gram om precies te zijn. De plaatjes spreken wel voor zich denk ik. Ook moeten de wifi antennes buiten de alu kast gemonteerd worden.






links de nieuw fanless case recht de nuc.

na delicaat gepriegel is de transplantatie voor een groot deel achter de rug. In de twee grijze pijpjes, helemaal links, zitten de wifi antennes.




Op het einde nog even opstarten. Wel spannend. En in de bios instellen dat hij nu doorgaat als fanless.

Indrukwekkende kast met veel koeloppervlak!

Nachtvlinder schreef :
In mijn werk heb ik veel te maken gehad met thermodynamica. Wel is waar niet in verband met elektronica maar nadat ik te maken kreeg met falende zaken als dynamo's en raspberry's door oververhitting valt het kwartje snel. Het verbaast me ook dat hier op ZF wel gezocht wordt naar 4k schermen en minstens een i7 processor. Allemaal fanless graag. Als er vervolgens maar een paar koelribben te zien zijn is men dik tevreden.

Dat geldt ook voor mijn miniPC. Niet te vergelijken met jouw kast. De praktijk zal het leren; ik neem aan dat het niet alleen over het niet overschreiden van Tj,max van de CPU cores gaat, maar dat lagere temperaturen de levensduur ook verlengen.

Vandaag leuk aan het freubelen geweest. Als resultaat een alternatief voor een muis. Behoorlijk goed te bedienen met koude natte handen. Niet erg ergonomisch. Maar ik ben er geen uren mee bezig. Dit is nog een beta versie. Bij het spelen er mee kwam ik er achter dat een plus en min toets wel heel handig zou zijn om direct in en uit te zoomen.

Nu een tijdje in praktijk getest. Veel pluspunten t.o.v. RM C120 plotter. Behalve dat de o-charts niet erg stabiel zijn. Na 5 - 8 uur loopt het vast. Bij gebruik van cm93 kaarten komt dit probleem niet voor. De ondersteuning van de o-charts plugin onder Debian laat voor als nog te wensen over. Wordt vervolgd. Men richt zich, lijkt het, liever op systemen waar er niet zo nauw beoordeeld wordt op stabiliteit zoals bij Debian wel het geval is.

Ondertussen goed zicht op het stroomverbruik in gebruik.

NUC verbruik 6,5 Watt. Terwijl OpenCPN + ontvangst NMEA draait + Wifi acces point en internet via aangesloten (USB) iPhone. Scherm niet aan.

Je weet toch dat de o-chart plugin een vroege beta is?? Voor normaal gebruik kan je beter de oesenc plugin gebruiken. (Tenzij je ook toegang hebt tot de test-server van O-charts)
Ter illustratie een stukje van mijn inbox over deze o-chart beta

rooiedirk schreef :
Tot nu toe heb is het mij niet gelukt om de oesenc plugin te installeren in mijn Debian Bullseye systeem. Niet via de pluging manager, niet via een tarball zowel ppa als via git en een eigen build. Ook een deb built werkt niet. Dus ik hou me aanbevolen voor een tip hoe ik dat zou moeten doen. Voor als nog zie ik de oesenc plugin als een doodlopende weg.

Ik heb alleen dit gevonden.
https://github.com/OpenCPN/OpenCPN/issues/2150