Onderwerp: nmea wifi repeater

roozeboos schreef :
Ik heb 7 Raymarine displays met lampjes, en nog nooit zijn die spontaan uit gegaan.... dus lang genoeg laag komt echt niet voor.

normaal gesproken niet nee. Maar het is niet altjd normaal.

oke, wordt even puzzelen hoe dat precies werkt. Op zoek naar het 80 bericht dus.

Ben benieuwd of ik wat kan vinden.

koko schreef :
Ik zou datagram 30 ook zoeken, een bit-shift is gebeurt voor je het weet ((in micro-seconden, timing-foutje).

hoe ga je dat doen?
Alsje ruwe seatalk data wil zien moet ik dat toevoegen in de software van de mux
dat wordt dan uitgeprint naar de usb poort.
Normaal wil je dat niet natuurlijk

roozeboos schreef :
Chris, ik heb eerlijk gezegd geen flauw idee. Het is voor mij een experiment met dit soort van data. Waarschijnlijk lukt het niet, maar heb ik wel een hoop geleerd aan het einde van het experiment. Die site waar Thomas naar linkte heeft wel mooie info. Jij kent die site ongetwijfeld uit je hoofd, maar hij geeft ook een manier om Seatalk op RS232 te krijgen.

Misschien heb ik dat trouwens niet eens nodig, want ik heb onlangs een Raymarine Seatalk<-> nmea converter op de kop getikt voor weinig. Die heeft zelf een RS232 uitgang. Vooralsnog heb ik die helemaal niet nodig in het boordsysteem want de mux doet het prima. Kan ik dat ding misschien gebruiken.

Ik ga d'r eens mee rommelen. Gewoon omdat het kan Mocht ik toch iets ontdekken dan hou ik je uiteraard op de hoogte.

wat je eigenlijk moet hebben is een Seatalk data logger. Alleen normale stervelingen kunnen daar helemaal niks mee. Je kan het niet zo snel lezen als bijvoorbeeld nmea.
Wat ik zeg, de mux kan dat wel, maar dan moet ik even een software versie voor je maken.
En dan is nog het probleem dat het waarschijnlijk om een stoorsignaal gaat. Grote kans dat dat dan niet door de software van de mux komt, en er dus ook niet uitkomt. Het voldoet immers niet aan 4800 bps data.

Het beste is wellicht nog om een scoop er aan te hangen en dan te triggeren op een lang genoeg laag signaal.
( 5bytes laag = 50 bits = 10 millisecs laag). wellicht kan je dan zien of het bericht eromheen klopt.
En dan weet je nog niet waar het vandaan komt. Wel dat het voorkomt. Maar dat weet je al, want je lampjes gaan uit...

Is Seatalk een hoop open collectors aan elkaar? 0 dus priority over 1? En geen CRC?
Dan lijkt het toch op een collision van messages....
Hebben ze in CAN beter over nagedacht...

roozeboos schreef :
Je kan de trigger ook aan de verlichting hangen

It Paradyske schreef : dat is zeker zo.
Collision komt zeker voor, maar de zender kan zien wat hij ontvangt. Komt dat niet overeen dan moet hij snel stoppen met zenden.

roozeboos schreef :
Dus bijvoorbeeld pollen op 1/3 van de bittijd voor die controle, en dan loslaten bij een fout, en data sampelen op 2/3 bittijd zodat je daar de juiste data krijgt?
(En doe je dat ook met de Chrismux? )

uiteraard

roozeboos schreef : Hmm, en toch gaat het fout....

ja, maar we moeten eerst vaststellen of het uberhaupt wel aan de mux ligt...

mijn lampjes op mijn raymarine zijn nog steeds aan. met life data door mux.

roozeboos schreef :
Tja, da's lastig. Weet er alles van als embeddedsoftwareontwikkelaar. Maar bij Koko gaan ze uit, met Mux, en zonder blijven ze aan. En dan kan het nog aan heel veel andere dingen liggen, maar jij wordt er op aangekeken. Dus vragen ze jou om de oplossing.

It Paradyske schreef :
In zo verre dat ik wel richting Chris kijk als het aan komt op een oplossing, maar er op aankijken valt mee. Net als vele gebruikers doe ik mijn best mee te denken, proefjes te doen en feedback te geven.
Door samenwerking zijn er heel wat verbeteringen, maar ook functionele uitbreidingen ontstaan. Voor mij is dat een waardevolle werkwijze waar ik op mijn manier aan probeer bij te dragen.

Vorig jaar al ontdekte ik dat als de Furuno gps uit was de verlichting ook bleef branden. Wellicht dat daar een bericht tussen zit dat bij de vertaling te dicht tegen een verlichtingbericht aan zit.
Het gekke is ook dat niet alle schermen reageren. Kortom, heel wat variabelen om te testen.

De lampjes is een bekend probleem ook zonder mux. Met 7 ST-50's, een ST-60 een C70 en en RM-marifoon in een Seatalkbus zonder mux gaan er ook geregeld lampjes uit. Drie klokjes zijn dan donker terwijl de rest blijft branden. Volgens mij zijn dat de ST50's, terwijl de ST50+'en en ST60's blijven branden. Ik verdenk accuspanning of een te veel aan data op de bus, waar de eerdere generatie ST50's gevoeliger voor is dan de latere instrumenten.

Blijft dus zaak om de st bus maximaal te ontlasten.. Geen onnodige data er op.. Ik kan me voorstellen dat de mix dataload enorm kan opvoeren.
In het verleden geen mijn stbus ook herhaaldelijk over de zeik.. Dat is inmiddels beter maar komt nog wel voor..
Ik heb er nog een extra fluxgate aanhangen..

FMJ schreef :
Das een interessante!

Met name de hoeveelheid data op de bus kan ik me iets bij voorstellen.....effe hard op denken.

Alweer een jaar geleden viel mij op dat de lampjes niet uitvielen als de GPS uit was. De Mux vertaald voor mij een aantal GPS gegevens naar ST. Zou dat voor een overload kunnen zorgen?

Hi,
Dat denk ik wel...
Ik heb al eerder zo min mogelijk berichten toegelaten op de ST bus. Dat hielp mij bij het reduceren van alarmering omdat GPS berichten kapot gingen en er allerlei alarmen gingen rinkelen.
Ik gan meer uitzetten zodat ik hoop dat de bus niet volloopt en er dus "lichtberichten" worden geïnterpreteerd.
Ik ga volgende week testen (want ook ff op en neer naar de UK)

Hans,
Wat heb jij aan de mux hangen? Kunnen we een beetje vergelijken en zien of daar nog wat uit te ontcijferen valt.

Nu je het zegt!

Ik heb een seizoen met een Seatalk<>SeatalkNG converter gevaren omdat er nog een oude ST50+ ingebouwd was. Daarvan ging de verlichting ook af en toe spontaan uit. Lijkt dus niets met de Mux temaken te hebben, maar een bug in het oude Seatalk systeem.

Het is niet echt een bug. Meer een nogal knullige definitie van het lamp uit commando.
Een paar 1 bitjes ervij en het is al een stuk meer onwaarschijnlijker dat t optreedt.
Toevoegen van een nette checksum zou ook een stuk helpen. Maarja, daar is t nu te laat voor!

Hallo Chris,

Een feature request:

Mijn windgever (CV7 LCJ-Capteurs) geeft, behalve windsnelheid en windhoek, ook de luchttemperatuur weer.
Dat gaat via een WIXDR-bericht.


De mux geeft het bericht keurig door (fragment van de logfile van de mux):


maar OpenCPN leest dat niet.
Ik begreep dat RooieDirk voor zijn Airmar een plugin heeft gemaakt die de oorspronkelijke NMEA-zin converteert naar iets dat OpenCPN wel leest.
Is het mogelijk om voor de mux iets te schrijven waarbij een WIXDR-bericht wordt omgezet in een voor OpenCPN leesbare zin, zodat de luchttemeratuur in het dashboard kan worden weergegeven?

taan schreef :
het ziet er al erg leesbaar uit, 13,0 graden Celsius.