Problem: Urdålig GPS?

Alla har vi olika behov av hur saker och ting fungerar. Uppenbarligen är nexusens gps tillräckligt bra för dina, för mina, där jag behöver en exakthet på 5-10 meter när jag står mellan två åttavåningshus, räcker det inte på långa vägar. Att sen som folk beskriver i tråden att gpsen inte låst efter en timmer väl ändå inte att betrakta som ok? Dessutom finns det andra enheter utan glonass som har en väl fungerande gps, så det går ju uppenbarligen att få till..

Sent from my GT-I9300 using Tapatalk 2

 

GPS:n i nexusen är det nog inge större fel på jämfört med andra med samma kretsar och som är utan Glonass.

Då börjar vi uppifrån och ner då:
GPS är radio vågor runt 1,5gHz när du kommer upp i dom frekvenserna så beter sig radiovågorna mer och mer som ljus ju högre frekvens desto mer ljus liknande blir dom. Anledningen att du har svårt att få en noggrannhet på 5-10 meter mellan två åttavåningshus är så ledes inte alls förvånande. Får du sol på dig var du än står mellan dessa hus? Studsar inte ljus strålarna i fönster mm och ger olika sken samt reflektioner mellan husen? Exakt likadant är det med radiovågorna för din GPS den får en drös information och studs och ekon från olika satelliter och försöker göra det bästa den kan av informationen.

Lägg sen till 100 wifi nätverk som finns i dom byggnaderna + 200 mobiltelefoner som finns i närheten och stör din GPS. Lägg sen till att du har solstormar och låga moln i vägen för signalerna. Så råkar någon slå på en micro och din GPS har många störningar att ta hänsyn till.
Citat från wikipedia:
Störningar

Vid konfliktsituation kan det vara av intresse för parterna att störa motståndarens tillgång till navigering och precisionsvapen och man har därför utvecklat ett antal olika system för störning av GPS, dock inget känt svenskt. Ett exempel är det ryska Aviaconversiya MAKS 1999 som har en uteffekt på 8 W och drivs av ett 12 V -batteri. Systemet väger ca 3 kg. Det stör inom en radie på 45 km i öppen terräng. Att störa GPS är billigt och orsakar stora problem för motståndaren.


Ha även i åtanke att GPS tillhör Amerikanska flygvapen det är inte byggt att fungera topp på våra breddgrader.

Folk i vissa städer i USA kan inte ens använda GPS i sin bil för att navigera för att det är så mycket höga byggnader så den visar fel på flera gator. Problemet har nog blivit bättre i och med a-GPS och tack vare nyare och bättre GPS-chipp men det finns efter som GPS är störnings känsligt.

Jag har en GPS fartkamera varnare i bilen den har jag haft i över 10 år ingen ny sak direkt men en ren GPS modul.
Där ser man varje gång hur olika väder stör den fruktans värt mycket. Någon dag kan man inte ens få den att fungera alls medans andra dagar är den klar på 10 sekunder. Visst utvecklingen går framåt sen den köptes men du hänger med vädret stör mycket. Ibland kan man lura den lite och starta om den efter ett tag om den inte kickat igång efter en bra stund (tror den fastnar i en loop om den blir störd i början när den startar upp sig).

Vilket får mig att tro att killen som råkat ut för att den inte låst på över 1h kan ha fått samma loop. Om jag inte mins fel så bygger ju GPS på en beräkning på gigantiskt många tal och tid. Får då denna Nexus mobil ett par galna siffror från någon av dess källor: a-gps, fel tid, störning från någon annan signal, dålig signal från satteliterna osv osv så börjar den räckan med fel siffror och kan helt enkelt inte räckan rätt hur mycket den en försöker. GPS modulen låser i denna loop tills den startas om och får nya siffror att räckan med. Att sen få allt detta att fungera med bra programmering tycker jag är rätt så duktigt.



Så vi samman ställer:

En GPS på samma plats men olika dagar kan på grund av olika förutsättningar visa helt olika och ta olika lång tid på sig att låsa det är nog bara att acceptera och tycka om.
Men utvecklingen går framåt Glonass kommer hjälpa till samt EU:s Galileo.

 

Märker att min Nexus har en rätt dålig GPS. Det konstiga är att den var väldigt bra när jag körde med ICS. Med Jelly Bean - Jelly Belly, AOKP Build 1 samt min senaste ROM, Liquid - har GPSen varit urdålig. Det tar 20-30 minuter att få en lock UTOMHUS på MOTORVÄGEN! Det måste vara något i mjukvaran eftersom den fingerade jättebra innan.

Sent from my Galaxy Nexus using Tapatalk 2

 

Låter som dom fuckat upp mjukvaran i din ROM då. Kan inte vara så att ROM:s GPS är gjord för det landet som ROMen är tillverkad i så att den blir lurad? Så den får börja räkna på att den är i Australien eller något...

Jag hade visserligen lite liknande problem med ICS ibland dock inte mer än max 5 minuter innan låsning.

Annars så antar jag att "UTOMHUS på MOTORVÄGEN" innefattar i en bil eller är det helt utomhus utan någon bil, plåt/byggnader, elektronik wifi eller liknande runt om kring?
För råkar din bil ha eluppvärmd framruta så tar den definitivt död på mottagning av GPS lika så vissa andra värme av stötande material i rutorna.

Mins fasen inte var GPS antennen sitter i GN nu men går kanske att googla fram om du vill testa att hålla mobilen på något annat sett om det hjälper.

 

Tack för lektionen... En uppfräschning i ämnet är ju alltid bra.

När jag hade Nexus hade jag många av de problem som beskrivs i denna och andra trådar, då i alla möjliga väder och andra yttre förhållanden. Då i orginalutförande ics 4.01. Bytte runt med olika romar och skillnaden på gpsens funktion varierade kraftigt. Ena romen låste på 5 sekunder, andra på 30,den tredje behövde omstart av GPS och/eller telefon. På liknande sätt var positioneringens noggrannhet skiftande. Det provades romar som sas vara optimerade för Europa, det provades andra som inte hade någon optimering alls och det provades att ändra i gps config. Resultatet var att ingenting som sas förbättra gpsens funktion faktiskt gjorde det, istället var det nästan helt random om det funkade eller ej. Att problemet ligger i mjukvaran ser jag som självklart. Till och med olika nightlys av cm9 varierade från i det närmaste perfekt gps till ingen låsning hur länge man än höll på.

Självklart testades detta, som jag sa, i varierande väder och andra förutsättningar under flera timmar varje dag.

I slutändan är nexusens gps medelmåttig när den fungerar. Ett jättekliv upp från tex sgs1,men jämfört med tex en desire är den inte bra. Tur för oss turfare att glonass verkar ha kommit för att stanna i nyare mid/highend mobiler :-)

Edit: allt helt empiriskt förstås.


Sent from my GT-I9300 using Tapatalk 2

 

Men problemet är konstant - oberoende vädret eller bil. Den har alltid fungerat på en massa olika ICS-rommar (har typ aldrig använt stock) hur länge som helst. Men inte nu längre.

 

Jag har börjat få upp ögonen för AOSP och tänkte att detta kunde vara ett litet schysst mini-projekt att rota runt med. Mina förväntningar är inte skyhöga, men med lite väl valda sökningar borde jag kunna ta reda på huruvida filen läses eller inte, utifrån AOSP-koden. Sen om Samsung gör något ovanpå det (man vet aldrig, kanske en del av regionsanpassningen, hmm?) kan jag såklart inte svar för.
Jag vet inte om det som sagts så här långt från alla inblandade innebär att någon redan gjort ingreppet jag är på väg att göra och har uppgifterna bekräftade "fo realz". Om det är så, höj rösten så vet vi ju.

 

Låter som ett lagom projekt. Jag är också intresserad av att få reda på fakta kring detta. Blunden har väl kopplingar till AOSP och kan kanske tipsa om var man ska leta?

 

Har jag klurat ut något mellan kvällens ölande och StarCraft II på Hard då? Mjo, något har jag väl lyckats gräva fram, men jag vet än så länge inte riktigt vad jag ska dra för slutsats av det.

I den senaste kodbasen från AOSP så finns det en fil:

Kod:

/frameworks/base/services/java/com/android/server/location/GpsLocationProvider.java

Den gör följande referens på rad 180:

Kod:

private static final String PROPERTIES_FILE = "/etc/gps.conf";

Om man då i sin tur följer PROPERTIES_FILE, stöter man på raderna 245-257:

Kod:

// properties loaded from PROPERTIES_FILE
private Properties mProperties;
private String mSuplServerHost;
private int mSuplServerPort;
private String mC2KServerHost;
private int mC2KServerPort;

private final Context mContext;
private final NtpTrustedTime mNtpTime;
private final ILocationManager mLocationManager;
private Location mLocation = new Location(LocationManager.GPS_PROVIDER);
private Bundle mLocationExtras = new Bundle();
private ArrayList<Listener> mListeners = new ArrayList<Listener>();

I närheten av det så finner man en hel del andra GPS-relevanta referenser, AGPs och lite annat.

På rad 423-424 görs körs följande:

Kod:

try {
    File file = new File(PROPERTIES_FILE)

och som ni säkert minns från ovan så fanns det en hänvisning till den PROPERTIES_FILE-filen.

Mellan raderna 429-447 försöker det läsas in data enligt:

Kod:

mSuplServerHost = mProperties.getProperty("SUPL_HOST");
String portString = mProperties.getProperty("SUPL_PORT");
mC2KServerHost = mProperties.getProperty("C2K_HOST");
portString = mProperties.getProperty("C2K_PORT");

Kan inte /etc/gps.conf öppnas kommer det att på rad 449 spottas ut:

Kod:

Log.w(TAG, "Could not open GPS configuration file " + PROPERTIES_FILE);

Kikar man på senaste commit-log:en säger den att den 10:e juli 2012, gjordes det senaste bidraget, vilket tyder på att den iaf haft behov att vara petad i under modern tid.

Sååå, vart leder detta oss? Mja, rent spontant känns det som om filen läses in, åtminstonde om koden som hänger med en enhet (i vårt fall specifikt Galaxy Nexus) inkluderar denna GpsLocationProvider.java-fil och den får vara orörd. Den läser in väldigt specifika saker, alltså de fyra inslagen nämnda ovan. Om man tar bort gps.conf eller moddar den så att de getProperty:s koden letar efter saknas, kommer det att loggas fel om det som man kan spana efter via tex logcat.
Jag har inte själv provat att ändra i gps.conf, utan kör original. Jag är dessutom inte en veteran i att rota igenom AOSP-kod utan använder mina färdigheter som Java- och app-utvecklare och erfarenheter och nyfikenhet , så ni får ta uppgifterna för vad de är: ett initialt försök att förstå GPS-inläsningen av "/etc/gps.conf".
Det finns fortfarande en del frågetecken för min egen del, främst tex om det kan göras anpassningar av kod för specifika enheter från olika leverantörer.
Nå, jag lämnar detta för ikväll och ser om jag hittar annat spännande, kanske tillochmed redan imorgon.

 

Intressant!

Leta efter om den läser in propertyn NTP_SERVER.

Det är den som tagits bort i gps.conf i jb.

 

Well, jag gjorde iaf sökningen och konstaterar då följande:

Filen "/frameworks/base/core/java/android/util/NtpTrustedTime.java" har på rad 62-63 en referens till NTP_SERVER enligt:

Kod:

final String secureServer = Settings.Secure.getString(
    resolver, Settings.Secure.NTP_SERVER);

Följer man spåret "Settings.Secure.NTP_SERVER" kommer man till filen "/frameworks/base/core/java/provider/Settings.java" där man på raden 4265 hittar:

Kod:

public static final String NTP_SERVER = "ntp_server";

Eftersom koden gör en getString från Settings.Secure.NTP_SERVER så kollade jag även upp om secureServer gav något. "/frameworks/base/core/java/android/util/NtpTrustedTime.java" gör gällande på rad 67:

Kod:

final String server = secureServer != null ? secureServer : defaultServer;

Nu börjar det dock bli lite drygt att göra sökningar och hålla reda på informationen. "server" som nyckelord är ganska drygt....

 

Jag tänkte att jag kunde försöka se hur "NtpTrustedTime.java" används och hittade en referens i vår gamle vän "frameworks/base/services/java/com/android/server/location/GpsLocationProvider.java", som tar in en instans av "NtpTrustedTime.java" på rad 387:

Kod:

mNtpTime = NtpTrustedTime.getInstance(context);

 

Om man ska dra en slutsats av allt detta så här långt, verkar det som om värden för just NTP_SERVER i filen "/etc/gps.conf" inte läses in. Det finns än så länge bara ett ställe då "/etc/gps.conf" refereras till och det ligger i filen "GpsLocationProvider.java"
Det görs ju NTP_SERVER-referering i bland annat "NtpTrustedTime.java" men det är en statiskt hårdkodad sträng som står där, som vi sett tidigare:

Kod:

public static final String NTP_SERVER = "ntp_server";

Det som _kan_ vara ett möjligt frågetecken är raden

Kod:

final String server = secureServer != null ? secureServer : defaultServer;

därför att defaultServer skulle kunna innehålla något som baseras på inläsning från externa filer, men det känns inte riktigt som om det skulle vara en rimlig möjlighet, baserat på hur inläsningen från "/etc/gps.conf" är skriven i GpsLocationProvider.java-koden.
Inläsningen av "/etc/gps.conf" görs mig veterligen bara en gång och det är genom GpsLocationProvider.java. Det är dessutom inte speciellt mycket som läses in därifrån, vilket får mig att dra slutsatsen att saker som NTP_SERVER inte kommer att läsas in under körning.

 

Kikar jag i min egen "/etc/gps.conf" så hittar jag dessa rader:

Kod:

XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
SUPL_HOST=supl.google.com
SUPL_PORT=7276

Om jag gör en sökning efter "XTRA_SERVER" så hittar jag filen "frameworks/base/services/java/com/android/server/location/GpsXtraDownloader.java"
som på raderna 58-60 innehåller:

Kod:

String server1 = properties.getProperty("XTRA_SERVER_1");
String server2 = properties.getProperty("XTRA_SERVER_2");
String server3 = properties.getProperty("XTRA_SERVER_3");

Detta matchar ganska väl innehållet i min "/etc/gps.conf", sen görs det inte några fler property-hämtningar i "GpsXtraDownloader.java". Nu säger inte detta att det inte görs fler property-hämtningar någon annanstans, men jag ville även se hur min "/etc/gps.conf" matchar koden och hur den refererar till det som står där.
Det börjar dock se ut som att ytterst lite läses in från "/etc/gps.conf" annat än:

Kod:

XTRA_SERVER_1
XTRA_SERVER_2
XTRA_SERVER_3
SUPL_HOST
SUPL_PORT
C2K_HOST
C2K_PORT

 

Jo det var ju nån som klargjorde efter rykten om att man skulle byta ntp_server till se.pool.ntp.org att den raden faktiskt inte användes alls i ics och att de alltid körde mot pool.ntp.org och i JB har ju den raden tagits bort helt i orginalfilen.

 

Jepp, det var blunden som gjorde det.

Jag märkte ju empiriskt att propertyn togs bort i jb.

Således kan man dra slutsatsen att gpsfixarna som nämns här inte gör någon skillnad på jb i och med att NTP_SERVER inte läses in.

Bra scoutat drlaban!

 

Ju mer jag har läst om det här både här i denna intressanta tråd och på XDA så är jag nog benägen att hålla med om det här med NTP och dess effekt på GPS:en. Det är nog så som ni säger att det inte spelar någon större roll om man har det värdet eller inte.

Det kan mycket väl vara så att anledningen till att GPS:en funkade bättre för mig efter att jag fixat med GPS.conf är den andra ändringen som inte nämnts här nämligen: ACCURACY_THRES=3000

Detta gör att gps:en kan acceptera en satellit och låsa även om mottagningen inte är perfekt.

Har labbat vidare med detta och lagt in den gps fix som finns till massor av enheter på XDA och funkar för de flesta versioner av Android från 2.2 och uppåt.
http://forum.xda-developers.com/showthread.php?t=1563226
Det var även i denna tråd jag frågade om gps.conf filens vara eller icke vara. Och jag inser ju nu att det svar jag fick faktiskt bara relaterade till att filen behövs för att Agps ska funka och inte om just parametern NTP_SERVER används.

När man läser kommentarerna i den gps.conf som kommer i denna fix så nämns det bland annat att ntp är relativt oviktigt för GPS så länge klockan i telefonen inte är extremt felaktig. Därför används ntp extremt sällan och då är inte lokala ntp servrar nödvändiga. Kan även vara därför det inte längre används i Jelly Bean om google då förbättrat hur klockan ställs ifrån mobilnätet.

Men det finns många parametrar som man kan labba med angående agps via gps.conf.

Vill ni läsa hela gps.conf från fix tråden ovan lägger jag in den här.

Jag kör med denna gps.conf nu och anser att min gps numer är helt okej. Så i mina subjektiva ögon har detta haft effekt.

Observera att jag inte har något med denna fil att göra utan det är Crypto på XDA som skapat denna fil och den är generell så att den funkar för de allra flesta enheter oavsett Android version.

GPS.conf :

Spoiler

Bli medlem eller logga in för att visa innehållet!

Observera att man kan scrolla i kodrutan ovan.. Finns en hel del att studera

 

Efter att ha kollat AOSP-koden själv så konstaterar jag att de enda properties som jag kan se läses från filen gps.conf är:

SUPL_HOST, SUPL_PORT, C2K_HOST, C2K_PORT

Det är i com.android.server.location.GpsLocationProvider som inläsningen görs från fil. mProperties är dock en medlemsvariabel och används för att initiera GpsXtraDownloader, som i sin tur läser ut XTRA_SERVER_1, XTRA_SERVER_2 och XTRA_SERVER_3.

Så jag kommer till samma slutsats som DrLaban. Inga andra properties än dessa läses in av AOSP-koden, så övrig info i gps.conf är ingen mening med att lägga in.

Kod:

      
  private static final String PROPERTIES_FILE = "/etc/gps.conf";
...
 mProperties = new Properties();
        try {
            File file = new File(PROPERTIES_FILE);
            FileInputStream stream = new FileInputStream(file);
            mProperties.load(stream);
            stream.close();

            mSuplServerHost = mProperties.getProperty("SUPL_HOST");
            String portString = mProperties.getProperty("SUPL_PORT");
            if (mSuplServerHost != null && portString != null) {
                try {
                    mSuplServerPort = Integer.parseInt(portString);
                } catch (NumberFormatException e) {
                    Log.e(TAG, "unable to parse SUPL_PORT: " + portString);
                }
            }

            mC2KServerHost = mProperties.getProperty("C2K_HOST");
            portString = mProperties.getProperty("C2K_PORT");
            if (mC2KServerHost != null && portString != null) {
                try {
                    mC2KServerPort = Integer.parseInt(portString);
                } catch (NumberFormatException e) {
                    Log.e(TAG, "unable to parse C2K_PORT: " + portString);
                }
            }

 

Allt detta kokar alltså ner till att jag lika gärna kan återställa min gpsconf från den backup som appen Faster GPS gjort?

Skickat från min Galaxy Nexus via Tapatalk 2

 

Jepp, precis.