Approfondimenti Tecnici

In tutti i libri e in tutte le guide lette sulla User eXperience, non ho mai trovato degli esempi reali sui quali venivano applicate tutte le regole lette per una buona esperienza utente, nè tantomeno un confronto. Con l’intento di approfondire l’argomento in questione, assieme al mio collega Luca (con cui è nata l’idea per questo laboratorio) abbiamo deciso di vedere come gli “esperti” rendono le proprie applicazioni così valide :) Abbiamo così scelto un’applicazione sulla quale è stato fatto un apposito studio per la UX: Foursquare !

Per rendere il nostro laboratorio ancora più interessante e approfondito, abbiamo scelto di effettuare il nostro studio su due piattaforme diverse: Android e Windows Phone 7. I due sistemi operativi hanno già di per se una User Interface ed una personalità d’uso completamente differente l’un l’altro, quindi anche le applicazioni differiranno molto fra di loro.

In questo post parleremo della porta OBD-II elemento chiave nel nostro progetto Aurora.

Un po' di storia

(tratto da wikipedia)
L'OBD-II è uno standard definito negli Stati Uniti a metà degli anni novanta che permette di avere un controllo completo sui parametri del motore e monitorare altre parti di un autoveicolo come il telaio e gli accessori; inoltre permette di connettersi al sistema di diagnostica. OBD-II è stato emanato dal California Air Resources Board. L'OBD-II è soprattutto un'interfaccia a sola lettura per acquisire segnali di diagnostica. Lo standard OBD-II definisce inoltre alcuni comandi per il controllo dell'output, per le modalità di autocontrollo e per l'azzeramento della memoria KAM (Keep Alive Memory). [...] Prima dell'autodiagnosi, erano i meccanici che dovevano fare una diagnosi dei guasti, mentre ora è le centralina stessa di bordo che si autocontrolla e verifica lo stato del mezzo. I sistemi OBD forniscono al proprietario del veicolo o ad un meccanico accesso alle informazioni sullo "stato di salute" dei vari sottosistemi del veicolo: la normativa standard (in Europa e Stati Uniti) è riferita però solo ai sottosistemi "emission relevant", cioè quelli che, se rotti, possono portare ad un aumento delle emissioni, come catalizzatore, sonda lambda ecc., mentre gli altri sistemi (es. airbag, climatizzatore ecc.) hanno un'autodiagnosi non standard, definita a piacimento da ogni costruttore automobilistico. [...] La quantità di informazioni diagnostiche disponibili via OBD è cambiata molto dall'introduzione, nei primi anni ottanta dei computer di bordo negli autoveicoli (centraline) che hanno reso possibile l'OBD. Le prime implementazioni di OBD accendevano semplicemente una lampadina spia nel caso di problemi, ma non fornivano alcuna informazione ulteriore relativa alla natura del problema. Le moderne implementazioni di OBD utilizzano una porta di comunicazione digitale per fornire informazioni in tempo reale in aggiunta a una segnalazione della natura dei problemi tramite codici standard (DTC) "Diagnostic Trouble Codes" che permettono di identificare rapidamente e risolvere malfunzionamenti del veicolo.

Oggi parleremo del protocollo I²c , fondamentale per il nostro progetto. Come anticipato  negli scorsi post, il protocollo serve a far colloquiare due o più dispositivi tramite un bus. In dettaglio prendiamo la citazione da Wikipedia:
"I²C, acronimo di Inter Integrated Circuit (pronuncia i-quadro-ci o i-due-ci), un sistema di comunicazione seriale bifilare utilizzato tra circuiti integrati [...]  classico bus I²C è composto da almeno un master ed uno slave (letteralmente "capo, padrone" e "sottoposto, schiavo")."
Nel nostro caso ci servirà a far colloquiare l'Arduino adibito per prendere informazioni dalla centralina tramite porta OBD-II e il nostro Aurora perchè (come specificato nel primo post del progetto), il micro controllore che stiamo utilizzando (Arduino UNO) supporta solo una seriale. Per testare il collegamento e rilevarne la velocità ho costruito un piccolo circuito.