Onderwerp: GPS fout

Kijk eens of de juiste chart datum (de geoïde) is ingesteld. De geoïde is een wiskundig model dat de vorm van de aarde benaderd en waarop de coördinaten gebaseerd worden. Op zeekaarten is dit dikwijls WGS84 of ETRS89 (verschil tussen beide is te verwaarlozen).

Kaartdatum (tegenwoordig vaak WGS84) misschien niet (meer) goed ingesteld?

Edit: zie dat Ondinneke me net voor was.

Als het niet het bovenstaande is kan je een "Map Shift" doen. Wel even controleren op een tweede bekende locatie of alles dan klopt.

Ik acht het ook mogelijk dat deze fout een ingewikkelde reclame campagne van de Pearl in Urk is.

WGS84 stond goed. Van alles geprobeerd...uiteindelijk maar een factory reset gedaan, daar knapte hij van op.

In ieder geval bedankt voor het meedenken!

Ach, GPS, highly overrated. Gegist bestek is veel nauwkeuriger

Stond ie nog op wintertijd?.

ik heb recent getest met 2 gps'en
oude USB: snelle fix, nauwkeurig, 4800baud, niks mis mee
nieuwe NMEA (9600b): drie minuten voor een fix en m'n schip gaat regelmatig de wal op (zonder m'n toelating )
heb prentjes! leuk hoor, schip op wandel

volgens leverancier normaal...
leren mee leven

ErikSnel schreef :
Ja, dan weet je tenminste zeker dat je niet weet waar je bent!

i1056.photobucket.com/albums/t...5027_zpscd2cd522.png

Wat vinden jullie van deze gps-fout? (en heeft er iemand een ideetje hoe ik dit kan oplossen?) Als ik onderaan het Opencpn scherm kijk zie ik de noorderbreedte constant blijven, de lengte daarentegen wisselt voortdurend tussen de exacte en een positie ongeveer 300 mijl ten oosten van mijn werkelijke positie, ik zit dus een groot deel van de tijd in Duitsland... Op mijn marifoon wordt de positie die zijn info van dezelfde gps-module krijgt wél stabiel weergegeven.

Monitor de NMEA data eens in OpenCPN en in een telnet sessie. Zijn die afwijkende posities dan ook zichtbaar? Lijkt me een foute interpretatie van Ubuntu / OpenCPN.

Kijk eens naar de kwaliteit van de data... Heb je rmc berichten of alleen bepaalde gps strings.. Ik had dat eerst ook toen ik de iPad gps data via de mux laten halen.. Furuno instellen dat hij idd de rmc strings doorgeeft ( menu) en zorgen dat je de draadjes goed aangesloten hebt...
Bij jou wellicht iets andere configuratie maar met deze afwijkingen is de gps onbruikbaar.. En zeker niet iets waarmee je moet leren leven..

Dit is wat hij binnenkrijgt, ik zie alleen de juiste positie info staan, niet die van mijn "Duitse positie". De fout wordt ook kleiner naarmate ik verder van Den Osse wegvaar in de richting van Bruinisse bv. Ter hoogte van de haven van Bruinisse is de fout nog maar 1 mijl...
i1056.photobucket.com/albums/t...4848_zps605e3f94.png

Staat de AIS aan? die AIVDO string ziet er raar uit. Volgens opencpn.org/ocpn/nmea_sentences

AIVDO klopt wel hoor.
RMC ziet er ook goed uit.
positie ook.

Zet je AIS eens uit.

De GPS data ziet er goed uit, het AIVDO bericht kan ik zo niet controleren, overtypen is me te lastig om daar een positie uit te genereren

Een positie kan op verschillende manieren worden geschreven. Minuten en/of seconden worden soms vertaald naar decimale eenheden.Als de ene manier wordt aanzien voor de andere kan er een klein of groot verschil opzitten. Dit merk je pas wanneer er getallen boven de 60 op het scherm verschijnen of nooit boven de 60 uitkomen.

Dit valt in te stellen in de GPS

nepal schreef :
Dat geldt alleen voor de display presentatie, de nmea output is altijd decimaal ( achter de minuten)

henkvd schreef : Maakt niet echt verschil hoor. Als ik mijn marifoon (GX2100) uitzet, kan ik normaal geen AIS binnenkrijgen maar dan blijft hij hetzelfde doen. Het gekke is ook dat de afwijking verschilt van de plaats waar ik vaar. Misschien moet ik in de MUX AIVDO berichten filteren maar ik veronderstel dat ik dan ook geen AIS meer krijg of hebben die twee niets met elkaar te maken?

Kan je een log maken, met het springen, van de nmea data.

TXT file maken


Als AIVDO niet in orde zou zijn kan je die filteren AIVDO is alleen eigenschip info, AIVDM zijn ontvangen targets.

Het vreemde is dat je klacht normaal wordt veroorzaakt door verminkte data ( vreemde karakters er tussen, afgebroken zinnen en dat niet netjes onder elkaar) daar is in je log geen sprake van, alleen de AIVDO berichten kan je niet snel even controleren op juiste positie info.

Ik ben eens gaan kijken in de logbestanden van OpenCPN en daar kan je dan toch die oostelijke positie terugvinden:


17:02:30 CEST: Setting Viewpoint Lat/Lon 51.7559, 12.1863
17:02:30 CEST: Setting Ownship Lat/Lon 51.7556, 12.1805
17:02:30 CEST: System default Language: nl_BE
17:02:30 CEST: Opencpn language set to: nl_BE
17:02:30 CEST: ChartSymbols loaded from /usr/share/opencpn/s57data/chartsymbols.xml
17:02:31 CEST: Using s57data in /usr/share/opencpn/s57data
17:02:31 CEST: Setting Viewpoint Lat/Lon 51.7559, 12.1863
17:02:31 CEST: Setting Ownship Lat/Lon 51.7556, 12.1805
17:02:31 CEST: Opening NMEA Datastream UDP:192.168.1.1:10110
17:02:31 CEST: Creating glChartCanvas
17:02:32 CEST: PlugInManager searching for PlugIns in location /usr/lib/opencpn
17:02:32 CEST: PlugInManager: Loading PlugIn: /usr/lib/opencpn/libgrib_pi.so
17:02:32 CEST: /usr/lib/opencpn/libgrib_pi.so
API Version detected: 107
PlugIn Version detected: 202
17:02:32 CEST: PlugInManager: Loading PlugIn: /usr/lib/opencpn/libdashboard_pi.so
17:02:32 CEST: /usr/lib/opencpn/libdashboard_pi.so
API Version detected: 106
PlugIn Version detected: 102
17:02:32 CEST: OpenGL-> Renderer String: AMD Radeon HD 6480G
17:02:32 CEST: OpenGL-> Using Framebuffer Objects
17:02:32 CEST: OpenGL-> Using FBO Stencil buffer
17:02:32 CEST: OpenGL-> Using Stencil buffer clipping
17:02:32 CEST: OpenGL-> Estimated Max Resident Textures: 98
17:02:32 CEST: Changing NMEA Datasource for GPGGA to UDP:192.168.1.1:10110 (Priority: 1)
17:02:32 CEST: Changing NMEA Datasource for GPGLL to UDP:192.168.1.1:10110 (Priority: 1)
17:02:32 CEST: Changing NMEA Datasource for GPGSA to UDP:192.168.1.1:10110 (Priority: 1)
17:02:32 CEST: Changing NMEA Datasource for GPRMC to UDP:192.168.1.1:10110 (Priority: 1)
17:02:32 CEST: Changing NMEA Datasource for AIVDO to UDP:192.168.1.1:10110 (Priority: 1)
17:02:32 CEST: ChartDB Cache policy: Max open chart limit is 20.
17:02:32 CEST: Loading chart db version: V018
17:02:32 CEST: Chartdb: Chart directory list follows
17:02:32 CEST: Chart directory #0: /home/dirk/Documenten/ENC_ROOT
17:02:32 CEST: Chart directory #1: /home/dirk/Documenten/20140305_U6Inland_Week10_NL/ENC_ROOT
17:02:32 CEST: Chart directory #2: /home/dirk/Documenten/BE7BZ001
17:02:32 CEST: Chart directory #3: /home/dirk/Documenten/BE7BZ002
17:02:32 CEST: Chart directory #4: /home/dirk/Documenten/Belgische kust
17:02:32 CEST: Chart directory #5: /home/dirk/Documenten/BE7EV003
17:02:32 CEST: Chart directory #6: /home/dirk/Downloads/kust bberge
17:02:32 CEST: GPS Watchdog Timeout is: 6 sec.
17:02:32 CEST: Loading World Chart Q=2 in 106 ms.
17:02:32 CEST: Background world map loaded from GSHHS datafiles found in: /usr/share/opencpn/gshhs/
17:03:16 CEST: Initializing Chart /home/dirk/Documenten/20140305_U6Inland_Week10_NL/ENC_ROOT/1R/6/1R66893I/1R66893I.000
17:03:17 CEST: Initializing Chart /home/dirk/Documenten/ENC_ROOT/1R5GR011.000
17:03:17 CEST: Initializing Chart /home/dirk/Documenten/ENC_ROOT/1R5GR022.000
17:03:17 CEST: Initializing Chart /home/dirk/Documenten/20140305_U6Inland_Week10_NL/ENC_ROOT/1R/6/1R6688XI/1R6688XI.000
17:03:17 CEST: Initializing Chart /home/dirk/Documenten/20140305_U6Inland_Week10_NL/ENC_ROOT/1R/6/1R66K8XI/1R66K8XI.000
17:03:18 CEST: Initializing Chart /home/dirk/Documenten/20140305_U6Inland_Week10_NL/ENC_ROOT/1R/6/1R66K93I/1R66K93I.000
17:03:18 CEST: Initializing Chart /home/dirk/Documenten/20140305_U6Inland_Week10_NL/ENC_ROOT/1R/6/1R66K99I/1R66K99I.000
17:03:18 CEST: Initializing Chart /home/dirk/Documenten/20140305_U6Inland_Week10_NL/ENC_ROOT/1R/6/1R66899I/1R66899I.000
17:03:42 CEST: LOGBOOK: 2014-05-28 15:03:42 UTC GPS Lat 51.75439 Lon 12.15768 COG 229.25465 SOG 5.15 Knopen
09:44:54 CEST: LOGBOOK: 2014-05-29 07:44:54 UTC GPS Lat 51.74161 Lon 3.89123 COG 30.50000 SOG 0.00 Knopen
09:49:55 CEST: Initializing Chart /home/dirk/Documenten/ENC_ROOT/1R5HV002.000
10:00:00 CEST: LOGBOOK: 2014-05-29 08:00:00 UTC DR Lat 51.74161 Lon 3.89123
10:30:00 CEST: LOGBOOK: 2014-05-29 08:30:00 UTC DR Lat 51.74161 Lon 3.89123
11:15:14 CEST: LOGBOOK: 2014-05-29 09:15:14 UTC DR Lat 51.74161 Lon 3.89123
11:30:00 CEST: LOGBOOK: 2014-05-29 09:30:00 UTC DR Lat 51.74161 Lon 3.89123
12:00:00 CEST: LOGBOOK: 2014-05-29 10:00:00 UTC DR Lat 51.74161 Lon 3.89123
12:30:00 CEST: LOGBOOK: 2014-05-29 10:30:00 UTC DR Lat 51.74161 Lon 3.89123
13:00:00 CEST: LOGBOOK: 2014-05-29 11:00:00 UTC DR Lat 51.74161 Lon 3.89123

roozeboos schreef :
Als ik het laatste AIVDO bericht overtik in rl.se/aivdm krijg ik:rl.se schreef :

Message 18 - Class B Position Report
!AIVDO,1,1,,A,BC`dU0@008=`O47IeFPC4?000000,0*5F

Parm# ↓ Parameter ↓ Value ↓ Description ↓
01 Message ID 18
02 Repeat indicator 1 Repeat once
03 User ID (MMSI) 244000001
04 Spare 0
05 SOG 0
06 Position accuracy 1
07 Longitude 11*54.7400'E
08 Latitude 51*44.4968'N
09 COG 30.5
10 True heading 30
11 Time stamp 0
12 Spare 0
13 Class B unit flag 0 Class B SOTDMA unit
14 Class B display flag 0 No display available, not capable of displaying Message 12 and 14
15 Class B DSC flag 0 Not equipped with DSC function
16 Class B band flag 0 Capable of operating over the upper 525 kHz band of the marine band
17 Class B Message 22 flag 0 No frequency management via Message 22 , operating on AIS1, AIS2 only
18 Mode flag 0 Station operating in autonomous and continuous mode (default)
19 RAIM-flag 0
20 Communication state selector flag 0 SOTDMA communication state follows


De positie sprongen zijn hiermee wel verklaard, je MMSI nr klopt ook niet

Dus, als ik het goed begrijp worden de sprongen toch veroorzaakt door de AIS-gegevens die binnenkomen. En dat MMSI-nummer, is dat het mijne of dat van het schip waarvan ik AIS-data binnenkreeg?

AIVDO is jouw scheeps info

Da's wel heel gek, dan moet ik mijn MMSI-nummer dus controleren op mijn marifoon. Het lijkt dus dat de marifoon via zijn AIS gegevens iets anders doorstuurt dan de GPS-gegevens die rechtstreeks van de GPS komen en dat dit conflicten geeft. Ik veronderstel dat ik die AIVDO gegevens kan filteren in mijn MUX. Als dat toch enkel de gegevens van mijn eigen schip zijn, heb ik die niet echt nodig om andere AIS-objecten te kunnen zien en heb ik aan de AIVDM gegevens genoeg.
Alvast heel hartelijk bedankt voor je hulp.