Onderwerp: XTE gaat de verkeerde kant op?

3Noreen schreef :
Je rukt de boel uit zijn verband. Flauw. Je weet wel beter. Beneden jouw nivo, dacht ik zo. Bah.

IN EEN RMB is de XTE altijd positief, gevolgd door een DTS, L of R.

Hier een RMB van de Froufrou uit NKE-apparatuur:
$IIRMB,A,0.01,R,,,,,,,0.5,339,5.86,A,A*56

Positieve XTE 0.01 links van de lijn, want DTS = R. Geen minteken.

Dat de displays daar een min voor zetten op basis van de DTS dat kan. Hun keuze.
Andere displays zetten er pijltjes bij. Hun keuze. In een RMB is XTE Positief. punt uit.

Bij mij aan boord, navigerend met een RMB uit de Garmin of uit WinGPS, is de weergave van de DTS op een ST60 Multi altijd correct. Altijd de goede kant op.

En de code van OpenCPN, gevonden door baggah (en later door mij) is simpelweg fout.
Als de XTE links van de route ligt (negatief is in OpenCPN, op zijn Frans, zeg maar) dan gaat er een L in de DTS van de RMB. Nog meer naar links...
Daar kunnen we lang of kort over lullen, die die versie van OpenCPN is dat simpelweg fout.

baggah schreef :
Ik roep dit nog even in herinnering voor degenen die dromen dat OpenCPN geen fouten maakt.....

Eh, de code is fout, maar de nmea komt er goed uit........
En ja hier gestest met 5.2.x en 5.5

holtere schreef :
hoi Rémy,

heb je hier wat uitleg bij?
Waar komt info vandaan, uit Timezero zelf neem ik aan? (niet uit OpenCPN)?
Hoe moeten we dit plaatje lezen?
Die 3 m en dat pijltje, betekent dat dat je 3 meter links van de route zit en naar rechts moet?


De andere plaat (van je RM plotter) zegt 4 meter. Dat is dus niet op hetzelfde moment.
En omdat je stilligt en een route 'vaart' bestaat de XTE dus compleet uit ruis van de GPS-positie.
Als de momenten niet EXACT hetzelfde zijn van die 2 plaatjes dan zegt het niets. Ene moment is de ruis naar SB, volgende moment weer naar BB.

Baas gebruik jij nu maar lekker je eigen software, Dan doe ik dat ook. We leven in een ander universum en daar ben ik heel tevreden mee.
Als je er plezier in hebt dat ik je gelijk geef, dan bij deze; Je hebt gelijk.

rooiedirk schreef :
Hé Dirk!
En hoe werkt dat dan precies, foute code om een goede RMB te vullen ?

Zulke code wil ik ook wel! Zelf-corrigerend!

3Noreen schreef :
Dank je.

rooiedirk schreef :
Wat nog mooier is. Mijn stuurautomaat doet dan ook precies wat ik wil.
Maar voor de goede sfeer laten we toch maar zeggen dat de code fout is.

Er hebben nu 3 mensen naar gekeken: rooiedirk, baggah en ik.
Alle 3 gezien dan een of andere versie van de code fout was.
Lijkt me duidelijk.

Waarschijnlijk zijn de meeste versies van de code goed, dat dan weer wel.
Sommige gebruikers hebben mazzel, andere pech....

Kunnen we proberen om zonder te schamperen een vinger op het verschijnsel te leggen?

@ Thomas,
De foto is vrijwel meteen op hetzelfde moment gemaakt maar stilliggend dus de afwijking is gering.
Je hebt gelijk, ik moet het nog een keer herhalen en dubbelchecken.
De route was in Timezero geactiveerd en Opencpn was niet opgestart.
Het laatje van Timezero is eenduidig. Het driehoekje zit links van de lijn, het bootje wijst naar de lijn in welke richting je moet en het pijltje linksonder geeft aan 3 m die kant op. Geen ruimte voor twijfel wat mij betreft.

@Rémy:
- timezero kan waarschijnlijk niet de OpenCPN RMB inlezen en weergeven?
- idd met OpenCPN aan én Timezero op PRECIES hetzelfde moment beide schermen vastleggen (liefst op 1 beeldscherm naast elkaar). OpenCPN zelf zal ook wel zeggen of je linksof rechts zit?
- pas als de RM-displays wat anders zeggen dan OpenCPN zelf kunnen we concluderen dat het aan RM ligt.

Misschien moet je even de laatste versie OpenCPN erop zetten, het schijnt nogal eens te veranderen met hun L en R

Ik heb geen inkomende data met daarin de RMB.
De software stuurt die RMB naar buiten het netwerk in, dus naar de mux via de USB.
Diezelfde RMB data komt niet meer terug.

holtere schreef :
OpenCPN stuurt die RMB naar je RM displays. Misschien doet Timezero dat ook??

In Timezero kan je je XTE en de DTS zien.

Dat kan vast in OpenCPN ook, in de kaart? Daar zal het wel goed gaan.
En dan maakt OpenCPN een RMB die naar je displays gaat.
Als het er op die displays anders uitziet (L ipv R sturen) dan in OpenCPN op de kaart, dan kunnen er 2 dingen aan de hand zijn.
- RM-haters zeggen dan dat het aan RM ligt; die weten niet wat L en R is
- OpenCPN-critici zeggen dat er een fout in het RMB-bericht zit (aangetoond in versie 5.2.nogwat).
(het kan ook nog allebei het geval zijn en dan heffen de fouten elkaar op. Vast niet het geval....)

We hebben dus de uitgaande RMB zelf nodig om te kijken waar het fout gaat....

Mij lijkt het uiterst onwaarschijnlijk dat de grootste leverancier ter wereld van marine apparatuur toevallig bij jou aan boord 2 of 3 apparaten heeft geleverd die het fout doen
(zeker in het licht van een bewezen foute code in OpenCPN).

We zoeken het tot de bodem uit! Hoe diep is het bij jou?

Ik heb helemaal niets nodig. Mijn stuurautomaat die doet wat ik wil. Einde oefening wat mij betreft. Het beschimpen kan wat mij betreft achterwegen blijven.

3Noreen schreef :
Mijn stuurautomaat ook, aangestuurd door Garmin-GPS of door WinGPS Voyager.
De RM-displays tonen ook altijd correct (in beide gevallen) waarheen gestuurd moet worden.
Dus beschimpen van RM ('amateurspul dat niet weet dat - naar links is'....) lijkt me niet terecht.

Maar Rémy had een rare verrassing op zijn display en OpenCPN heeft (zeggen 3 mensen die ernaar gekeken hebben) een fout in 1 versie van de code, inmiddels gecorrigeerd (wat bewijst dat het fout was).
Dus voor hem en mij is de oefening nog niet voorbij.... we willen nu weten hoe het zit.
Je mag rustig blijven meelezen hoor

Inderdaad het mooie van open source software is dat iedereen naar de code kan kijken. Dat is helaas met veel software niet het geval.

Zo stilliggend krijg ik geen mooie afwijking van de routelijn om e.e.a. duidelijk vast te stellen. Ik moet daarvoor varen. Bericht daarvan volgt dus later.
Thomas,
Ik stuur je een mail met nmeaberichten van TZ.

3Noreen schreef :
Gelukkig maar, want ondeskundigen kunnen al gauw meer code kapotmaken dan toevoegen

Maar het mag gezegd, samenwerken levert vaak prima resultaten op.
Vooral als het binnen een beetje een georganiseerd verband gebeurt, een bedrijf bijvoorbeeld.

Doen ze veel aan open source in de aannemerij ?
Dan wil ik wel eens wat betonijzer vlechten!
Stucadoren lijkt me ook leuk! Is dat moeilijker dan schilderen? Vast niet, is gewoon dikke verf

Baasklusje schreef : Ho even Ik beweer helemaal niet dat de code fout is. Dit noemen ze ook wel sarcasme... Dat jij dat als overvloedig gebruiker van dit stijlmiddel dit niet herkent verbaasd me dan weer Jij beweert na het zien van dit stukje code dat dit 100% fout is. Gelukkig ben je nog wel zo eerlijk om toe te geven dat je niet hebt gecheckt waar XTEDir vandaan komt.....

Had je dat wel gedaan dan zou je ook gezien hebben dat XTEDir -1 = als je rechts van je route zit, en +1 indien links van je geplande route.

Je 100% fout conclusie is dus op z'n minst een beetje voorbarig. (Ook sarcastisch )

Ik heb ook geprobeert te zoeken naar veranderingen in de betreffende stukjescode voor versie 5.2.x maar hiervoor niets kunnen vinden. Dit kan ook aan mijn manier van zoeken liggen, dus ik ben erg benieuwd naar de veranderingen die baggah gevonden heeft.

rooiedirk schreef : Baasklusje schreef :
Je kunt je oprecht afvragen of de baas de code wel echt bekeken heeft.

Ah er staan nog een paar vragen van BK open, sorry effe niet gezien.Als het gaat over nmea dan ben ik het er mee eens, maar de variabele leg_info.Xte word alleen intern in OpenCPN gebruikt, en dan mag je natuurlijk gerust een andere defenitie gebruiken. Heeft namelijk wel als voordeel dat je met 1 variabele zowel de afstand als L/R kan defenieren.
Waarbij de DirectionToSteer direkt afgeleid is van XTEDir. En de XTEDir wordt dan weer berekent door de normaal-vektor naar je route segment te vergelijken met BTW (BearingToWaypoint)
Tuurlijk wel, al weet ik niet hoe lang en hoe diepgaand. Nu ikzelf wat beter kijk zit er misschien toch een kleine onnauwkeurigheid in de code. Momenteel wordt er een simpele vector berekening gedaan om de normaalvector te vinden. Maar de aarde is een bol en niet plat(toch?). Zal een verder kijken wat de consequenties hiervan zijn, en of het ook goed gaat als je route over de datumgrens loopt.

Als je een route uitzet waarbij de bol van de aarde van belang is kun je daar rekening mee houden. Opencpn maakt dan tussen waypoints.

WinGPS is voor IJsselmeernavigatie ontwikkeld. Dan komt dat niet zo nauw

De twijfels van 3N ga ik even niet op in.
Als hij gelezen had kon hij quotes uit de code zien. Zelf opgehaald.

@rooiedirk:
ik heb gezien dat de XTEDir negatief moet zijn om een L in de RMB te zetten.
Nu is, zoals 3N ostentatief duidelijk maakt, voor alle mensen die een beetje van zeilen weten een negatief getal een indicatie voor links.
Nu reken ik mezelf ook een beetje tot dat soort zeilers en ik heb aangenomen dat een negatieve XTEDir dus links van de lijn is.
De vectorberekening zelf heb ik niet nagerekend (wel gezien), dus ik weet niet wanneer die een negatief resultaat geeft. Mijn aanname was die van alle (vooral Franse ) ervaren zeilers.
baggah heeft voor zijn post hetzelfde gedaan: niet gechecked die XTEDir.

Dus, met een negatieve XTEDir een L in een RMB zetten is (lijkt) de verkeerde kant aan te geven.
Kan natuurlijk zijn dat de OpenCPN schrijvers het precies andersom hebben gedaan... laat 3N het niet horen

Blijven een paar dingen over:
- holtere heeft om meerdere RM apparaten gezien dat een RMB uit OpenCPN hem de verkeerde kant op stuurt (de reden voor dit draadje)
- de kans dat RM daar iets verkeerd doet is vrijwel nul. Dat zou namelijk al 20 jaar geleden zijn opgevallen, toen OpenCPN nog niet eens bestond. Mijn RM-ST60s wijzen altijd de goede kant op (zonder OpenCPN).
- baggah heeft in de sources gezien dat er 1 versie was waarin het andersom stond gecodeerd dan in een andere.

Zoals altijd met Occam's Razor is de simpelste verklaring vaak de beste.
En dat is niet de kans dat alle RM apparaten niet weten wat L en R betekent......

Wordt vervolgd als holtere weer op het water zit.
Ik heb hem gevraagd te kijken wat OpenCPN op de kaart zegt over de cross-track, en wat er in de RMB staat die er dan verstuurd wordt.
Dat moet hetzelfde zijn in ieder geval. Als het goed in de kaart staat (rechts van de lijn dan stuur naar links) en fout in de RMB dan weten we het.....

Misschien kan iemand anders dat experiment even doen?

Overigens, die negatieve waarden voor 'naar links' werken logisch bij kompaskoersen en windrichtingen. Dingen die kleiner worden als ze linksom draaien. Ook een klok, zelfs.
Maar voor parallele lijnen (koers, track, XTE) is het niet per se logisch.
Daarom vermoedelijk ook de XTE als positief getal en een DTS erbij, in de RMB.
Voorkomt (Franse) verwarring.

Zie mijn filmpje: RMB output (en lokaal routevenster) zijn zoals ze moeten zijn...