Onderwerp: Mux naar Raspberry zonder USB?

dan moet je dat via de seriele poort doen. Die zit er op een raspberry, maar die is volgens mij TTL en niet op rs232 nivo.
Dus dan moet er weer een omzetter tussen.
usb werkt prima ondertussen, lekker zo houden.

Noorderzon schreef :
Eenvoudig is het niet en het driver probleem speelt niet bij de raspberry pi, omdat de Roosmux zelfs een galvanisch gescheiden USB heeft zie ik niet in waarom je die niet zou willen gebruiken.

Bij mij hangen ze via de usb aan elkaar. Werkt perfect. Baudrate kan veel hoger bij USB waardoor de complete gemuxte datastream zonder problemen in de Pi komt en de door de Pi gegenereerde data (waypoint + routes voor de GPS)probleemloos bij de GPS aankomen.

De seriële poort van de Rpi wordt door het besturingssysteem gebruikt als debug console. Die functie zul je eerst moeten omleiden voordat je hem vrij hebt om aan te sluiten op de mux. Verder is die,zoals opgemerkt, op TTL nivo.
Je kunt ook een andere GPIO pin gaan gebruiken. Daar is echter geen hardware serial uart. Die zul je dan software matig moeten emuleren. Niet echt wat je probeert na te streven als "analoge aansluiting" Ook is deze dan nog op TTL 3,3 volt nivo.
Al met al zoals voorgaande al hebben opgemerkt via usb veel betrouwbaarder.

Koezt schreef :
Sinds ik mezelf wat serieuzer bezighoud met boordelectronica, lees ik graag mee in dit soort draadjes.
Je laatste opmerking roept bij mij een vraag op.
Wat doet de gps met de data die van de computer komt? Er vanuitgaande dat die gps niet meer is dan ontvanger van gps-signalen van satellieten en geen apparaat dat de koers regelt. Dat doet de Pi toch, in dit geval?

Gepost met de officiële Zeilersforum-app

Dat ligt er aan wat voor GPS je hebt,
OpenCPN heeft bijvoorbeeld een functie om waypoints en routes naar een Garmin-GPS te sturen. Erg makkelijk als je die GPS in de kuip hebt, en daar op stuurt, terwijl OpenCPN binnen draait.
Heb zelf een scriptje geschreven die een GPX bestand converteert naar een Magellan Meridian-formaat, en dan door stuurt naar mijn GPS.
Voorbeeld:
Had de pdf van de Ore omgezet naar een KAP-kaartje voor OpenCPN, daarop een route de Ore in gemaakt, en die naar de GPS gestuurd. Je kan dan in de kuip heel precies op een COG naar de Waypoints varen.

Mijn GPS geeft overigens cross track messages uit als je naar een waypoint vaart, dus die kan de autopilot weer aansturen.

Als je een mux hebt met ethernet, is dat een robuste manier om de Pi aan te sluiten.

Anders kan je nog een optocoupler prutsen op een GPIO pen.

Ethernet is tegenwoordig de standaard bij prof. Apparatuur. In het "echie" hebben ze nmea2000 over geslagen.

Gepost met de officiële Zeilersforum-app

WADnWIND schreef :
Naar mijn weten zit er op de mux geen ethernet aansluiting. Is bovenstaand bedoelt als antwoord op de vraag ?

Op zich is de USB/serieel aansluiting op een PI erg betrouwbaar, maar is het wel verstandig om de USB kabels te fixeren of te voorzien van een trekontlasting, alvorens de kabel verder gaat. Inderdaad is er anders altijd een risico dat de stekker los komt onderweg.

Als boordnavigatie PC is het dan ook te adviseren om de PI zelf in een grotere kast te plaatsten, waarin je de USB kabels nog goed vast kan zetten. De connectors zijn dan niet direct meer toegankelijk zonder de kast te openen, maar je hoeft r eigenlijk nooit meer bij.

Er is geen enkele serieuze standaard behuizing op voor de PI die hier in voorziet. het zijn allemaal kastjes voor hobby-bob's op de keukentafel. Leuk voor experiment, maar niet echt bedoeld voor uren hobbelen op IJsselmeer of Noordzee.

Volgens mij ging de vraag meer over de usb driver.
als die faalt dan werkt het niet meer.
Waar windows vroeger daar nogal instabiel was, kun je volgens mij nu wel stellen dat usb best wel goed werkt.
Dan is er dus geen reden om de usb niet meer te gebruiken.

Behalve wellicht als je een losstaande laptop hebt, en bang bent dat je bijvoorbeeld achter het kabeltje blijft hangen. en de boel stuktrekt. Dan is wifi de oplossing.


Overigens, Wat wandwind zegt beweer ik ook al een hele tijd, dat nmea2k nu dus ook uitgefaseerd , en ethernet ingevoerd wordt . Maar dan zit je toch weer met ethernet kabel en pluggen. Dat is voor een gps ontvanger overkill natuurlijk.
Ik denk toch echt dat bij ons aan boord voor 95% van de gevallen nmea0183 gewoon de beste oplossing is.
Behalve wellicht voor radar. Waar extra bandbreedte nodig is. ( om bijvoorbeeld door te geven aan opencpn)

WADnWIND schreef :
Goed dat dit tegenwoordig ergens afgesproken is! Is dit een NMEA standaard? Of een open Signak-K? Wil je wat meer vertellen betreft wat voor taal de apparaten onderling praten? Is er, fysiek gezien, ook hardware gersprcificeerd, connectoren etc? Waar kan ik deze standaard vinden?

En onze Mickey Mouse apparatuur aan boord, hoe staat het daar met de ontwikkelingen? Ik kijk wellicht niet goed, maar ik vind nog geen smart sensoren die een andere taal dan NMEA0183 of N2K spreken. Wordt dit, denk je, dezelfde "standaard" of komen er meer versies van "something via TCP/IP over Ethernet". Als Ethernet protocol bedoel je TCP/IP toch?

nou de genoemde radar dus bijvoorbeeld.Een mede ZF'er heeft een nieuwe radar die via ethernet de beelden doorgeeft aan opencpn. Daar is toen een plugin voor gemaakt.

Je krijgt straks natuurlijk plotters en displays met een ethernet aansluiting in de watersportwinkel.

Wat voor taal spreken deze apparaten onderling? Waar vind ik de specificatie van deze standaard? Is deze open?

roozeboos schreef :
Die zijn er al een tijdje: zo heeft Simnrad de SonicHub, daar kun je 3D fishfinders op aansluiten. Of dit via TCP/IP gaat weet ik niet, maar er wordt voor zover ik weet wel gebruik gemaakt van de electrische Ethernet standaard. Vooralsnog lijken deze voorbeelden op een maatwerktoepassing.

Vandaar mijn vraag waar ik meer over "deze tegenwoordige standaard" kan vinden. Is Signal-K opgenomen in deze standaard, gaan er NMEA1083 of N2K PGN's over of wordt er een merk-specifiek taaltje gesproken?

het zou verstandig zijn om signal-k te gebruiken, maar volgens mij wordt dit volledig genegeerd door de merken die er toe doen.
signal-k is m.i. gemaakt omdat n2K hun specs hebben afgeschermd. (€€€)

Er zijn verschillende redenen en oorzaken mbt het ontstaan van SignalK.
1: De oprichters zochten naar een open protocol zodat ze hun eigen gewenste functies kunnen toevoegen, zonder daarvoor te hoeven betalen.
2: Ze wilden een protocol dat door applicatie/software bouwers eenvoudig is te gebruiken.
3: Het moet goed zijn te comprimeren
4: moet rekening kunnen houden met rechten en time stamps
Vast nog veel meer het is zeer goed doordacht.

Er wordt gebruik gemaakt van Json strings die eenvoudig zijn aan en uit te kleden op de verschillende niveaus, bijvoorbeeld op je eigen schip hoef je niet te vertellen dat het de positie is van je eigen schip, stuur je je positie naar een ander schip of naar de andere kant van de wereld dan is het handig je naam mee te sturen en bijvoorbeeld de tijd van opname.

Het is een taal dat gebruik kan maken van verschillende protocollen/signaal niveaus, zo kun je het versturen over USB, Ethernet, RS232, RS422(NMEA0183) ga zo maar door.

De gevestigde orde snapt er niets van en vindt het maar eng dat open gedoe dus die kijken eerst maar eens de kat uit de boom.
Aangezien de oprichters er niets aan verdienen hebben ze natuurlijk beperkte mogelijkheden en moet je dus een beetje geduld hebben, ik zou graag een berg sensoren etc. voor ze bouwen maar ook ik heb een beperkt budget.
Maar zie waar OpenCPN nu is? Dus dat een goed systeem gratis kan zijn is wel bewezen.

De ethernet protocollen zijn merkgebonden gesloten. Zo heeft Sailor/Thrane&Thrane een nog onbekend protocol waarmee je al hun apparatuur kan bedienen etc.

NMEA183 over ethernet protocol is ingediend door Meindert Sprang jaren terug en zijn voorstel voor poort 10110 is door de daarvoor geëigende organisatie toegekend wereldwijd. Details weet ik niet meer, hij zal je ongetwijfeld willen vertellen hoe het zit.

Verder vrijwel kan elke software overweg met NMEA183 over IP, of het nu Windows, Android en zelfs appel is. het werkt feilloos.

Maar m.b.t. de TS. Is er aanleiding om bevreesd te zijn dat opeens de PI een USB kabel niet meer herkend? Op de PC of laptop is dat niet van belang meer, omdat je elk toestel verbind via WiFi.
Het liefst UDP, dat werkt altijd, in de catagorie "flikker maar over de muur". 1 packet meer of minder merkt niemand.

Aanleiding van mijn verzoek om uitleg wat onderstaand statement:
WADnWIND schreef :
Dank voor de nuancering in de laatste berichten. Om dit zijstapje af te sluiten:

• Ethernet wordt door verschillende fabrikanten gebruikt om specifieke "proprietary" data te versturen van hoge bandbreedte (bv grafische radarbeelden, 3D fishfinders...)
• Er is binnen deze industrie (hobby of "prof. Apparatuur") géén standaard afgesproken hiervoor. Signal-K zou een kandidaat kunnen zijn daarvoor (is dit geschikt om grafische beelden te versturen?)
• NMEA0183 over TCP/IP of UDP bestaat al járen (poort 10110 idd) en heeft m.i. weinig te maken met het al of niet overslaan van N2K.

De ontwikkelingen lijken nog immer op applicatieniveau plaats te vinden. Signal-K zie ik niet als standaard omarmd worden door de grote merken en ik heb nog geen smart sensoren gezien die van een "standaard" (al of niet open) protocol gebruik maken wat over TCP/IP gaat.

Wel jammer want technisch lijkt het mij heel eenvoudig een (bv) dieptesensor te maken die je via een Ethernet verbinding aan een TCP/IP switch hangt. Sensor zou dan Signal-K kunnen praten. De Ethernet standaard staat tegenwoordig toch ook toe om apparaten te voeden dacht ik?

Nachtvlinder schreef :
Jazeker, PoE (power over ethernet)

Gepost met de officiële Zeilersforum-app

nou dat is dus niet zo makkelijk.
een nmea0183 uitgang is gewoon een rs485 chippie van 1,5 euro. En klaar.
Met ethernet heb je wel wat meer nodig hoor, nog afgezien van de grote kabel en de RJ connector.
En dat allemaal om +- 30 bytes te versturen per seconde...

Bedankt allen. Het antwoord op mijn vraag is wel duidelijk: relatief eenvoudig is het niet en ook niet beter of zoiets.

Mezelf afvragend waarom ik het eigenlijk vroeg: een groot deel gevoel dat een USB aansluiting fragieler is dan een de weggewerkte GPIO pinnen. Ook valt het mij op dat Openplotter moeite lijkt te hebben met meerdere USB naar serieel converters: ik krijg dan steeds een waarschuwing dat er conflicten zijn in namen van die aansluitingen. Of zoiets. Tenslotte het argument van WadnWind. Ik ben van huis uit gewend aan 'stevig vastschroeven' van kabels en aansluitpuntjes.

Maar tov een reeds bestaande N2K smart sensor? Daar zit toch ook extra hw, sw en een micro-C kabeltje in/aan vast?

Noorderzon schreef : Is dat een bekend probleem?

Zeilprutser schreef : Ter verduidelijking: wanneer er meerdere converters tegelijk gebruikt worden (dus niet meerdere types/merken converters). Ik had er van de zomer drie tegelijk in en als ik de RPi dan opnieuw startte, dan wees Openplotter mij erop dat er een onderling conflict was. Ik moest in Openplotter dan zelf instellingen wijzigen om de data van de drie converters weer binnen te krijgen.

roozeboos schreef : Volledig met je eens!

Maar het lijkt er op dat veel consumenten alleen maar in verkooppraatjes willen geloven, NMEA0183 is voor die types "uit" ze willen een smart sensor ze denken misschien dat ze daar slimmer van worden
Dus voor die mensen:
Chris en ik ontwikkelen Disruptive systemen waardoor je smartsensoren kunt verbinden met de Cloud door je eigen free roaming netwerk aan boord heb je inzicht in je Big Data die je naar eigen wens kunt visualiseren. Door deze Data Visualization zijn we de Game Changers in de markt.

Keuze hulp:
Bent u slim? neem dan een domme sensor!
Bent u dom? neem dan een slimme sensor!