Simboli su Rele'

Un piccolo promemoria (piu' che altro per mia memoria)
Un rele' ha almeno tre contatti : un Comune, un NA contatto normalmente aperto cioe' in assenza di eccitazione del rele' disconnesso dal rele' ed un NC contatto normalmente chiuso cioe' in connessione con il Comune in assenza di eccitazione.

IP Statico Ethernt per Intel Edison

Lo scenario e' quello di dover impostare una Intel Edison con Yocto su una rete con DHCP ma impostata con un IP Fisso

Per prima cosa, visto che il DHCP ha la priorita' sulle impostazioni statiche, si deve evitare di interrogare il DHCP Server editando il file /etc/systemd/network/enp0.network

-----------------------------------
[Match]
Name=enp0*
[Network]
DHCP=no
------------------------------------

subito dopo si puo' configure la scheda mediante Connection Manager
-----------------------------------------------------------------
#!/bin/sh
systemctl start connman
connmanctl enable ethernet
connmanctl disable wifi
-----------------------------------------------------------------

a questo punto con
connmanctl services si ottiene il nome della rete cablata- Il nome e' qualcosa del tipo
ethernet_MAC_ADDRESS_cable

a questo punto si continua con la configurazione

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

connmanctl config ethernet_001f5bff272e_cable --ipv4 manual 192.168.1.200 255.255.255.0 192.168.1.1

connmanctl config ethernet_001f5bff272e_cable --nameservers 8.8.8.8
connmanctl config ethernet_001f5bff272e_cable --timeservers 193.204.114.232

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

per vedere se la configurazioni sono andate a buon fine si puo' digitare ip a oppure editare il file /var/lib/connman/ethernet_001f5bff272e_cable# 

[ethernet_001f5bff272e_cable]

Name=Wired

AutoConnect=true

Modified=2016-08-13T13:41:18.789456Z

IPv4.method=manual

IPv4.DHCP.LastAddress=192.168.1.200

IPv6.method=auto

IPv6.privacy=disabled

IPv4.netmask_prefixlen=24

IPv4.local_address=192.168.1.200

IPv4.gateway=192.168.1.1

Nameservers=8.8.8.8;

Timeservers=193.204.114.232;   

C.H.I.P

ATTENZIONE: il segnale composito standard di CHIP e' NTSC. Si devono quindi usare televisori/monitor che supportino la doppia codifica o deve essere impostata manualmente la codifica PAL in UBoot (e' quindi necessario armarsi un cavo TTL-USB per connettersi alla porta seriale in fase di boot)
i pin Tx ed Rx sono vicini a GND sulla fila interna vicino alla porta microUsb (tra GND e FEL per essere piu' precisi

screen /dev/ttyUSB0 115220

quando si vedono i messaggi di Uboot si deve premre un tasto (non della tastiera attaccata al CHIP ma sulla consolle seriale) e si digitano i comandi

setenv video-mode sunxi:720x576-24@50,monitor=composite-pal,overscan_x=40,overscan_y=20
savenv

reset------------------------------------------------------------------------------------

E' passato un po' di tempo (circa 1 mese) da quando ho ricevuto per posta il mio primo tentativo di pledge su Kickstarter ovvero C.H.I.P. un microcomputer con 512 Mb di Ram, 4 Giga di storage, un processore da 1 Giga e la possibilita' di avere uscita video in HDMI, VGA o composito (non c'e' Ethernet ma solo Wifi integrato)

La prima cosa da fare per poter usare il modulo VGA e' quello di flashare il firmware con la versione 4.4 GUI che crea un desktop Debian.... e qui sono entrato nei guai

Per entrare in modalita' programmazione del firmware si deve cortocircuitare i pin GND e FEL (si trovano sulla fila interna del connettore vicino alla microUsb) per entrare in fastboot mode e subito dopo connettere la corrente

Per la riprogrammazione si deve usare necessariamente Chrome almeno alla versione 49 perche' il tutto avviene tramite un plugin del browser

Non e' proprio intuitivo ma qui si deve premere Start Flashing. Per comodita' e' meglio scarica il file immagine da qui cliccando sull'icona della nuova

Per usare il DIP Vga e' necessario utilizzare la versione del firmware 4.4 ma dopo un bel po' di tentativi su diversi sistemi operativi, con diversi cavi, con diversi alimentatori CHIP non dava segni di vita ne' su VGA ne' sul segnale composito ne' sulla porta seriale legata alla porta microsub

Giusto per provare ho montato la versione GUI 4.3 e finalmente sono riuscito a far partire il sistema, anche se solo con la qualita' del segnale composito

Se si connette il cavo USB con una Linux Box, nel mio caso una Centos, apparira' una porta seriale virtuale (nel mio caso /dev/ttyACM0) da cui si accede ad una shell
di default le credenziali sono

user : root
password : chip

Da qui in poi il sistema si comporta come una Debian quindi c'e' poco da dire..peraltro non avendo il DIP VGA montato rimangono scoperti i connettori GPIO per le prove

Il consumo del dispositivo ha un picco di 580 mA in boot ed un consumo di 200 mA in idle (questo ultimo valore differisce di molto da quelli di fabbrica che riporta valori piu' bassi di oltre la meta')

PS ho aperto un ticket vero l'assistenza di NextThing Co per vedere se riesco a far funzionare la VGA
(aggiornamento...il problema non e' il DIP ma il fatto che con il sistema 4.4 semplicemente il sistema non fa il boot.)

CHIP e' un po' esosa di corrente...quando l'alimentazione e' scarsa semplicemente si spenge. In generale il picco di consumo senza il DIP VGA e' di circa 300 mA con un valore di idle di 170 mA

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