Onderwerp: RPI als boordcomputer

brambo schreef :
Nou, overal waar je daar iets van leest op internet, wordt je hel en verdoemenis beloofd als je niet op allerlei speciale manieren er voor zorgt dat je de poorten goed vastspijkert. Maar dat lijkt dus reuze mee te vallen.

Wat ik ook niet verwacht had, is dat SignalK zoveel rekenkracht gebruikt, dat t gewoon zoveel warmte scheelt. Want dat is echt VEEL: een delta T met de omgeving van 25 graden of 40!!! Dat is een verschil in stroomverbruik van bijna een factor 2.

Joop66 schreef :
Allo Joop,

nooit iets gemerkt van sterke toename van het stroomgebruik door SignalK. Wat wel wat scheelt is de kernel versie. De processor temperatuur was hier eerst tot 50 o C en nu met de 64 bits versie rond de 42 o C met de laatste kernel versie. Werkt kennelijk efficienter.

Zo'n server toepassing vergt maar weinig energie. Het Linux systeem is in feite opgebouwd uit servers.

Bram

rooiedirk schreef : Nog even een kleine toevoeging. Als je OpenCPN nmea bepaalde regels laat 'uitzenden', zorg dan dat dezelfde regels weer uitfilterd op de ingang. Sommige apparatuur stuurt nmea dat binnenkomt door naar de uitgang (OpenCPN ook). Om te voorkomen dat de data gaat 'rondzingen' moet je deze dus ergens blokeren.

@ Bram volgens mij heb je nog niet door dat Joop Openplotter niet meer gebruikt.
Anyway ik vermoed dat het opvallende hogere processor verbruik icm Signalk en Openplotter ook werd beïnvloed door eventueel rondzingen.
Maar ook ik zou het er af gooien als je het niet gebruikt.

@ Rooie dirk,
Dat geldt ook voor de zinnen voor de AP?
Ik laat deze uitzenden zoals onderstaande. Dan zou ook de invoerpoort die niet moeten accepteren?
Ik gebruik een invoerpoort via de usb van de mux en als een uitvoerpoort een Aten usb 232 converter.

Dat is inderdaad verstandig. Ik heb aanboord 2 GPS'en en eentje stuurt alle ingangdata mee naar de uitgang. Een ingebouwde multiplexer zeg maar.
Als je het niet doet loop je de kans op 'rondzingen', en dat is erg lastig om op te sporen. Of OpenCPN loopt vast door een overschot aan inputdata, of data raakt 'weg' door een overbelaste nmea lijn. En om te voorkomen dat je bv in jouw geval bij een nieuwe stuurautomaat opeens een plotter hebt die het niet meer doet, is het verstandig om dit altijd te doen.

Zeilprutser schreef :
Beste ZP,

je hebt het gebruik van de OpenPlotter opties nog niet begrepen.

Het is a geen besturing systeem. Alleen een hulpmiddel om bepaalde applicaties te gebruiken. Maar dat hoeft natuurlijk niet. Je kunt eenvoudig hiermee installeren wat je zelf erop wilt hebben.

Wie wil er nu geen draadloos Access punt om op zijn tablet de data of met VNC het scherm te kunnen bedienen. Of een alias voor je usb poorten aansluitingen.

Je kunt dat uiteraard ook zelf wel proberen te maken.

Hoe eenvoudig is het om OpenCPN te installeren of de SignalK server.

Maar het hoeft allemaal niet. Al gebruik je niet meer dan een item zoals xyGribs.

Dan is de installatie erg eenvoudig.

Zou het eerst maar een zelf proberen.

Groet,


Bram

Zeilprutser schreef :
Rondzingen lijkt me sterk:
1: Ik had de uitgang van jouw mux nog niet aan de gang.
2: Die is aangesloten op de AP. De AP geeft geen data door. Die stuurt alleen zijn eigen HDM signaal uit, en de roerstand sensor. Verder gebeurt er op die uitgang niks.

Als er iets heeft rondgezongen, is dat binnen SingalK.

Overigens had ik eerder een keer op windows iets dergelijks gedaan met NavmonPC. Als dat rondzingt, loopt de pc binnen een seconde vast.

Joop66 schreef :
Als je de verbindingen binnenhaalt via SignalK en via het interne netwerk (localhost) doorsluist naar OpenCPN, heb je geen rondzingen. Als je GPS invoer direct en OpenCPN aanbrengt en ook nog naar dubbel op naar SignalK verplaatst, ja dan doe je het niet goed.

SignalK is tegelijk de multiplexer.

Bram

brambo schreef :
Met alle respect, Bram, maar ik vond t niet eenvoudig. Ik vond t ingewikkeld. Misschien niet t juiste woord. Misschien is abstract een beter.

Vooral omdat ik geen mogelijkheid gevonden heb om data stromen op elk punt binnen SignalK te zien. Daardoor blijft het maar "vertrouwen" dat t goed gaat. Het leek er om die reden ook op dat de datastroom van OpenCPN naar SingalK niet op gang kwam. Maar dat weet ik dus niet zeker. Want ik kon nergens een thermometer in steken, en de data stromen daadwerkelijk bekijken.

Het lijkt me ook omslachtig: NMEA 0183 komt binnen, wordt omgezet naar SingalK, wordt omgezet naar NMEA 0183, gaat naar OpenCPN. Van daaruit komt er een datastroom terug, NMEA0183, gaat naar SingalK, naar NMEA0183 voor de seriele poort.

Maar goed. Voorlopig ben ik SignalK-vrij, en blij.

En inderdaad: Ik wil geen draadloos Access Point voor tablets.

Ik hoop dat je begrijpt dat ik dit op geen enkele manier persoonlijk vervelend bedoel. Maar de waarheid is gewoon: Ik kwam er niet uit. Mogelijkerwijs kom ik er nog achter dat t toch anders moet. Ik ga er achter komen.

Joop66 schreef : Dat bedoel ik ook, gezien de instellingen die je toen gebruikte was ik iig de draad kwijt.
Daarom zat ik de hele tijd om die flowchart te zeuren.

@Joop66

Ik heb het al eerder aangegeven. In Openplotter is er een optie de gehele data stroom van SignalK te tonen ook van de NMEA2000 invoer. Met vertalingen wat de NMEA2000 codes zijn. Dus de combinatie van in en uitvoer vanuit verschillende verbindingen.

Zie bijgaande schermafdruk. Hiervan mijn NMEA2000 GPS invoer en via localhost zichtbaar in OpenCPN.

Er is in SignalK nu ook een applicatie voor een autopilot. Of het werkt ? Ik kan het hier achter mijn bureau niet proberen.

Hier het installatie scherm. schijnt ook te werken in de applicatie MXTommy.

Zeilprutser schreef :
Nou ja, de flow die ik wilde hebben, was heel simpel.

Maar welke ik uiteindelijk gemaakt heb??? Geen idee.

Volgens mij niet veel. Want ik zou geen idee hebben hoe dat zou moeten.

Maar daar zit ook meteen het risico in: ik kan dus ook niet nagaan of ik t niet gemaakt heb.

Allemaal roepen dat t heel simpel is, doet niet ter zake.

Ik vind een dieselmotor allemaal heel simpel.

Of een tandwielkast.

Of een (mechanisch) horloge.

Ik vind een dieselmotor allemaal heel simpel.

Ja, dat was vroeger. Nu hangen er computers aan vast voor de commonrail inspuit ventielen en andere regelsystemen, die vele malen ingewikkelder zijn dan een RPI.

De meeste monteurs hebben al geen begrip meer, hoe de software allemaal werkt.

Gelukkig hebben ik nog een ouderwetse diesel in de boot, waar ik zelf de controle over heb.

brambo schreef : You're missing the point.....

brambo schreef :
In het verleden bekeken deze plugin bekeken er is iig een multiplexer/adapter voor nodig die de speciale NMEA "$seatalk" sentences ondersteunt en omzet naar native seatalk berichten en die dan ook op de werkelijke seatalk bus doorstuurt. Deze plugin werkt dus ook alleen voor Raymarine autopilots. Ik dacht dat die van Yachtdevices dat die speciale sentences ondersteunt, geen idee of de Roosmux dit kan (staat niet expliciet op de product site vermeld?).

Deze speciale NMEA sentences pakken de rauwe seatalk berichten in en zorgen ervoor dat ze herkenbaar zijn voor devices die deze kunnen verwerken (=op de seatalk bus zetten).

@Rooseboos, wellicht ook interessant voor jouw om deze plugin te analyseren (seatalk sentences eruit peuteren), want je kunt er ook de autopilot mee in en uitschakelen (standby/auto) (en autotack?). Wellicht mooi te integreren in de bestaande oplossing met radiografische afstandbediening om zo de 'volledige' autopilot mbv de goedkope RF remotes werkende te krijgen.

PvO schreef : dit soort discussies met Bram zijn echt zinloos. Ik heb dat allang opgegeven. Old dog/new tricks...

Orange Sunset schreef : dat zie je correct, qua roosmux. Deze kan lezen en schrijven van en naar seatalk.
en die afstandbediening naar seatalk zit er ook al in.

roozeboos schreef :
Allo beste Roos,

je zou toch niet meer reageren.

Ik probeer informatie te verstrekken over de laatste stand van zaken om anderen te helpen. En wie kijkt er meestal als eerste naar deze laatste informatie ? Overdag en gedurende de avond ? Dat weet je zelf het beste !

Groet,

Bram

Ik reageer toch ook niet op jou, ik reageer op PVO.

Eentje voor Rooie Dirk, denkelijk.

In OpenCPN laat de windveer zich niet zien.




Hij staat wel aangevinkt in "tactics":


OpenGl staat ook aan:


Winddata komt ook binnen, in de vorm van, VWT, VWR en MWV.

De gedachte bekroop me: misschien heeft de windveer MWD nodig.

Dus: NMEA converter opgehaald.

Volgende probleem:

Werkt niet.


HDG data komt binnen:



Iemand?

Voor de record: dit is dus op RPi4

Joop66 schreef : Eh ik zie in je nmea converter plaatje "no data" wat dus betekent dat het niet binnen komt. Ik ken de tactics plugin verder niet, maar moet daar HDG of HDT in? en je snelheid? je hebt use SOG ipv STW niet aangevinkt, heb je wel STW data die binnenkomt?

Als ik naar de NMEA berichten kijk kloppen daar een paar dingen niet aan tov de NMEA afspraak. Een bericht begint altijd met ?,! (of ~ maar dit is een gereserveerd karakter), dan een TALKER ID van 2 karakters bv GP en dan 3 karakters voor de sentence gevolgd door een komma; dus bv: $IIDBT,

Ik zie in jouw voorbeelden o.a. dat er ??HDG1 staat, HDG1 is geen sentence identifier of er is een ',' vergeten tussen HDG en 1. Kortom een ongeldig NMEA bericht.
Ik zie ook en $SDDBT_002 bericht ook dit is geen geldige sentence identifier (DBT_002).

Ik weet niet of je die berichten ergens manipulieert, maar daar zou ik eerst eens naar kijken. Voor de NMEA berichten kan je hier een hoop info vinden: NMEA opbouw

@Yazz,

De laatste foto is het schermpje van nmeaconverter, waar je de formules in geeft voor t bewerken van de berichten. De foto daarboven zie keurige nmea berichten. Dat is wat er binnen komt.