Daar komt inderdaad wel wat bij kijken. Multipath-problemen krijg je vooral in situaties waarbij het zicht op de hemel beperkt is, bijvoorbeeld in een gebouw voor een raam. GPS ontvangers registreren dit probleem over het algemeen wel (als dilution of precision), maar moeten toch het beste maken van wat ze wel ontvangen.

Helaas zie je nog weinig ontvangers die in staat zijn -tegelijk- meerdere systemen te gebruiken, bijvoorbeeld gps, glonass en in de toekomst galileo. Ik vermoed echter dat die er meer gaan komen naarmate de techniek vordert. Galileo zal hier waarshijnlijk aan bijdragen door haar grotere precisie (1 meter resolutie voor het 'gratis' signaal). Als je data uit meerdere systemen combineert kun je ook beter vaststellen dat een signaal waarschijnlijk een reflectie is en genegeerd kan worden tot het directe signaal zichtbaar wordt.

Het plotten in bovenstaande figuur, was 1 per sec.
 
Waar ik het meeste last van heb zijn reflecties in de bebouwde kom,
in deze GPS module kan ik opgeven onder welke horizon hoek, satellieten nog valide zijn.
meestal zet ik deze op 15 graden, zodat de meeste bebouwings reflectie afvalt.
 
Dat is goed te zien als de antenne bijv. naast het huis wordt gezet, daardoor zijn er satellieten aan de andere
kant van het huis die dan nog net niet zichtbaar zijn voor de GPS. Maar door reflectie worden
satellieten, die nog net niet zichtbaar zijn toch door de bebouwings reflectie toch waargenomen met een behoorlijke sterkte.
Vaak ziet de software het ook dat het niet klopt, omdat de berekeningen in de knoop komen, en wordt de des betreffende
satelliet alsnog gedisabled door de GPS module. Maar als er te weinig satellieten totaal in zicht zijn wordt dat niet opgemerkt,
door de software en ontstaan er uitschieters, afhankelijk van de extra reflectie weg.

Het kan inderdaad verkeren. Gisteren vloog ik van boekarest naar amsterdam, en rond kruishoogte eens geprobeerd wat de gps van mn telefoon er van maakte vergeleken met het systeem dat de schermpjes met vluchtdata vult.

Tot mn verbazing klopte de hoogte over het algemeen binnen 100-200 ft van wat het display aangaf, al weet ik niet waarop die displays gebaseerd zijn. Toestel was een tamelijk oude A318 van Tarom, met een airshow systeem op kleine lcd schermpjes die boven de stoelrijen hangen (geen AVOD). Ik weet niet of dat systeem zelf ook op GPS werkt of zn hoogteinformatie haalt uit barometrische bron.

Ik vermoed dat het een systeem wel sensordata gebruikt gezien het ook de buitentemperatuur laat zien, maar voor locatie waarschijnlijk wel van gps afhankelijk is (positie leek te nauwkeurig om op inertial guidance te werken oid).

Mooie figuur. Wat is de tijd per stip?

 
Komt wel meer voor, hier zie je ook uitschieters, dit is een stationaire plot van enkele uren met de hoogte gefixeerd,
satellieten, staan niet stil, en varieren in aantal. 
 
 

Ik vermoed dat deze 'misser' te maken had met mis-synchronisatie van de gps tijd en de gps tijd die de telefoon bijhield. X en Y coordinaten herstellen zich relatief snel omdat de positie van de sats nog wel bekend is, maar voor de Z component moet de klok weer synchroniseren en dat kost blijkbaar een stuk meer tijd.

Dat het voor de x en y coordinaten sneller vlot trekt komt door de aanname dat je je bevindt op een bolschil, terwijl voor de z coordinaat de positie binnen een hele bol berekend moet worden (uiteraard binnen zekere grenzen, maar het komt in de praktijk voor dat er kilometers afwijking van NAP zijn bij gebruik in de bergen of bijvoorbeeld aan boord van vliegtuigen. In het laatste geval kan de voorkeur zijn om x en y via gps te bepalen, maar z barometrisch.

Kan de bepaling van hoogte (z) en positie (x,y) verbeterd worden door te middelen over een slim gekozen tijdsinterval? Een langdurige gps-registratie op mijn smartphone vertoont meestal een begin met drift, dan een plateau, en weinig ruis. Waar begint het plateau met een kleine standaarddeviatie? Afgaande op de drie registraties in onderstaande grafiek zou het tijdsinterval kunnen beginnen na de eerste anderhalf uur, en stoppen aan het eind, of bij een incidentele gps-misser zoals hier op t=22 h. De standaarddeviatie van de plateauwaarde is dan minder dan 1 meter.
 
Maar als de verschillende plateauwaardes van de drie registraties worden samengenomen is de standaarddeviatie ongeveer 2 m. Daardoor is de standaarddeviatie uiteindelijk weinig beter dan bij blindelings middelen over de totale tijd.
 
Het gps-resultaat kan ook vergeleken worden met een referentiewaarde. Het zolderraam bevindt zich 14 m boven NAP (d.w.z. 13.5 m boven straatniveau, en straatniveau is 0.5 m boven NAP, volgens de ahn-website. Maar is NAP precies gelijk aan MSL, het zeeniveau van gps?). Dat verschilt 3 m met de gps-hoogte.  De (x,y) positie verschilt ongeveer 10 meter met de (x,y) positie volgens google earth. Maar hoe nauwkeurig geeft google earth de positie van een huis aan?
   
De plotselinge gps-misser op t=22 h, die lang doorwerkt, is een raadsel. In de omgeving van de smartphone gebeurde er niets. Misschien was het een storing van de app, of misschien was er iets met het gps-signaal.
 
Opmerkelijk is trouwens dat de standaarddeviatie van de gps-hoogte in dit praktijkvoorbeeld ongeveer even groot is als de standaarddeviatie van de horizontale positie, dus niet groter zoals theoretisch verwacht werd.

Afgezien van ionosfeer en reflecties zit het systeem sowieso veel complexer in elkaar.

Om positie te bepalen moet je een aantal zaken weten:

- afstand tot de sat (tijdsverschil met interne klok)
- positie van de sat (azimuth/elevatie, uitrekenen)
- identiteit van de sat

Dat lijkt op zich niet zo moeilijk, maar het heeft een paar grote problemen: de exacte positie van de gps sats is niet nauwkeurig voorspelbaar. Deze informatie (ephermis) wordt verzonden door de sats, maar op een extreem lage bitrate. Daarnaast is er data die verstoringen in kaart bregnt (almanac) die je ook nodig hebt. Het binnenhalen van de hele almanac en ephermis duurt pakweg een kwartier, als je tenminste een kwartier lang zicht hebt op 1 sat, anders kun je opnieuw beginnen.

Een complete cold start van een gps systeem zou in de praktijk pakweg 20 minuten duren (vereist 12.5 minuten zich op een enkele sat, en dan heb je lang niet altijd gezien ze over de horizon verdwijnen).

Er is echter wel een shortcut om dat veel sneller te doen: een aanname. Die aanname is initieel dat je je op de grond bevindt, en vervolgens niet de hele almanac en ephermis nodig hebt om je positie op het oppervlak te bepalen. Door te 'gokken' dat je op de grond staat kun je aannames maken over de hoeken waaronder je de sats ziet, en daarmee de afstanden.

Dit maakt dat een gps systeem als standalone navigatie in de auto een fix realiseert in pakweg een minuut.

De ultieme oplossing is om almanac, ephermis en nauwkeurige tijd te verkrijgen via een andere weg, bijvoorbeeld internet. Deze 'assisted gps' oplossing zorgt ervoor dat je met een smartphone in de openlucht al in pakweg 10 seconden een fix hebt voor lat/long.

Om de hoogte nauwkeurig te krijgen heb je echter ook de exacte gps tijd nodig. Deze is lastiger te verkrijgen: via NTP krijg je een aardig nauwkeurige tijd, maar de echt nauwkerige vereist vergelijken van signalen van diverse sats. Dit vereist het nodige meten en synchroniseren, waardoor het lang duurt voor je de hoogte goed in beeld hebt.

Voor het idee: via NTP krijg je een tijd die correct is in de orde van een milliseconde. Dat lijkt heel nauwkeurig, maar als je er positie op moet bepalen is het een afwijking van 300 kilometer. Door de uitgezonden tijdcodes van een paar sats te vergelijken bepaal je de ware gps tijd, maar het kost enige tijd om dit goed te krijgen.

De weg die de radio signalen afleggen is niet constant, de ionosfeer is in beweging.
Er is zelfs enige dag en nacht ritme ook bij GPS, soms wel tot 100 nSec.
Wat al een verschil oplevert van 30 meter. De radio signalen volgen niet altijd het rechte pad.
 
Ik heb een vaste opstelling van een gps antenne buiten en module van Rockwell binnen.
geeft alleen ruwe GPS data, daar kan je ook je hoogte kan vast zetten, wat al
een hele verbetering oplevert in positie. Geeft een mooi inzicht in de werking.
 
Daarnaast varieert ook het aantal zichtbare satellieten, en de hoek waaronder
ze verschijnen, onzekerheden genoeg.
 
In de waarnemingen zie ik net zoveel variatie in positie als hoogte, 
variaties in  positie tot 30 meter zijn heel normaal. In de moderne GPS software
wordt dit allemaal gecorrigeerd. Hoogte variaties vallen onder de zelfde onzekerheden
als de positie.

De drift van z en x duurde veel langer dan ik had verwacht, anderhalf uur. Als je slechts een paar minuten de hoogte meet dan lijkt de waarde vrij constant, maar dat is dus onbetrouwbaar.

 

Er bestaat een app, 'GPS averaging', die de metingen vanaf het begin middelt, maar die zou hier weinig verbetering opgeleverd hebben.

Vrij typisch resultaat. Het laat ook goed zien hoe gps doet waar het voor gemaakt is (lat/long nauwkeurig bepalen), terwijl hoogste slechts een extratje is.

Het is wel interessant om te zien hoe de nauwkerigheid zich gaat vergelijken met galileo, wat een lat-long positie met een nauwkeurigheid van een centimeter kan bereiken (met een licensed prodcut, anders is het ca 1 meter).

Aardig is ook dat we straks 4 simulatne systemen hebben (gps, glonass, galileo en het chinese systeem), wellicht valt er meer precisie te winnen door deze te combineren. Zeker glonass zit al in veel producten gezien rusland een flinke importheffing (ik dacht 25%) heeft op apparaten die wel gps maar geen glonass ondersteunen.

Hoogte (z) en positiemeting (x,y) op basis van gps met smartphone op een vaste plaats bij het raam, gedurende 6 uur. De hoogte varieert 10 meter in de loop van anderhalf uur.
   

Klopt inderdaad, 51 meter boven MSL, wat goed lijkt te kloppen. Dat getal krijg ik overigens alleen vlakbij een raam of op het balkon en na een paar minuten fix, daarvoor fluctueert het tot onzinnige waarden als 15 meter terwijl de lat/long coordinaten wel redelijk betrouwbaar zijn.

Of een eenvoudige gps module de hoogte boven MSL kan bepalen valt te bezien: WGS84 is een eenvoudig model dat via een berekening op basis van lengte- en breedte coordinaten een correctie geeft ten opzichte van de cirkelvormige banen van de gps sats. Voor MSL heb je een lookup table nodig. Dit hoeft geen bijzonder grote tabel te zijn, maar wel dusdanig groot dat het niet zomaar te implementeren is in de eenvoudigste microcontrollers.

Stel dat je het per 100 km2 een waarde wilt geven van 1 byte en alleen het land opneemt in de tabel zit je toch al aan ca 16 kB. Uiteraard peanuts in termen van het geheugen van een smartphone of iets degelijks, maar voor iets als een arduino is dat toch het halve flashgeheugen, en voor een simpele PIC of ATTiny zelfs meer dan er aanwezig is.

Benm schreef: Ik heb een GPS app (gps status, android) waarbij ik kan kiezen voor hoogte vs WGS84 of MSL. Het geeft 98 meter boven MSL en 98 meter boven WGS.

 
Daar moest waarschijnlijk staan "98 meter boven WGS en 51 meter boven MSL"? Dezelfde app geeft hier in Amsterdam tenminste WGS = MSL + 47, net als bij WillemB. Het verschil WGS-MSL is overal in Nederland ongeveer gelijk, volgens een kaartje in wikipedia (klik).

Ja, die van mij ook, is een kale module die NMEA codes afgeeft, zoals bij jou, of een code gemaakt
door de fabrikant.  Ik heb dan ook allen een zeer oude MS-DOS interface, om er mee te communiceren.
 
vandaar mijn hoogte ook 47 meter is, ik kan switchen, tussen intern referentie of opgegeven referentie.
 
Ik heb een scherm vol met getallen.., die steeds worden bijgewerkt, idem met de datum,
die wordt ook terug gerekend naar 1980.
 
Ik gebruik die module als tijd referentie.