Onderwerp: Incorrect RMC bericht! Hoe kan dit?

37south schreef :
Ik zei niet dat ze niet bestaan; ik zei dat ik ze niet ken

Ja duh BK, dat is wel bekend hoor (van die checksum). Begint wel irritant te worden, dat gestook van jou. Het is je goede recht natuurlijk. Maar in dit geval staan toch echt de beste stuurlui aan wal.


Uiteraard lees ik een heel bericht in, inclusief checksum. Ik doe niks met die buffer. Gewoon doorgeven aan de uit buffer.
Dat er een karakter wordt gemist is op zich nogal opvallend. En vervelend.
Dit heb ik in ieder geval nog nooit meegemaakt, en heb toch al heel wat data voorbij zien komen.

Geef me nu even de tijd om samen met 3Noreen een diagnose te stellen.
Ben even benieuwd wat er dus op die mux aangesloten zit, en of daar ook die 10Hz berichten in zitten.

Baasklusje schreef :
NMEA 0183 gebruikt LRC (longitudinal), geen CRC.

roozeboos schreef :
Je kunt wel blijven vragen maar als je niet ingaat op mijn voorgaande vragen is dat weinig stimulerend.
Op de mux waar de fout die ik hierboven beschreven heb zit dus een airmar 800 smart diepte/log, NKE output, airmar kompas. Alle op 4800 baud en de ais 38400 baud. Er wordt 1 output gebruikt op 57600 baud.
Moet toch foutloos te doen zijn voor de mux.

3Noreen schreef :
Dit vraag ik omdat je twee muxen hebt. Ik weeet niet wat op wat zit. en of de ene mux wellicht ook de andere aanstuurt.
Dank je wel voor het antwoord.
En de airmar doet 10 Hz? En welk berichtje? HDG?
wat stuurt de NKE?
zit niks op rs232?

37south schreef :
De Standard voor NMEA 183 zegt:

Checksum Field. The absolute value calculated by exclusive-OR'ing the 8 data bits (no start bits or stop bits) of each character in the Sentence, between, but excluding "!" and "*". The hexadecimal value of the most significant and least significant 4 bits of the result are converted to two ASCII characters (0-9, A-F (upper case)) for transmission. The most significant character is transmitted first. The Checksum field is required in all transmitted sentences.

CRC wordt idd niet genoemd in de officiele standaard (LRC ook niet). CRC wel in allerlei uitleg-documenten. Maar goed, het is niet zo relevant. Checksum moet kloppen bij de data.....

Dit vond ik ook nog: An 8-bit LRC such as this is equivalent to a cyclic redundancy check using the polynomial x8 + 1, but the independence of the bit streams is less clear when looked at in that way.
en.wikipedia.org/wiki/Longitudinal_redundancy_check

je krijgt gelijk BK, als is het niet relevant.
kunnen we weer door?

roozeboos schreef :
Heb ik je ooit tegengehouden?

Ik weet nog wel wie je in het begin geholpen heeft de Performance in de mux te krijgen

Baasklusje schreef :

Nou ineens niet relevant? Je begon er zelf over en nog wel CRC32. Het is behoorlijk relevant, want een LRC is slechts een XOR van alle characters en kan dus makkelijk kloppen terwijl data verminkt is of ontbreekt. De kans dat dit gebeurt bij CRC16 of CRC32 is vele malen kleiner, maar dat weet je toch wel, na 50 jaar software schrijven? (net als ikzelf trouwens).

Baasklusje schreef : diezelfde die nu zegt dat je t simpel moet houden. Niet echt consequent. Of komt de wijsheid met de jaren?

roozeboos schreef :
Is het nu mijn schuld dat de mux af en toe foutjes maakt?

37south schreef :
Laat maar hangen, hij gaat t nooit toegeven en dan zijn we straks weer paginas verder, en geeft 3Noreen geen antwoord meer.
Waarom moet het toch altijd uit de klauwen lopen...

Baasklusje schreef :
Bedankt, en nu heeft de mux performance issues

Ik geloof dat ik 8 pagina's geleden begonnen ben met het omschrijven van apart gedrag in een aantal Seatalk en NMEA berichten, grappig te zien dat over 8 pagina's heen de discussie over hele andere dingen gaan. Maar goed ik hoop en ga er vanuit dat een ieders mux probleem snel en netjes wordt opgelost.

Ik ben afgelopen weekend er nog niet aan toe gekomen om nieuwe logs te maken. Komend weekend hoop ik. Dan kan ik mijn uitdaging ook weer in de groep gooien.

37south schreef :
Niet echt relevant. Een checksum moet kloppen, en moet berekend worden voor verzenden. Het is immers het bewijs voor integriteit van de data in het bericht.
Hoe dat berekenen gaat is een detail; het kan met meer of minder kans op een per ongeluk toch juiste checksum.
Maar berichten met missende delen van datavelden en de 'oude' checksum erachter, dat kan nooit aan de manier van berekenen liggen (LRC versus CRC). Zeker niet als het meer dan eens voorkomt.

Checksum berekenen vóór verzenden is de enige manier die zekerheid geeft.

Over CRC errors gesproken, zie de volgende logging die ik gemaakt heb met de iNmeaLogger iPhone app. De iPhone is via WIFI gekoppeld aan de Roosmux. Omdat ik nog niet verder heb kunnen debuggen wijs ik ook niks en niemand aan wie de mogelijke oorzaak is van de incorrecte CRC waarden!!

$SARMC,114910,A,5119.846,N,00256.107,E,18.6,44,270517,0>.0,W*45
!AIVDM,1,1,,A,133tF2002UP=7ALMMV9DuT0N0<4O,0 - Checksum input 69 calculated 45 69
$SAVWR,24.0,L,6.7,N,,,,*74 !AIVDM,1,1,,A,69WJRB40OEGr06P140,4 - Checksum input 116 calculated 74 116
$SAVWR,24.0,L,6.5,N,,,,*76 !AIVDM,1,1,,A,3344Eh0031P<hhBMGw7UDDDL0P00,0 - Checksum input 118 calculated 76 118
$SADPT,13.3,0*7D - Checksum input 125 calculated 7D 125
$SADBT,,f,13.3,M,,F*32 - Checksum input 50 calculated 32 50
$SAVHW,,T,42.0,M,6.6,N,,,*16 - Checksum input 22 calculated 16 22
$SAHDG,42.0,,,,*6D - Checksum input 109 calculated 6D 109
$SAMTW,16.0,C*06 - Checksum input 6 calculated 06 6
$SAVWR,28.5,L,6.5,N,,,,*7F - Checksum input 127 calculated 7F 127
$SAVWR,28.5,L,6.5,N,,,,*7F - Checksum input 127 calculated 7F 127
$GPVTG,043.0,T,043.0,M,7.3,N,13.5,K,D*15 !AIVDM,1,1,,B,133qNL00000>i<lMG=95H0lP0@9N,0 - Checksum input 21 calculated 15 21
$SADPT,13.0,0*7E - Checksum input 126 calculated 7E 126
$SADBT,,f,13.0,M,,F*31 - Checksum input 49 calculated 31 49

Mijn plan is nog om tijdens het varen op verschillende punten tegelijkertijd een logging te maken zodat ik achteraf de berichten kan vergelijken. Ben ik nog niet aan toe gekomen.

Sorry dat ik me ermee bemoei, maar je kunt toch nooit de situatie van 3Noreen nabootsen, tenzij je 4 logs ontvangt en die op de een of andere manier exact zou kunnen timen? Het lijkt mij dat je met bijv. NMEAtalker soortgelijke datastromen kunt genereren.

roozeboos schreef :
Snap niet de relevantie van je vraag. Zou leuk zijn als je de moeite neemt dat uit te leggen. Maar goed de documentatie staat wel op het web van de betreffende instrumenten.
Airmar H2183
NMEA 183 output interface Product reference: 90-60-357
Beide instrumenten zullen wel de volle bandbreedte van 4800 in beslag nemen.

Verder meen ik toch al mede gedeeld te hebben wat er op die mux die deze fouten maakt aangesloten zit. Dus niets op de rs232 die ook niet aangevinkt is in de matrix.
Het maakt niet uit waar ik de uitgang op aansluit. PC met opencpn of de plotter of mijn raspberry. De fouten blijven zoals verwacht het zelfde.
roozeboos schreef :
Dit stelt niet gerust. Als je zou knutselen aan die berichten zou dat een simpele verklaring zijn. Je bent "vergeten" de checksum aan te passen. Maar als het puur toeval is ga je toch aan andere toch structurele problemen denken. Zelf denk ik echter dat er wel degelijk aan de zin bewust iets door de software wordt veranderd. Dat blijkt uit een eenvoudig testje. Stuur één enkel VHW bericht met 1 decimaal en het gaat probleemloos door de mux. Stuur je 2 decimalen gaat het fout. Zonder welk andere belasting van de mux. Het is ook opvallend dat alleen het getal voor het aantal knopen veranderd en niet de km/uur.

zeilbootje schreef :

Ik zie geen foute LRC's. De twee waardes aan het eind van elke zin zijn in hex en dec.

Alleen staat achter de GPVTG geen NL (new line)

zeilbootje schreef :
In oorsprong gaat het daar nog steeds over. Geeft de mux de ingekomen berichten op de juiste wijze door ?
Natuurlijk kan ik jou situatie niet nabootsen maar het is voor mij wel een aanleiding een al langer lopend probleem te adresseren.

37south schreef :
Hhhhmmmm stom, dat had ik natuurlijk zelf ook kunnen bedenken. Door de twee waarden dacht ik dat ontvangen en berekend niet overeen kwamen. Kan ik dit in het blunders draadje plaatsen

3Noreen schreef :
Tuurlijk, geen enkele probleem. Ben het draadje aan het volgen en ik zie een aardige discussie ontstaan. Be my guest!

3Noreen, dank voor de antwoorden.
ik ga de airmar datasheet opzoeken en uitvinden of er met 10 Hz wordt gestuurd, en welk bericht.
Sorry voor mijn domheid.

het missende nulletje zie ik hier ook. Een moment Gary, ik ga het even uitzoeken nu.
In ieder geval dank voor het geduld en de melding. Wordt zeer gewaardeerd.

Ah, okay, duidelijk. de vhw wordt niet zomaar doorgegeven, maar inderdaad geprocessed. Ik haal de STW eruit.
daarbij valt het tweede nulletje achter de komma weg.
Ik vind het tweede getal achter de komma sowieso maar onzin, want wees eerlijk welke snelheid gever is tot op twee getallen achter de komma nauwkeurig??????

Maar goed, ik zal m alsnog erbij zetten.


Op zich goed nieuws hoor, want dat betekent dat de inlees routine geen karakters mist. Dat was pas echt vervelend geweest.