[Megoldva] Redmi 4x CrDroid nincs GPS jel

Regen hasznaltam mar ilyesmit, de most rakerestem a Playben, feltettem az elsot, es ki is probaltam. Az NMEA Tools tud ilyet (valoszinuleg a tobbi is). Csinaltam egy logot is, a GGA es RMC mondatokat kiszedtem, mert abban benne van a pontos koordinatam.

$GNGSA,A,3,26,09,04,11,,,,,,,,,1.73,1.49,0.88,1*01
$GNGSA,A,3,,,,,,,,,,,,,1.73,1.49,0.88,2*0B
$GNGSA,A,3,24,,,,,,,,,,,,1.73,1.49,0.88,3*0C
$GNGSA,A,3,06,43,22,09,36,16,,,,,,,1.73,1.49,0.88,4*07
$GNGSA,A,3,194,,,,,,,,,,,,1.73,1.49,0.88,5*30
$GPGSV,4,1,13,09,80,020,19.8,06,48,252,,04,46,066,23.9,07,44,189,,1*66
$GPGSV,4,2,13,11,34,302,13.7,36,34,163,,03,22,125,,16,18,073,31.3,1*6B
$GPGSV,4,3,13,20,16,307,,30,15,204,,26,14,044,27.3,45,01,101,,1*78
$GPGSV,4,4,13,48,,,,1*6A
$GLGSV,2,1,7,71,68,017,,73,45,122,,72,36,298,,87,34,296,,1*40
$GLGSV,2,2,7,70,30,085,,74,14,165,,88,13,340,,1*77
$GAGSV,3,1,10,03,61,065,9.7,08,60,278,,13,44,268,,25,28,095,,7*5B
$GAGSV,3,2,10,15,27,205,,26,17,324,,24,16,039,19.5,02,13,144,,7*6B
$GAGSV,3,3,10,05,10,079,,07,09,265,,7*77
$BDGSV,6,1,22,21,79,331,,45,47,136,,31,45,062,,22,41,099,15.1,1*61
$BDGSV,6,2,22,36,36,061,26.1,42,28,292,,09,24,055,14.8,05,23,132,,1*70
$BDGSV,6,3,22,11,22,270,,43,17,297,12.7,34,15,249,,26,12,185,,1*65
$BDGSV,6,4,22,06,11,056,21.1,60,09,114,,07,08,088,,02,08,110,,1*60
$BDGSV,6,5,22,16,07,055,14.4,10,07,098,,12,07,223,,40,07,079,,1*64
$BDGSV,6,6,22,56,05,085,,14,04,289,,1*7C
$QZGSV,1,1,1,194,05,042,25.0,1*5F
$GNVTG,0.41,T,,M,0.000,N,0.000,K,A*26

Ha erdekel a szabvany, kisebb tutorialok vannak a neten, hogy hogy kell parse-olni/ertelmezni.
Tomoren: ASCII, $ es * kozt vannak az NMEA mondatok, a * utan a korabbi byte-ok checksumja (ha jol emlekszem, byte-onkenti XOR), a vegen ujsor jel (talan \r\n, de lehet, hogy \n is eleg).

Minden mondat egy parancsnevvel kezdodik, es utana vesszovel szeparalt szamok meg betuk vannak. Az elso 2 betu azt jelzi, hogy melyik muholdrendszer uzenete (GP: GPS, GL: Glonass, BD: Beidu/Pajtu, stb.. a GN - ha jol emlekszem - egy tobb rendszerbol szamolt, osszesitett valami), az utana levok meg az uzenet tipusat adjak meg. Teged a GSA erdekel (hasznalt muholdak), es a GSV (latott muholdak). A GSV-nel az elso szam azt jelenti, hogy ebben az uzenetblokkban hany ilyen uzenet lesz, a kovetkezo az, hogy ez hanyadik uzenet. Utana (minden sorban) az szerepel, hogy hany ilyen rendszeru muholdat lat osszesen. Itt a GPGSV 13 muholdat lat, es egy sorban 4-4 muhold fer el, igy a 13 muholdhoz 4 sor kell (4,1,13 aztan 4,2,13, utana 4,3,13, vegul 4,4,13). Utana jon muholdankent 4-4 szam, az azonosito, a horizonntol szamitott magassag fokban, az irany (ugy emlekszem, 0 fok az eszak), es az utolso meg a jelerosseg. Szamok hianyozhatnak persze, ha annyira gyenge a jelerosseg, vagy ha valami baja van. Az utolso 1-es a signal ID, elvileg katonai frekiknel mas jon, de olyannal nem volt dolgom.

A GSA a hasznalt muholdakat mutatja, az A vagy M modfuggo, utana 1 ha nincs fix, 2 ha 2D fix van (van pozicio, de nincs magassag), 3 ha 3D fix van (van magassag is), utana a felhasznalt muholdak ID-jait irja, a sor vegen levo szamok pedig a pontossagot fejezik ki valami egeszen elvetemult formatumban (a muholdak meg a vevo altal bezart test terfogatat adja).

Kb. 3 evig fejlesztettem az iGO-t, az alatt eleg sok kutyu megfordult nalam (pont abban a csapatban voltam). Mar eleg regen volt, szoval a reszletek azota valtozhattak.

Androidon ketfelekepp tudsz pontos GPS koordinatat kapni: fel tudsz iratkozni location-okre, ebben az esetben Location objektumokat kapsz a rendszertol (az elkert providertol fuggoen lehet GPS (precise), vagy mobiltornyos/wifis pontossagu (coarse location)), a masik esetben meg fel tudsz iratkozni a nyers NMEA stream-re, aminek a parse-olasat neked kell megoldanod. WinCE-n soros portot nyitsz a megadott parameterekkel (tipikusan UART, 38400 BAUD, 8N1), es a parse-olas ott is a te dolgod. Linuxon/QNX-en is ugy emlekszem, az utobbihoz hasonlit jobban, de olyan kutyukkel mas foglalkozott.

Meg a 4-es Android verzio megjelenesekor volt olyan bug par kinai eszkoznel, hogy a Location objektumhoz nem allitott be pontossagot (vagy pontatlant adott), de a bejovo NMEA mondatokban benne volt mindharom dop ertek. Ez egyertelmuen software bug, a kesobbiekben javitottak. Irtam hozza workaround-ot, amit ha aktivaltal a megfelelo config file-ban, megnyitotta az NMEA streamet is, es ha aszerint rendben volt a pontossag, akkor elfogadta (az iGO csak bizonyos pontossagot elerve hajlando navigalni). Ugy 2012 aprilis kornyeki patch lehetett, accuracy_workaround=1 kellett az Androidos kutyu sys.txt-jebe.

Az NMEA-nal a koordinatak fokban es szogpercben jonnek be, es a vevotol fugg, hogy hany tizedesjegy a pontossaga. Volt egy olyan bug is (mar nem emlekszem milyen OS-en), hogy a vartnal tobb - vagy lehet, hogy kevesebb - szamjegyen abrazolta, es ez nem tetszett valamilyen parsernek. Ott a feltetel lazitasa volt a megoldas. (a tipikus amugy az, hogy a szogperc 4 tizedesre jon be, itt meg vagy 7-et kuldott)

Ezek ismereteben egy NMEA olvaso appal ugy tudsz megallapitani software hibat, hogy ranezel a bejovo streamre. Ha az Android rosszul parse-olja, a Location-ok rosszak, de a GPS vevorol jo formatumban jon be az adat (ezt kapod meg a masik interface-en), akkor bug van az Androidos parserben. Az NMEA interface meg ugye azt az adatot adja, ami a vevo chip TX laban megjelenik (szoval ha tapot adnal ra, akkor idovel digit. szkoppal/logikai analizatorral pont ezt latnad).

Ujrainditas meg ugy segit, hogy az a hardware-t is ujrainicializalhatja (foleg a kikapcsolas-bekapcsolas), szoval ha abban van valami hiba, az helyrejohet.