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)

Appena ho un po' di tempo vedo di replicare il tuo stesso lavoro cercando anche di far funzionare correttamente la IMU ( cosa che tra l'altro devo far funzionare pure per la centralina controllo sospensioni per lavoro😅).

41 minuti fa, 8coibaf scrive:

Appena ho un po' di tempo vedo di replicare il tuo stesso lavoro cercando anche di far funzionare correttamente la IMU ( cosa che tra l'altro devo far funzionare pure per la centralina controllo sospensioni per lavoro😅).

Ci sto perdendo il sonno 🤣 so che è lì!

1 ora fa, jeby scrive:

Ci sto perdendo il sonno 

 

In pratica la telemetria, fino a dove tira il bluethoot?

Potresti farti seguire da qualche "Stratega" che sta al "Muretto"

 

Ad oggi cosa leggi?

- % apertura farfalla

- schiacciamento freno

- angolo di sterzo

- temperatura aria ingresso farfalla

- temperatura acqua

- temperatura olio

 

che altro?

45 minuti fa, TurboGimmo scrive:

In pratica la telemetria, fino a dove tira il bluethoot?

Potresti farti seguire da qualche "Stratega" che sta al "Muretto"

 

 

Yes, ma non so quanto possa funzionare in auto in movimento... il BLE in queste condizioni tira poco, una decina di metri scarsa, lo sviluppatore di RaceChrono sta lavorando per implementare qualcosa basato su streaming via rete per chi lo volesse usare veramente.

45 minuti fa, TurboGimmo scrive:

In pratica la telemetria, fino a dove tira il bluethoot?

Potresti farti seguire da qualche "Stratega" che sta al "Muretto"

 

Ad oggi cosa leggi?

- % apertura farfalla

- schiacciamento freno

- angolo di sterzo

- temperatura aria ingresso farfalla

- temperatura acqua

- temperatura olio

 

che altro?

 

Angolo di sterzo

Pressione freno e switch del pedale

% apertura farfalla (assoluta e relativa)

% pressione acceleratore

giri motore

velocità auto

velocità delle singole ruote 

Switch frizione e credo switch di marcia inserita (non il numero di marcia, solo se sei in folle o no)

Carico calcolato

Temperatura acqua

Temperatura aria

Angolo di accensione

 

Poi come dicevo ci sono i dati della piattaforma inerziale ma non riesco a correlarli

 

 

quanto è il ritardo delle varie app di lettura?

 

perchè ho idea che sia infinitesimo , o almeno infinitesimo rispetto ai riflessi umani di lettura

12 minuti fa, skid32 scrive:

quanto è il ritardo delle varie app di lettura?

 

perchè ho idea che sia infinitesimo , o almeno infinitesimo rispetto ai riflessi umani di lettura

 

L'app in questione,  RaceChrono, non è fatta per visualizzare i dati in tempo reale... o meglio, può farlo ma non dà più informazioni del quadro strumenti della vettura. E' ottima per prendere i tempi e per l'analisi a posteriori (sia dai grafici, se sei capace, sia con l'overlay su video che è sempre molto utile).

 

 

Comunque il protocollo BLE riesce a trasmettere con una latenza bassa fino a 3 ms. L'ECU manda dati ogni 2 ms circa, anche per quello non si mandano su tutti i dati al volo, almeno nell'applicazione Arduino, ma si selezionano alcuni canali (fino a 6, perché il chip MCP2515 che legge il can bus ha a disposizione fino a 6 filtri). Anche il canale più veloce viene trasmesso dalla centralina una volta ogni centesimo di secondo, quindi l'accrocchio Arduino pesca il canale dal buffer e lo manda su al volo al momento giusto. In realtà per ora non manda alla massima frequenza di aggiornamento dalla ECU, ma legge il dato alla metà o ad un quarto della frequenza massima di aggiornamento, che comunque è più che sufficiente per fare dei grafici e delle animazioni smooth e beccare bene quello che avviene: il dato di frenata viene campionato 50 volte al secondo, è difficile che una frenata duri meno di 0.04 secondi (25 hz), quindi campionando a 50 hz sei sicuro di stare lontano da aliasing e simili.

 

Va poi considerato che il modulo GPS più figo arriva al massimo a 20 hz di campionamento, e quelli più diffusi arrivano massimo a 10 hz...

RaceChrono comunque consente un aggiustamento dell'offset. Inoltre se si prendono i tempi usando un GPS ad alta frequenza di aggiornamento (10 hz, CONSIGLIATISSIMO!) e se si logga la velocità da centralina, l'applicazione consente di aggiustare a posteriori automaticamente i dati, basandosi sulle letture di velocità. Così anche in caso di ritardi tra centralina e app si possono annullare i ritardi tra diversi set di dati.

 

 

Con l'OBD-2 invece è un macello sia come frequenze di aggiornamento sia per i ritardi che possono essere anche importanti (nell'ordine anche dei decimi di secondo). Questo è il motivo per cui quando usi applicazioni di cruscotti virtuali basati su letture da OBD-2 vedi i dati muoversi con ritardo e con letture fastidiosamente lente.

 

@jeby lo sfilatino monta centralina Ford.

 

(A riguardo, su LLCC c'è il resoconto di un meccanico che ha strappato fuori tutta l'elettronica e l'ha sostituita con soluzioni custom made in concomitanza con l'installazione del cambio sequenziale con soluzioni interessanti come l'implementazione del controllo di trazione)

 

Al momento purtroppo non posso metterci mano perché l'ho spedito dal concessionario con una copiosa perdita d'olio dal differenziale. 😭

Piccolo aggiornamento: ho corretto la formula per la percentuale di pressione del pedale dell'acceleratore, ho aggiunto l'ID relativo al livello di carburante e ho finalmente trovato dove si annida il valore dell'accelerazione laterale  è nel frame 090, racchiuso in due byte! Le altre accelerazioni probabilmente non escono dal modulo del DSC perché non sono utilizzare da altri moduli (probabilmente l'accelerazione laterale è invece usata dall'ABS)

 

Ho aggiornato l'how to relativo al reverse engineering del can-bus su un altro repository, e l'ho postato anche sul mio blog:

 

https://www.jeby.it/2021/03/how-to-reverse-engineer-your-car-can-bus/

 

Inoltre ho lavorato per miniaturizzare l'accrocchio:

 

Sabato dovrebbe arrivare la stampante 3D e si parte ca fare una bella scatolina