Onderwerp: nmea wifi repeater

roozeboos schreef : Ach, 't is niets
Hier is nog een screenshot van m'n scope. Mijn SeaTalk bridge zendt een datagram (het eerste byte wat je ziet in de trace, deze trekt de lijn mooi naar 1 à 2V), dan begint net aan het einde van dat byte jouw mux een datagram (jouw mux trekt de lijn maar net onder de 5V overigens) en de resulterende mix levert een 180 op, de start van een '80' datagram voor de sturing van de verlichting. En de twee volgende bytes zijn 00 dus "licht uit". Kennelijk begint jouw mux al te zenden terwijl de lijn nog "busy" is.

roozeboos schreef :
Kijk dat bedoel ik nou: gentelmans talking

Krijg alleen dat screenshot niet geüpload. Ik kan toch wel gewoon een plaatje meesturen hier???

mhsprang schreef : heb het plaatje nog niet.
Maar het eerste byte moet wel een command byte zijn. (met het eerste of laatste bitje hoog of laag, dat weet ik niet zo.)
anders mag de ontvanger dat niet als een goed bericht interpreteren. gebeurt dat dan ook toevallig?
evengoed is het wel een waardeloos protocol.

mhsprang schreef :
Wat voor bestand is het?

roozeboos schreef : Ik heb 'm je gemaild. Op zich is er niks mis met dit protocol. Er zijn heel veel indutriele protocollen die ofwel ook een 9-bit addressing gebruiken of framing d.m.v. idle-time tussen de frames, zoals Modbus. Ik heb momenteel een paar installaties waarbij de MiniPlex middels Modbus sensoren en flow computers uitleest en omzet naar NMEA. Gaat perfect. Het is alleen zaak dat wanneer je zo'n protocol programmeert, je op framing niveau de boel goed test en probeert te verstoren. Wanneer dat allemaal goed werkt, is de rest een eitje.

Faran schreef : Een BMP.

Een BMP file moet lukken
Voeg bestand in. bestand kiezen en openen, dan op voeg in klikken.

Niet met je eens dit keer . Checksum is toch wel het minimale wat erin moet.
evenals een lengte byte.
pas dan kun je herkennen dat het een corrupt bericht is. Zeker met 1 datalijntje is dat zeer belangrijk!
Maar goed, er is toch niks aan te doen, het is een gegeven.

Faran schreef :

Nou, niet dus....

Ik heb je een PB gestuurd.

@edit Even getest. Een BMP file lukt dus niet Renamen van het bestand ook niet. In Paint geladen en gesaved als png file en daar is-ie dan:

roozeboos schreef : Ben ik wel met je eens. In ieder geval één van beide maakt het al een stuk betrouwbaarder.
Toch is dat SeaTalk redelijk solide en de kans dat er een bitje 'omvalt' is niet zo groot op een klein gesloten netwerkje. En als dat gebeurt bij Seatalk, is dat niet zo erg omdat de informatie steeds herhald wordt en de meeste waardes worden gemiddeld door de instrumenten. Ik zag overigens ook dat jij voor de positie alleen 50 en 51 verstuurt. Waarom niet 58 ook? Daar is de precisie 10 keer groter. Als je die beide ook ontvangt en omzet naar NMEA 0183, moet je 50 en 51 negeren wanneer je 58 omzet, omdat je anders een NMEA positie krijgt die heen en weer springt. Been there, done it wrong. Fixed it

dat kan zijn , maar sommige berichten worden niet herhaald, zoals het licht uit commando.
En drie maal raden welk bericht wel eens verkeerd wordt geinterpreteerd...

De start bericht identificatie hangt af van 1 bitje. En iedereen mag tegelijk gaan zenden.
nou moet je wel meteen stoppen bij een collision dat snap ik wel, maar ideaal is het allemaal niet.
Het werkt vast goed, maar niet bij teveel data!

bitjes vallen wel degelijk om, gewoon vanwege het protocol

roozeboos schreef : Ik heb daar nog eens over nagedacht en inderdaad: het Raymarine display zou die corrupte pakketjes helemaal niet mogen zien, ook al is negende bit gezet omdat er geen 10 bits stilte aan voorafging... En het bij een collision kan een bit alleen maar nul worden wanneer 'ie één was en nooit andersom omdat op de SeaTalk bus een 1 recessief is en en 0 dominant.

Dus als jij en ik het nu gewoon beter doen dan Raymarine, dan komt alles goed

Faran schreef : Top! bedankt.

mhsprang schreef :
Ook voordat ik de Roosmux had geinstalleerd, kwam het weleens voor dat van een enkel display de verlichting spontaan uit ging. (met de roosmux gebeurd dit wel vaker)

Ik begreep van Koko dat het vooral gebeurt als Furuno Gp3X nmea berichten worden doorgestuurd naar seatalk.
Ik kan me voorstellen dat er dan gewoon veel meer berichten op de Seatalk bus worden gezet. En het daardoor vaker fout kan gaan.

In mijn code staat geen commando "licht uit" uiteraard. Dat had ik al nagekeken. Dus het kan alleen gebeuren als er een bericht verkeerd wordt geinterpreteerd door de raymarine displays. Al dan niet met een juist eerste commando byte.

Ik ga hier naar kijken, maar wordt echt pas volgende week. Ben erg druk momenteel.
Ik wil het wel oplossen, want er is niks irritanter dan dat snachts de backlight steeds uit gaat. Af en toe een berichtje missen is niet zo erg, maar dit merk je meteen.
Het bericht van PvO geeft ook al aan dat het wellictht ook deels een Raymarine probleem is. dank daarvoor, dan zien we het dus wat breder, want handig is voor de diagnose. (dwz: met andere hardware treedt het probleem ook op)

Mijndert ook bedankt,

Ik blijf hier melden wat de ontwikkelingen zijn.

Ik ga ook even meten met de scoop, die hoge spanning van de databit = 0 kan volgens mij niet.

koko schreef :
Om mijn eigen vraag maar te beantwoorden ben je blijkbaar niet aan het spammen en zijn excuses voor de suggestie van mijn kant wel op zijn plaats. Bij deze mijn wel gemeende excuses dus.

Ik zie graag dat experts samenwerken

roozeboos schreef :
Dat klopt Chris. Ik heb een keer gemerkt dat de verlichting keurig bleef branden, tot ik ontdekte dat de gps (furuno gp 32) uit stond. Toen ik die aan zette ging binnen 5 minuten het licht uit. Dat heb ik nog een paar keer herhaald en telkens hetzelfde patroon.

Ik heb vijf van die schermen op een rijtje en ze gaan niet altijd allemaal tegelijk uit, net als dat ze niet altijd allemaal aangaan als ik er eentje aanzet. Ook zie je ze in stappen minder fel gaan branden. Dat is een functie van de schermen en dat zal met diverse commando's op de bus gezet worden.

ik heb het probleem ook, maar het gaat weg zodra ik mijn stuurautomaat, st4000, er tussenuit haal. Geen idee wat dat betekent, of waar de fout precies zit,

koko schreef : Aanvaard!

Nachtvlinder schreef :
Misschien meer gemak dan veiligheid. Ik mag hopen dat we bij uitval van ons boordnetwerk ook op meer traditionele navigatie of een backup systeem kunnen terugvallen.

Als je de multiplexer in een bestaand, goed functionerend NMEA netwerk hangt is de multiplexer naar mijn idee geen SPF. Zolang de multiplexer kan beschikken over de data van de gevers heb je extra functionaliteit (bijvoorbeeld data voor je navigatie tablet) waar je gebruik van kunt maken als je kaartplotter uit mocht vallen. Die kaartplotter is op dit moment bij ons het single point of failure voor wat betreft de weergave van AIS targets.

Tenzij een defect apparaat het hele netwerk crasht zou een iPad waarop nog steeds alle data (excl. radar overlay) te zien zijn bij ons aan boord een handige backup zijn.

heb zelf nu even gemeten aan de seatalk datalijn.

daar is te zien dat het nul nivo op 0.275 mV zit. Is dus in orde.

ga nu even kijken naar de verplichte pauze wachten na een bericht voordater verzonden kan worden.

Ik zou er zo vrolijk van worden als het verlichtingsisue is opgelost! Keep going Rooz