GPS es adatgyűjtés tervezése

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Irányítástechnika és Informatika Tanszék

Kapitány Ágoston

GPS­es adatgyűjtés tervezése

Önálló laboratórium  Bsc képzés Konzulens: Dr. Kis László

Budapest, 2013/14 2. félév

Tartalomjegyzék Tartalomjegyzék.....................................................................................................................2 Feladat kiírása........................................................................................................................3 GPS vevő bemutatása...........................................................................................................3 Hozzáférhető GPS adatok.....................................................................................................3 GPS vevő konfigurálása........................................................................................................3 NMEA protokoll......................................................................................................................4 UBX protokoll.........................................................................................................................5 Feldolgozandó UBX csomagok..............................................................................................6       NAV­SVINFO...................................................................................................................6       NAV­SOL.........................................................................................................................6       RXM­RAW........................................................................................................................6       RXM­SFRB......................................................................................................................6 Az adatgyűjtő program...........................................................................................................6 Projekt fájljai...........................................................................................................................7 Állapotgép..............................................................................................................................7 A programban felhasznált adatszerkezeket...........................................................................8 Kimeneti fájl formátuma.........................................................................................................9 Adatok felhasználása Matlab­ban..........................................................................................9 További lehetőségek............................................................................................................10 Irodalomjegyzék...................................................................................................................11 Függelék...............................................................................................................................12       A programban használt C struktúrák.............................................................................12       A program tipikus kimenete a képernyőn......................................................................14

Feladat kiírása A feladatom egy u­blox vevőhöz egy adatokat gyűjtő szoftver tervezése és programozása,  ami a nyers adatokat olyan rendezett formában tárolja el, hogy az offline feldolgozás során könnyen hozzáférhetők legyenek Matlab környezetből és felhasználhatók legyenek  pozíciószámító algoritmusok kipróbálásához.

GPS vevő bemutatása Az adatgyűjtéshez egy u­blox 6­os GPS modult használtam. Ez a modul a hétköznapi  GPS vevőkhöz hasonlóan tud NMEA adatokat is szolgáltatni, viszont a gyártó saját UBX  protokollját felhasználva nyers, alacsonyabb szintű adatok szolgáltatására is alkalmas. Így  lehetőség nyílik arra, hogy a GPS modul belső algoritmusa helyett saját algoritmusokat  használjunk. A modulhoz a külső antenna RP SMA csatlakozón csatlakozik. A vevő 5 Hz­es  időközökkel tud pozícióadatokat szolgáltatni. A GPS modulhoz lehetőség van RS­232­es, USB és SPI portokon csatlakozni. A  tápellátás biztosítása is USB porton történik, ezért az adatgyűjtéshez az USB portot  választottam. A modul működése (portok, szolgáltatott adatok, stb.) számítógépről konfigurálhatóak az  ucenter szoftverrel. A konfiguráció is UBX protokoll alapú, így bármelyik portról működés  közben a vevőnek küldött csomagokkal is konfigurálható a modul.

Hozzáférhető GPS adatok Az u­blox 6­os modul alacsonyabb szintű adatokat is szolgáltat. Ilyen a Carrier phase, a  Pseudorange, Doppler mérések adatai, valamint a Subframe buffer tartalmát. Az első  három a vevő méréseinek eredménye, míg a Subframe buffer a műholdtól érkező adatokat paritásbit ellenőrzött formában tartalmazza. Ez azt jelenti, hogy a vevő csak az ellenőrzött, hibátlanul vett adatokat adja át nekünk. A subframe­ek tartalmazzák a műholdak  pályaadatait, és az ionoszféra adatait, valamint a pontos GPS időt. Az ephemeris adatok  néhány óráig, az almanac adatok több napig érvényesek.

GPS vevő konfigurálása A vevő konfigurációját elég csak egyszer elvégezni, mert képes egy belső flash és  EEPROM memóriában eltárolni a beállításokat. A konfigurációhoz a gyártó ucenter  programját használtam. A konfiguráció UBX csomagokkal is megoldható. Az adatgyűjtéshez csak UBX csomagokra volt szükség, így az NMEA üzeneteket  kikapcsoltam, a mérési frekvenciát 5 Hz­re állítottam, valamint kiválasztottam a számomra  szükséges csomagtípusokat, amiket a programban szeretnék feldolgozni. A program a vevő felül érkező NMEA vagy nem feldolgozandó UBX csomagokat figyelmen kívül hagyja, a felesleges adatok kikapcsolására egy beágyazott rendszerben azért lenne  szükség, hogy sávszélességet és energiát takarítsunk meg.

ublox GPS vevő A gyártó ucenter szoftverének konfigurációs felülete

NMEA protokoll Az NMEA 0183 protokoll napjaink egy elterjedt, széles körben alkalmazott protokollja.  Elsősorban tengeri navigációhoz fejlesztették ki (National Marine Electronics Association  fejleszti), hogy egy szabványos protokollal kössék össze a GPS vevőket számítógéppel,  vagy más eszközzel. Ma a legtöbb GPS modul támogatja ezt a protokollt, mert a  hétköznapi felhasználáshoz a legtöbb szükséges információt biztosítja. Viszont az önálló  laboratórium feladathoz az NMEA üzenetek nem tartalmaznak elég adatot, mert a nyers  mérési eredményeket a vevő működése és a protokoll eltakarja, mert felhasználónak csak  számított pozícióadatokat és néhány tájékoztató jellegű műholdadatot ad. Tipikus NMEA üzenet: $GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,55.2,M,,*76 $GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A $GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70 $GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79 $GPGSV,3,3,11,29,09,301,24,16,09,020,,36,,,*76 $GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43 $GPGGA,092751.000,5321.6802,N,00630.3371,W,1,8,1.03,61.7,M,55.3,M,,*75 $GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A $GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70 $GPGSV,3,2,11,02,39,223,16,13,28,070,17,26,23,252,,04,14,186,15*77 $GPGSV,3,3,11,29,09,301,24,16,09,020,,36,,,*76 $GPRMC,092751.000,A,5321.6802,N,00630.3371,W,0.06,31.66,280511,,,A*45

NMEA Protocol (forrás: u­blox Receiver and Protocol Description)

UBX protokoll Az UBX protokoll összetettebb mint az NMEA. Az u­blox cég fejlesztése, ami lehetőséget  ad a gyártó moduljaival, hogy alacsonyabb szintű mérési adatokhoz is hozzáférjünk,  valamint a modulok konfigurációja is ezen a protokollon keresztül valósul meg. A protokoll sajátossága, hogy bináris. Így az csomagok (az NMEA protokollal szemben)  nem olvashatóak a portra terminállal csatlakozva, viszont tömörebb, így egy lassabb soros kapcsolaton is több adat átvihető. A csomagok azonosítására a Class és az Id szolgál. Az  átviteli hibák kiszűrését két byte­os, 8 bit­es Fletcher algoritmussal számított  ellenőrzőösszeg biztosítja. Egy UBX csomag felépítése a következő:

Az UBX csomag felépítése (forrás: u­blox Receiver and Protocol Description) Az ellenőrzőösszeg a Class, Id, Length és a Payload byte­okon számolandó.

Feldolgozandó UBX csomagok NAV­SOL Ezekben a csomagokban megtalálhatóak a modulban futó pozíciómeghatározó algoritmus eredményei, amire azért van szükségünk, hogy legyen összehasonlítási alapunk a saját  algoritmusok kipróbálásakor. A pozíciókat ECEF (Földközéppontú, Földhöz rögzített)  formátumban kapjuk, a belső algoritmus futásáról megtudhatunk néhány információt (pl. a  számításokhoz felhasznált műholdak száma, pozíció pontossága, stb.) NAV­SVINFO Ezek a csomagok látható műholdakról tartalmaznak adatokat könnyen feldolgozható és  értelmezhető formátumban. Ezek az adatok elsősorban tájékoztatásul szolgálnak (pl.  műholdak pozíciója horizontális koordináta rendszerben, ami könnyen felhasználható egy  felhasználói interfészen az „égbolt” megjelenítésére). RXM­RAW Nyers mérési adatokat tartalmaznak ezek a csomagok: Carrier phase, Pseudorange és a  Doppler mérések eredményeit. RXM­SFRB A többi csomagtól eltérő jellegű adatokat tartalmaz. Ebben a csomagban vannak a GPS  műholdaktól fogadott nyers pálya és időadatok. Mivel ezek más jellegű adatok, és más  időközönként érkeznek (Ephemeris: néhány órára, Almanac adatok több napig  érvényesek), ezért teljesen külön fájlba fogom eltárolni. Subframes 1 2/3 4/5

Words

Description

1­2

Telemetry and handover words (TLM and HOW)

3­10

Satellite clock, GPS time relationship

1­2

Telemetry and handover words (TLM and HOW)

3­10

Ephemeris (precise satellite orbit)

1­2

Telemetry and handover words (TLM and HOW)

3­10

Almanac component (satellite network synopsis, error correction)

GPS üzenetek formátuma (http://en.wikipedia.org/wiki/GPS_signals)

Az adatgyűjtő program A program feladata, hogy a soros porton érkező adatokat fogadja, feldolgozza és egy új  struktúrában fájlba mentse, hogy az összegyűjtött mérési adatok könnyen hozzáférhetőek, betölthetőek és felhasználhatóak legyenek további számításokhoz. A számítógéphez az u­blox modul USB­n keresztül csatcsatlakozik. Így egy USB­n emulált soros kapcsolaton érkeznek az adatok. Ezt a virtuális soros portot is kell inicializálni, ami a program feladata. A fogadott bájtokon egy állapotgép végzi el a feldolgozást. Ekkor kell  megvizsgálni az ellenőrzőösszeg helyességét és a Class­Id páros alapján a megfelelő  struktúrába tölteni. A fájlba csak időben összetartozó adatokat ír ki a program, amit úgy valósítottam meg, 

hogy egy belső collection_t struktúrába addig gyűjtöm az adatokat, amíg újabb  időbélyegű csomag nem érkezik. A programot C nyelven írtam, hogy szükség esetén könnyen hordozható legyen egy  beágyazott rendszerre. A program úgy is fordítható, hogy alkalmas legyen nyers UBX  csomagok fájlból történő feldolgozására. Ehhez egy minta bemeneti fájl az ubx_log.bin.  Ezt az üzemmódot fejlesztéshez, teszteléshez érdemes használni.

Projekt fájljai README ser.c compile­and­run config.h functions.h functions.c functions.h packet.h packet.c ubx_log.bin view_gps_log.m

a program rövid leírása, működése a főprogram (állapotgép, csomagok azonosítása) a projekt fordítását és futtatását segítő bash szkript konfigurálható preprocesszor direktívák, a program beállításához több helyen felhasznált függvények fejlécei több helyen felhasznált függvények (pl PRN azonosító konvertálása) több helyen felhasznált függvények fejlécei (pl PRN konvertálása) a fogadott csomagokat struktúrákban tároltam, ezek deklarációja a struktúrákhoz tartozó függvények nyers bemeneti fájl, GPS vevő nélküli teszteléshez Matlab program a létrehozott fájlok beolvasására

Állapotgép A program alapvető működését egy állapotgép biztosítja. Az állapotok közötti áttéréseket  kizárólag a fogadott bináris adatok és azok sorrendje határozza meg. A: Kezdőállapot, mindaddig itt marad, amíg nem fogad szinkron karaktert. (0xB5) B: Itt már a második szinkron karaktert (0x62) várjuk, ha nem az érkezik, visszaértünk az A állapotba. C: két szinkron karakter után valószínűleg valós csomagot olvasunk be, így  beolvashatjuk a fejlécet D: A beolvasott fejlécből (Class, Id és Length byte­ok) meghatározzuk, hogy milyen   hosszúságú csomagot kell fogadnunk. E: ebbe az állapotba jutunk, ha már beolvastuk az egész csomagot a az ellenőrző összeggel együtt, ellenőrizzük az ellenőrző összeget. F: Itt döntjük el, hogy szükségünk van­e a beérkezett csomagra, ha igen eltároljuk.

A programban felhasznált adatszerkezet Minden időpillanathoz tartozik egy collection_t struktúra, amiben az összetartozó  adatokat a következő formában tároltam: Fejléc, ami az időponthoz tartozó általános adatokat tartalmazza. Táblázat, ami a műholdanként tárolja a paramétereket. Hogy az szerkezet nem bomoljon meg és fix méretű maradjon, így minden műholdhoz  bevezettem egy validRXM és egy validNAV flag­et, amivel jelzem, hogy érvényes­e az  oszlopban az adat. Az érvénytelen mezők majd a Matlabban lesznek NaN­ba konvertálva. collection_t iTOW, fTOW, week, gpsFix, fixflags, ecefX, ecefY, ecefZ, pAcc, ecefVX, ecefVY, ecefVZ, sAcc, pDop,  numSV

#1

#2

#3

#4

...

validRXM validNAV cpMes prMes doMes mesQI cno lli flags quality elev azim prRes

A struktúra akkor íródik fájlba, ha a struktúrába betöltendő következő csomag időbélyege  már nagyobb értéket tartalmaz a korábbiakhoz képest. (A programban itt megengedek  ±1ms eltérést, ekkor az RXM csomagból veszem át az időpontot.) A subframe­bufferből kinyert adatokat más struktúrában kell tárolni, és a feldolgozását is  függetleníteni kell a többi csomagtól, mert a benne található adatok frissülés időközei nem  a GPS vevőtől függenek, hanem a GPS rendszertől, így teljesen más időközönként  érkeznek. Egy teljes frame 5 subframe­ből áll. Minden műholdtól egyedi frame­ek érkeznek, így  ezeket műholdanként külön kell gyűjteni és tárolni. Arra is figyelni kellett, hogy néha  hibásak a subframe­ek, így a vevő paritás ellenőrzés után nem adja tovább a soros  porton. Így csak akkor tudunk összeállítani egy teljes frame­et, ha az összes subframe  beérkezett. Ennek követésére műholdanként jelzőbiteket vezettem be, hogy nyomon  kövessem a subframe­ek beérkezését. A framek­hez nem tartozik külön időbélyeg, mert  az megtalálható bennük, a PRN kódjuk a tömbben elfoglalt helyük alapján határozható  meg.

A teljes frame­eket a következő struktúrában tároltam: rxm_sfrb_t #1

#2

#3

#4

...

valid wrd

Kimeneti fájl formátuma A létrehozott fájlok formátuma megegyezik a struktúrában leírtakkal, így egyszerűen  beolvasható és feldolgozható Matlab­ban. A struktúrák pontos leírása (C nyelvi formában)  a függelékben található.

Adatok felhasználása Matlab­ban A betöltés megoldható egyszerű fread művelettel és vektorba illesztéssel: iTOW(end+1)=fread(fin,1,'uint32'); fTOW(end+1)=fread(fin,1,'int32'); plot3(ecefX, ecefY, ecefZ);

A számított pozíció időben és térben változása. (ECEF x­y­z [m])

Carrier phase mérés eredménye (x:[ms] y:[L1 cycles], műholdanként)

Pseudo range adatok (x:[ms] y:[m], műholdanként)

További lehetőségek A program ebben a formában már megvalósítja a kívánt konverziót a Matlab felé. A  Matlab­ban így már közvetlenül hozzáférhetőek a mérési adatok, így újabb algoritmusok  (pl. Carrier phase­t felhasználó pontosabb helymeghatározás) kipróbálhatóak. A program C nyelven van megírva, így akár egy Matlab­ban megírt és kipróbált  algoritmussal kiegészítve alkalmazható lehet egy beágyazott rendszerben  helymeghatározásra.

Irodalomjegyzék: A GPS rendszer működése: http://www.u­blox.com/images/downloads/Product_Docs/GPS_Compendium%28GPS­X­ 02007%29.pdf A u­blox GPS modul leírása és UBX protokoll: http://www.u­blox.com/images/downloads/Product_Docs/u­ blox6_ReceiverDescriptionProtocolSpec_(GPS.G6­SW­10018).pdf  /dev/ttyACM0 USB port inicializáció: http://git.savannah.gnu.org/cgit/gpsd.git/snapshot/release­3.10.tar.gz Subframe leírása: http://www.gps.gov/technical/icwg/ICD­GPS­200C.pdf PRN kódok kiosztása: http://www.losangeles.af.mil/shared/media/document/AFD­070530­036.pdf Táblázat a 6. oldalon: http://en.wikipedia.org/wiki/GPS_signals

Függelék A programban használt C struktúrák typedef struct{ uint32_t iTOW; (Receiver Time) uint16_t week; uint8_t numSV; uint8_t reserved1; struct { double cpMes; double prMes; float doMes; uint8_t sv; int8_t mesQI;

int8_t cno; uint8_t lli; } SV[50]; } rxm_raw_t; typedef struct{ uint32_t iTOW; uint32_t fTOW; int16_t week; uint8_t gpsFix; uint8_t flags; int32_t ecefX; int32_t ecefY; int32_t ecefZ; uint32_t pAcc; int32_t ecefVX; int32_t ecefVY; int32_t ecefVZ; uint32_t sAcc; uint16_t pDop; uint8_t reserved1; uint8_t numSV; uint32_t reserved2; } nav_sol_t; typedef struct{ int32_t iTOW; uint8_t numCh; uint8_t globalFlags; uint16_t reserved2; struct { uint8_t chn; uint8_t svid; uint8_t flags; this SV (Ephemeris or Almanach)

details)

uint8_t quality;

uint8_t cno;

// [ms] Measurement integer millisecond GPS time of week // [weeks] Measurement GPS week number (Receiver Time). // # of satellites following. // Reserved // // // // // // // // // // //

[L1 cycles] Carrier phase measurement [m] Pseudorange measurement [Hz] Doppler measurement Space Vehicle Number Nav Measurements Quality Indicator: >=4 : PR+DO OK >=5 : PR+DO+CP OK <6 : likely loss of carrier lock in previous interval [dbHz] Signal strength C/No. Loss of lock indicator (RINEX definition) 50 channel

// // // // // // // // // // // // // // // // // //

[ms] GPS ms time of week [ns] fractional nanoseconds remainder of rounded ms above [week] GPS week (GPS time) GPS fix Type (0..5), No Fix, Dead Reckoning only, 2D, 3D-Fix, GPS+Dead Reckoning, Time Fix only Fix Status Flags [cm] ECEF X coordinate [cm] ECEF Y coordinate [cm] ECEF Z coordinate [cm] 3D Pos. Accuracy Estimate [cm/s] ECEF X velocity [cm/s] ECEF Y velocity [cm/s] ECEF Z velocity [cm/s] Speed Accuracy Estimate Position DOP Reserved Number of SVs used in Nav Solution Reserved

// // // //

[ms] GPS ms time of week Number of Channels 0: Antaris, Antaris4 | 1: u-blox5 | 2: u-blox6 Reserved two bytes

// // // // //

Channel number, 255 if SVs not assigned to a channel Satellite ID Bitmask 0: svUsed: SV is used for navigaton 1: diffCorr: Differential correction data is available for

// 2: orbitAvail: Orbit information is available for this SV // // // // //

3: 4: 5: 6: 7:

orbitEph: Orbit information is Ephemeris unhealthy: SV is unhealthy / shall not be used orbitAlm: Orbit information is Almanac Plus orbitAop: Orbit information is AssistNow Autonomous smoothed: Carrier smoothed pseudorange used (see PPP for

// // // // // // // //

Bitfield: 0: This channel is idle 1: Channel is searching 2: Signal aquired 3: Signal detected but unusable 4: Code Lock on Signal 5, 6, 7: Code and Carrier locked [dbHz] Carrier to Noise Ratio (Signal Strength)

int8_t elev; uint16_t azim; int32_t prRes; } SV[50]; } nav_svinfo_t; // __attribute__((__packed__)) typedef struct{ /* fejléc */ /* nav-sol */ uint32_t iTOW; (Receiver Time) int32_t fTOW; uint16_t week; uint8_t gpsFix; uint8_t flags; int32_t ecefX; int32_t ecefY; int32_t ecefZ; uint32_t pAcc; int32_t ecefVX; int32_t ecefVY; int32_t ecefVZ; uint32_t sAcc; uint16_t pDop; uint8_t numSV; /* táblázat */ uint8_t validRXM[SNUM]; uint8_t validNAV[SNUM]; uint8_t reserved1[3]; /* rxm-raw */ double cpMes[SNUM]; double prMes[SNUM]; float doMes[SNUM]; int8_t mesQI[SNUM]; int8_t cno[SNUM]; uint8_t lli[SNUM];

// // // //

[deg] Elevation in integer degrees [deg] Azumuth in integer degrees [cm] Pseudo range residual in centimeters 50 channel

// [ms] Measurement integer millisecond GPS time of week // // // // // // // // // // // // // // //

[ns] fractional nanoseconds remainder of rounded ms above [weeks] Measurement GPS week number (Receiver Time). GPS fix Type (0..5), No Fix, Dead Reckoning only, 2D, 3D-Fix, GPS+Dead Reckoning, Time Fix only Fix Status Flags [cm] ECEF X coordinate [cm] ECEF Y coordinate [cm] ECEF Z coordinate [cm] 3D Pos. Accuracy Estimate [cm/s] ECEF X velocity [cm/s] ECEF Y velocity [cm/s] ECEF Z velocity [cm/s] Speed Accuracy Estimate Position DOP Number of SVs used in Nav Solution

// 1: valid | 0: unvalid // 1: valid | 0: unvalid

// // // // // //

[L1 cycles] Carrier phase measurement [m] Pseudorange measurement [Hz] Doppler measurement Nav Measurements Quality Indicator [dbHz] Signal strength C/No. Loss of lock indicator (RINEX definition)

/* nav-svinfo */ uint8_t flags[SNUM]; uint8_t quality[SNUM]; int8_t elev[SNUM]; int16_t azim[SNUM]; int32_t prRes[SNUM]; } collection_t;

// // // // //

Bitmask Bitfield [deg] Elevation in integer degrees [deg] Azumuth in integer degrees [cm] Pseudo range residual in centimeters

typedef struct{ uint8_t wrd[62][5*3*10]; uint8_t valid[62]; } rxm_sfrb_t;

// Words of Data // 00011111 if the last SF is arrived

A program tipikus kimenete a képernyőre RXM-SFRB [sv: 25] (Subframe Buffer) (SFRB-ID: 1) 0 10001011 00001011 11110100 10000010 48 10111111 01010000 00000000 00111100 96 00111000 11001110 00000011 10000010 144 10000011 01001001 00001011 00100011 192 00000000 00000000 00001000 00000010 (SFRB-ID: 2) 0 10001011 00001011 11110100 10000010 48 00100011 00000110 11001000 00101110 96 00110101 01011000 01110011 00000101 144 11001101 11110100 10000011 00010000 192 00001100 11111001 10011111 01100010 (SFRB-ID: 3) 0 10001011 00001011 11110100 10000010 48 00000000 00100001 01111110 10111100 96 00000000 00110010 00100111 11000111 144 00011101 01101111 00011010 01110111 192 11111111 10100111 10011100 00100011 (SFRB-ID: 4)

00110000 00100111 01000011 01100010 11110100

00100101 47 10010111 95 00001110 143 01110000 191 01000111 239

00110000 10000001 11111011 00101100 01110000

10101000 47 00000111 95 00000001 143 10100001 191 01111101 239

00110001 10011010 00010111 11110101 00001010

00101101 47 11000100 95 00000101 143 00101001 191 01110010 239

0 10001011 48 01011101 96 11111101 144 10101011 192 01101111 (SFRB-ID: 5) 0 10001011 48 01000111 96 11111101 144 01010101 192 10001100

00001011 00001101 00111011 10001111 10000110

11110100 01111110 00000000 00000110 00110100

10000010 10010000 10100001 11011010 01000101

00110001 00010001 00001101 11110000 00000000

10110000 47 00111000 95 01000001 143 10000011 191 00101000 239

00001011 00111011 01001000 00011011 11011110

11110100 00101001 00000000 01111111 11001110

10000010 10010000 10100001 10001100 00101100

00110010 00010100 00001100 01000110 00000000

00110100 47 00101111 95 10110101 143 01110011 191 00110011 239

NAV-SVINFO (Space Vehicle Information) iTOW: 399979000 [ms] numCh: 14 globalFlags: 2 chn: 15 svid: 2 [1] flags: 4 quality: 1 cno: 0 [dbHz] elev: 8 [deg] azim: 140 [deg] prRes: 0 [cm] chn: 12 svid: 4 [3] flags: 4 quality: 4 cno: 13 [dbHz] elev: 18 [deg] azim: 103 [deg] prRes: 0 [cm] chn: 13 svid: 6 [5] flags: 16 quality: 1 cno: 0 [dbHz] elev: 65445 [deg] azim: 0 [deg] prRes: 0 [cm] ... ...

NAV-SOL (Navigation Solution Information) iTOW: 399979000 [ms] fTOW: -344471 [ns] week: 1789 [week] gpsFix: 3 flags: 1101 ecefX: 408247246 [cm] ecefY: 141045091 [cm] ecefZ: 467755334 [cm] pAcc: 754 [cm] ecefVX: 5 [cm/s] ecefVY: -2 [cm/s] ecefVZ: 2 [cm/s] sAcc: 2 pDop: 236 numSV: 5

RXM-RAW (Raw Measurment Data) iTOW: 399979999 [ms] week: 1789 [weeks] numSV: 6 sv: 24 [23] cpMes: -1839304.648859 [cycles] prMes: 20020881.636431 [m] doMes: 504.819824 [Hz] mesQI: 4 cno: 23 [dbHz] lli: 3 sv: 12 [11] cpMes: -5120231.331706 [cycles] prMes: 20656088.268789 [m] doMes: 2375.685059 [Hz] mesQI: 7 cno: 34 [dbHz] lli: 0 sv: 17 [16] cpMes: 206312.646099 [cycles] prMes: 22682848.484822 [m] doMes: -1758.731445 [Hz] mesQI: 4 cno: 15 [dbHz] lli: 3 ... ...