TinyLiDAR per IoT: 3 passaggi

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:04

Se ti guardi intorno, noterai che molti piccoli dispositivi intelligenti vengono utilizzati nella vita di tutti i giorni. In genere sono alimentati a batteria e di solito sono collegati a Internet (ovvero il "cloud") in qualche modo. Questi sono tutti quelli che chiamiamo dispositivi "IoT" e stanno rapidamente diventando un luogo comune nel mondo di oggi.

Per gli ingegneri di sistemi IoT, viene dedicato un grande sforzo di progettazione all'ottimizzazione del consumo energetico. La ragione di ciò è ovviamente dovuta alla limitata capacità disponibile nelle batterie. Sostituire le batterie in grandi quantità in aree remote può essere una proposta molto costosa.

Quindi questo istruibile riguarda l'ottimizzazione della potenza in tinyLiDAR.

Riepilogo TL;DR

Abbiamo una nuova modalità di misurazione "Real Time" (a partire dal firmware 1.4.0) per aiutare a massimizzare l'autonomia della batteria nei dispositivi IoT.

Spremere più succo dalle batterie

Intuitivamente, possiamo aumentare l'autonomia semplicemente riducendo il consumo energetico dei dispositivi IoT. Ok allora è ovvio! Ma come puoi farlo in modo efficace e calcolare correttamente il tempo di esecuzione previsto? Scopriamolo…

Passaggio 1: pura energia

Ci sono molti modi per farlo, ma noi preferiamo scomporlo alle basi e convertire tutto in energia. L'energia elettrica si misura in Joule (simbolo J) e per definizione:

Un Joule è l'energia dissipata sotto forma di calore quando una corrente elettrica di un ampere passa attraverso una resistenza di un ohm per un periodo di un secondo.

Poiché l'energia (E) è anche tensione (V) x carica (Q), abbiamo:

E = V x Q

Q è corrente (I) x tempo (T):

Q = I x T

Quindi l'energia in Joule può essere espressa come:

E = V x I x T

dove V è la tensione, I è la corrente in Ampere e T è il tempo in secondi.

Supponiamo di avere un pacco batterie composto da quattro batterie AA alcaline (LR6) collegate in serie. Questo ci darà una tensione iniziale totale di 4*1.5v = 6v. La fine della vita utile per una batteria alcalina AA è di circa 1,0 V, quindi la tensione media sarebbe di circa 1,25 V. Secondo la scheda tecnica mfr "La capacità erogata dipende dal carico applicato, dalla temperatura di esercizio e dalla tensione di interruzione". Quindi possiamo presumere circa 2000 mAhr o meglio per un'applicazione a basso consumo come un dispositivo IoT.

Pertanto possiamo calcolare che abbiamo 4 celle x 1,25 V per cella x 2000 mAhr * 3600 sec = 36000 J di energia disponibile da questo pacco batteria prima che debba essere sostituito.

Per semplificare i calcoli, possiamo anche presumere che l'efficienza di conversione sia del 100% per il nostro regolatore di sistema e ignorare il consumo energetico del controller host.

Una parola sul ciclismo

No, non il tipo su cui cavalchi! Ci sono un paio di concetti tecnici conosciuti come "Power Cycling" e "Sleep Cycling". Entrambi possono essere utilizzati per ridurre il consumo energetico, ma c'è una differenza tra i due. Il primo prevede lo spegnimento del dispositivo fino a quando non è necessario e quindi l'accensione solo per un breve periodo per eseguire una misurazione, ecc. Sebbene questo metodo sia allettante da utilizzare a causa della sua corrente di spegnimento zero, c'è un inconveniente in cui ci vorrà del tempo quantità di tempo non banale per riavviare e bruciare energia mentre lo fai.

Il secondo concetto consiste nel mantenere il dispositivo in modalità di sospensione con la speranza che si risvegli più velocemente ma brucerai una quantità limitata di corrente mentre dorme. Quindi qual è il migliore da usare?

Dipende da quanto spesso ti devi svegliare.

Passaggio 2: esegui i numeri

Vogliamo trovare l'energia totale (E) normalizzata a 1 secondo per ogni scenario elencato di seguito.

Caso A: Tc = 1sec; effettuare una misurazione della distanza ogni secondo Caso B: Tc = 60sec; prendere una misurazione della distanza ogni minuto. Caso C: Tc = 3600sec; prendere una misurazione della distanza ogni ora.

Per fare ciò, possiamo dire che Tc è il tempo di ciclo per le nostre misurazioni, ton il tempo attivo e toff il tempo inattivo e riorganizzare le nostre formule energetiche come mostrato qui:

Per tinyLiDAR, il tempo di avvio è di circa 300 ms o meno e durante questo periodo sarà necessaria una media di 12,25 mA durante il funzionamento con un'alimentazione regolata di 2,8 V. Quindi consumerà circa 10,3 mJ di energia per ogni avvio.

La corrente di sospensione/riposo per tinyLiDAR è un 3uA ultra basso. Questo è di gran lunga inferiore al tasso di autoscarica mensile dello 0,3% di un pacco batterie alcaline, quindi indagheremo utilizzando solo il metodo "sleep cycle" qui.

Perché non rinunciare al micro e passare direttamente al sensore VL53?

La risposta a questo non è così ovvia. Nei primi giorni dello sviluppo degli smartphone abbiamo appreso che mantenere in vita il processore ad alta velocità affamato di energia per riprodurre gli mp3 era un metodo infallibile per ridurre la durata della batteria. Anche allora abbiamo fatto ogni sforzo possibile per utilizzare "processori applicativi" a bassa potenza per le attività periferiche come la riproduzione di musica. Non è molto diverso oggi e in effetti, si potrebbe dire che è ancora più importante poiché miniaturiamo tutti questi dispositivi IoT con ogni diminuzione della capacità della batteria. Pertanto, l'utilizzo di un processore per applicazioni a bassissima potenza per l'unico compito di controllare il sensore VL53 e fornire dati pronti per ulteriori elaborazioni è un vantaggio decisivo per qualsiasi applicazione alimentata a batteria.

Modalità di misurazione tinyLiDAR

Potrebbe non essere chiaro nel manuale dell'utente in questo momento [ma lo sarà ad un certo punto poiché aggiorniamo sempre il nostro manuale dell'utente:)] -- ci sono in realtà 3 diverse modalità di misurazione in tinyLiDAR.

Modalità MC

Fin dall'inizio di tinyLiDAR, eravamo ossessionati dal tentativo di ottenere misurazioni più veloci dal sensore ToF VL53. Quindi abbiamo ottimizzato il nostro firmware per ottenere i dati di streaming più veloci e coerenti da esso. Ciò ha comportato l'introduzione del buffering. Un po' di buffering è una buona cosa poiché consente al controller host (ad esempio Arduino) di ottenere i dati di misurazione in un lampo e passare a cose più importanti. Pertanto il buffering è assolutamente necessario e per questo siamo in grado di raggiungere velocità di streaming superiori a 900Hz anche su Arduino UNO relativamente lento. Quindi, il tempo di risposta più veloce sarà nell'uso della modalità MC o "continua" di tinyLiDAR.

A proposito, se mai ne hai la possibilità, dovresti collegare un cavo seriale al pin di uscita TTY su tinyLiDAR e vedrai cosa fa questa modalità MC. Prende letteralmente una misurazione il più velocemente possibile e, così facendo, riempie il buffer I2C con i dati più recenti in assoluto. Sfortunatamente, poiché sta funzionando alla massima velocità, sta anche bruciando la massima quantità di energia. Vedi sotto per il grafico corrente rispetto al tempo di questa modalità MC.

Modalità SS

La modalità successiva è quella che chiamiamo "SS" per la modalità "single step". Questa è fondamentalmente la stessa modalità ad alte prestazioni sopra, ma in un unico ciclo di stepping. Quindi puoi ottenere risposte rapide da tinyLiDAR ma i dati saranno del campione precedente, quindi dovrai prendere due misurazioni per ottenere i dati più recenti. Vedi sotto per il grafico corrente rispetto al tempo di questa modalità SS.

Entrambe le modalità di cui sopra si sono adattate bene alla maggior parte degli utenti poiché erano veloci e facili da usare: basta emettere un comando "D" e leggere i risultati. Però …

Passando al mondo IoT in cui ogni milli-Joule conta, abbiamo un nuovo paradigma.

Ed è l'esatto opposto di ciò che abbiamo codificato in tinyLiDAR! Per il mondo IoT abbiamo bisogno di singole misurazioni a intervalli non frequenti per risparmiare energia ed estendere il tempo di esecuzione.

Modalità RT

Fortunatamente, ora possiamo dire che abbiamo una soluzione per questo scenario a partire dal firmware 1.4.0. Si chiama modalità "RT" per misurazioni "in tempo reale". E fondamentalmente implementa un metodo di attivazione, attesa e lettura. Per usarlo, puoi ancora solo dare il comando "D" per iniziare la misurazione, ma per questa modalità RT devi aspettare un periodo di tempo appropriato per la fine della misurazione e poi leggere i risultati. tinyLiDAR passa automaticamente allo stato di quiescenza più basso di meno di 3uA tra i campioni. In realtà è ancora semplice da usare e ancora più efficiente dal punto di vista energetico poiché devi solo prendere una misurazione invece di due per ottenere i dati più recenti, ovvero zero buffering.

Vedi sotto per il grafico corrente rispetto al tempo di questa nuova modalità RT.

Passaggio 3: misurazioni effettive

L'utilizzo della modalità continua MC per misurazioni IoT non frequenti ha poco senso poiché abbiamo bisogno solo di misurazioni singole. Quindi possiamo invece focalizzare la nostra attenzione sulle modalità SS e RT. Il funzionamento di tinyLiDAR da un'alimentazione regolata di +2,8 V ci fornisce la dissipazione di potenza più bassa. Quindi, utilizzando i preset High Accuracy (200ms), abbiamo misurato il seguente consumo di energia su tinyLiDAR:

SS/modalità passo singolo: 31,2 mJ in media su 2 misurazioni

Modalità RT/tempo reale: media di 15,5 mJ su 1 misurazione

Inserendo questi valori sopra nella nostra formula energetica e normalizzando a un secondo, possiamo trovare le aspettative di autonomia supponendo che l'energia dal nostro pacco batteria sia 36000 J.

Caso A: lettura ogni secondo (prendere 2 letture per ottenere i dati più recenti)Tc = 1secTon = 210ms per lettura x 2 letture Toff = Tc - Ton = 580msIon(avg) = 26.5mA per lettura Ioff(avg) = 3uA corrente di riposo Vcc = Tensione di alimentazione 2,8 V L'energia attiva consumata dal carico in Joule è Eon = Vcc x Ion x Ton = 2,8 V x 26,5 mA * 420 ms = 31,164 mJ L'energia inattiva consumata dal carico in Joule è Eoff = Vcc x Ioff x Toff = 2,8 V x 3 uA x 580ms = 4.872uJ Normalizzazione a TcE = (Eon + Eoff)/Tc = (31.164mJ + 4.872uJ)/1 = 31.169mJ o 31,2mJ al secondo Il tempo di esecuzione in secondi è quindi l'energia totale della sorgente/energia consumata che è 36000J / 31,2 mJ = 1155000 secondi = 320 ore = 13,3 giorni

Ripetendo questi calcoli, possiamo trovare i tempi di esecuzione per gli altri scenari:

Modalità SS

Caso A: 2 letture al secondo. L'energia normalizzata è 31,2 mJ. Pertanto l'autonomia è di 13,3 giorni.

Caso B: 2 letture al minuto. L'energia normalizzata è 528uJ. Pertanto l'autonomia è di 2,1 anni.

Caso C: 2 letture all'ora. L'energia normalizzata è 17uJ. L'autonomia è calcolata a >>10 anni, quindi il carico dovuto a tinyLiDAR è trascurabile. Il pacco batteria sarà quindi limitato solo dalla sua durata (cioè circa 5 anni)

Modalità RT

Caso A: 1 lettura al secondo. L'energia normalizzata è 15,5 mJ. Pertanto, il tempo di esecuzione è di 26,8 giorni.

Caso B: 1 lettura al minuto. L'energia normalizzata è 267uJ. Pertanto l'autonomia è di 4,3 anni.

Caso C: 1 Lettura all'ora. L'energia normalizzata è 12,7 uJ. L'autonomia è calcolata a >>10 anni, quindi il carico dovuto a tinyLiDAR è trascurabile. Il pacco batteria sarà quindi limitato solo dalla sua durata (cioè circa 5 anni)

Quindi, la nuova modalità in tempo reale che utilizza il ciclo del sonno è un vantaggio qui per estendere il tempo di esecuzione oltre 4 anni se viene eseguita una misurazione ogni minuto come mostrato nel caso B.

Si noti che il consumo energetico del controller host non è stato preso in considerazione per questa analisi e le specifiche del pacco batteria erano prudenti. Puoi trovare batterie molto più potenti in base alle tue esigenze.

Grazie per aver letto e restate sintonizzati poiché forniremo un esempio IoT funzionante utilizzando tinyLiDAR per il nostro prossimo istruttore. Saluti!