Innholdsfortegnelse:
Video: TinyLiDAR for IoT: 3 trinn
2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:25
Hvis du ser deg rundt, vil du legge merke til at mange smarte små enheter blir brukt i hverdagen. De er vanligvis batteridrevne og vanligvis koblet til Internett (aka "skyen") på en eller annen måte. Dette er alt vi kaller "IoT" -enheter, og de er i ferd med å bli vanlig sted i verden i dag.
For IoT -systemingeniører brukes mye designinnsats på å optimalisere strømforbruket. Årsaken til dette skyldes selvfølgelig den begrensede kapasiteten som er tilgjengelig i batterier. Å bytte batterier i store mengder i fjerntliggende områder kan være et veldig dyrt forslag.
Så dette instruerbare handler om å optimalisere kraften i tinyLiDAR.
TL; DR oppsummering
Vi har en ny "sanntids" målemodus (fra fastvare 1.4.0) for å maksimere batteritiden på IoT -enheter.
Klemmer mer juice fra batterier
Intuitivt kan vi øke kjøretiden ved ganske enkelt å redusere IoT -enheters strømforbruk. Ok, så det er åpenbart! Men hvordan kan du gjøre dette effektivt og riktig beregne forventet kjøretid? La oss finne det ut…
Trinn 1: Ren energi
Det er mange måter å gjøre dette på, men vi foretrekker å bryte det ned til det grunnleggende og konvertere alt til energi. Elektrisk energi måles i Joule (symbol J) og per definisjon:
En Joule er energien som spres som varme når en elektrisk strøm på en ampere passerer gjennom en motstand på en ohm i en periode på ett sekund.
Siden energi (E) også er spenning (V) x ladning (Q), har vi:
E = V x Q
Q er nåværende (I) x tid (T):
Q = I x T
Så energi i Joules kan uttrykkes som:
E = V x I x T
hvor V er spenningen, I er strømmen i ampere og T er tiden i sekunder.
La oss anta at vi har en batteripakke som består av fire AA alkaliske (LR6) batterier koblet i serie. Dette vil gi oss en total startspenning på 4*1,5v = 6v. Slutten på levetiden for et alkalisk AA -batteri er ca 1,0v, så gjennomsnittsspenningen vil være omtrent 1,25v. I følge databladet til produktfremgangsmåten "Levert kapasitet er avhengig av påført belastning, driftstemperatur og spenning." Så vi kan anta omtrent 2000mAhr eller bedre for applikasjoner med lavt drenering, for eksempel en IoT -enhet.
Derfor kan vi beregne at vi har 4 celler x 1,25V per celle x 2000mAhr * 3600s = 36000 J energi tilgjengelig fra denne batteripakken før den må byttes ut.
For enklere beregninger kan vi også anta at konverteringseffektiviteten er 100% for systemregulatoren vår og ignorere vertskontrollens strømforbruk.
Et ord om sykling
Nei, ikke typen du sykler på! Det er et par tekniske konsepter kjent som "Power Cycling" og "Sleep Cycling". Begge kan brukes til å senke strømforbruket, men det er en forskjell mellom de to. Den første innebærer å slå av enheten til den er nødvendig og deretter slå den på bare for en kort stund for å utføre en måling osv. Selv om denne metoden er fristende å bruke på grunn av nullstrømmen, er det en ulempe at det vil ta litt ikke-triviell tid til å starte opp igjen og forbrenne energi mens du gjør det.
Det andre konseptet innebærer bare å holde enheten i hvilemodus med håp om at den vil våkne raskere, men du vil brenne en endelig mengde strøm mens den sover. Så hvilken er best å bruke?
Det avhenger av hvor ofte du trenger å våkne.
Trinn 2: Kjør tallene
Vi ønsker å finne den totale energien (E) normalisert til 1 sekund for hvert scenario nedenfor.
Sak A: Tc = 1sek; ta en avstandsmåling hvert andre Tilfelle B: Tc = 60sek; ta en avstandsmåling hvert minutt. Sak C: Tc = 3600sek; ta en avstandsmåling hver time.
For å gjøre dette, kan vi si at Tc er syklusen for målingene våre, tone den aktive tiden og deaktivere den inaktive tiden og omorganisere våre energiformler som vist her:
For tinyLiDAR er oppstartstiden omtrent 300 ms eller mindre, og i løpet av denne tiden vil det i gjennomsnitt ta 12,25 mA mens den opererer fra en regulert 2,8 volt forsyning. Derfor vil den forbruke omtrent 10,3 mJ energi for hver oppstart.
Søvn/hvilestrøm for tinyLiDAR er en ultralav 3uA. Dette er langt lavere enn 0,3% månedlig selvutladningshastighet for en alkalisk batteripakke, så vi vil undersøke ved å bare bruke "søvnsyklus" -metoden her.
Hvorfor ikke avstå fra mikro og gå direkte til VL53 -sensoren?
Svaret på dette er ikke fullt så åpenbart. I begynnelsen av smarttelefonutviklingen lærte vi at å holde den kraftsultne høyhastighetsprosessoren i live for å spille av mp3 -er var en sikker metode for å redusere batterilevetiden. Selv da gjorde vi alt vi kunne for å bruke "applikasjonsprosessorer" med lavere strøm til periferioppgaver som å spille musikk. Det er ikke mye annerledes i dag, og faktisk kan du si at det er enda viktigere ettersom vi miniatyriserer alle disse IoT -enhetene med hver reduserte batterikapasitet. Så det er en klar ressurs for alle batteridrevne applikasjoner å bruke en applikasjonsprosessor med svært lav effekt for den eneste oppgaven med å kontrollere VL53-sensoren og levere data klar for videre behandling.
tinyLiDAR målemoduser
Det er kanskje ikke klart i brukerhåndboken for øyeblikket [men vil være på et tidspunkt da vi alltid oppdaterer brukerveiledningen:)] - det er faktisk 3 forskjellige målemoduser i tinyLiDAR.
MC -modus
Fra begynnelsen av tinyLiDAR var vi besatt av å prøve å få raskere målinger fra VL53 ToF -sensoren. Så vi optimaliserte fastvaren vår for å få de raskeste og mest konsistente streamingdataene fra den. Dette innebar innføring av buffering. Litt buffering er bra siden det lar vertskontrolleren (dvs. Arduino) få måledataene sine på et blunk og gå videre til viktigere ting. Derfor er buffering absolutt nødvendig, og på grunn av dette er vi i stand til å oppnå strømningshastigheter på over 900Hz, selv på den relativt treg Arduino UNO. Derfor vil den raskeste responstiden være ved bruk av tinyLiDARs MC eller "kontinuerlig" modus.
BTW, hvis du noen gang får en sjanse, bør du koble en seriell kabel til TTY -utgangspinnen på tinyLiDAR, så ser du hva denne MC -modusen gjør. Det tar bokstavelig talt en måling så raskt som mulig, og ved å gjøre det fyller den I2C -bufferen med de absolutt siste dataene. Dessverre, siden den kjører på full hastighet, brenner den også maks strøm. Se nedenfor for gjeldende vs tid -grafen for denne MC -modusen.
SS -modus
Den neste modusen er det vi kaller "SS" for "enkelt trinn" -modus. Dette er i utgangspunktet den samme høyytelsesmodusen ovenfor, men i stedet for en enkelt trinnløkke. Så du kan få raske svar fra tinyLiDAR, men data kommer fra forrige prøve, så du må ta to målinger for å få de nyeste dataene. Se nedenfor for gjeldende vs tid -grafen for denne SS -modusen.
Begge de ovennevnte modusene har passet regningen pent for de fleste brukere siden de var raske og enkle å bruke - bare gi ut en "D" -kommando og les resultatene. Derimot …
Fremover til IoT-verdenen hvor hver milli-Joule teller, har vi et nytt paradigme.
Og det er det stikk motsatte av det vi har kodet i tinyLiDAR! For IoT -verden trenger vi enkeltmålinger med sjeldne mellomrom for å spare strøm og forlenge kjøretiden.
RT -modus
Heldigvis kan vi nå si at vi har en løsning for dette scenariet fra fastvare 1.4.0. Det kalles "RT" -modus for "sanntids" målinger. Og det implementerer i utgangspunktet en trigger, vent og les metode. For å bruke den kan du fortsatt bare utstede "D" -kommandoen for å starte målingen, men for denne RT -modusen må du vente en passende tid før målingen er ferdig og deretter lese resultatene. tinyLiDAR går automatisk til sin laveste hviletilstand for sub 3uA mellom prøver. Det er faktisk fortsatt enkelt å bruke og enda mer energieffektivt nå, siden du bare må ta en måling i stedet for to for å få de nyeste dataene, dvs. nullbuffering.
Se nedenfor for gjeldende vs tid -grafen for denne nye RT -modusen.
Trinn 3: Faktiske målinger
Å bruke MC -kontinuerlig modus for sjeldne IoT -målinger gir liten mening siden vi bare trenger enkeltmålinger. Derfor kan vi i stedet fokusere vår oppmerksomhet på SS- og RT -modusene. Drift av tinyLiDAR fra en regulert forsyning på +2,8v gir oss den laveste effekttapet. Så ved å bruke forhåndsinnstillingene med høy nøyaktighet (200 ms) målte vi følgende energiforbruk på tinyLiDAR:
SS/enkelttrinnsmodus: 31,2 mJ i gjennomsnitt over 2 målinger
RT/sanntidsmodus: 15,5 mJ i gjennomsnitt over 1 måling
Ved å koble disse verdiene ovenfor til energiformelen vår og normalisere til ett sekund, kan vi finne kjøretidsforventningene som antar at energien fra batteripakken er 36000 J.
Case A: lesing hvert sekund (ta 2 avlesninger for å få de siste dataene) Tc = 1secTon = 210ms per lesing x 2 avlesninger Toff = Tc - Ton = 580msIon (avg) = 26,5mA per lesing Ioff (avg) = 3uA hvilestrøm Vcc = 2,8V forsyningsspenning Aktiv energi som forbrukes ved belastning i Joule er Eon = Vcc x Ion x Ton = 2,8V x 26,5mA * 420ms = 31,164mJ Inaktiv energi som forbrukes ved belastning i Joule er Eoff = Vcc x Ioff x Toff = 2,8V x 3uA x 580ms = 4.872uJ Normalisering til TcE = (Eon + Eoff)/Tc = (31.164mJ + 4.872uJ)/1 = 31.169mJ eller 31.2mJ per sekund Runtime i sekunder er derfor den totale energien til kilde/energi som forbrukes som er 36000J / 31.2mJ = 1155000 sekunder = 320 timer = 13.3 dager
Når vi gjentar disse beregningene, kan vi finne kjøretiden for de andre scenariene:
SS -modus
Sak A: 2 avlesninger per sekund. Normalisert energi er 31,2 mJ. Derfor er kjøretiden 13,3 dager.
Sak B: 2 avlesninger per minutt. Normalisert energi er 528uJ. Derfor er kjøretiden 2,1 år.
Sak C: 2 avlesninger per time. Normalisert energi er 17uJ. Kjøretid er beregnet til >> 10 år, og derfor er lasting på grunn av tinyLiDAR ubetydelig. Batteripakken vil derfor bare begrenses av holdbarheten (dvs. ca. 5 år)
RT -modus
Case A: 1 lesing per sekund. Normalisert energi er 15,5 mJ. Derfor er kjøretiden 26,8 dager.
Sak B: 1 lesing per minutt. Normalisert energi er 267uJ. Derfor er kjøretiden 4,3 år.
Sak C: 1 lesing per time. Normalisert energi er 12,7uJ. Kjøretid er beregnet til >> 10 år, og derfor er lasting på grunn av tinyLiDAR ubetydelig. Batteripakken vil derfor bare begrenses av holdbarheten (dvs. ca. 5 år)
Derfor er den nye sanntidsmodusen med søvnsykling en fordel her for å forlenge kjøretiden siste 4 år hvis en måling tas hvert minutt som vist i sak B.
Vær oppmerksom på at vertsstyringens energiforbruk ikke ble tatt i betraktning for denne analysen, og at batteripakkens spesifikasjoner var på den konservative siden. Du kan finne mye kraftigere batterier etter ønske som passer dine behov.
Takk for at du leser og følg med, for vi kommer med et fungerende IoT -eksempel ved bruk av tinyLiDAR for vår neste instruerbare. Jubel!
Anbefalt:
Slik laster du fôr til kyr: 9 trinn
Slik laster du fôr til kyr: Alt som lever trenger mat for å overleve. I vinter- og vårmånedene er det ikke gress for kyr å beite på. Dette gjør det veldig viktig at kuene blir matet skikkelig slik at de produserer sunne kalver. I de følgende trinnene vil pr
CircuitPython og TinyLiDAR: Enkelt eksempel: 3 trinn
CircuitPython og TinyLiDAR: Enkelt eksempel: MicroElectronicDesign tinyLiDAR er en ST VL53L0X-basert time-of-flight (ToF) -modul med en i2c-bussforbindelse. Adafruit -mikrokontrollerkortene kobles enkelt til denne sensoren, ettersom de kan snakke i2c -protokollen over datapinnen
TinyLiDAR i garasjen din !: 10 trinn
TinyLiDAR in Your Garage !: DIY WiFi Garage Door Opener Project IoT -verden begynner bare å eksplodere - hvert teknologiselskap rundt om i verden prøver å finne ut hvordan de vil passe inn i denne nye verden. Det er bare en stor mulighet! Så for dette instruerbare, jeg
Kan jeg bruke TinyLiDAR i Scratch ?: 3 trinn
Kan jeg bruke TinyLiDAR i … Scratch ?: Vi får av og til forespørsler om å spørre om tinyLiDAR vil fungere på deres spesielle databehandlingsplattform. Selv om tinyLiDAR ble designet som en brukervennlig LiDAR -sensor for Arduino UNO, er det ingenting som hindrer den i å bli brukt på andre plattformer
TinyLiDAR på en Pi?: 9 trinn (med bilder)
TinyLiDAR på en Pi?: Hei igjen! Vel, nå som du har brukt litt kvalitetstid med tinyLiDAR og din Arduino - kan din Raspberry Pi kanskje føle deg litt ensom;) Pi har vel en I2C -port? Så hvorfor ikke koble den til og prøve den der ?! God plan, men hvis du allerede har tr