ELM 327

Ho avuto modo di provare ELM327, un dispositivo WiFI o Bluetooth, che si collega CAN Bus delle automobili per avere informazioni in tempo reale sul funzionamento del motore

Versione Bluetooth e WiFi

La presa del sistema ODB (diagnostica di bordo) e' presente in tutte le macchine moderne (post 2000) e si trova in posizioni differenti. Nella Fiat Qubo si trova sotto al volante a sinistra nel quadro fusibili dopo avere rimosso un ampio coperchio

La presa OBD e' quella di colore giallo posta in verticale

Per raccogliere i dati esistono numerosi programmi per praticamente tutti i sistemi operativi, compresi smartphone. Sul CD in dotazione sono presenti diversi programmi fra cui Torque Pro per Android (che e' un programma a pagamento su Play Store)

Dovendo sviluppare una applicazione per interfacciare OBD ho pero' necessita' di capire come funziona nel dettaglio il dispositivo. Alcune interessanti informazioni si possono trovare a questo link

ELM327 in versione WiFi si presenta come un Access Point senza password e senza criptazione con DHCP. L'IP di default dell'ELM327 e' 192.168.0.10 e non e' possibile modificare (in modo semplice) l'SSID

ATTENZIONE: questa configurazione crea un paio di problemi

• se ci sono macchine vicine tutte con ELM327 ci sara' confusione perche' tutte si dichiarano con lo stesso SSID
• il telefono si collega all'access point dell'ELM327 e non si collega piu' ad Internet (su Android compare il segno della connessione con il punto esclamativo)

in conclusione puo' essere piu' comodo usare un modulo Bluetooth anche se il punto 1 non e' totalmente superato (diciamo che il raggio d'azione di BT e' inferiore a WiFi e cio' aiuta a non confondere le connessioni)

Effettuando una scansione con nmap si ottiene
-------------------------------------------------------------------------------
[root@localhost linnocenti]# nmap -sS 192.168.0.10

Starting Nmap 6.40 ( http://nmap.org ) at 2016-08-09 22:09 CEST
Nmap scan report for 192.168.0.10
Host is up (0.012s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:0E:C6:01:F7:B6 (Asix Electronics)

Nmap done: 1 IP address (1 host up) scanned in 23.68 seconds


Starting Nmap 6.40 ( http://nmap.org ) at 2016-08-09 22:18 CEST
Nmap scan report for 192.168.0.10
Host is up (0.0022s latency).
PORT      STATE SERVICE
35000/tcp open  unknown
MAC Address: 00:0E:C6:01:F7:B6 (Asix Electronics)

[root@localhost linnocenti]# nmap -sU 192.168.0.10

Starting Nmap 6.40 ( http://nmap.org ) at 2016-08-09 22:20 CEST
Nmap scan report for 192.168.0.10
Host is up (0.0015s latency).
Not shown: 998 closed ports
PORT      STATE         SERVICE
67/udp    open|filtered dhcps
49153/udp open|filtered unknown
MAC Address: 00:0E:C6:01:F7:B6 (Asix Electronics)

Nmap done: 1 IP address (1 host up) scanned in 65.55 seconds

[root@localhost linnocenti]# nmap -sO 192.168.0.10

Starting Nmap 6.40 ( http://nmap.org ) at 2016-08-09 22:22 CEST
Nmap scan report for 192.168.0.10
Host is up (0.053s latency).
Not shown: 253 closed protocols
PROTOCOL STATE SERVICE
1        open  icmp
6        open  tcp
17       open  udp
MAC Address: 00:0E:C6:01:F7:B6 (Asix Electronics)

Nmap done: 1 IP address (1 host up) scanned in 18.47 seconds
-----------------------------------------------------
Il sistema si presenta come una ASIX Electronics (in particolare e' un AX220XX, un dispositivo che fa da ponte tra una RS232, ovvero il sistema ODB, ed il WiFi

Sul UDP sono aperti i servizi DHCP ed un servizio sconosciuto su porta 49153 (questa porta sembra che sia necessaria per connettere l'interfaccia AX200 RS3232-to-WiFi al vero e proprio modulo WiFi  in ascolto su 25125/TCP...non e' possibile programmare il modulo WiFi se non dissaldondolo e connettendosi in seriale TTL con la caratteristica modalita' Null Modem..quindi con collegamento Tx-Tx, Rx-Rx vedi questo documento a pagina 8)

Su TCP viene scoperto un servizio HTTP su porta 80. Connettendosi si ottiene in riposta una pagina index..html vuota
Il dispositivo risponde anche al Ping

Non viene mostrata (e non ne capisco il motivo la porta 35000/TCP) che e' quella dove effettivamente e' presente il server che fornisce i dati

si puo' telnettare su porta 35000 e mediante comandi AT si possono ottenere le informazioni desiderate
per semplicita' ho provato ad interrogare il numero di giri motore che si ottengono inviando il comando 010C

(anche in questo caso niente password...meno male che con OBD non si possono modificare i parametri del motore .....)
-----------------------------------------------------
[root@localhost linnocenti]# telnet 192.168.0.10 35000
Trying 192.168.0.10...
Connected to 192.168.0.10.
Escape character is '^]'.
>010c
>10C13F0
-----------------------------------------------------
La risposta non e' quella attesa (vedi questo link), mi sa qualche casino sulla codifica dei caratteri,  che doveva essere qualcosa del tipo

>010C
SEARCHING: OK
41 0C 0F A0

in ogni caso si puo' pensare che gli rpm siano 13F0 che tradotti indicano in decimale 5104 questo numero deve essere diviso per 4 per un valore di 1276 rpm
a motore spento il numero di giri e' ovviamento 0

>10C0000

Per Bluetooth il discorso e' piu' o meno il solito. Ci si connette con il servizio della seriale virtuale Bluetooth con il pin 1234 con baud rate 38400 8N1
un po' piu' nel dettaglio..per prima cosa ho dovuto sbloccare il soft block sul bluetooth della Linux Box

[root@localhost linnocenti]# rfkill list
0: tpacpi_wwan_sw: Wireless WAN
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
3: hci0: Bluetooth
Soft blocked: yes
Hard blocked: no

[root@localhost linnocenti]# rfkill unblock 3

[root@localhost linnocenti]# rfkill list

0: tpacpi_wwan_sw: Wireless WAN

Soft blocked: no

Hard blocked: no

1: phy0: Wireless LAN

Soft blocked: no

Hard blocked: no

3: hci0: Bluetooth

Soft blocked: no

Hard blocked: no

a questo punto si scansiona per cercare l'ELM 327
hcitool scan

Scanning ...
00:1D:A5:68:98:8C OBDII

avendo l'ID BT si puo' interrogare il dispositivo per vedere che servizi espone

sdptool browse  00:1D:A5:68:98:8C

Browsing 00:1D:A5:68:98:8C ...
Service Name: SPP
Service RecHandle: 0x10001
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1

viene mostrata la porta seriale virtuale BT che e' quella su cui passano i dati RFCOMM

ATTENZIONE : il dispositivo non si spenge quando viene tolto il collegamento dalla chiave della macchina e quindi viene consumata la batteria anche a macchina ferma.

Crontab su Intel Edison/Yocto

Curiosamente sull'immagine standard di Yocto di Intel Edison non e' installato il server di cron.

opkg update
opkg install cronie

Un piccolo riassunto per mia memoria della sintassi di crontab
ogni minuto
* * * * * /path/to/script

ogni 5 minuti

*/5 * * * * /path/to/script

ogni minuto pari

*/2 * * * * /path/to/script

ogni minuto dispari

1-59/2 * * * * /path/to/script

ogni 24 ore (a mezzanotte)0 0 * * * /path/to/script

Reverse SSH su Intel Edison

Il tunnel reverse SSH e' un metodo estremamente comodo per amministrare macchine su reti private senza necessariamente installare una VPN e senza dover cambiare le configurazioni dei firewall (questo perche' la connessione viene iniziata dall'interno della rete privata, regola generalmente accettata e non filtrata dai firewall su un protocollo SSH che viene spesso lasciato non filtrato)

Le condizioni necessarie sono
1) una macchina deve essere disponibile con indirizzo pubblico
2) le due macchine devono poter instaurare una connessione SSH

diciamo di avere una macchina A su indirizzo pubblico del tipo 150.217.xxx.xxx ed una chiamata B (una Intel Edison per esempio) su una rete privata con indirizzo del tipo 192.168.1.10. L'obbiettivo e' di amministrare la macchina B da A mediante una shell SSH

Per prima cosa si deve procedere allo scambio delle chiavi in modo da rendere l'autenticazione automatica (cio' aiuta nel caso in cui la connessione cada per creare uno script per riattivarla in modo automatico o per iniziare il reverse tunnel al boot)

Macchina B
con il comando
ssh-keygen 

si creano una coppia di chiave pubblica e privata per la macchina B.
Su Intel Edison non e' disponibile ssh-agent quindi e' piu' comodo NON utilizzare una passphrase 

a questo punto si copia la chiave pubblica sulla macchina A mediante

scp -P 22 ~/.ssh/id_rsa.pub root@150.217.xxx.xxx:~/.ssh/authorized_keys
per comodita' l'utente della Intel Edison e quello della macchina remota sono identici e sono root (lo so, non si fa....e' solo per semplicita')

da questo punto ci si dovrebbe loggare da B (Edison) al server esterno con il solo comando

ssh root@150.217.xxx.xxx
se tutto va bene si puo' procedere a creare il tunnel inverso

dalla macchina B si digita il comando

ssh -R 19999:localhost:22 root@150.217.xxx.xxx

a questo punto la connessione e' stabilita. Per amministrare la macchina B dalla macchina A si digita

ssh localhost -p 19999

e si entra nella shell di B

A questo punto non e' ancora finita perche' bisogna assicurarsi che la macchina B chiami A ad ogni riavvio (per esempio per mancanza di corrente)
Per fare cio' si deve creare la directory

mkdir /etc/init.d

copiare il file script che avvia il reverse tunnel e renderlo eseguibile
a questo punto si digita

update-rc.d script.sh defaults

sembra finito ma non e' cosi' perche' se la connessione non viene usata (ovvero non passano pacchetti lungo il tunnel) il collegamento viene resettato dopo un timeout. Non volendo modificare le impostazioni del server la soluzione piu' semplice e' usare autossh

L'installazione non e' banale perche' non e' disponibile il pacchetto opkg

wget http://www.harding.motd.ca/autossh/autossh-1.4e.tgz 

gunzip -c autossh-1.4e.tgz > autossh.tar  

tar xvf autossh.tar 

cd autossh-1.4e 

./configure 

make 

make install

si sostituisce il comando precedente con autossh

autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -L 19999:localhost:22 root@150.217.xxx.xxx 

un altro sistema e' quello di usare la sintassi
autossh -i /home/root/.ssh/id_rsa. -M 20002 -N -R 20000:localhost:22 root@150.217.73.18 &

Fauna caldinese

Nel Mugnone non c'e' acqua cosi' sono andato a fare un giro alla COOP

NTPDATE su Intel Edison

Intel Edison non ha un RTC con batteria tampone, per cui e' necessario ricavare l'ora esatta contattando un servizio NTP.

Si parte installando il comando ntpdate con
opkg update
opkg ntpdate

se e' stato montato cron il servizio sara' aggiornato automaticamente per fare una richiesta NTP ogni 30 minuti (per verificare crontab -e) dovrebbe esserci una riga del tipo

30 * * *  * /usr/bin/ntpdate-sync client

per configurare il server a cui deve essere fatta la richiesta si va in /etc/default/ntpdate e si edita NTPSERVERS. Per l'Italia un servizio di uso comune puo' essere ntp1.inrim.it

Proxy settings ed OPKG su Intel Edison

Per poter effettuare gli aggiornamenti di Intel Edison all'interno di una rete proxata si deve configurare  il file /etc/opkg/opkg.conf modificando le option

Per motivi che non ho ben definito ho dovuto inserire l'indirizzo numerico del proxy perche' il DNS non riusciva a risolvere l'indirizzo mnemonico (il DNS funzionava correttamente su altre macchine della stessa rete)

GMail Notifier con Yun ed Edison

Per verificare se vi sono messaggi non letti in una casella postale di GMail non e' necessario utilizzare l'accesso POP3 od IMAP. Esiste infatti un servizio Atom che riporta tale informazione

Per fare cio' si usa la url
https://mail.google.com/mail/feed/atom/label

ma prima di fare cio' si deve andare nella configurazione della propria mailbox e configurare almeno una label e poi associare un filtro ad una determinata label

per esempio si puo' creare una label Lavoro e poi creare un filtro che in base ad un indirizzo mail associa l'etichetta Lavoro.

per recuperare il numero delle mail arrivate con la label Lavoro E NON APERTE si puo' usare il comando dove username e' la mail privata di @gmail.com e la password  e' quella dell'account

curl -u username:password "https://mail.google.com/mail/feed/atom/Lavoro" -k --silent |grep -o "<fullcount>[0-9]*</fullcount>" |grep -o "[0-9]*"

se si lancia il comanda si ha un errore di violazione. Questo perche' gli account di GMail sono particolarmente protetti. Per fare si' che il comando abbia buon fine si deve andare nel proprio account e cercare Consenti app meno sicure e settare On

Fatto cio' si puo' creare uno script che se il numero delle mail non lette con una determinata label e' maggiore di zero effettua una azione, diciamo azionare un rele' collegato al pin D12 a sua volta collegato per esempio ad una sirena o ad una luce a 12 V

YUN
In YUN si procede caricando lo script bash e poi, dall'interfaccia web, si abilita l'accesso REST senza password (OPEN)

Si carica quindi lo sketch Bridge dagli esempi e si lancia lo script sottostante

------------------------------
gmail=$(curl -u username:password "https://mail.google.com/mail/feed/atom/Lavoro" -k --silent |grep -o "<fullcount>[0-9]*</fullcount>" |grep -o "[0-9]*")
#echo $gmail
if [ "$gmail" -gt "0" ]; then
        then curl http://localhost/arduino/digital/12/1;
else
        then curl http://localhost/arduino/digital/12/0;
fi
------------------------------

Edison 
------------------------------
advertence=$(curl -u username:password "https://mail.google.com/mail/feed/atom/Lavoro" -k --silent |grep -o "<fullcount>[0-9]*</fullcount>" |grep -o "[0-9]*")
echo $advertence

if [ "$advertence" -gt "0" ]; then
        ./accendi.py
else
    ./spegni.py
fi
------------------------------

accendi.py
------------------------------
#!/usr/bin/env python

import mraa

x = mraa.Gpio(12)
x.dir(mraa.DIR_OUT)
x.write(1)
------------------------------

spegni.py
------------------------------
#!/usr/bin/env python

import mraa

x = mraa.Gpio(12)
x.dir(mraa.DIR_OUT)
x.write(0)
------------------------------

Arduino Sleep Mode

La possibilita' di "addormentare" il microcontrollore di Arduino e' documentata da anni con la possibilita' di avere 5 livelli di risparmio energetico ed essere risvegliata mediante interrupt.

Esiste una soluzione piu' lineare che e' quella di usare le JeeLib con la funzione Sleepy::loseSomeTime che corrisponde ad una funzione delay con il sistema in sonno profondo che si risveglia senza la necessita' di un interrupt esplicitp

in modo molto semplice lo sketch base e'
----------------------------

#include <JeeLib.h>

ISR(WDT_vect) { Sleepy::watchdogEvent(); }

void setup() {

}
 
void loop() {

  // fai qualcosa
  Sleepy::loseSomeTime(5000);    
}

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

L'unica accortezza con questa funzione e' il parametro e' in millisecondi ed il suo formato e' una word per cui al massimo si puo' arrivare a 65535 (ovvero circa 65 secondi). Per effettuare ritardi piu' lunghi si deve inserire la funzione in un ciclo del tipo

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

unsigned int minuti = 60;  //ritardo in minuti

for (byte i = 0; i < minuti; ++i)

 Sleepy::loseSomeTime(60000); //60.000 microsecondi = 1 minuto 

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

Visto che in fase di sleep e' disabilitato il clock dall'oscillatore al quarzo, il calcolo del tempo risulta non accurato (un utente riporta che loseSomeTime(60000) termina dopo 59 secondi)

Non sono riuscito a fare misure dirette (il mio misuratore Volt/Amp si ferma alla decina di mA) ma sembra che in fase di sleep il consumo del microcontrollore sia inferiore di circa un fattore 10 per scendere a qualche microA

Fauna Caldinese

Datalogger obsoleto

Mi sono stati regalati alcuni componenti elettronici tirati fuori da un armadio senza una precisa indicazione del loro utlizzo

Ad un esame attento degli integrati probabilmente si tratta di un datalogger. Sono presenti delle schede removibili al cui interno degli integrati M27128AF1, una UV EPROM (notare la finestrella scoperta) da 128 Kb per un totale di 4 moduli con un totale  512 Kb.

L'altra scheda e' ad occhio una vecchia ISA Full Size. Si notano un componente DM74LS38 (4 porte indipendenti di NAND), un P8255A-5 un integrato programmabile della Intel per funzione di IO per interfacciare un computer e un SN54LS245 ed un P8259A per la gestione programmabile degli interrupt

Trova le differenze

1984 - Commodore 64

1995?? - Olivetti M24

2016 - Sala macchine

Debian 8 su PowerBook G4 Titanium

Con questo post si rientra alle origini del blog ovvero installare Debian su macchina obsolete
In questo caso c'e un dubbio. Ha una mela sullo schermo ma e' un Apple PowerBook od un PC piuttosto bruttino e molto standard ????
Si tratta di un modello particolarmente esotico (su Ebay al momento non sono presenti in vendita esemplari funzionanti) ovvero di un A1025 PowerBook G4 Titanium, un pezzo di storia risalente al 2002 nel periodo di passaggio da OS 9 a OS X

La macchina era destinata alla distruzione ed era priva dell'Hd (il precedente possessore si e' sincerata di rimuovere tutti i suoi dati)..fortunatamente ha lasciato pero' il flat cable per il montaggio dell'HD . Ha montati 256 MB di Ram (standard dell'epoca)

Scheda madre con il nuovo HD da 40 Gb

Accesso alla Ram sotto la tastiera

Le porte sono tutte nascoste da uno scomodissimo sportellino sul retro del computer

L'installazione di Debian 8 per PowerPC (non ci sono repository PowerPC su Debian.it quindi bisogna puntare su Debian.org) non ha mostrato nessun problema...la mancanza di Ram mette un po' in crisi XFCE ma con un po' di tuning si tratta di macchina ancora usabile

Servo Shield per Arduino

Avevo gia' provato ad usare i servo sia in modo diretto che tramite una scheda apposita. Questa volta devo realizzare un movimento PTZ per una webcam

Questa e' la volta dell'Adafruit Servo Shield (o meglio di un suo clone cinese)
La scheda, che funziona sul I2C, riesce a pilotare 16 canali da 0 a 15 a ciascuno dei quali corrisponde un servo

Arduino non eroga abbastanza tensione per cui e' necessario connettere una alimentazione esterna allo shield. Nel mio caso ho usato un modulo MB102 da breadboard collegato ad alimentatore da 2 A/12 V per pilotare due servo. Puo' essere anche necessario inserire un condensatore

Questa e' la pedinatura con il cavo giallo (dati) verso l'interno della scheda ed il cavo marrone (GND) sull'esterno)

Fatte le connessioni si deve scaricare la librerie apposita da Adafruit
Quiesto e' lo sketch che ho usato..si devono definire i valori minimi e massimi di rotazione (da riccercare per tentativi)

----------------------------------------------------
#include <Wire.h>
#include <Adafruit_PWMServoDriver.h>

Adafruit_PWMServoDriver pwm = Adafruit_PWMServoDriver(0x40);

#define SERVOMIN  200
#define SERVOMAX  400

void setup() {
  pwm.begin();
  pwm.setPWMFreq(60);  // Analog servos run at ~60 Hz updates
  yield();
}


void loop() {
  for (uint16_t pulselen1 = SERVOMIN; pulselen1 < SERVOMAX; pulselen1++) {
         pwm.setPWM(1, 0, pulselen1);
         delay(20);



        for (uint16_t pulselen = SERVOMIN; pulselen < SERVOMAX; pulselen++) {
              pwm.setPWM(0, 0, pulselen);
              delay(20);
              }
        delay(500);
        for (uint16_t pulselen = SERVOMAX; pulselen > SERVOMIN; pulselen--) {
              pwm.setPWM(0, 0, pulselen);
              delay(20);
              }
         delay(500);
  }

  for (uint16_t pulselen1 = SERVOMAX; pulselen1 > SERVOMIN; pulselen1--) {
         pwm.setPWM(1, 0, pulselen1);
         delay(20);



        for (uint16_t pulselen = SERVOMIN; pulselen < SERVOMAX; pulselen++) {
              pwm.setPWM(0, 0, pulselen);
              delay(20);
              }
        delay(500);
        for (uint16_t pulselen = SERVOMAX; pulselen > SERVOMIN; pulselen--) {
              pwm.setPWM(0, 0, pulselen);
              delay(20);
              }
         delay(500);
  }

}
----------------------------------------------------

Raggi cosmici e Android

Avevo sentito della possibilita' di usare il CCD della fotocamera dei comuni telefoni per individuare i raggi cosmici (o meglio i muoni che sono l'effetto dell'interazione del raggio cosmico con l'atmosfera.. quando un muone colpisce un CCD libera degli elettroni che sono misurabili dall'elettronica della fotocamera..per una descrizione piu' dettagliata si veda questo documento)

Questo effetto e' particolarmente visibile nelle fotografie riprese sulla stazione spaziole (i pixel, nella foto sottostante,  bruciati dal passaggio di raggio cosmico sono indicati dal cerchietto rosso).

Per vedere se riuscivo a catturare qualche evento ho usato l'applicazione DECO dell'Universita' del Winsconsin. Si tratta di un sistema di rilevazione distribuito che invia i dati ad un server centrale per discriminare i veri eventi dai falsi positivi

Il problema principale e' che il CCD, ovvero la sua matrice di sensori (ovvero i pixel), non sono tra loro calibrati e si deve quindi estrapolare dal rumore di fondo un eventuale evento.

Nonostante le bassa probabilita' di registrare un evento ho ottenuto nel giro di poche ore 6 eventi su  7770 osservazioni. O sono fortunato o c'e' qualcosa da capire.
Scaricando i dati dal sito a questo indirizzo queste sono le immagini relative ai miei eventi

Dati originali

Rielaborazione 

Rimettendo in ordine i dati all'interno di una GIF animata si vede chiaramente che alcuni punti a luminanza maggiori compaiono su diversi fotogrammi

Se si cerchiano di verde i pixel ad alta luminanza e si sottraggono dalle immagini delle acquisizioni reali si nota che, quelli indicati come eventi in realta' non sarebbero nient'altro che pixel fuori calibrazione all'interno della matrice dato che si trovano nella stessa posizione ed hanno una posizione reciproca uguale (e' altamente improbabile che un evento si ripeta nella stessa posizione della matrice nell'arco di un cosi' poco tempo, circa 3 ore di osservazione)

Visto che ho la fortuna di lavorare con colleghi che manipolano sostanze blandamente radioattive ed ho esposto il sensore della macchina fotografica ad un campione test di Cs137 in modo da forzare l'eccitazione dei pixel del CCD.

In questo modo, dal rumore di fondo, ogni tanto compaiono dei pixel piu' luminosi

Ancora una volta mettendo in fila le immagini si vede che il pixel piu' luminoso e' sempre il solito.

Non si tratta quindi dell'eccitazione derivante dal passaggio di una particella o radiazione ma di un errore del sensore della camera

In conclusione esperimento non riuscito
Per la cronaca ho provato a contattare gli sviluppatori di DECO sia sulla mailing list di Google che alla mail di riferimento ma non ho ottenuto risposta da circa 7 giorni. Peraltro le mie sono state le uniche registrate per 5 giorni consecutivi... non so quanto il progetto sia ancora attivo

Intel Compute Stick ed Ubuntu

Ho preso su Ebay per un cinquantina di euro (arrivato nuovo ed impacchettato.. il prezzo su Ebay e' di 136 euro)  e' di un Intel Compute Stick, piu' nel dettaglio il modello BOXSTCK1A32WFC con incluso un processore Atom con 2 Gb Ram, 32 Gb di disco e sistema operativo Windows 10...ne esiste anche una  versione con premontato Ubuntu ma costa circa uguale e monta solo 1 Gb Ram e 8Gb di disco

Primi dettagli: per usare l'adattore HDMI2VGA ho dovuto comprare un connettore HDMI femmina-femmina

Il modulo non e' proprio parco nei consumi. In fase di boot arriva anche a 1.2 A

Un altro problema e' che il Intel Compute Stick monta una sola USB 2 da 500 mA. Se si monta un Hub USB passivo e si collegamento mouse stampante e network dongle non si riesce ad alimentare il tutto...me ne sono accorto perche' il led sotto il mouse era spento. La soluzione e' quella di usare una HUB alimentato o tastiera e mouse Logitech con Universal Receiver oppure tutto bluetooth (in questo caso pero' non si riesce ad entrare nel BIOS)

Per Compute Stick esiste una apposita distribuzione Linuxium ma ho voluto comunque provare con una Ubuntu 16.04 64 bit standard per vedere come andava.
Per avviare il boot da BIOS si deve selezionare l'apposita opzione (vedi immagine sottostante) Configuration/Select Operating System

Visto che non volevo compromettere l'installazione di Windows 10 ho inserito una SD Card da 16 Gb ed ho installato il sistema con le impostazioni dello screenshot sottostante (la SD Card non e' cosi' lenta nell'uso)

Il sistema si e' installato e riavviato senza problemi tranne il fatto che GRUB, pur presentando l'opzione Windows non riusciva ad avviarlo (leggendo sembra che sia un problema legato a 32/64 bit)
Ubuntu 16.04 funziona bene tranne per il fatto che mancano i moduli per gestire la scheda WiFi e Bluetooth di Compute Stick. Una volta scoperto che il chip interno e' un Realtek 8723bs e' facile trovare i moduli da scaricare e compilare

Wifi
Bluetooth


Cercando di risolvere il problema di Grub e non volendo usare una soluzione preconfenzionata ho provato ad usare Ubuntu 16.04 da questo link ma Grub ha presentato sempre i soliti problemi

DXL335 con Arduino FIO

Un semplice progettino per un accelerometro accoppiato a XBee.
Per questa configurazione e' stata scelta una Arduino Fio, purtroppo oramai fuori produzione, una scheda che monta il microcontrollore di Arduino Leonardo accoppiato ad un socket Xbee con un connettore JST per una batteria LiPo e la predisposizione per il pannello solare

Il modulo Xbee non e' presente nella foto per far vedere il socket. il cavo blu in origine era tra DTS di Xbee e D10 per mandare il sleep mode il modulo di trasmissione)

La Arduino FIO si programma tramite FTDI Breakout (i pin devono essere saldati a mano).
L'ADXL e' stato brutalmente saldato ai pin A5, A6 ed A7 per i canali rispettivamente Z,Y ed X mentre per l'alimentazione ho fatto un paio di patch

Come si deve dal confronto con la moneta da due euro la dimesione totale del progetto e' estremamente ridotta (la batteria LiPo e' da 1400 mAh)


Lo sketch e' molto semplice e si limita ad effettuare una lettura analogica su ogni asse (per la conversione in accelerazione si veda questo precedente post) e mandare la lettura sulla porta seriale che e' direttamente collegata, senza modificare niente al modulo XBEE
------------------------------------------------------
void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.print(analogRead(A7));
  Serial.print("\t");
  Serial.print(analogRead(A6));
  Serial.print("\t");
  Serial.print(analogRead(A5));
  Serial.println();
  delay(100);
}

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 &
----------------------------