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

Wired Ethernet su Intel Edison

Come prova ho provato a connettere via cavo Ethernet la Edison utilizzando un dongle USB-Ethernet

Il primo tentativo (ricordarsi di spostare il selettore verso la porta USB standard per attivarla) , utilizzando un dongle Lenovo USB 3 che usa il modulo cdc_ether, non e' andato a buon fine perche' il modulo non era riconosciuto dal kernel

Successivamente ho provato con un vecchio dongle USB-Ethernet di Apple che utilizza il modulo Asix  AX 88772 che e' stato immediatamente riconosciuto


[  872.328790] usb 1-1: new high-speed USB device number 3 using dwc3-host
[  872.368156] usb 1-1: New USB device found, idVendor=05ac, idProduct=1402
[  872.368187] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  872.368209] usb 1-1: Product: Apple USB Ethernet Adapter
[  872.368228] usb 1-1: Manufacturer: Apple Inc.     
[  872.368247] usb 1-1: SerialNumber: 019F66
[  873.250659] asix 1-1:1.0 eth0: register 'asix' at usb-dwc3-host.2-1, ASIX AX88772 USB 2.0 Ethernet, 00:1f:5b:ff:27:2e
[  873.379958] systemd-udevd[410]: renamed network interface eth0 to enp0s17u1

Peraltro il dispositivo ha assunto direttamente l'IP da DHCP
-----------------------------------------------
root@edison:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 98:f1:70:67:20:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.43.200/24 brd 192.168.43.255 scope global wlan0
       valid_lft forever preferred_lft forever
4: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 02:00:86:73:47:06 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.15/24 brd 192.168.2.255 scope global usb0
       valid_lft forever preferred_lft forever
5: enp0s17u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1f:5b:ff:27:2e brd ff:ff:ff:ff:ff:ff
    inet 10.200.4.12/16 brd 10.200.255.255 scope global enp0s17u1
       valid_lft forever preferred_lft forever
    inet6 fe80::21f:5bff:feff:272e/64 scope link
       valid_lft forever preferred_lft forever
-----------------------------------------------

A questo puo' essere comodo disabilitare la connessione WiFi con i seguenti comandi

systemctl start connman
systemctl enable connman
connmnanctl
connmanctl> disable wifi

Android 6.0.1 su Nexus 5

Visto il calo dei prezzi mi sono preso un Nexus 5 32 Giga per sviluppo su Android 6

Il telefono era nuovo e quindi all'accensione e' iniziata la fila degli aggiornamenti che, partendo dalla versione 4.4, mi avrebbero preso un bel po' di tempo via OTA.
Durante un aggiornamento incrementale di Android 4.4.3 il telefono si e' riacceso con il robottino con la pancia aperta e la scritta Errore in rosso. 2 minuti di panico e poi il sistema si e' riavviato da solo

Non volendo ripetere l'esperienza e per risparmiare tempo ho provato a fare direttamente il salto a 6.0.1 evitando le OTA.

Dopo aver scaricato il file https://dl.google.com/dl/android/aosp/hammerhead-mob30m-factory-8fc48e44.tgz  (579 Mb) ed averlo scompattato ho seguito questi passi

adb reboot bootloader
fastboot oem unlock
./flash-all

bisogna armarsi di pazienza prima di riottenere il dispositivo funzionate (circa 20 minuti).

Autostart Python e Sketch in Intel Edison

Gli sketch su Intel Edison, a differenza di Arduino, non vanno in esecuzione automatica.
Per fare cio si deve creare la directory /etc/init.d ed un file sh

mkdir /etc/init.d
cd /etc/init.d
vi automatico.sh

all'interno del file automatico.sh si digita il comando exec puntado al file sketch.elf che dovra' essere stato prima spostato dalla directory /tmp a /sketch
----------------------------
#!/bin/sh
exec /sketch/sketch.elf /dev/ttyGS0 /dev/ttyGS0
----------------------------
a questo punto per l'esecuzione automatica si rende il file eseguibile

root@edison:/etc/init.d# chmod +x /etc/init.d/automatico.sh
root@edison:/etc/init.d# update-rc.d automatico.sh defaults
lo stesso si puo' fare anche con gli script Python modificando il contenuto del file /etc/init.d/automatico.sh come segue
----------------------------
 #!/bin/sh
python /home/root/programma.py >> /dev/null 2>&1 &
----------------------------

Modulo Radio 433 MHz HM-TRP con SIK

Volevo provare a sostituire i moduli XBee con qualcosa di piu' perfomante, piu' che altro alla ricerca di allargare il raggio di trasmissione
Su consiglio di un amico mi sono comprato i trasmettitori 433 MHz 500 mA della Drotek che dovevano essere basati sul firmware open source Sik

http://www.drotek.com/shop/en/home/642-radio-telemetry-kit-433mhz-500mw.html

Si tratta di moduli radio nati per essere montati sui droni ed hanno gia' i connettori predisposti per PixHawk ma di fatto sono solo dei trasmettitori che si comportano come delle seriali virtuali

Il dispositivo e' arrivato senza nessun tipo di documentazione (CD, Libro), sul sito non ci sono riferimenti alla documentazione. Ho provato a contattare direttamente Drotek e devo ammettere che questa ditta non ha assolutamente nessuna assistenza clienti (la prossima volta compro in Cina...tanto e' uguale a parte il prezzo)

Sulla base delle poche informazioni fornite dal mio amico mi sono rimboccato le maniche ed ho cercato di prendere il controllo del dispositivo.

Connesso il trasmettitore ad una CentOs 7 via microUsb il dispositivo compare come seriale virtuale.
------------------------------------------------
Jun 29 15:31:31 localhost kernel: usb 1-1.2: new full-speed USB device number 3 using ehci-pci
Jun 29 15:31:31 localhost kernel: usb 1-1.2: New USB device found, idVendor=10c4, idProduct=ea60
Jun 29 15:31:31 localhost kernel: usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 29 15:31:31 localhost kernel: usb 1-1.2: Product: CP2102 USB to UART Bridge Controller
Jun 29 15:31:31 localhost kernel: usb 1-1.2: Manufacturer: Silicon Labs
Jun 29 15:31:31 localhost kernel: usb 1-1.2: SerialNumber: 0001
Jun 29 15:31:31 localhost mtp-probe: checking bus 1, device 3: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2"
Jun 29 15:31:31 localhost mtp-probe: bus: 1, device: 3 was not an MTP device
Jun 29 15:31:32 localhost kernel: usbcore: registered new interface driver cp210x
Jun 29 15:31:32 localhost kernel: usbserial: USB Serial support registered for cp210x
Jun 29 15:31:32 localhost kernel: cp210x 1-1.2:1.0: cp210x converter detected
Jun 29 15:31:32 localhost kernel: usb 1-1.2: cp210x converter now attached to ttyUSB1
------------------------------------------------

a questo punto rimane il problema di programmarlo e ricevere/inviare i dati
Se si cerca il firmware Sik si attiva a questa pagina su GitHub. Nella sottocartella Firmware/Tools ci sono dei comodi script Python ed in particolare leggendo il codice del programma show_regs.py sembra quello utile a capire se il dispositivo risponde

per fare funzionare questo script si devono soddisfare le dipendenze con PySerial (pip install pyserial) e Pexpect. Per questa seconda libreria ho avuto qualche problema con pip ed ho usato l'installazione standard partendo da http://pexpect.sourceforge.net/doc/#download ed installando con python setup.py install

A questo punto digitando
[root@localhost tools]# ./show_regs.py /dev/ttyUSB1

si hanno le seguenti risposte

------------------------------------------------
showing registers on /dev/ttyUSB1
+++
ATI
OK
ATI5

ATI
SiK 1.9 on HM-TRP
ATI5
S0:FORMAT=25
S1:SERIAL_SPEED=57
S2:AIR_SPEED=64
S3:NETID=25
S4:TXPOWER=11
S5:ECC=1
S6:MAVLINK=1
S7:OPPRESEND=1
S8:MIN_FREQ=433050
S9:MAX_FREQ=434790
S10:NUM_CHANNELS=10
S11:DUTY_CYCLE=100
S12:LBT_RSSI=0
S13:MANCHESTER=0
S14:RTSCTS=0
S15:MAX_WINDOW=131
ATI6
ATI6
silence_period: 404
tx_window_width: 6978
max_data_packet_length: 118
ATI7
ATI7
L/R RSSI: 54/0  L/R noise: 66/0 pkts: 0  txe=0 rxe=0 stx=0 srx=0 ecc=0/0 temp=-276 dco=0
ATO
------------------------------------------------

La spiegazione dei parametri ripresa da qui e' la seguente

• FORMAT - this is for EEPROM format version. Don’t change it
• SERIAL_SPEED - this is the serial speed in ‘one byte form’ (see below)
• AIR_SPEED - this is the air data rate in ‘one byte form’
• NETID - this is the network ID. It must be the same for both your radios
• TXPOWER - this is the transmit power in dBm. The maximum is 20dBm
• ECC - this enables/disables the golay error correcting code
• MAVLINK - this controls MAVLink framing and reporting. 0=no mavlink framing, 1=frame mavlink, 2=low latency mavlink
• MIN_FREQ - minimum frequency in kHz
• MAX_FREQ - maximum frequency in kHz
• NUM_CHANNELS - number of frequency hopping channels
• DUTY_CYCLE - the percentage of time to allow transmit
• LBT_RSSI - Listen Before Talk threshold (see docs below)
• MAX_WINDOW - max transmit window in msecs, 131 is the default, 33 recommended for low latency (but lower bandwidth)

i codici sulla potenza di trasmissione sono

Power (dBm)	Power (milliWatts)
1	1.3
2	1.6
5	3.2
8	6.3
11	12.5
14	25
17	50
20	100

quindi il modulo radio utilizza effettivamente un firmware SiK e si chiama HM-TRP.
La velocita' di download di default e' 57600

A questo punto ho provato a collegare il secondo modulo via USB ma nessuna risposta (led spenti).. Dronetek non mi ha spiegato il motivo di tale configurazione (ad occhio il modulo da collegare non via Usb e' quello che si monta sul drone mentre l'altro, via Usb, e' da connettere al PC/Tablet di controllo del drone)

Ho provato allora ad alimentare il modulo tramite una Arduino ed il connettore DF13

Visto che il modulo si e' acceso ho caricato un semplice sketch di SoftwareSerial sulla Arduino per mandare una stringa ed ho messo in ascolto con Minicom (57600 8N1) il secondo modulo sulla Linux Box collegato via serial

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

SoftwareSerial mySerial(10, 11); // RX, TX

void setup()
{
  mySerial.begin(57600);
}

void loop() // run over and over
{
  mySerial.println("Prova trasmissione");
}

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

Si e' quindi acceso il led rosso se entrambi i dispositivi radio ed sono riuscito a vedere il flusso dati

Per configurare i moduli radio (per esempio per cambiare il baud rate oppure la potenza di trasmissione) si puo' utilizzare il software Mission Planner

Si seleziona la porta seriale, si seleziona Inital Setup, Sik Radio, Local., Carica Settaggi.

Una soluzione alternativa e' APM Planner

In una prova con potenza di trasmissione 11 corrispondente a 12 mW si riesce a ricevere il segnale fino ad almeno 150 m. In Italia il massimo valore di potenza ammesso per la trasmissione radio e' di 100 mW ma il trasmettitore puo' arrivare a 500 mW

Accedere da Arduino a Yocto su Intel Edison

Un altro sistema (dopo quello via seriale visto qui) per scambiare dati tra il lato Arduino ed il lato Edison e' quello di sfruttare il fatto che Arduino IDE espone il file system.

tramite il comando system e' possibile lanciare dei comandi sulla shell di Yocto e potendo creare file. Nel banale esempio sottostante si appende il valore 1 al file /home/root/luca.txt...forgiando la stringa in modo adeguato si possono per esempio salvare i valori letti  da un sensore o le stringhe GPS

mini sketch Arduino
--------------------------
void loop()
{
system("echo '1' >> /home/root/luca.txt");
delay(1000);
}
--------------------------

E' possibile oltre che a scrivere anche leggere i file sul parte Yocto da sketch Arduino

Scambio seriale tra Arduino Expansion Board e Intel Edison

Scambiare dati tra il lato Arduino (via Expansion Board) ed Intel Edison non e' immediato perche' in Yocto non sono predisposte porte seriali.(ripreso da questo link)

Per aggirare il problema si deve installare prima socat, con le istruzioni sotto indicate
----------------------------
wget http://www.dest-unreach.org/socat/download/socat-2.0.0-b8.tar.gz 

tar xvf socat-2.0.0-b8.tar.gz 

cd socat-2.0.0-b8 

configure 

make 

make install

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

Una volta installato il programma si creano delle interfacce seriali virtuali

nohup socat pty,link=$HOME/tty0,raw,echo=0 pty,link=$HOME/tty1,raw,echo=0 &

(viene generato un messaggio ma non si tratta di un errore)
Si vedra' che in /home/root/ sono comparsi di due dispositivi tty0 e tty1

Adesso si puo' caricare su Arduino IDE lo sketch sottostante che di fatto usa una seriale virtuale che punta su /home/root/tty0
----------------------------------------------
RingBuffer rx_buffer_S1;
TTYUARTClass mySerial(&rx_buffer_S1, 3, false);

void setup() {
  mySerial.init_tty("/home/root/tty0");
  mySerial.begin(115200);
}

void loop()
{
  mySerial.write("luca");
  delay(500);
}
---------------------------------------------

Per leggere i dati inviati dal lato Arduino (in questo caso una semplice stringa) e' sufficiente puntare minicom (o altro terminale seriale) su /home/root/tty1 con i parametri 115200 8N1