l0destar è un tracker open source per veicoli a bassissimo consumo: come funziona

l0destar è un tracker per veicoli completamente open source: integra GNSS, LTE-M/NB-IoT, CAN-FD e IMU intelligente, con un consumo dichiarato di circa 35,5 µA durante lo sleep. Le principali caratteristiche e come realizzarlo in proprio.

Un localizzatore per auto capace di seguire il veicolo quasi in tempo reale, rilevare urti, inclinazioni e tentativi di traino, controllare la tensione della batteria e dialogare con le centraline attraverso CAN-FD e K-Line. Tutto con hardware e software open source, senza dipendere obbligatoriamente dal cloud di un produttore. Si chiama l0destar ed è un progetto che prova a riportare il vehicle tracking nelle mani di chi vuole avere il massimo controllo e avvalersi di una gestione completamente autonoma.

Tra i riferimenti dichiarati dall’autore ci sono OpenTracker di Geolink, progetto comparso nel 2014 come tracker GPS/GLONASS open source compatibile con Arduino, e Fortebit Polaris, sua evoluzione programmabile anche in Python e disponibile con modem 2G, 3G e NB-IoT. l0destar riprende quella filosofia, ma la porta su una piattaforma molto più recente: GNSS, reti LTE a basso consumo, diagnostica automobilistica moderna e sensori inerziali capaci di analizzare direttamente alcuni movimenti.

Il progetto ha già accumulato oltre 430.000 km di tracciamento secondo il sito ufficiale, ma va fatta subito una precisazione importante: l0destar non è un prodotto commerciale pronto da installare. Le revisioni v2.1, v2.6, v3.0, v3.1, v3.2 e v3.3 hanno raggiunto vari livelli di costruzione e test al banco, mentre la v3.4 risulta progettata ma non ancora realizzata e verificata; nel complesso si parla ancora di progetto sperimentale.

Tracker veicoli open source

l0destar punta tutto sui consumi: circa 35,5 µA a riposo

Uno dei numeri che rende l0destar particolarmente interessante è il consumo energetico dichiarato durante lo sleep: circa 35,5 µA a 12 V. La misura pubblicata riguarda una scheda v3.3 modificata con la correzione dell’accelerometro prevista per la v3.4 ed è stata effettuata attraverso una resistenza da 10 kΩ, alimentatore da banco e multimetro Fluke.

Per un tracker installato permanentemente su un’automobile è un dato importante: il dispositivo deve restare collegato alla batteria anche quando il mezzo rimane fermo per giorni o settimane; un assorbimento elevato si tradurre in una possibile causa di mancato avviamento.

Il circuito di alimentazione ruota attorno al dispositivo LT8609A di Analog Devices, un convertitore buck sincrono con ingresso fino a 42 V. Il componente può scendere sotto 2,5 µA di corrente di quiescenza nella modalità Burst ed è pensato proprio per alimentazioni che devono sopportare ampie variazioni di tensione. Su un impianto automotive è una caratteristica essenziale: la linea nominale a 12 V non è affatto una sorgente perfettamente stabile.

l0destar aggiunge inoltre una protezione hardware contro le sovratensioni generate da un eventuale guasto del regolatore. L’obiettivo dichiarato è scollegare l’alimentazione del modulo nell’ordine dei microsecondi prima che una tensione anomala possa raggiungere la parte logica. È un approccio interessante perché non affida una funzione critica al firmware: se il problema riguarda proprio l’alimentazione, attendere che intervenga il software sarebbe una scelta fragile.

Il cuore è Nordic nRF9151: LTE-M, NB-IoT e GNSS nello stesso SiP

La piattaforma scelta per le revisioni più recenti ruota attorno al Nordic Semiconductor nRF9151, un System-in-Package destinato alle applicazioni IoT cellulari. Integra un processore Arm Cortex-M33 a 64 MHz, 1 MB di flash, 256 KB di RAM, modem LTE-M/NB-IoT e ricevitore GNSS.

Un tracker automobilistico non deve trasferire centinaia di megabit al secondo: gli servono copertura, consumi ridotti e la possibilità di inviare piccoli pacchetti di telemetria anche quando il veicolo si trova lontano dalle aree urbane: LTE-M e NB-IoT nascono proprio per dispositivi con requisiti di questo tipo.

Il sito indica una latenza tipica della telemetria nell’ordine di 3-5 secondi e punta a un’acquisizione GNSS a 1 Hz.

Un’altra scelta significativa riguarda le SIM multi-rete: l’idea è ridurre la dipendenza dalla copertura di un singolo operatore, aspetto tutt’altro che secondario per un dispositivo che potrebbe attraversare regioni o Paesi diversi.

Non solo posizione GPS: l’IMU può capire cosa sta succedendo all’auto

La localizzazione racconta dove si trova il veicolo, ma non necessariamente cosa gli sta accadendo. Per colmare questa lacuna l0destar utilizza ASM330LHHX di STMicroelectronics, un’IMU (inertial measurement units) automotive a sei assi che combina accelerometro e giroscopio.

Al suo interno ST integra una macchina a stati finiti programmabile e un Machine Learning Core capace di elaborare direttamente i dati dei sensori. La documentazione del produttore cita applicazioni come riconoscimento dello stato di movimento, rilevamento di urti, inclinazione e attività anomale; sono funzioni molto vicine alle necessità di un tracker per veicoli.

Il vantaggio tecnico consiste nel poter prendere alcune decisioni direttamente nel sensore, senza tenere costantemente sveglio il processore principale. Il Machine Learning Core calcola caratteristiche statistiche sui segnali, applica filtri ed esegue alberi decisionali configurabili. La finite state machine può invece reagire a sequenze di movimento definite in precedenza.

In pratica, se l’automobile è parcheggiata non serve interrogare continuamente accelerometro e CPU ad alta frequenza. L’IMU può svolgere il ruolo di sentinella a basso consumo e generare un interrupt quando riconosce una variazione significativa. Da qui derivano funzioni come rilevamento di urti, inclinazione e traino; lo stesso principio può contribuire al dead reckoning, cioè alla stima del movimento quando il segnale satellitare peggiora o scompare temporaneamente.

CAN-FD trasforma il tracker in qualcosa di più di un localizzatore

La parte forse più ambiziosa è l’interfaccia con l’elettronica del veicolo. l0destar integra un controller MCP2518FD collegato via SPI e un transceiver MAX33041E per accedere alle reti CAN.

Le reti CAN (Controller Area Network) sono i bus di comunicazione usati nei veicoli per permettere alle diverse centraline elettroniche – motore, ABS, airbag, climatizzazione e altri moduli – di scambiarsi dati senza collegamenti punto-punto dedicati.

Il MCP2518FD supporta sia CAN 2.0B sia CAN-FD, mentre il MAX33041E lavora fino a 5 Mbps e integra protezioni contro guasti, cortocircuiti, scariche elettrostatiche e tensioni anomale sulle linee CANH e CANL. Il progetto punta a una vera interfaccia diagnostica e telematica che possa evolvere insieme al firmware.

I test pubblicati sulla revisione v3.1 sono piuttosto dettagliati. L’autore ha provato comunicazioni CAN-FD con fase di arbitraggio a 500 kbps e data phase a 2 e 5 Mbps; a 5 Mbps il singolo bit dura appena 200 ns.

Limitarsi a CAN significherebbe però escludere una quantità notevole di veicoli più vecchi. Per questa ragione l0destar mantiene anche una interfaccia K-Line, basata sul transceiver NXP TJA1027, componente compatibile con questa modalità di comunicazione oltre che con LIN.

È uno dei passaggi che rende il progetto più credibile dal punto di vista tecnico. Non c’è soltanto una lista di funzioni teoriche; il repository documenta errori, misure e modifiche nate durante il bring-up reale della scheda.

Attenzione alle revisioni precedenti alla v3.3

Nel repository l’autore avverte chiaramente che le schede antecedenti alla v3.3 presentano un problema sulla linea L del circuito K-Line. Se collegata al veicolo e cortocircuitata esternamente verso i 12 V, l’attivazione del MOSFET 2N7002 può provocarne rapidamente la distruzione e, nello scenario peggiore, trasferire la tensione della batteria verso il GPIO e il nRF9151.

Per tale ragione il firmware mantiene la linea L disabilitata per impostazione predefinita sulle vecchie revisioni. La v3.3 modifica invece il circuito introducendo un AL5809-90 che limita la corrente a circa 90 mA, protezione termica e un percorso separato per rilevare lo stato elettrico della linea.

Prima di pilotarla, il firmware può inoltre eseguire un breve impulso di prova di 5 ms: se il livello resta alto, interpreta la condizione come una possibile connessione a bassa impedenza verso la batteria e non procede con l’inizializzazione. È una mitigazione sensata, ma soprattutto ricorda perché sarebbe sbagliato considerare oggi l0destar un dispositivo automotive certificato.

Hardware costruibile a casa, ma senza fingere che sia un progetto per principianti

Uno dei principi dichiarati è mantenere la scheda assemblabile manualmente con attrezzatura relativamente economica. La scheda misura circa 66,65 x 37,55 mm, mentre il contenitore di riferimento arriva a circa 72,5 x 43,4 x 28,5 mm.

L’autore evita package esasperatamente difficili da saldare. Tuttavia, saldare i componenti, gestire RF, alimentazioni automotive, CAN, modem cellulari e circuiti collegati direttamente all’impianto elettrico di un’automobile richiede una certa esperienza.

La filosofia del progetto è quella di fornire un design di riferimento replicabile a chi sa cosa sta facendo, anziché consegnare una scatola nera già chiusa e vincolata a un servizio remoto.

L’apertura non riguarda soltanto gli schemi elettrici: il repository comprende cartelle dedicate all’hardware, al firmware, al software server e alla documentazione. Sono disponibili anche i file CAD per il contenitore.

Le licenze cambiano a seconda del materiale: i file hardware utilizzano CERN-OHL-P-2.0, firmware e software server Apache-2.0, mentre documentazione, CAD del case e contenuti multimediali adottano CC BY 4.0.

Ti consigliamo anche

Link copiato negli appunti