Onderwerp: Incorrect RMC bericht! Hoe kan dit?

Overigens doet dit zich alleen voor als de snelheid correctie niet op 100% staat.
Dit staat onder diversen in het instelprogramma.
Daar zat de echte fout. Ik vervang de STW als er gecorrigeerd moet worden, en heb de checksum niet aangepast.
Bij geen correctie gaat het originele bericht gewoon meteen eruit, as is.

Dit kan je dus corrigeren zonder software update, Gary.

nb: zelfde ook als je de functie: voeg SOG in VHW bericht via de schakelaar gebruikt.

roozeboos schreef :
Het gaat niet om de tweede decimaal het gaat om de checksum die niet goed is.
Kijk dan ook naar de DBT en de VWR. En alle andere zinnen waar je "iets" mee doet. Het mooist zou zijn dat je er helemaal niets mee doet als de gebruiker daar niet bij de instellingen om vraagt.

Verder genereert de laatste software een ongevraagde RMB bericht. Mijn mux hoeft geen performance te berekenen. Dat doet mijn raspberry wel voor mij over 360 graden.

duidelijk. lees ook mijn bericht voor deze nog even.

vwb RMB: bij diversen RMB toevoegen uitzetten.

roozeboos schreef : Gaat wel over iets anders, maar bij DTW van NMEA naar ST wordt er ook maar 1 cijfer achter de komma weergegeven. Daardoor zit ik toch zo'n 100mtr naar een DTW scherm met daarop 0,00NM aan te kijken voordat de AP naar het volgende routepunt wordt gestuurd.

Als je toch komma getallen aan het aanpassen bent......

Is er nog duidelijkheid waarom VWR met een foute checksum doorkomt ?

Zou het kunnen dat de routine die de positie uit de ais haalt / zet een checksum fout genereert ?

VWR = zelfde fout, is ook gecorrigeerd.
voor jou:
Als je AWA correctie op nul zet, moet dat goed gaan met checksum.

.

Hier nog wat historie over verschillen van inzicht betreft het belang en doel van de checksum. Onduidelijk wat er met deze feedback gebeurd is destijds.

checksums worden uiteraard gewoon meegenomen en gecalculeerd.
Het is in ieder geval niet de boedoeling ze te negeren.
Dat er nu een bugje gevonden is daarin, doet niets af aan de goede bedoelingen.

ben jij nog bereid tot het uitvoeren van een update, Gary?
Je kan daarna nog terug naar de oude versie als het niet helpt.

gebruik dan deze link:
www.star-tracking.com/stw3f.zip

Voorlopig krijg ik de VWR zin niet goed door de mux. Ook al staat de correctie op 0 of 000 Ik snap ook helemaal niet waarom de mux een extra decimaal er inschrijft.

Input,
$IIVWR,025.,L,12.2,N,06.3,M,022.6,K*62
Output mux
$IIVWR,26.2,L,12.2,N,06.3,M,022.6,K*62
Input
$IIVWR,024.,L,12.3,N,06.3,M,022.8,K*6C
Output mux
$IIVWR,25.2,L,12.3,N,06.3,M,022.8,K*6C

Voorlopig ben ik wel blij met die checksum fout. Anders was ik er nooit achter gekomen dat de data ongewenst veranderd worden.

3Noreen schreef :
elk nadeel heb zijn voordeel

staat de awa correctie op 0? bij diversen.

heb je de update al gedraaid?

roozeboos schreef :
deja vue momentje hier. Gaan we toch niet weer doen ?
roozeboos schreef :
Ja AWA staat op nul zoveer dat met de instel software lukt. Een keer of tien gedaan. Nu lijkt hij toch echt op nul te staan als ik de instellingen ophaal.

Maar wat mij nog het meest verbaast is dat er een decimaal bijkomt. Je kan dat niet eens instellen.

3Noreen schreef :
Het zijn wel nog steeds 3 digits, maar nu zonder leading zero en met 1 ongevraagde decimaal (decimalen in 0-360 zijn sowieso niet heel nuttig)

Het lijkt dus het meeste op een verschuiving van 1 digit.
Hoe zit het met waarden boven de 99? Krijg je dan wel 3 digits voor de decimale punt?

BK, ga jij nu mijn code debuggen? Af, in je mand.

Als je even de moite neemt om te lezen wat ik in de afgelopen postjes schreef , dan weet je dat het allang opgelost is.
Awa kan op nul gezet, en ook de VHW is op te lossen door Gary.
Dat die extra nul wegvalt is op zich prima, want dat kan ie toch nooit meten. Als de checksum maar klopt.


Gary, met het bestaande instelprogramma 19R wat je nu hebt kan je prima een update draaien. Dat werkt gewoon.
Het is allemaal vrijwillig natuurlijk. maar ik ben wel benieuwd hoe jou systeem daarmee werkt.

Chris het lijkt er op dat dit een ander probleem is dan de voorgaande. Behalve dat je checksum niet klopt gebeurt er nog iets opmerkelijks/ namelijk dat
025 veranderd in 26.2 en 024 in 25.2. Dit zou helemaal niet moeten kunnen onafhankelijk van wat voor correctie er voor AWA er dan ook met het instel programma gekozen wordt. Immers je kunt geen decimalen als correctie opgeven.

Het instel programma wat bij mij werkt heeft een kleinere aantal mogelijke instelleningen dan de huidige nieuwe firmware. Dat lijkt me niet goed aflopen. Er staan dan random bits op plekken waar de firmware iets zinvols verwacht.

Inmiddels is mijn noodplan uitgevoerd en kan ik mijn tocht vervolgen. Voor dit jaar gaat de raspberry de taken van de mux overnemen in zover de mux bugs bevat.

okay dan laten we het zo, goede vaart.

roozeboos schreef :
Ik hoop natuurlijk dat jij ondertussen de bugs in de mux oplost. Ook uit eigenbelang. Het lijkt met toch niet prettig om een product te verkopen waar je op zee niet goed op kunt vertrouwen.

Verder brengen de mijne dan na de zomer 2e hands nog een leuke prijs op.

komt goed, heel erg bedankt voor je input.

overigens mist er een karakter bij je input
Input,
$IIVWR,025.,L,12.2,N,06.3,M,022.6,K*62

na de 25. moet zijn 25.0

ik zal deze fout maar opvangen in mn code. Blijkbaar treedt dat dus ook op.

roozeboos schreef :
Hoe kom je daar nu bij.....
De data tussen de komma's zijn de data. Punt-uit.
Daar mmoet je niets afhalen of bijmaken.
025. is 025 en geen decimalen.

3Noreen schreef :
Ik ben nog niet in mijn mand. Ik zei dat er iets verschoven lijkt (de meest signficante digit eraf, de 0, en een decimaal erbij.).
En dat hou ik nog even vol, gezien de bovenstaande quote van 3Noreen.

Nu gaan we wel heel diep op de materie in maar de uitkomst van de standaard C functie
strtod() is exact het zelfde of ik er nu 3.0 ,003 , 3 of 003. als argument gebruik.

Ik heb even deze code regel laten meelopen op mijn raspberry software. wind_dr is de inhoud van het richingveld in de VWR zin

printf("wind richting is %s %g\r\n",wind_dr,strtod(wind_dr,0));

Dat geeft de volgende uitkomst.

wind richting is 004. 4
wind richting is 004. 4
wind richting is 003. 3

enz. enz.