TinyLiDAR voor IoT: 3 stappen

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:18

Als je om je heen kijkt, zie je dat er in het dagelijks leven veel slimme kleine apparaten worden gebruikt. Ze werken meestal op batterijen en zijn meestal op de een of andere manier verbonden met internet (ook wel de 'cloud' genoemd). Dit zijn allemaal wat we 'IoT'-apparaten noemen en ze worden tegenwoordig snel gemeengoed in de wereld.

Voor IoT-systeemingenieurs wordt veel ontwerpinspanning besteed aan het optimaliseren van het stroomverbruik. De reden hiervoor is natuurlijk te wijten aan de beperkte capaciteit die beschikbaar is in batterijen. Batterijen in grote hoeveelheden vervangen in afgelegen gebieden kan een zeer dure aangelegenheid zijn.

Dus deze instructable gaat helemaal over het optimaliseren van de kracht in tinyLiDAR.

TL;DR samenvatting

We hebben een nieuwe "Real Time" meetmodus (vanaf firmware 1.4.0) om de batterijduur in IoT-apparaten te maximaliseren.

Meer sap uit batterijen persen

Intuïtief kunnen we de runtime verlengen door simpelweg het stroomverbruik van de IoT-apparaten te verminderen. Oke dat is duidelijk! Maar hoe kunt u dit effectief doen en de verwachte looptijd goed berekenen? Laten we het uitzoeken…

Stap 1: Pure energie

Er zijn veel manieren om dit te doen, maar we geven er de voorkeur aan om het terug te brengen tot de basis en alles om te zetten in energie. Elektrische energie wordt gemeten in Joules (symbool J) en per definitie:

Een joule is de energie die als warmte wordt gedissipeerd wanneer een elektrische stroom van één ampère gedurende een periode van één seconde door een weerstand van één ohm gaat.

Aangezien energie (E) ook spanning (V) x lading (Q) is, hebben we:

E = V x Q

Q is Stroom (I) x tijd (T):

Q = ik x T

Dus energie in Joules kan worden uitgedrukt als:

E = V x ik x T

waarbij V de spanning is, I de stroom in Ampère en T de tijd in seconden.

Laten we aannemen dat we een batterijpakket hebben dat bestaat uit vier AA-alkalinebatterijen (LR6) die in serie zijn geschakeld. Dit geeft ons een totale startspanning van 4 * 1.5v = 6v. Het einde van de levensduur van een alkaline AA-batterij is ongeveer 1,0 V, dus de gemiddelde spanning zou ongeveer 1,25 V zijn. Volgens de mfr-datasheet "De geleverde capaciteit is afhankelijk van de toegepaste belasting, bedrijfstemperatuur en uitschakelspanning." We kunnen dus uitgaan van ongeveer 2000 mAhr of beter voor een toepassing met een laag verbruik, zoals een IoT-apparaat.

Daarom kunnen we berekenen dat we 4 cellen x 1.25V per cel x 2000mAhr * 3600sec = 36000 J energie beschikbaar hebben uit dit batterijpakket voordat het moet worden vervangen.

Om de berekeningen eenvoudiger te maken, kunnen we ook aannemen dat de conversie-efficiëntie 100% is voor onze systeemregelaar en het stroomverbruik van de hostcontroller negeren.

Een woord over fietsen

Nee, niet het type waarop u rijdt! Er zijn een aantal technische concepten die bekend staan als "Power Cycling" en "Sleep Cycling". Beide kunnen worden gebruikt om het stroomverbruik te verlagen, maar er is een verschil tussen de twee. De eerste houdt in dat u uw apparaat uitschakelt totdat het nodig is en vervolgens slechts korte tijd wordt ingeschakeld om een meting uit te voeren enz. Hoewel deze methode verleidelijk is om te gebruiken vanwege de nul-uit-stroom, is er een nadeel waar het enige tijd in beslag zal nemen. niet-triviale hoeveelheid tijd om een back-up op te starten en energie te verbranden terwijl je dit doet.

Het tweede concept houdt in dat je het apparaat gewoon in de slaapstand houdt in de hoop dat het sneller wakker wordt, maar je verbrandt een eindige hoeveelheid stroom terwijl het slaapt. Dus welke is het beste om te gebruiken?

Het hangt af van hoe vaak je wakker moet worden.

Stap 2: Voer de cijfers uit

We willen de totale energie (E) vinden die is genormaliseerd naar 1 seconde voor elk hieronder vermeld scenerio.

Geval A: Tc = 1sec; elke seconde een afstandsmeting uitvoeren Geval B: Tc = 60sec; elke minuut een afstandsmeting uitvoeren. Geval C: Tc = 3600sec; doe elk uur een afstandsmeting.

Om dit te doen, kunnen we zeggen dat Tc de cyclustijd is voor onze metingen, ton de actieve tijd en de inactieve tijd uitschakelen en onze energieformules herschikken zoals hier getoond:

Voor tinyLiDAR is de opstarttijd ongeveer 300 ms of minder en gedurende deze tijd duurt het gemiddeld 12,25 mA bij gebruik van een gereguleerde 2,8 V-voeding. Daarom verbruikt het ongeveer 10,3 mJ energie voor elke startup.

De slaap-/ruststroom voor tinyLiDAR is een ultralage 3uA. Dit is veel lager dan de maandelijkse zelfontlading van 0,3% van een alkalinebatterij, dus we zullen hier alleen de "slaapcyclus"-methode gebruiken.

Waarom niet afzien van de micro en direct naar de VL53-sensor gaan?

Het antwoord hierop is niet zo voor de hand liggend. In de begindagen van de ontwikkeling van smartphones leerden we dat het in leven houden van de energieverslindende high-speed processor om mp3's af te spelen een trefzekere methode was om de levensduur van de batterij te verkorten. Zelfs toen hebben we er alles aan gedaan om "toepassingsprocessors" met een lager vermogen te gebruiken voor randtaken zoals het afspelen van muziek. Het is tegenwoordig niet veel anders en je zou zelfs kunnen zeggen dat het nog belangrijker is, aangezien we al deze IoT-apparaten miniaturiseren met elke afnemende batterijcapaciteit. Dus het gebruik van een ultra-low power applicatieprocessor voor de enige taak van het besturen van de VL53-sensor en het leveren van gegevens die klaar zijn voor verdere verwerking, is een absolute aanwinst voor elke batterijgevoede applicatie.

tinyLiDAR-meetmodi

Het is op dit moment misschien niet duidelijk in de gebruikershandleiding [maar zal op een gegeven moment zijn omdat we onze gebruikershandleiding altijd bijwerken:)] -- er zijn eigenlijk 3 verschillende meetmodi in tinyLiDAR.

MC-modus

Vanaf het begin van tinyLiDAR waren we geobsedeerd door het proberen om snellere metingen van de VL53 ToF-sensor te krijgen. Daarom hebben we onze firmware geoptimaliseerd om er de snelste en meest consistente streaminggegevens uit te halen. Dit omvatte het introduceren van buffering. Een beetje bufferen is een goede zaak, omdat het de hostcontroller (d.w.z. Arduino) in staat stelt om zijn meetgegevens in een flits te krijgen en verder te gaan met belangrijkere dingen. Daarom is bufferen absoluut noodzakelijk en hierdoor zijn we in staat om streamingsnelheden van meer dan 900 Hz te bereiken, zelfs op de relatief trage Arduino UNO. Daarom is de snelste reactietijd bij het gebruik van tinyLiDAR's MC of "continue" modus.

Trouwens, als je ooit de kans krijgt, moet je een seriële kabel aansluiten op de TTY-uitgangspin op tinyLiDAR en je zult zien wat deze MC-modus doet. Het neemt letterlijk zo snel mogelijk een meting en vult daarbij zijn I2C-buffer met de absoluut laatste gegevens. Helaas, aangezien het op volle snelheid draait, verbruikt het ook de maximale hoeveelheid stroom. Zie hieronder voor de huidige vs tijdgrafiek van deze MC-modus.

SS-modus

De volgende modus is wat we "SS" noemen voor "single step"-modus. Dit is in feite dezelfde high-performance-modus hierboven, maar in plaats daarvan in een enkele stepping-lus. U kunt dus snelle reacties krijgen van tinyLiDAR, maar de gegevens zijn afkomstig uit het vorige voorbeeld, dus u zult twee metingen moeten doen om de allerlaatste gegevens te krijgen. Zie hieronder voor de huidige vs tijdgrafiek van deze SS-modus.

Beide bovenstaande modi passen goed bij de meeste gebruikers, omdat ze snel en gemakkelijk te gebruiken waren - geef gewoon een "D" -opdracht en lees de resultaten. Echter …

Vooruit naar de IoT-wereld waar elke milli-joule telt, hebben we een nieuw paradigma.

En het is precies het tegenovergestelde van wat we hebben gecodeerd in tinyLiDAR! Voor de IoT-wereld hebben we afzonderlijke metingen nodig met onregelmatige tussenpozen om stroom te besparen en de looptijd te verlengen.

RT-modus

Gelukkig kunnen we nu zeggen dat we vanaf firmware 1.4.0 een oplossing hebben voor dit scenario. Het wordt de "RT"-modus genoemd voor "realtime" metingen. En het implementeert in feite een trigger, wacht en lees-methode. Om het te gebruiken, kunt u nog steeds gewoon het "D"-commando geven om de meting te starten, maar voor deze RT-modus moet u een geschikte hoeveelheid tijd wachten voordat de meting is voltooid en dan de resultaten lezen. tinyLiDAR gaat automatisch naar de laagste rusttoestand van sub 3uA tussen monsters in. Het is eigenlijk nog steeds eenvoudig te gebruiken en zelfs nog energiezuiniger, omdat u slechts één meting hoeft uit te voeren in plaats van twee om de allernieuwste gegevens te krijgen, d.w.z. nul buffering.

Zie hieronder voor de huidige versus tijdgrafiek van deze nieuwe RT-modus.

Stap 3: Werkelijke metingen

Het gebruik van de MC-continue modus voor niet-frequente IoT-metingen heeft weinig zin, omdat we slechts enkele metingen nodig hebben. Daarom kunnen we onze aandacht in plaats daarvan richten op de SS- en RT-modi. Het bedienen van tinyLiDAR vanaf een gereguleerde voeding van +2.8v geeft ons de laagste vermogensdissipatie. Dus bij het gebruik van de voorinstellingen voor hoge nauwkeurigheid (200 ms) hebben we het volgende energieverbruik op tinyLiDAR gemeten:

SS/eenstapsmodus: 31,2 mJ gemiddeld over 2 metingen

RT/realtime-modus: 15,5 mJ gemiddeld over 1 meting

Door deze bovenstaande waarden in onze energieformule in te voeren en te normaliseren tot één seconde, kunnen we de runtime-verwachtingen vinden, ervan uitgaande dat de energie van ons batterijpakket 36000 J is.

Geval A: lees elke seconde (neem 2 metingen om de laatste gegevens te krijgen)Tc = 1secTon = 210ms per meting x 2 metingen Toff = Tc - Ton = 580msIon(avg) = 26.5mA per meting Ioff(avg) = 3uA ruststroom Vcc = 2,8V voedingsspanning Actieve energie verbruikt door belasting in Joules is Eon = Vcc x Ion x Ton = 2,8V x 26,5mA * 420ms = 31,164mJ Inactieve energie verbruikt door belasting in Joule is Eoff = Vcc x Ioff x Toff = 2,8V x 3uA x 580ms = 4,872uJ Normaliseren naar TcE = (Eon + Eoff)/Tc = (31,164mJ + 4,872uJ)/1 = 31,169mJ of 31,2mJ per seconde Runtime in seconden is daarom de totale energie van de bron/energie die wordt verbruikt, wat 36000J is / 31,2 mJ = 1155000 seconden = 320 uur = 13,3 dagen

Door deze berekeningen te herhalen, kunnen we de looptijden voor de andere scenario's vinden:

SS-modus

Geval A: 2 metingen per seconde. Genormaliseerde energie is 31,2 mJ. Daarom is de looptijd 13,3 dagen.

Geval B: 2 metingen per minuut. Genormaliseerde energie is 528uJ. Daarom is de looptijd 2,1 jaar.

Casus C: 2 metingen per uur. Genormaliseerde energie is 17uJ. De looptijd is berekend op >>10 jaar, dus de belasting door tinyLiDAR is verwaarloosbaar. Het batterijpakket wordt daarom alleen beperkt door de houdbaarheid (d.w.z. ongeveer 5 jaar)

RT-modus

Casus A: 1 meting per seconde. Genormaliseerde energie is 15,5 mJ. Daarom is de looptijd 26,8 dagen.

Casus B: 1 meting per minuut. Genormaliseerde energie is 267uJ. Daarom is de looptijd 4,3 jaar.

Casus C: 1 meting per uur. Genormaliseerde energie is 12,7uJ. De looptijd is berekend op >>10 jaar, dus de belasting door tinyLiDAR is verwaarloosbaar. Het batterijpakket wordt daarom alleen beperkt door de houdbaarheid (d.w.z. ongeveer 5 jaar)

Daarom is de nieuwe realtime-modus die slaapcycli gebruikt, hier een voordeel om de looptijd tot 4 jaar te verlengen als er elke minuut één meting wordt uitgevoerd, zoals weergegeven in geval B.

Merk op dat het energieverbruik van de hostcontroller niet in aanmerking is genomen voor deze analyse en dat de specificaties van het batterijpakket aan de conservatieve kant waren. U kunt naar wens veel krachtigere batterijen vinden om aan uw behoeften te voldoen.

Bedankt voor het lezen en blijf op de hoogte, want we zullen een werkend IoT-voorbeeld geven met tinyLiDAR voor onze volgende instructable. Proost!