Onderwerp: Seatalk loopt vast

Vorige week viel ons op dat de Sog en Cog steeds vastliep op de klokken.
Een snelle blik van Web op de laptop (waar deze data ook binnenkomt via de Multiplexer) leverde op dat er vreemde tekens in de datastroom zat

Vandaag maar eens op onderzoek gegaan.

Een beschrijving van hoe de boel in elkaar zit.

5 klokken (wind, ch, kompas, tridata en een graphic) en de gevers zijn: wind, diepte, log en fluxgate (die alles is raymarine st60+)

dan is een multiplexer-usb waar de seatalk op de seatalk ingang is aangesloten.
verders is er op de nmea in een gps muis aangesloten
1 nmea out is gaat naar de graphic om zo de gps data op het seatalk netwerk te krijgen.


Nu komen er een hoop screenshots met aanvullende info, hopende uit te vinden waar het fout gaat.
Alle info komt binnen op de multiplexer waarna deze naar de laptop gestuurd wordt.

Datastroom (nmea) via OpenCpn bekeken


Datastroom (nmea) via navmon bekeken


Je ziet in beide rare tekens

Datastroom van ALLEEN DE GPS via navmon bekeken

Deze is/lijkt helemaal goed, zonder rare tekens.

Datastroom (nmea) via navmon bekeken

Hier zie je dus weer rare tekens, de vreemde data onstaat dus in het seatalk netwerk (zo lijkt het)

De multiplexer config


We hebben ook nog geprobeerd de multiplexer in server OF hub stand te zetten, maar beide leveren dezelde vreemde tekens op

De multiplexer config in server mode


De multiplexer config in hub mode


Voor zover lijken de problemen dus alleen in het seatalk netwerk te vinden.
En ineens rinkelde er een klein belletje, maar dat is dus maar een hersenspinsel.

Zou het kunnen zijn dat de seatalk data naar de multiplexer wordt gestuurd waar deze weer omgezet wordt in nmea data die weer terug gestuurd wordt naar de graphic waardoor deze telkens 2x dezelfde data krijgt en de weg kwijt raakt.

Overigens komen de vreemde tekens NIET in langs als je de datastroom via de multiplexer-config tool bekijkt.

iemand enig idee waar die vreemde tekens vandaan komen ?

Een paar dingetjes die me opvallen:
- De vreemde tekens zijn consequent (steeds dezelfde), dus lijkt het niet op ruis, slechte verbindingen o.i.d.
- De Seatalk naar NMEA vertaler berekent wel netjes een checksum (*04 of *0D)

Wat je verder zou kunnen proberen:
- Laat alleen GPS positioning/COG/SOG sentences toe vanuit de mux naar je ST60+ Graphic. Kan je denk ik via de mux instellen, of anders misschien op je Graphic). D.w.z. probeer het eerst eens met alleen $GPRMC
- Schakel selectief ST60+ instrumenten uit om te zien welke de vreemde tekens veroorzaakt, of analyseer de datastroom of er bepaalde gegevens missen. Het zou zelfs een bug in de multiplexer kunnen zijn die bepaalde Seatalk data niet begrijpt.

Jeroen.

als een Graphic (of Multi) 2 maal dezelfde berichten krijgt waarvan 1 via NMEA en 1 via Seatalk dan loopt hij zeker vast.
Als je rondzingende berichten heb gemaakt via de Seatalk ==> NMEA conversie krijg je zeker dubbele VTGs etc.
En daar houden die displays niet van.
groet
t

Ok, daar is het vermoeden dus min of meer mee bevestigd.
Maar hoe moet ik dat dan oplossen...

H2O geeft al een optie, maar van dat soort regels en filters bouwen heb ik totaal geen kaas gegeten.

als je met de sw van de Mux (MPXconfig) een capture doet zie je precies wat er allemaal de mux ingaat, en van welke bron.
Je kunt dan gewoon een bericht blokkeren in de mux door met een muisklik een verbodsbordje te maken (op de blauwe pijl klikken)
groet
t

Ok, dat begrijp ik, maar dat is wat de mux ingaat, eigenlijk wil ik alleen maar de berichten die terug gaan naar seatalk filteren ? als ik bijv. alle seatalk berichten blokkeer dan zie ik die ook niet meer in bijv nav. software waardoor een log een stuk incompleter is, of zie ik dat verkeerd ?

uit de Mux komt geen seatalk, het gaat erin op de conversie-ingang en komt er als NMEA weer uit op de talker-poorten.
Heb je de NMEA OUT van de Graphics ook in gebruik, nee toch?

Dat begrijp ik dat er geen seatalk uit de mux komt.
Berichten die ik blokkeer zie ik die wel nog op het usb kanaal ?
Dus stel ik blokkeer alle seatalk berichten, zie ik dan die dat wel nog in de nav programma's ?

Nee ik gebruik ik niet de nmea out van de graphic, dat zou helemaal een zooitje worden

berichten die je blokkeert op de mux komen er nergens meer uit, ook niet naar de PC.
zelf gebruik ik niet de seatalk=> NMEA conversie van de mux.
In plaats daarvan wel de NMEA OUT van een Multi/Graphics, en daaruit krijg je dan alles wat je wilt aan navigatiedata (NMEA OUT aan een Listener van de Mux). Nooit een geblokkeerde ST60.
groet
t

Dus eigenlijk zeg je: knoop die gps aan de graphic (nmea in) vanaf daar (nmea out) naar de mux (nmea in) en het probleem is opgelost.

nee.
- Knoop de GPS aan de mux,
- de NMEA OUT van de Graphics ook aan de MUX.
- de NMEA IN van de Graphics aan een talker van de MUX
- Gebruik NIET de Seatalk conversie van de MUX.
Zo zit het bij mij, en dat werkt feilloos.

groet
t

dus alleen dat vinkje weghalen bij seatalk --> nmea ?
Dat heb ik gisteren ook bedacht/geprobeerd maar toen ik dat deed stopte de datastroom in mpx-config

Nog maar eens proberen, als het bij jou werkt moet het bij mij ook kunnen.

Plaatje van jou kan ik niet lezen, erg klein heb je een grotere
Kom je trouwens naar de goulashmeeting ?

Ik gebruik die NMEA-out van de graphics bewust niet omdat die de Seatalk data samen met de data die op NMEA-in binnenkomt, maar om de 2 seconden verzend. Dat is veel langzamer dan het eigenlijke Seatalk verkeer. Bij mij werkt de conversie van Seatalk naar NMEA in de mux overigens prima, zonder dat er een snelheidsdrempel in de NMEA-datastroom zit.

Als het een Mux van Shipmodul is kan je trouwens ook prima telefonische support krijgen van de maker ervan. Zorgen dat je het systeem hebt lopen en direct uitvoeren wat hij voorstelt...

Het probleem is getraceerd en kan worden opgelost.
Ind. contact gehad met de maker en die mailde het volgende (ik post het even om dat het anderen misschien ook weer verder kan helpen)

tsja, problemen die Meindert net zelf pas ontdekt heeft kunnen wij ook niet oplossen

groet
t

zo's maar net....maar toch mooi dat het opgelost is én er nog een update beschikbaar is om dit probleem op te lossen

vd week de multiplexer maar even opsturen, het is net ff te ver om heen en weer te rijden en er op te wachten.