Onderwerp: Navico radar i.c.m. Raspberry Pi

Ik heb een Navico 3G radar op de kop getikt en ik had al een Raspberry met Openplotter en OpenCPN. Ik weet dat het mogelijk is om de radar in OpenCPN met behulp van een plugin werkend te krijgen. Softwarematig kom ik er waarschijnlijk wel uit zeg maar. Maar de manier van bekabelen is voor mij nog vaag.

Er komt een kabel met RJ45 stekker en een voedingskabel uit de radar dome. Die gaan wanneer een standaard MFD display gebruikt wordt allebei via een Ri12 Interface box naar dat MFD display. Ik wil het nu dus op de Raspberry aansluiten, maar het schijnt dat het niet geadviseerd wordt om die RJ45 vanaf de radar rechtstreeks in de LAN poort van de Raspberry te steken.

De vraag is of hier iemand met ervaring hierin is of weet hoe ik dit moet aanpakken?

B.v.d.

Radar overlay gaat inderdaad met een plugin. Deze plugin gebruikt wél OpenGL, en dat is nogal een probleem op een Rpi.

Maar even zoeken op het Cruisers Forum moet je een stuk wijzer maken.
bv http://www.cruisersforum.com/forums/f134/help-wiring-rj45-connector-for-navico-radar-213616.html
Maar er zijn nog meer

Beste Dirk,

OpenGL is geen enkel probleem met de Raspberry Pi. Je moet de (full) VC4 driver aanzetten in raspi-config.

En de laatste kernel versie gebruiken. Nu 4.19.49-V7+. (sudo rpi-update)

Dan werkt het buitengewoon goed en snel. Echter geen OpenGL texture cache instelling gebruiken.

De radar plugin werkt volgens de ervaringen van derden prima in combinatie met de RPI. Bij voorkeur een RPI3B+ en een snelle Sd kaart.

Groet,


Bram

Je kan een gewone switch gebruiken. Om van simnet naar ethernet te gaan heb ik een keer iets gepost, kan het zo niet vinden. Maar behelst niet meer dat stekkertje aankrimpen. Hier met een 4G radar op open cpn en dat gaat uitstekend.

Hoe weet je eigenlijk van welk ipadres de radar gebruik maakt?

Gepost met de officiële Zeilersforum-app

De meeste nieuwere apparaten met een ethernet aansluiting kunnen automatisch detecteren of er een normale kabel of een cross kabel aangesloten is en dan automatisch zich hierop aanpassen. Een raspberry kan dit niet. Om de radar direct op de raspberry aan te sluiten heb je een cross kabel nodig. Met gewone kabels zal er een hub/switch tussen moeten.

alweereengijp schreef : Die had ik bewaard
zie bijlage:

Bedankt voor alle richtingaanwijzers en tips. Dat helpt me op weg. Ook de pennummering plaat is handig!
Mijn systeem komt aardig overeen met dit plaatje:



met deze NMEA0183 interface box:



Wat ik nu van jullie begrijp is dat ik een kabel moet maken die van de 'Network' aansluiting van de afgebeelde interface box, rechtstreeks de Raspberry netwerk aansluiting ingaat.

Maar wat ik niet begrijp aan het bovenste plaatje in deze post is dat de NMEA0183 heading data dezelfde 'Network' poort in lijkt te gaan. Je zou verwachten dat de NMEA data de 'Comms' poort in zou moeten?

En mijn laatste vraag: als ik niet de heading sensor NMEA0183 data wil 'invoegen' dan zou ik toch die hele interface box kunnen skippen en de kabel met RJ45 aansluiting die vanaf de radar komt rechtstreeks in de Raspberry stoppen? Ik heb sowieso heading data in OpenPlotter/OpenCPN.

In mijn handleiding staat:

Bedankt Dirk, die informatie had ik gevonden. Maar MARPA gebruik ik praktisch niet echt, het gaat mij meer om een stabiel noord-boven plaatje. En daarover lees ik (ik geloof in je link naar Cruisersforum) dat het wel geadviseerd wordt om de heading data bij de interface box in te voegen, maar dat noord-boven ook werkt wanneer OpenCPN zelf die heading data al heeft...

Tja je mag het zelf weten natuurlijk maar als je ARPA hebt danwel kunt krijgen... Zodra je meer als één target tegelijk in de gaten wilt houden is het toch wel erg gemakkelijk.

brambo schreef :
Zucht, daar gaan we weer. Een herhaling van zetten: OpenGL is een enorm probleem op de Pi, tenzij je het scherm via hdmi aanstuurt. Wat meestal het geval is bij externe schermen. Dat doet Brambo en daarom werkt het bij hem probleemloos. Een Pi met een eigen scherm, zoals het officiële 7 inch touchscreen, is meestal aangesloten op de DSI-interface en dan is OpenGL een no-go.
Waarom schrijf ik dit dan, als het een herhaling van zetten is? Omdat er altijd iemand kan meelezen die de informatie voor het eerst ziet, op basis daarvan doodleuk openGL aan zet en vervolgens getrakteerd wordt op een zwart scherm.
Dat wil overigens niet zeggen dat de radar-plugin niet zou werken. Want voor de DSI-interface heeft de ontwikkelaar een workaround gemaakt in de vorm van de Fake VC4 driver. Dan wordt OpenGL softwarematig geëmuleerd.

Ik zucht ook maar weer, als beweerd wordt dat OpenGL niet goed zou werken.

Nu is de aansluiting naar de meeste monitoren HDMI of DVI en daar gaat het over. Met andere beeldschermen heb ik geen ervaring en vind het vreemd dat dit daarop niet zou werken.

De grafische processor bepaalt de werking van OpenGL en niet het beeldscherm.

Groet,

Bram

brambo schreef :
Je mag best zuchten, maar je weet heel goed dat het probleem bestaat, dat het goed gedocumenteerd is en dat de ontwikkelaar om die reden de fake driver heeft geschreven.

De GPU bepaalt inderdaad de werking van OpenGL, maar voor de GPU van de Pi is de ondersteuning nog verre van compleet. Daarom heeft het geheel ook nog steeds de "experimental" status. En tussen de GPI en het beeldscherm zit de grafische interface. De Pi heeft er twee, DSI en HDMI. DVI is in dit geval helemaal niet van toepassing, dat heeft de Pi niet. Aan die grafische interface hangt een software-implementatie, het is meer dan alleen een connector. En blijkbaar is daar nog werk te doen, want OpenGL over HDMI werkt wel en OpenGL over DSI werkt niet.
En zodra jij weer schrijft dat het probleemloos werkt, zal ik herhalen dat dat slechts ten dele klopt.

Bram schrijft altijd dat alles goed werkt op de raspberry. Totdat er weer de zoveelste update beschikbaar is.
Dan werkt het ineens weer prima... (??)

Je zou natuurlijk kunnen wachten op de ultieme update waar alle problemen mee opgelost zijn.
Kan echter wel even duren...

Nu zal er ook wel weer een boze reactie komen van Bram
Hoeft niet, ik ben gewoon realistisch.

Het probleem is dat Brambo niet weet wat DSI is, gewoon kort en duidelijk melden:
Eclips schreef :

Wie zonder zonde is, ....
Wil de software die geen bugs kent opstaan.

Maar zonder gekheid zelf heb ik veel meer vertrouwen in open source dan brakke gesloten software. Niet voor niets draait het overgrote deel van de apparaten in de kern op open source. Inclusief de meeste smartphones.

je schrijft in je zin dat open source prima is en gesloten brak.
Lijkt me nog al kort door de bocht. En is volslagen onzin.
Er is ook heel veel brakke open source en prima gesloten software.

Maar goed je hebt het over vertrouwen, en dan is emotie, en meestal niet gebaseerd op keiharde feiten.
En is natuurlijk ook niks aan te doen, ik zal je ook niet kunnen overtuigen. En probeer het dan ook maar niet.

Mijn emotie is dat ik juist minder vertrouwen heb in open source : omdat iedere jan doedel van alles kan gaan zitten veranderen in de broncode. Ongetwijfeld met de beste bedoeling. Maar iedere verandering is nog geen verbetering. Zo blijkt wel bij de rpi.
Maar goed we dwalen nu af.
Let's agree to disagree.

roozeboos schreef :
Daarom ben ik ook zo hardnekkig in het temperen van Brambo's enthousiasme, hoe leuk ik de Pi ook vind. Dit probleem bestaat al sinds de eerste ondersteuning van OpenGL, op dit moment zo'n 2 jaar geleden. Het is nog steeds niet opgelost en de ontwikkelaar weet dat ook. En even goed schrijft Bram hier na iedere firmware-update dat het "probleemloos werkt en de kaarten over het scherm vliegen", terwijl dat slechts voor bepaalde configuraties klopt.

oh ik vind de rpi ook leuk hoor. Heb er zelfs een piggy back voor ontworpen. toegegeven, wel in opdracht, anders had ik het niet gedaan.
Grote FPA erbij. Geeft een hoop leuke toepassingen. Zoals ineens wel voldoende seriele poorten..

roozeboos schreef :
Als dat graag wilt kan ik wel wat voorbeelden geven.
Positieve;
90% van de smartphones draaien in de kern op open source
90% van alle internet routers, jawel open source
meer dan 50% van alle internet servers .... open source.
Waarom, omdat het veel betrouwbaarder is. IBM heeft zeker 10 jaar geleden hier ook onderzoek naar gedaan en is tot een soortgelijke conclusie gekomen. Niet op onderbuik gevoelens maar op basis van harde dollars.

Als negatieve wil ik er wel een paar voorbeelden van gesloten software noemen waardoor de kwaliteit van de hardware volledig te niet wordt gedaan. De hardware zo goed als waardeloos is. Ondanks eindeloze rij van updates.

Zelfs dat je hier een forum hebt is te danken aan open source.

Zoals ik al zei, let's agree to disagree.

ZF en OpenSource is wel een leuke vergelijking (Buiten de software die gebruikt wordt) Open source is vooral kennis en kunde delen en beschikbaar maken aan anderen. Dat is duidelijk iets wat het forum doet (even afgezien van alle dwaalsporen die gemaakt worden)Niet iedereen kan zomaar veranderingen aanbrengen in de broncode van een project. Je kan een voorstel tot verandering/verbetering indienen(pull-request), dit wordt dan bekeken, beoordeeld en indien goed bevonden wordt het opgenomen.
Wat wel kan is je eigen kopie van de broncode aanpassen en weer ergens op het grote www dumpen, maar dat is wat anders dan het originele project aanpassen/verkloten.

Okay, in dat geval. En wie beoordeelt dat?
nb:
Ik ben overigens meer een embedded ontwerper. Dan is kennis van de hardware wel degelijk aanwezig.
Vandaar waarschijnlijk mijn twijfels.
Dat is een heel ander nivo dan forum software wat op linux draait.
Bovendien draai ik bij 98% van de projecten niet eens een operating system. Dat scheelt ook een hoop bugs.

Je plaatst een 'pull request' op de github(meestal) van het project, en dan is jouw voorstel code met reden waarom en hoezo voor iedereen die wil (meestal vooral mede codeurs) te zien en van commentaar te voorzien. En pas bij een algemene consensus wordt het dan opgenomen.
Hier github.com/OpenCPN/OpenCPN/pulls staan bv wat openstaande requests voor OpenCpn.