Onderwerp: Vreemd verschijnsel in WinGPS Voyager

Zeilprutser schreef :
Dat is maar gedeeltelijk waar. Ik heb in mijn eigen software onnauwkeurigheden. Daarom zoek ik sparring partner(s) om het thema te bespreken. Ik vind die onnauwkeurigheid oprecht interessant.
Opmerkingen van Aswin zoalszijn daarom prikkelend.
Je kunt met hele dure instrumenten en dure software het oplossen (misschien) Maar snappen hoe het werkt is leuker.

Zeilprutser schreef :
Het topic gaat over het gebruik van een klok die er niets mee te maken heeft voor het berekenen van snelheid. De rest is bijzaak
Jij gebruikt toch ook geen kompas dat er niets mee te maken heeft voor de AP?

Laat ik het dan toch maar samenvatten:
Baasklusje heeft gelijk mbt het topic als je snelheid wilt berekenen op basis van 2 gekregen posities dan kun je het beste de tijd gebruiken die bij de posities hoort.
3Noreen heeft gelijk dat als je je snelheid wilt weten dat je beter de SOG kunt gebruiken die al is berekend door de GPS o.a. ook op basis van het doppler effect.
Mijn nuance de GPS is vooral heel nauwkeurig bij "enige" snelheid/verplaatsing.
Wat de drempel snelheid voor "een" "betrouwbare" GPS is weet ik niet, dat kan nogal verschillen per type en de locatie op het schip, onderdekse en ingebouwde GPSen beschouw ik als niet betrouwbaar voor deze exacte toepassing.

3Noreen schreef :
Zo is dat.

Die ruis in de WinGPS SOG (maar soms met een richting in de ruis) waar Aswin op doelt kan door van alles komen.

Nog weer even wat daar gebeurt, bij de SOGberekening:
- de GPS meet een positie.
- stuurt die weg (iets later). Als de AIS-GPS erg druk is (AIS!) dan zal dat wegsturen vertraagd zijn.
- het bericht gaat over N2K naar de Miniplex.
- Die moet het omzetten in NMEA0183.
- Maar die kan het druk hebben, 10Hz berichten uit EV1, veel AIS, etc. Onbekende variabele vertraging
- de Miniplex stuurt de positie in NMEA0183 (GLL,GGA,RMC,RMB) eruit. Kan even duren.
- De NMEA komt aan in de PC. USB op 38.400.
- De USB pakt het op en stuurt het door naar WinGPS.
- Dat was net iets anders aan het doen, de kaart verschuiven bijvoorbeeld.
- en de PC doet ook nog andere dingen, SPD draaien, ZF-pagina displayen, etc.
- Dan heeft WinGPS het bericht binnen (we weten niet hoe lang nadat de positie door de GPS is vastgesteld)
- en dan gaat WinGPS op de klok van de PC kijken. Weer vertraging (PC is toevallig even bezig).
- de vastgestelde tijd gaat WinGPS vervolgens gebruiken om een SOG te berekenen,over de afstand sinds de vorige cycle van dit circus.

Zeilprutser schreef :
Dat heb ik hem niet horen zeggen Maar hij vindt dat vast wel.

Mezelf heb ik dat wel horen zeggen, o.a. tegen Stentec.

De grap van SOG en COG uitrekenen aan de hand van posities is dat als je de tussentijd langer maakt de nauwkeurigheid sterk toeneemt. Je hebt dan een koers met een veel hogere nauwkeurigheid dan als je een filter over de COG die je GPS uitspuugt. Daar kan je hele leuke dingen mee doen.

3Noreen schreef :
Maar het is al zo afgrijselijk precies, met die moderne GPSen.

Baasklusje schreef :
Als je software schrijft voor je zelf, zoals ik weet je hoe nauwkeurig je GPS is. Maar in het geval zeilprutser weet de schrijver van de software dat niet maar kan door middel van bovenstaande check er misschien wel achter komen.
Maar weet je wel hoe goed je GPS is kun je kijken bij een min of meer rechte koers of een verband is tussen COG_langloopend en COG_kortlopend. Zit bijvoorbeeld de kortlopende wisselend met een vaste tussentijd boven en onder de langlopende dan verteld dat "iets"

Experiment gedaan:
- NMEA met 1 Hz aan een Python programmatje gevoerd.
- de SOG uit de RMC zo gepakt,ongewijzigd.
- uit de positie en tijd uit elke RMC de afstand en tijdverloop berekend (steeds verschil tussen 2 RMC's).
- De klok daarvoor is dus de GPSklok die in het RMC-bericht staat in 0.00 seconden
- SOG is afstand gedeeld door tijdverloop
- En ook diezelfde afstand gedeeld door het tijdsverloop OP DE PC. Met 1 Hz Nmea is dat ook iets als 1 seconde, mag je hopen. Maar die PC staat ook andere dingen te doen.

100 seconden log genomen, wegvaren, optrekken en weer wat afremmen (Den Oever, sluis uit, naar de brug)
Het resultaat:



SOG * 100.
Oranje/bruin is de SOG zo uit de RMC (de doppler-meting van de GPS?). Strakke lijn.
De blauwe is de berekende SOG met de tijd in het RMC-bericht. Ietsje ruis, door niet perfecte posities.
En de grijze is met de PC-klok. Die volgt meestal leuk de blauwe, maar hij heeft ook rare uitschieters.
Vooral naar beneden. Dan keek de PC even niet meteen op de klok.

Gemiddelde van alle drie is gelijk, 3,7 kts. Ietsje verschil in de 1/100 ktsen.

Op zich zoals je zou verwachten lijkt me. Ik vermoed dat de blauwe GPS-SOG lijn toch ook wat geflatteerd is, in de GPS zal ook wel een filtertje zitten om onnauwkeurigheden in de dopplermeting af te vlakken.

ilCigno schreef :
Sommige dingen wel....
Het gebruik van een andere klok dan de GPSklok leidt tot rare resultaten. Is ook nergens voor nodig,je krijgt de tijd van de positie op een presenteerblaadje in RMC, GLL en GGA.

Andere dingen niet.....
De bruine lijn (SOG uit GPS-RMC) is wel erg fraai.
Zou dat een pure (doppler)meting zijn of heeft de GPS daar wat aan gesmoothed?

De blauwe (afstand/tijd) is denk ik gewoon ongeprepareerd.

Ik zal straks eens een langere log met meer SOG-snelheid door het programma halen.

Baasklusje schreef :
Welke GPS heb je? Weet je misschien welke chip erin zit?

Onze start van de 24uurs afgespeeld, een kwartier.
Zelfde kleuren:
- bruin de RMC-SOG
- blauw de SOG berekend uit afstand en tijd in de RMCrecords
- grijs de SOG berekend uit afstand in RMC en tijd op dePC (van binnenkomen record).

Zelfde beeld. Veel ruis met die PCklok, meer naarmate de SOG toeneemt.



@rooiedirk, gaat OpenCPN deze berekening nog aanpassen?

Van Stentec heb ik nog geen reactie.

Aswin schreef :
Dit is de GPSdata (RMC) uit de CTRX AIS-transponder.
Calidris weet vast welke chip daarin zit?

Baasklusje schreef :
Bedoel je dat de gebruiker van OpenCPN niet meer de keuze zelf zou moeten kunnen doen. Je wilt hem behoeden.

Welke timestamps gebruikt OpenCPN voor die alternatieve SOG berekening?

tip:
content.u-blox.com/sites/defau...eet_UBX-20033635.pdf

Als ik rooiedirk goed begrepen heb (eerdere post van hem in deze draad) gebruikt OpenCPN, net als WinGPS, de PCklok voor de snelheidsberekening, en niet de time stamps in de NMEArecords.

Dit schreef hij:

Hmmm, onder het motto “zoveel mogelijk opties”, kan er nóg een optie bij, namelijk welke klok/timestamps te gebruiken

Baasklusje schreef :
Ik ben wel heel benieuwd wat jij en rooiedirk willen "verbeteren". Om de stroom uit te rekenen zul je toch een timestamp op het log moeten hebben.

COG gaat het om…

Roozeblij schreef :
Velocity accuracy 0.05 m/s zegt de datasheet.

Dat is 0,09 kts, dus nauwkeuriger dan 0,1 kts.

200 dollar, alleen de losse ontvanger module

3Noreen schreef :
Ik wil nix verbeteren aan OCPN.
Ik heb het in het verleden even vaak weer van de PC gekieperd als geïnstalleerd wegens verregaande onbegrijpelijkheid en verwarrende user interface. Zal aan mij gelegen hebben.

En waarom rooiedirk zegt dat het geen stroom kan berekenen weet ik niet.
Dat is simpel 2 vectoren van elkaar aftrekken, SOG/COG minus HDG/STW.
Bij voorkeur gemeten op hetzelfde tijdstip, maar heel kritisch is dat niet, want beide veranderen maar langzaam.

Nachtvlinder schreef :
Open Sores in Optima Forma