TL;DR;
Riassunto: roba da nerd su centraline, CAN-bus, Arduino e applicazioni per la telemetria. Se siete ancora qui, continuate pure a leggere
Ciao a tutti, condivido con voi un piccolo progetto "fai da te" che sto portando avanti. Da qualche anno quando vado in pista uso RaceChrono, un'applicazione "lap timer", che prende i tempi sul giro usando riferimenti GPS. Questa applicazione può anche ricevere dati dalle varie centraline dell'auto, ed è poi possibile usare questi dati in sovraimpressione su un video per fare analisi e migliorare i propri tempi ecc ecc.
La maggior parte delle app simili usa i dati ottenuti tramite il protocollo diagnostico OBD-2 o OBD-II. Questo protocollo funziona a domanda e risposta: l'applicazione, tramite un apposito adattatore, chiede di ottenere un dato e la centralina, quando ha tempo, risponde. Ovviamente questo protocollo non è pensato per fornire in modo affidabile dati ad alta velocità.
Fortunatamente dalla versione 6 di RaceChrono è possibile leggere direttamente i dati che viaggiano sul CAN-bus, ovvero il network che collega tutte le centraline sull'auto.
Su questo network passano moltissime informazioni, tutte quelle che le varie centraline della vettura si scambiano per garantire il corretto funzionamento dell'auto. Ad esempio i segnali relativi alla pressione del pedale del freno, per l'ABS, dell'angolo di sterzo, della posizione dell'acceleratore, le accelerazioni dalla piattaforma inerziale per l'ESP ecc ecc.
A differenza di OBD-2 non c'è bisogno di interrogare e aspettare una risposta, i dati viaggiano sempre a cadenze assegnate, fino anche a 100 aggiornamenti al secondo. Purtroppo, a differenza del protocollo OBD-2 che è molto ben documentato, come interpretare quello che viaggia su CAN-bus è noto praticamente solo al costruttore e a chi compra le tabelle con i "Data Length Code". Non solo, una volta capito cosa contiene il messaggio, bisogna anche trovare una funzione di trasferimento, un'equazione, che trasformi il dato digitale in una misura leggibile.
Per questo motivo si rende necessario un "reverse engineering" per capire a cosa corrispondono i messaggi acquisiti.
In questa guida, in inglese, spiego come ho fatto ad ottenere una serie di associazioni tra messaggi sul CAN-bus e dati misurati, utilizzando un Raspberry Pi e una scheda di acquisizione CAN.
Questa procedura vale per qualunque auto dotata di CAN-bus e presa OBD, ed è totalmente sicura perché si limita a leggere dati, non manda nessun segnale. Se avete tempo e voglia provate anche voi, potrebbe essere interessante avere un database di "ID" per diverse vetture.
Su OpenGarage c'è già qualcosa di simile: http://opengarages.org/index.php/Raw_link_references_for_CAN_IDs ma è molto limitato e, ad esempio, gli ID trovati per Mazda vanno bene per la 3 ma non per MX-5.
Ad esempio @superkappa125 potresti provare sullo sfilatino, che centralina monta? Magari è simile a MX-5, o magari è simile a qualcosa per Ford. @8coibaf potresti tirar fuori gli ID per la 124, che poi immagino saranno molto simili ad alre auto Abarth.
Le associazioni ottenute le ho raccolte in questo file: https://github.com/jeby/RaceChronoDiyBleDevice/blob/master/can_db/mazda_mx5_nc.md
In cui ho anche specificato l'equazione da inserire in RaceChrono per ottenere un dato leggibile.
Tutto questo lavoro per cosa? Per costruire un dispositivo, basato su Arduino, che una volta connesso alla porta OBD dell'auto mandi i segnali CAN-bus tramite BLE allo smartphone, grazie alle API messe a disposizione dallo sviluppatore di RaceChrono.
Le istruzioni per costruire il dispositivo e il codice per farlo funzionare sono un fork personalizzato di un progetto analogo fatto per funzionare su BRZ/GT86, modificato per funzionare su Mazda MX5 di terza generazione.
Anche qui: è tutto molto sicuro, il codice si limita a leggere e inviare la lettura. L'unico problema è che per ora non è implementato il pairing, quindi chiunque a portata potrebbe leggere i segnali sul CAN-bus (leggere, ma non scrivere!)
Alternativamente RaceChrono può leggere il CAN-bus anche da dispositivi a marchio OBDLink compatibili, come OBDLink LX, MX e MX+, ma attualmente c'è un bug che impedisce di leggere gli ID sotto al 100. Il bug è già stato risolto nella 7.2 beta per Android, la cui release finale è attesa per quest'anno.
Il dispositivo Arduino comunica via BLE ed è quindi limitato nel numero di ID che invia, per ora a 6 ID, ma raggiunge frequenze di aggiornamento molto elevate, fino a 50 messaggi / secondo per alcuni canali, considerate che sul CAN-bus le frequenze massime sono intorno ai 100 messaggi / secondo su alcuni ID.
A livello di costi, se avete pazienza, se la dogana non fa storie, e se avete già saldatore a stagno e cavetteria varia, il dispositivo Arduino verrà a costare circa la metà del meno costoso tra gli OBDLink, quindi circa 25€
Ho già testato in strada e funziona tutto in maniera impeccabile, sto ancora cercando di tirare fuori informazioni dall'ID 090 che credo contenga informazioni provenienti dalla piattaforma inerziale, ma non riesco a trovare una funzione di trasferimento che rappresenti il dato. Attendo di poter andare di nuovo in pista per acquisire dati più vicini ai massimi delle accelerazioni leggibili (in strada 1 g me lo scordo)