Lettore file UBX in Python

uno script scritto di fretta per risolvere un problema di debug sulla trasmissione via radio di un file ubx 

magari puo' servire a qualcun altro

=================================================

def crc_check(valore):

global ck_a

global ck_b

ck_a = (ck_a+valore) % 256

ck_b = (ck_b+ck_a) % 256

#print "CK_A : " + str(hex(ck_a)) + "  CK_B : " + str(hex(ck_b))

#file = open('acm0_remoto.ubx', 'r')

#file = open('usb0.ubx', 'r')

file = open('arcetri_ucenter.ubx', 'r')

#file = open('orto.ubx', 'r')

off=0

fine=0

ck_a = 0

ck_b = 0

good = 0

bad = 0

pacchetto = -1

while 1:

char = file.read(1)

off=off+1

pacchetto = ""

if ord(char) == 181: #B5

pacchetto = pacchetto + char

if (off == (fine+1)):

print "OK"

inizio = off -1

ck_a = 0

ck_b = 0

char = file.read(1)

off=off+1

#pacchetto = pacchetto + char

if ord(char) == 98: #62

#

if (inizio == fine + 1):

print "////////////////////// OK ////////////////"

print "/////////////////// " + hex(lungh) +" ////////////////"

#good = good + 1

else:

print "******************** ERRORE **************"

print "*****************DIFF " + hex(inizio-fine) + "*********"

#somma_diff = somma_diff + (inizio-fine)

#bad = bad+1

print "================================================="

print "======GOOD :" + str(good) + "==========BAD :"+ str(bad) + "==========================="

print "================================================="

pacchetto = pacchetto + char

print "Offset inizio: " + hex(inizio)

char = file.read(1)

pacchetto = pacchetto + char

off=off+1

print "Message Class: " + hex(ord(char)),

if (ord(char) == 1):

print " NAV ",

if (ord(char) == 2):

print " RXM ",

if (ord(char) == 4):

print " INF ",

if (ord(char) == 5):

print " ACK ",

if (ord(char) == 6):

print " CFG ",

if (ord(char) == 10):

print " MON ",

if (ord(char) == 11):

print " AID ",

if (ord(char) == 13):

print " TIM ",

classe = ord(char)

crc_check(ord(char))

char = file.read(1)

pacchetto = pacchetto + char

off=off+1

print " Message ID: " + hex(ord(char)),

crc_check(ord(char))

if (classe == 2):

if (ord(char)) == 0x10:

print " RAW "

if (ord(char)) == 0x11:

print " SFRB "

if (ord(char)) == 0x12:

print " SFRBX "

if (ord(char)) == 0x13:

print " RAWX "

print 

char = file.read(1)

pacchetto = pacchetto + char

off=off+1

print "Payload Length High: " + hex(ord(char))# + " " + str(ord(char))

lungh = ord(char)

crc_check(ord(char))

char = file.read(1)

pacchetto = pacchetto + char

off=off+1

print "Payload Length Low: "  + hex(ord(char))# + " " + str(ord(char))

lungh = (256*ord(char)) + lungh

print "Lunghezza :" + str(hex(lungh))#+ " " + str(lungh)

crc_check(ord(char))

for t in range(lungh):

char = file.read(1)

print hex(ord(char)),

pacchetto = pacchetto + char

off=off+1

crc_check(ord(char))

print 

char = file.read(1)

pacchetto = pacchetto + char

off=off+1

print 

crc_1 = ord(char)

char = file.read(1)

pacchetto = pacchetto + char

off=off+1

print "CRC 1: " + hex(crc_1) +"  CRC 2: " + hex(ord(char))

crc_2 = ord(char)

print "CK_A  :" + hex(ck_a) + "  CK_B : " + hex(ck_b)

if ((ck_a == crc_1) and (ck_b == crc_2)):

print "CRC OK"

good = good + 1

corretto = open('corretto.ubx', 'a')

corretto.write(pacchetto)

corretto.close()

else:

print "Errore CRC"

bad = bad + 1 

fine = off-1

print "Fine :" + hex(fine)

try:

input()

except SyntaxError:

pass

Gps Kalman Filter con Arduino Uno

Partendo da questo link volevo provare a testare il filtro Kalman sui dati di un GPS ma privo della contributo di una IMU (come fatto qui)

La libreria Arduino utilizzata (questo il link) e' una conversione di un codice in C originario

Mettendo a confronto la linea blu dei dati non filtrati con quella rossa dei dati filtrati e lasciando ferma l'antenna GPS si osserva che il filtro funziona ma non limita le tipiche fluttuazioni (anche molto significative) del segnale GPS

Questo test e' stato effettuato con due antenne a basso costo: un primo modulo senza marca di derivazione cinese ed una antenna con predisposizione per PixHawk denominata gygpsv5 con a bordo un Ublox NEO6M-V2

Utilizzando il codice scaricato da Internet senza particolari modifiche tutto funzionava con il modulo cinese ma non con Ublox nonostante i messaggi NMEA fossero correttamente ricevuti da Arduino.

Salvando i dati si capisce il motivo

Neo 6P
$GLGSV,3,3,09,88,20,181,*56
$GNGLL,4347.03855,N,01113.80955,E,132645.00,A,A*7C
$GNRMC,132646.00,A,4347.03855,N,01113.80955,E,0.030,,270319,,,A*6B
$GNVTG,,T,,M,0.030,N,0.055,K,A*3E
$GNGGA,132646.00,4347.03855,N,01113.80955,E,1,08,1.35,42.1,M,45.5,M,,*76
$GNGSA,A,3,12,24,25,32,,,,,,,,,2.61,1.35,2.23*1E
$GNGSA,A,3,68,86,77,87,,,,,,,,,2.61,1.35,2.23*12

GPS
$GPGSV,2,2,08,32,33,290,40,14,26,308,23,31,04,310,,34,,,*47
$GPRMC,133332.000,A,4347.0429,N,01113.8140,E,0.21,175.07,270319,,,A*60
$GPGGA,133333.000,4347.0428,N,01113.8140,E,1,5,1.55,36.1,M,47.6,M,,*6E
$GPGSA,A,3,12,25,24,29,32,,,,,,,,1.83,1.55,0.98*00
$GPGSV,2,133,37,25,58,293,33,24,46,141,33,29,37,207,25*75
$GPGSV,2,2,08,32,33,290,39,14,26,308,22,31,04,310,,34,,,*48
$GPRMC,133333.000,A,4347.0428,N,01113.8140,E,0.35,175.07,270319,,,A*65
$GPGGA,133334.000,4347.0427,N,01113.8141,E,1,5,1.55,36.1,M,47.6,M,,*67
$GPGSA,A,3,12,25,24,29,32,,,,,,,,1.83,1.55,0.98*00


Il modulo cinese usa delle frasi NMEA che iniziano per GP***** mentre Ublox usa frasi che usaon un prefisso GN****. La libreria TinyGPS riconosce solo il primo prefisso e quindi non sa come trattare i dati dell'Ublox ...e' stato sufficiente editare la libreria sostituendo le stringhe per rendere compatibile TinyGPS con UBlox.....ma come mai questa differenza

GN e' un prefisso generico che si usa per qualunque sorgenti date (Gps americano, Beidu, Glonass etc) mentre il prefisso GP e' relativo solo al GPS americano. (Glonass per esempio ha il prefisso GL).

-----------------------------------------------------------------
#include <SoftwareSerial.h>
#include <TinyGPS.h>
#include <GPSFilter.h>

#define RXPIN 2
#define TXPIN 3

#define GPSBAUD 9600

TinyGPS gps;
SoftwareSerial uart_gps(RXPIN, TXPIN);

GPSFilter f(2.5);

unsigned long lastUpdate;
unsigned long lastSentence;
float c;

void setup()
{
 Serial.begin(9600);
 uart_gps.begin(GPSBAUD);
 lastSentence = millis();
 lastUpdate = millis();
}


void loop()
{
 while(uart_gps.available()) {    
   char c = uart_gps.read();
    
   if(gps.encode(c)) {
     int year;
     byte month, day, hour, minute, second, hundredths;
     unsigned long age;
     gps.crack_datetime(&year,&month,&day,&hour,&minute,&second,&hundredths,&age); //Get the date from the GPS
     unsigned long date; 
     gps.get_datetime(&date,0,0);
     if(date == TinyGPS::GPS_INVALID_DATE){
        Serial.println(F("Invalid Age"));
         continue;
     }
     if(age == TinyGPS::GPS_INVALID_AGE) {
         Serial.println(F("Waiting for more valid data"));
         continue;
     }
     float latitude, longitude;
     double dlat,dlong;
     gps.f_get_position(&latitude, &longitude);

     double ulat,ulong;
     ulat = (double)latitude;
     ulong = (double)longitude;
     c = (millis() - lastSentence)/1000;
     f.update_velocity2d(ulat,ulong,c);
     lastSentence = millis();
  
     if((millis() - lastUpdate) >= 500 || lastUpdate == NULL){
          f.get_lat_long(&dlat,&dlong);
         Serial.print(latitude,8);
         Serial.print(";");
         Serial.print(longitude,8);
         Serial.print(";");
         Serial.print(dlat,8);
         Serial.print(";");
         Serial.println(dlong,8);     
        
         }
          lastUpdate = millis();
   }
 }
}

U-Blox U-Center e Wine

U-Center di U-Blox funziona correttamente in Wine su Debian
L'unica accortezza e' che si deve creare un symlink della porta USB verso un COM virtuale con

ln -s /dev/ttyACM0 /home/luca/.wine/dosdevices/com5

a questo punto il GPS verra' visto in U-Center sotto COM5

Galileo su Ublox M8T

per poter abilitare la ricezione del segnale della costellazione Galileo su Ublox M8T si deve aggiornare il software alla versione 3.01.
Per fare cio' si deve scaricare il firmware dal sito Ublox e poi da U-Center si avvia Flash Firmware Update. In firmware image si deve puntare al file scaricato mentre il file flash.xml da inserire nella casella Flash definition file si trova all'interno della cartella di installazione di Ublox

Una volta terminato il tutto  si abilita la ricezione del segnale Galileo a fianco di Glonass e GPS

Si puo' verificare che il nuovo firmware sia stato correttamente installato  andando nei messaggi UBX->MON->VER

A questo punto succede una cosa un po' strana...guardando i grafici non compare mai nessun satellite con la sigla che inizia per E (i Galileo si riconoscono per la lettera E seguita da un numero) ma andando un UBX->RXM->RAWX si vedono chiaramente comparire i Galileo (per esempio nell'immagine sottostante E18-E08-01)

Checksum di stringhe NMEA e pacchetti UBX

Visto che mi trovo a trasmettere dati GPS via radio e' necessario verificare che i dati non siano stati corrotti. Un metodo semplice e' quello di calcolare il checksum delle stringhe NMEA e dei pacchetti Ublox


NMEA
--------------------------------------------------
il checksum delle stringhe NMEA e' piuttosto semplice. Prima di tutto la stringa e' terminata da 0d e 0a.

Prendiamo per esempio la stringa
$GNVTG,,T,,M,0.005,N,0.010,K,A*39

il checksum e' 39

per il calcolo si toglie il primo carattere $ e tutto cio' che e' dopo il carattere *.
si prendono poi i caratteri e si effettua uno XOR di ogni carattere della stringa (in esadecimale)

quindi 47 XOR 4e XOR 56 XOR 54 XOR 47 ....... = 39

in questo caso il checksum calcolato e' uguale dal checksum ricevuto, Cio' vuol dire che il pacchetto e' stato ricevuto correttamente
--------------------------------------------------


UBX
I pacchetti UBX sono di tipo binario e non hanno una lunghezza fissa
I pacchetti partono con i due caratteri B5 e 62, seguono due byte che identificano la classe del messaggio e l'ID del messaggio. Seguono poi due bytes che indicano la lunghezza del messaggio (inteso solo come il payload), il payload e due bytes finali di checksum (8 bit unsigned)

Quindi il payload parte dal byte 7 in formato 16 bit senza segno in formato Little Endian

L'algoritmo di checksum e' quello di Fletcher.
Questa e' la versione scritta nel manuale Ublox

ma il codice piu' corretto dovrebbe essere il seguente, che rinormalizza ad ogni passaggio con il modulo 255

Ublox M8T + Intel Edison + RTKLib

Collegare un Ublox M8T e processare i dati direttamente all'interno della Edison con RTKLib e' un procedimento estremamente lineare e simile a quello di un normale PC

Il GPS, al contrario di YUN, viene riconosciuto immediatamente e le librerie RTKLib si compilano direttamente sulla Intel, complice anche l'assenza di dipendenze da altre librerie

L'unica accortezza e' quella di spostare lo switch SW1 verso la porta USB tipo A per abilitare questa porta (e conseguentemente disabilitare la porta microUsb OTG)

NTP Server con Ublox M8T e Arduino Yun

Avevo gia' fatto qualcosa di simile, ma in questo esempio mostrero' come usare una Arduino Yun ed un modulo Ublox M8T per creare un server NTP che utilizza il segnale GPS per avere l'informazione del tempo

Prima di tutto si deve collegare l'Ublox alla Yun mediante la porta USB. Se si effettua tale operazione da dmesg si vede che il dispositivo e' riconosciuto ma non viene creata la porta seriale corrispondente. Questo e' dovuto al fatto che Linino e' un sistema Linux ridotto all'osso e pochi moduli del kernel sono montati di default

Si deve quindi scaricare il pacchetto kmod.usb-acm mediante le seguenti istruzioni

opkg update
opkg install kmod-usb-serial kmod-usb-acm

a questo punto viene creata una porta seriale virtuale in /dev/ttyACM0

Si scarica e si installa quindi il demone gpsd

opkg update
opkg install gpsd gpsd-clients ntpdate

e si attiva mediante il comando

gpsd /dev/ttyACM0 -n -F /var/run/gpsd.sock
per verificare se il flusso dati proveniente dal GPS e' interpretato in modo corretto si puo' digitare

cgps -s

si installa quindi il server ntp
opkg update
opkg install ntpd ntp-utils

e si modifica il file di configurazione in /etc/ntp.conf aggiungendo queste linee

-----------------------------------------

server 127.127.28.0 minpoll 4 maxpoll 4 

fudge 127.127.28.0 time1 0.0 refid GPS 

server 127.127.28.1 minpoll 4 maxpoll 4 prefer 

fudge 127.127.28.1 refid PPS
-----------------------------------------

e si lancia il servizio
/etc/init.d/sysntpd disable
/etc/init.d/ntpd enable
/etc/init.d/ntpd start
a questo punto digitando
ntpq -p
si vedra' apparire il GPS tra la sorgente delle fonti dati (e visto che sara' anche con quello di minor latenza) sara' il preferito. La Yun e' preconfigurata per usare il tempo UTC (come quello del GPS) e non ha di default configurate le timezone

Ublox M8T e vegetazione

Visto che e' in previsione una installazione di un UBlox in un'area attualmente priva di vegetazione ma che sara' vegetata con l'arrivo della bella stagione ho voluto vedere se un prato puo' degradare il segnale GPS ricevuto. La seconda antenna di riferimento per il DGPS era invece posta in un'area asfaltata con una ottima visione del cielo

L'antenna e' nascosta dall'erba a sinistra del PC

Nonostante tutto il post-processing dei dati ha mostrato un fix FGPS molto stabile

DGPS con Ublox M8T e RTKLib a 5Hz e 10Hz

In caso di utilizzo di GPS Differenziale in modalita' dinamica puo' essere utile avere una frequenza di campionamento piu' veloce dello standard di una acquisizione al secondo, in particolar modo se il rover si muove rapidamente.
L'Ublox M8T permette questa funzionalita' almeno fino al valore di campionamento di 10Hz (piu' veloce non ho provato ma il file di configurazione permette di inserire il tempo di campionamento in millisecondi, il che fa pensare che si posssano inserire valori inferiori ai 100 millisecondi

L'unica accortezza, per permettere il campionamento piu' veloce, e' quello di modificare la velocita' della porta seriale (anche se si acquisisce via USB) modificando il valore standard di 9600 bps portandolo a 115200 bps. Si deve tenere anche conto che il file di configurazione di RTKLib, nonostante si chiami ubx_m8t_glo_raw_5hz.cmd non modifica la velocita' della porta per cui, cosi' come e', e' sostanzialmente inutile


-----------------------------------
# RTKNAVI options (2016/02/08 17:25:54, v.2.4.3 b8)

pos1-posmode       =single     # (0:single,1:dgps,2:kinematic,3:static,4:movingbase,5:fixed,6:ppp-kine,7:ppp-static,8:ppp-fixed)
pos1-frequency     =l1         # (1:l1,2:l1+l2,3:l1+l2+l5,4:l1+l5)
pos1-soltype       =forward    # (0:forward,1:backward,2:combined)
pos1-elmask        =15         # (deg)
pos1-snrmask_r     =off        # (0:off,1:on)
pos1-snrmask_b     =off        # (0:off,1:on)
pos1-snrmask_L1    =0,0,0,0,0,0,0,0,0
pos1-snrmask_L2    =0,0,0,0,0,0,0,0,0
pos1-snrmask_L5    =0,0,0,0,0,0,0,0,0
pos1-dynamics      =off        # (0:off,1:on)
pos1-tidecorr      =off        # (0:off,1:on,2:otl)
pos1-ionoopt       =brdc       # (0:off,1:brdc,2:sbas,3:dual-freq,4:est-stec,5:ionex-tec,6:qzs-brdc,7:qzs-lex,8:stec)
pos1-tropopt       =saas       # (0:off,1:saas,2:sbas,3:est-ztd,4:est-ztdgrad,5:ztd)
pos1-sateph        =brdc       # (0:brdc,1:precise,2:brdc+sbas,3:brdc+ssrapc,4:brdc+ssrcom)
pos1-posopt1       =off        # (0:off,1:on)
pos1-posopt2       =off        # (0:off,1:on)
pos1-posopt3       =off        # (0:off,1:on,2:precise)
pos1-posopt4       =off        # (0:off,1:on)
pos1-posopt5       =off        # (0:off,1:on)
pos1-posopt6       =off        # (0:off,1:on)
pos1-exclsats      =           # (prn ...)
pos1-navsys        =1          # (1:gps+2:sbas+4:glo+8:gal+16:qzs+32:comp)
pos2-armode        =continuous # (0:off,1:continuous,2:instantaneous,3:fix-and-hold)
pos2-gloarmode     =off        # (0:off,1:on,2:autocal)
pos2-bdsarmode     =off        # (0:off,1:on)
pos2-arthres       =3
pos2-arthres1      =0.9999
pos2-arthres2      =0.25
pos2-arthres3      =0.1
pos2-arthres4      =0.05
pos2-arlockcnt     =0
pos2-arelmask      =0          # (deg)
pos2-arminfix      =10
pos2-armaxiter     =1
pos2-elmaskhold    =0          # (deg)
pos2-aroutcnt      =5
pos2-maxage        =30         # (s)
pos2-syncsol       =off        # (0:off,1:on)
pos2-slipthres     =0.05       # (m)
pos2-rejionno      =30         # (m)
pos2-rejgdop       =30
pos2-niter         =1
pos2-baselen       =0          # (m)
pos2-basesig       =0          # (m)
out-solformat      =llh        # (0:llh,1:xyz,2:enu,3:nmea)
out-outhead        =off        # (0:off,1:on)
out-outopt         =off        # (0:off,1:on)
out-timesys        =gpst       # (0:gpst,1:utc,2:jst)
out-timeform       =hms        # (0:tow,1:hms)
out-timendec       =3
out-degform        =deg        # (0:deg,1:dms)
out-fieldsep       =
out-height         =ellipsoidal # (0:ellipsoidal,1:geodetic)
out-geoid          =internal   # (0:internal,1:egm96,2:egm08_2.5,3:egm08_1,4:gsi2000)
out-solstatic      =all        # (0:all,1:single)
out-nmeaintv1      =0          # (s)
out-nmeaintv2      =0          # (s)
out-outstat        =off        # (0:off,1:state,2:residual)
stats-eratio1      =100
stats-eratio2      =100
stats-errphase     =0.003      # (m)
stats-errphaseel   =0.003      # (m)
stats-errphasebl   =0          # (m/10km)
stats-errdoppler   =1          # (Hz)
stats-stdbias      =30         # (m)
stats-stdiono      =0.03       # (m)
stats-stdtrop      =0.3        # (m)
stats-prnaccelh    =10         # (m/s^2)
stats-prnaccelv    =10         # (m/s^2)
stats-prnbias      =0.0001     # (m)
stats-prniono      =0.001      # (m)
stats-prntrop      =0.0001     # (m)
stats-prnpos       =0          # (m)
stats-clkstab      =5e-12      # (s/s)
ant1-postype       =llh        # (0:llh,1:xyz,2:single,3:posfile,4:rinexhead,5:rtcm)
ant1-pos1          =90         # (deg|m)
ant1-pos2          =0          # (deg|m)
ant1-pos3          =-6335367.6285 # (m|m)
ant1-anttype       =
ant1-antdele       =0          # (m)
ant1-antdeln       =0          # (m)
ant1-antdelu       =0          # (m)
ant2-postype       =llh        # (0:llh,1:xyz,2:single,3:posfile,4:rinexhead,5:rtcm)
ant2-pos1          =90         # (deg|m)
ant2-pos2          =0          # (deg|m)
ant2-pos3          =-6335367.6285 # (m|m)
ant2-anttype       =
ant2-antdele       =0          # (m)
ant2-antdeln       =0          # (m)
ant2-antdelu       =0          # (m)
misc-timeinterp    =off        # (0:off,1:on)
misc-sbasatsel     =0          # (0:all)
misc-rnxopt1       =
misc-rnxopt2       =
misc-pppopt        =
file-satantfile    =
file-rcvantfile    =
file-staposfile    =
file-geoidfile     =
file-ionofile      =
file-dcbfile       =
file-eopfile       =
file-blqfile       =
file-tempdir       =/tmp
file-geexefile     =
file-solstatfile   =
file-tracefile     =
file-cmdfile1      =ubx_m8t_glo_raw_10hz.cmd


# 

inpstr1-type       =serial     # (0:off,1:serial,2:file,3:tcpsvr,4:tcpcli,7:ntripcli,8:ftp,9:http)
inpstr2-type       =off        # (0:off,1:serial,2:file,3:tcpsvr,4:tcpcli,7:ntripcli,8:ftp,9:http)
inpstr3-type       =off        # (0:off,1:serial,2:file,3:tcpsvr,4:tcpcli,7:ntripcli,8:ftp,9:http)
inpstr1-path       =ttyACM0:115200:8:n:1:off
inpstr2-path       =
inpstr3-path       =
inpstr1-format     =ubx        # (0:rtcm2,1:rtcm3,2:oem4,3:oem3,4:ubx,5:ss2,6:hemis,7:skytraq,8:gw10,9:javad,10:nvs,11:binex,12:rt17,15:sp3)
inpstr2-format     =rtcm2      # (0:rtcm2,1:rtcm3,2:oem4,3:oem3,4:ubx,5:ss2,6:hemis,7:skytraq,8:gw10,9:javad,10:nvs,11:binex,12:rt17,15:sp3)
inpstr3-format     =rtcm2      # (0:rtcm2,1:rtcm3,2:oem4,3:oem3,4:ubx,5:ss2,6:hemis,7:skytraq,8:gw10,9:javad,10:nvs,11:binex,12:rt17,15:sp3)
inpstr2-nmeareq    =off        # (0:off,1:latlon,2:single)
inpstr2-nmealat    =0          # (deg)
inpstr2-nmealon    =0          # (deg)
outstr1-type       =file       # (0:off,1:serial,2:file,3:tcpsvr,4:tcpcli,6:ntripsvr)
outstr2-type       =off        # (0:off,1:serial,2:file,3:tcpsvr,4:tcpcli,6:ntripsvr)
outstr1-path       =./ufast2.txt
outstr2-path       =
outstr1-format     =llh        # (0:llh,1:xyz,2:enu,3:nmea)
outstr2-format     =llh        # (0:llh,1:xyz,2:enu,3:nmea)
logstr1-type       =file       # (0:off,1:serial,2:file,3:tcpsvr,4:tcpcli,6:ntripsvr)
logstr2-type       =off        # (0:off,1:serial,2:file,3:tcpsvr,4:tcpcli,6:ntripsvr)
logstr3-type       =off        # (0:off,1:serial,2:file,3:tcpsvr,4:tcpcli,6:ntripsvr)
logstr1-path       =./ufast2.ubx
logstr2-path       =
logstr3-path       =
misc-svrcycle      =10         # (ms)
misc-timeout       =10000      # (ms)
misc-reconnect     =10000      # (ms)
misc-nmeacycle     =5000       # (ms)
misc-buffsize      =32768      # (bytes)
misc-navmsgsel     =all        # (0:all,1:rover,2:base,3:corr)
misc-proxyaddr     =
misc-fswapmargin   =30         # (s)

-----------------------------------

File di configurazione per acquisizione raw a 10Hz. Nella prima riga evidenziata in giallo si imposta la velocita' della seriale, nella seconda il passo di campionamento (100 ms)
-----------------------------------
!UBX CFG-GNSS 0 32 32 1 3 16 16 0 0

!UBX CFG-GNSS 0 32 32 1 6 16 16 0 1

!UBX CFG-MSG 2 21 0 0 0 1 0 0

!UBX CFG-MSG 2 19 0 0 0 1 0 0

!UBX CFG-PRT 1 0 0 2256 115200 7 7 0

!UBX CFG-RATE 100 1 1

@
!UBX CFG-MSG 2 21 0 0 0 0 0 0

!UBX CFG-MSG 2 19 0 0 0 0 0 0

!UBX CFG-RATE 100 1 1
-----------------------------------

Rtkrcv, per il post processing, si deve essere sicuri di impostare il corretto valore del passo di campionamento

Questi sono i risultati di due prove di DGPS con rover e stazione entrambi con Ublox M8T. Le condizioni di misure non erano ottimali data la presenza di palazzi ed ambiente urbano ma si ottiene comunque un fix piuttosto stabile 

Prova a 5Hz

Prova a 10Hz

Ublox M8T : sensibilita' in DGPS con RTKLib

Premessa : come in qualunque caso conoscere la  riposta aiuta nel risolvere una domanda. In un caso reale non conoscendo l'ora e l'entita' dello spostamento diventa difficile estrapolare i reali movimenti nascosti all'interno del rumore della misura


Ho voluto provare a vedere quale fosse il minimo  spostamento che e' possibile registrare usando il modulo Ublox M8T in modalita' differenziale usando RTK-Lib in modalita' cinematica (usando come base sia una Ublox M8T che un Leica 1200)

(allargare le immagini per vedere il dettaglio)
Prova 1:
in questo caso il sensore e' stato spostato di 9 cm. Lo spostamento calcolato e' di circa 6.9 cm (76% dello spostamento reale)

Prova 2:
Lo spostamento reale e' stato di 8 cm. Lo spostamento calcolato e' di circa 6.2 cm (77% dello spostamento reale)

Prova 3: 
Qui lo spostamento reale e' stato di 4 cm. Dopo l'elaborazione dei dati GPS lo spostamento e' calcolabile in 3.1 cm (77% dello spostamento reale)

Lo spostamento calcolato e' sempre sottostimato (circa 76-77%) ma si nota che e' possibile avere misure sostanzialmente affidabili fino ai 4 cm

Reset to factory default Ublox M8T

L'UBlox, come molti altri dispositivi complessi. e' dotato di una memoria non-volatile. Per questo motivo e' abbastanza semplice, provando e riprovando, mandarlo in uno stato non desiderato
Per riportare i settaggi ai valori di default si usi U-Center nella finestra Messages/UBX->CFG/Revert to default configuration. Non e' necessario, anzi e' sconsigliato, riflashare il firmware

Per vedere il firmware dell'Ublox da UCenter si  va nella finestra Messages/UBX->MON->VER

Un altro interessante settaggio e' in UBX->CFG->RXM che permette di impostare la modalita' Power Save

DGPS Ublox 2 Ublox M8T

Per rendere le cose un po' piu' complicate ho provato ad usare due antenne Ublox M8T per ottenere un sistema DGPS senza la necessita' di appoggiarmi sulla Provincia di Firenze

Stessa metodologia gia' applicata nelle prove precedenti, usandone una come rover ed una come base
Le due antenne sono state tenute ferme tranne per uno spostamento di 8 cm al tempo 10:45:00 con un fix differenziale di oltre il 99%

per confronto questa e' l'elaborazione con i dati dell'antenna della Provincia di Firenze

Il sistema quindi e' funzionante

DGPS cinematico con RTKLib e Ublox M8T

Una prova di usare l'Ublox M8T in modalita' differenziale e dinamica.
L'antenna fissa e' stata quella della ex Provincia di Firenze mentre il rover e' stato l'Ublox con parametri di acquisizione in modalita' raw 1 dato al secondo

La modalita' di acquisizione e' stata identica a quella illustrata qui tranne per il fatto che il rover non era fermo ma in movimento. L'elaborazione e' stata fatta in post-processing

Dal punto di vista del software la modifica da effettuare e' di andare in Options di RTKPost e modificare da Static a Kinematic 

Questo invece e' il plot con il fix differenziale

per avere un riferimento ho camminato sul bordo dei sentieri in asfalto e percorso il bordo della circonferenza. C'e' una discreta discrepanza con l'immagine di Google Earth ma credo che il problema sia principalmente relativo alla georefenziazione dell'immagine e non ai dati del GPS anche perche' le linee risultano rettilinee ed il cerchio ha una ottima forma

Raw data su UART1 in Ublox M8T ed Arduino

Sono arrivato al punto di connettere l'Ublox M8T ad Arduino. La connessione, come nel suo fratello minore, e' banale perche' basta connettere Vcc (in questo caso 5V), GND e Tx al D2 di Arduino

Lo sketch e' una banale modifica dell'esempio di SoftwareSerial

------------------------------------------
#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3); // RX,TX

void setup()
{
  Serial.begin(9600);
  mySerial.begin(9600);
}

void loop()
{
  if (mySerial.available())
    Serial.write(mySerial.read());
}
------------------------------------------

Il problema e' che sulla porta seriale UART1 di Ublox di default vengono trasmessi solo i dati NMEA ed anche abilitando i messaggi UBX questi si vedono passare sulla porta USB e non sulla UART1

Cio' deriva dal fatto che i messaggi UBX su UART1 devono essere esplicitamente abilitati da U-Center andando nel menu Configuration View (CTRL+F9), MSG, dalla tendina si selezione RXM-RAWX, si spunta la UART1 e si preme SEND

A questo punto si vedranno i messaggi raw UBX anche sulla porta seriale

Validazione UBlox M8T

Tempo fa avevo provato a validare il modulo GPS di Adafruit (con pessimi risultati) usando un punto trigonometrico di coordinate conosciute

Stavolta e' stato il turno dell'UBlox M8T

Il sistema e' stato messo in registrazione dei dati in modalita' binaria e poi i dati sono stati postprocessati mediante RTKPost di RTKLib in modo differenziale con la registrazione dell'antenna dell'ex Provincia di Firenze (i dati sono scaricabili da qui, in formato Rinex compresso e aggiornati ogni ora con passo a 30 secondi)

Come si vede si ottiene il fix del punto differenziale dopo circa 5 minuti di registrazione (il che corrisponde a circa 10 misure visto il passo a 30 secondi)

Una volta ottenuto il fix la posizione e' molto stabile (dell'ordine del centimetro)

2016/02/18 09:21:00.000   43.833049301   11.307061053   203.6658   1   7   0.0016   0.0011   0.0027   0.0006  -0.0005  -0.0013   0.00   22.2

Visto che l'antenna della Provincia ha una posizione conosciuta si puo' tentare anche il posizionamento assoluto del punto di misura dell'Ublox
Secondo quanto riportato dal calcolo di post processing la posizione incognita risulta essere

Lat = 43.8330496301
Long = 11.307061053
(conversione effettuata mediante questo servizio online)

che corrisponde in coordinate metriche Gauss Boaga Fuso Ovest a

N = 1685517.05
E = 4855934.20

secondo quanto riportato dalla scheda del punto trigonometrico (fonte Regione Toscana) la posizione del punto in coordinate metriche e'

N = 1685517.43
E = 4855934.06

in conclusione la differenza di posizione e' di circa 38 cm su N e 14 cm su E. In realta', come si vede dalla figura, l'antenna non era posizionata esattamente al centro del chiodo ma spostata di circa 20 cm e si deve tenere conto anche dell'incertezza sulla conversione)

Si puo' dire che l'Ublox M8T e' validato con postprocessing per precisione alla decina di centimetri

RTKLib su Raspberry

Allo scopo di usare una attrezzatura piu' leggera e di maggiore durata di batteria ho provato ad accoppiare l'UBlox M8T ad una Raspberry B alimentando il tutto con un power bank da 10000 mAh

Per fare cio' era necessario compilare le RTKLib sulla Raspbian. La compilazione e' avvenuta senza nessuna modifica rispetto a quella che si esegue su desktop e rtkrcv funziona correttamente anche su Raspberry (ovviamente ci vuole molta pazienza per compilare i sorgenti data la velocita' del processore)

Per scaricare i dati e' stato sufficiente abilitare l'SFTP e connettersi con un cavo cross da portatile

RTKLib postprocessing base e rover

Viene qui descritta una prova di post processing i dati di un Ublox M8T mediante il software RTKLib

L'attrezzatura e' costituita da una base Leica 500 ed un modulo Ublox M8T in acquisizione raw collegato ad un pc Debian

Il Leica 500 era configurato per una acquisizione al secondo (come l'Ublox) e permette la registrazione di L1+L2 mentre l'M8T acquisisce solo L1

Entrambi i dispositivi erano statici al momento dell'acquisizione

Questa e' la mappa dei punti derivati da una acquisizione senza post processing

Come si vede i dati sono distribuiti su un'area di raggio di circa 3 m. (la zona di acquisizione aveva alberi e non era particolarmente ben esposta)

I dati del Leica 500 sono stati esportati in Rinex mediante il proprio software mentre i dati binari dell'Ublox sono stati convertiti in Rinex con RTKLib

L'elaborazione del dato e' stata effettuata con RTKPost sotto Windows e mostra come i dati dell'Ublox risultino migliori con fluttuazioni di circa +/- 20 cm rispetto al punto medio

--------------------------------------------------------

Se non si  ha una stazione base si puo' sfruttare lo stesso principio per migliorare le misure basandosi su stazioni di misura che distribuiscono dati su Internet come la rete RING (nel mio caso la stazione piu' vicina e' quella di Carmignano di Prato). I dati vengono distribuiti in directory che hanno come nome il giorno progressivo dell'anno .... per esempio il giorno 8 febbraio 2016 si trovera' nella cartella 039 e cosi' via

I dati si possono scaricare il giorno successivo a quello dell'acquisizione e sono in formato Rinex compatto (CRinex). Per poterlo usare con RTKPost deve essere convertito in Rinex standard mediante il software crx2rnx che e' incluso nel pacchetto di RTKLib

Questi sono i risultati di una prova. In questo caso ci sono oltre 20 chilometri tra l'Ublox e la stazione remota (che risulta essere dalla scheda anagrafica un Leica 1200) ed il passo di campionamento e' differente perche' la stazione remota registra dati solo ogni 30 secondi

La distribuzione dei punti senza correzione e' molto migliore del caso precedente perche' l'antenna GPS M8T e' stata montata su un tetto; comunque i punti sono compresi in un cerchio di +/- 1 m rispetto al punto medio

Per migliorare il dato, oltre ai file Rinex, si possono scaricare da qui i dati relativi alle effemeridi dei satelliti . I dati sono organizzati in directory secondo il criterio settimana_gps_numero del giorno. Per esempio il giorno 10 febbraio 2016 corrisponde alla cartella 1883 (ovvero la 1883° settimana GPS) ed il giorno mercoledi' corrisponde al codice 3 (0=domenica). Le effemeridi sono nel file .sp3 e sono divise in 4 file di 6 ore ciascuno (per i dati delle ore 10 si deve scarica il file igu18833_06.sp3).

Lo stesso si puo' fare per i dati del modello della ionosfera da ftp://ems.estesc.esa.int/pub/  dove sono distribuiti file .ems sempre con il formato del giorno progressivo (in questo caso mercoledi' 10 febbraio corrisponde alla directory d041 in cui i dati sono poi divisi per ora)

Nelle opzioni deve essere scelto il passo di campionamento piu' lento (in questo caso quello della base a 30 secondi)

Anche in questo caso e' visibile un miglioramento del dato grezzo (gia' peraltro buono) con una incertezza dell'ordine di 20 cm