Onderwerp: Vreemd verschijnsel in WinGPS Voyager

Als ik WinGPS via UDP 'voer' met flink versneld afgespeelde NMEA-records gebeurt er iets geks.
Klein programmatje leest een oude nmealog, en stuurt dat via UDP naar WinGPS.
Nu staat in die records gewoon de SOG (in RMC-records) en de watersnelheid (in VHW-records)
Dit laat het Navigatie-schermpje in WinGPS zien:



De watersnelheid is ok.
De SOG wordt kennelijk berekend uit 'iets', wellicht afgelegde afstand en PC-kloktijd, maar niet genomen uit de RMC die van de GPS komt.
En dan wordt de stroming en wind ook fout berekend....

Dat zou toch niet zo moeten. Ik heb het Stentec gemaild.

Weet iemand hoe OpenCPN dit doet?

Beste BK,

zou eens kijken naar de SignalK server. Als er meerdere dezelfde bronnen zijn kun je aangeven welke de voorkeur heeft. Daar ligt mogelijk het probleem.

Groet,

Bram

Goed gevonden Baasklusje!

Eigenlijk zouden de fix time, COG en track angle gebruikt moeten worden uit het RMC bericht. Maar misschien is het een workaround omdat sommige GPSen die niet zo zuiver hierin de data aanleveren?

Ik neem aan dat in de data gewoon de originele fix tijdstip is gebruikt? Maar die is slechts op de seconde nauwkeurig lijkt het? Mogelijk dat WinGPS daarom die tijdstippen (deels) negeert gezien een GPS vaak met 10Hz kan zenden en gewoon de ontvangsttijdstippen binnen die 10Hz gaat gebruiken voor de verdere berekeningen samen met de posities.

Er zal wel een reden voor zijn, want het kost veel meer moeite om dit te programmeren dan gewoon de data over te nemen uit de RMC.

Alleen de DOG zou dan handmatig berekend moeten worden, maar dat zou die moeten doen obv de positie en de fix time. Wel de juiste RMC kiezen voor de seconde, maar uiteindelijk middelt het zich uit.

Baasklusje schreef :
Je hebt een sterke opvatting over de werking van software.

En niet versneld afspelen?
Je kan het bestand evt ook via navmonpc doorsturen naar wingps, en versnellen. Dan kan je zien of het zich ook in navmonpc voordoet, of alleen in Wingps.
Hoe is log gemaakt? Alle data zelfde hz?

Gepost met de officiële Zeilersforum-app

Afgelopen zomer had ik ook dat de SOG niet overeenkwam met STW.
Verschil was niet zo extreem en daar ik niet bekend was met stroming in grote- en kleine belt weet ik het eerst daaraan. Verschil was een knoop of zo.
Gemeld aan stentec, maar dag later was het weer goed en kon dus geen detail logging maken.


Gepost met de officiële Zeilersforum-app

Sjoerd02 schreef :
1 knoop is of wat stroom of een afwijking van de log.

666 schreef :
- Alle data dezelfde 1 Hz
- Versneld afspelen via NavmonPC: correcte snelheid (SOG) in NavmonPC, te hoge SOG in WinGPS
- De afwijking van de SOG in WinGPS is lineair met de afspeelsnelheid.

Het kan haast niet anders dan dat WinGPS de snelheid berekent uit de afstand tussen 2 posities (te vinden in veel soorten GPSrecords) gedeeld door de verstreken tijd.
Alleen, die tijd moet dan niet te verstreken tijd op de PC zijn maar de versnelde verstreken tijd uit de NMEArecords.
Wellicht gebruikt WinGPS nog een berekening voor snelheid uit de tijd dat er nog geen RMC (met SOG erin) was, of zo iets.

Het is bij normaal gebruik natuurlijk geen issue, ik had het alleen niet verwacht.....
Ik was een demo van SPD aan het maken voor zaterdag, de wintermeeting.
Met SPD naast WinGPS beide dezelfde (versnelde) UDP NMEA stream gebruikend....

Ik zie dit ook wanneer ik mbv NMEA logger NMEA data voer aan WinPGS. Ik meen mij te herinneren dat hier iets over geschreven is in de handleiding bij het hoofdstuk aanmaken van een polar diagram. Daarbij gebruikt wingps SOG. Misschien dat ze hun eigen demping (of juist niet) willen gebruiken om een beetje goede data te krijgen.

Aswin schreef :
Hier zal wel het antwoord in zitten. Van de diverse sensoren die aan boord zijn is de GPS de enige met een klok stamp. Het log en de windmeter voegen geen tijdsaanduiding toe. Daarbij heeft NMEA0183 last van jitter. Een beetje leuke zeil software doet daar iets tegen. Mogelijk hebben ze bij Stentec iets slims bedacht en hebben ze er voor gekozen de mogelijkheid om versneld af te spelen daaraan opgeofferd. Verder moeten zij rekening houden met een grote verscheidenheid van gebruikte instrumenten. Oudere RM GPS's gaven bijvoorbeeld maar met 0,5Hz een RMC bericht. Maar andere GPS's berekenen de SOG en COG niet door middel van differentiëren maar met het Doppler effect. Wat hele andere data geeft. Differentiëren geeft altijd een data reeks die een halve periode achter loopt.

@BK Kan je een klein stukje van je log hier droppen, ben ook wel nieuwschierig wat OpenCPN doet. Bij normaal versneld afspelen weet ik dat er geen probleem is, maar je kan OpenCPN ook instellen om C en S-OG te bepalen aan de hand van twee posities met een bepaald tijdsverschil. Hoe dat gaat weet ik niet.

3Noreen schreef :
En dan lijkt het dus logisch, als je een beetje wil dempen, om een klok te nemen die daarbij past.
De klok uit de GPS records.
In ieder geval niet de PC-klok.......

In een GLL zitten positie en tijd
in een GGA ook positie en tijd
In een RMA positie en sog, geen tijd
in een RMC alle 3: positie, tijd en sog.

Als WinGPS zonder RMC en RMA moet kunnen werken dan is zelf berekenen de enige optie.
Maar dan welmet de tijd uit GGA of GLL, niet de computerklok.
Ik zal eens een log zonder RMC voeren!

Baasklusje schreef :
Jou logica ontgaat mij. Als je iets als bijvoorbeeld de stroom wilt uitrekenen lijkt het me zaak om voor de snelheid door het water en voor de snelheid over de grond de zelfde kolk te nemen. Als je iets slims inbouwt om te zorgen dat hier boven door mij geschetste problemen oplost dat je de klok van dat "slims" gebruikt.
PC-klokken zijn naar nauwkeurig tot op de ms. Nagenoeg geen jitter. Dat is een tijdsbericht van een GPS in ieder geval niet.

3Noreen schreef :
Stel je hebt 2 posities.
Je wil weten hoe snel je de afstand ertussen hebt afgelegd.
Dan neem je de tijd op beide posties, de afstand ertussen, en je deelt afstand door tijdsverschil.

Als je een willekeurig ander tijdsverschil neemt (de tijd op de PC tijdens versneld afspelen een log, bijvoorbeeld) krijg je niet de werkelijke snelheid. Je deelt dan door (in dit geval) veel te weinig tijd.

Inmiddels een log zonder RMC en zonder RMA gevoerd. Dat lust WinGPS ook.
Er komt een positie en koers in beeld. We varen snel over het scherm.
Ook hier gebruikt WinGPS de PC-tijd (tijdens de snelle replay) en niet de tijd uit GLL en GGA.
Vreemd.

Overigens, in RMC en GLL zit tijd in honderdste seconden.
Lijkt me nauwkeurig genoeg voor onze snelheden (trimarans uitgezonderd )

Baasklusje schreef :
1. Je kunt er voor kiezen als software ontwikkelaar het versneld af kunnen spelen van een log op te offeren aan andere doelen die je hebt.
2. als je stroom wilt uitrekenen zul je de snelheid door het water moeten weten/gebruiken. Die snelheid door het water heeft geen klok. Daar moet je dus een klok aan toevoegen. Welke klok ga je gebruiken. De klok van de GPS waarvan je zeker weet dat je last van jitter hebt of doe je "iets" anders.
3. De mogelijkheid dat een GPS de snelheid en richting door middel van een doppler vergelijking laat je geheel buiten beschouwing. Ik denk dat 99,9% van de bezitters van een GPS niet weten welke van de twee methodes de GPS gebruikt. Maar er zit wel een tijdsverschil tussen.
4.De tijd die het kost om een RMC bericht serieel te versturen kan nogal verschillen. Bij 4800 baud is dat een eeuwigheid in deze context.

Aardig allemaal, maar in een GLL, GGA en RMC zit het tijdstip waarop de GPS de positie heeft vastgesteld.

Om dan die tijd niet te gebruiken maar een andere, op de PC, waar dat GPS-bericht pas een tijdje later aankomt (4800 bps en 1 HZ) en dan nog later door het programma wort opgepakt (dat programma was iets anders aan het doen, kaart verschuiven bijvoorbeeld) dan weet je iig zeker dat je niet een betere tijd hebt dan de tijd die al in het GPSrecord stond.

Baasklusje schreef : Met de normale instellingen doet OpenCPN het goed, al kan je niet de stroom uitrekenen. Laat je OpenCPN rekenen met een vast tijdinterval tussen twee posities dan gaat het ook verkeerd. Zal gelijk een voorstel maken om dit te verbeteren, misschien kan het nog mee in versie 5.8.

rooiedirk schreef :
Bedoel je dat ook OpenCPN niet de tijd uit de GPSrecords gebruikt maar de PC-tijd?
En ook niet de SOG uit de RMC gebruikt?

3Noreen schreef :
Nu geef je zelf een uitstekende reden om de tijd in het RMCrecord (of een GLL,GGA) te gebruiken, en niet de tijd op de PC.
Dank je

Bovendien, in de RMC zit de SOG. Als die er is ga je toch niet weer zelf SOG uitrekenen met ook nog een klok die er niets mee te maken heeft?

Baasklusje schreef :
Je leest heel er selectief. Confirmation bias
Bij open sores kun je kiezen op welke manier hij het uitrekent.

Baasklusje schreef :
Moeilijk hé. De meting van de snelheid door het water moet op zoveel mogelijk het zelfde tijdstip plaatsvinden als de meting van de snelheid over de grond. Maar van de snelheid door het water weet je niet wanneer die plaats heeft gevonden. Om toch maar iets uit te rekenen neem je aan dat de delay van beide metingen veroorzaakt door de NMEA het zelfde is. Dus voor beide metingen neem je het tijdstip van binnenkomst.

3Noreen schreef :
Laat dat nu precies zijn wat SPD doet.... En dan ook nog met een instelbare middeling van de ruizige watersnelheid over een aantal metingen.

Overigens zijn, gezien de zeer geringe wijziging per seconde van bootsnelheid (een flinke massa, moeilijk te versnellen of vertragen) in zowel SOG als STW, en de nog geringere wijziging per seconde van stroomsnelheid, de tijdsverschillen (gemiddeld een halve seconde bij 1 Hz NMEA) tussen de metingen geheel totaal en absoluut irrelevant.


Je doet me een beetje denken aan 2 gepromoveerde medewerkes van me, lang geleden, een doctor in de wiskunde en een doctor in de kernfysica.

Bij een afwijking in metingen van het verwachte resultaat verwierp de wiskundige meteen de hele theorie, maar de natuurkundige zei 'meetfout'.

Baasklusje schreef :
Vandaar dat mensen zeeziek worden en problemen met hun evenwichtsorgaan ondervinden op zee.

3Noreen schreef :
Ik word nooit zeeziek op zee.
Ik heb een 1 kHz evenwichtsorgaan.