Energiförbrukning i ett batteridrivet NB-IoT-baserat system
Man kan lätt förledas att tro att det är enkelt att konstruera batteridrivna IoT-system med extremt låg energiförbrukning. Men det finns massor av möjliga problem på vägen och det är viktigt att hela tiden kontrollera att man är på rätt spår. Här kommer ett praktikfall där ett batteridrivet IoT-system används för att effektivisera äppel- och vinodlingar i södra Sverige.
Bakgrunden är att jag i ett projekt tagit på mig att programmera våra nya NB-IoT-baserade mätstationer, i samma stil som tidigare de Sigfox-baserade d:o. Mätstationerna är till för användning i fält (bokstavligt talat) inom den svenska odlingsnäringen.
Med tanke på all hype kring NB-IoT, var jag angelägen att se hur bra medias NB-IoT-utsagor stämde med verkligheten. För hur många har inte, liksom jag, hört att man ska kunna driva ett (ospecificerat) system som skickar data över NB-IoT i upp till 10 år med ett (ospecificerat) batteri?
Jag har sett den utsagan i skrift flera gånger men har, baserat på erfarenhet av GPRS för samma typ av tillämpning, lite svårt att tro att de egenskaperna kan kombineras i kommersiellt gångbara, hanterbara system. Så därför behövde jag verifiera energiåtgången i detalj för att se om tekniken höll vad den lovade, så vi kunde använda den i projektet.
Den digitala bondepraktikan
Projektets fulla namn är ”IoT och AI för att öka konkurrenskraften i svensk frukt- och vinproduktion” och är ett EIP-Agri-projekt finansierat via Jordbruksverket. En alternativ och enklare beskrivning är ”Den Digitala Bondepraktikan”.
Några av kraven på systemet är som följer: Det skall vara – batteridrivet; ruggat (för fältbruk ute i äppel- och vinodlingar); robust (dvs. kunna starta om sig självt vid olika slags störningar); erbjuda säker (krypterad) dataöverföring (med kvittens), bygga på befintlig WAN-teknik för att vi skall slippa bygga egen infrastruktur, vara underhållsfritt, ha så låg energiförbrukning att det räcker med en 10×15 cm solpanel för långsiktig (åratal) strömförsörjning, etc.
För ett tag sedan hade jag dessutom kommit i kontakt med ett relativt nystartat företag (Qoitech AB) på Ideon i Lund, som utvecklat ett mätsystemskoncept optimerat för att kolla energiförbrukningen i batteridrivna system. Konceptet består av två delar, dels mätmodulen som kallas Otii Arc, dels mätprogramvaran Otii. Systemet säljs bl.a. via DigiKey.
Första mätstationerna
Sagt och gjort – jag hade just placerat ut de första NB-IoT-mätstationerna på Flyinge vingård, för att samla in data från ett 10-tal olika givare per mätstation. Allt ifrån väder och vind till markfukt och marktemperatur. Eftersom jag tidigare använt liknande mätstationer från samma tillverkare, men för Sigfox, antog jag (naivt nog visade det sig) att dokumentationen för NB-IoT-varianten skulle vara lika korrekt, speciellt kring hur man får enheterna att gå ner i ”sleep mode” för lägsta möjliga energiåtgång.
Data hade nu börjat ackumuleras på projektets mätinsamlingsserver, men då jag studerade den datan mer i detalj såg jag till min förskräckelse att mätstationernas registrerade kvarvarande batterikapacitet föll långsamt men monotont mot noll, trots installerade solpaneler för att ladda desamma. Vad var fel?
Enligt leverantörens, av NB-IoT-modemet, datablad, kan man läsa att den typiska strömförbrukningen i ”Power Saving State” skall vara c:a 10 µA; och i ”connected mode” mindre än 78 mA medelström. Med kunskap om att MPU-kortet och mätkortet i systemet tillsammans drar mindre än 40mA i drift och några 10-tals µA i ”sleep mode”, så tänkte jag att hela systemet i drift borde dra mindre än 120 mA, och mindre än 1 mA sovande, allt från ett 6.6 Ah Li-jon-batteri på nominellt 4.2 V. Döm då om min förvåning när jag kopplat in min Otii Arc till mitt system under testning (SUT), och det visade sig att jag inte kunde få mitt SUT att starta korrekt. Det körde några rader i koden, fram till initiering av NB-IoT-modemet och bootade sen om.
Varför?
Det är här Otii Arc kommer in i bilden. Otii Arc är inte bara ett verktyg för att karakterisera batterier, utan även en PSU med detaljloggning, med 1ms upplösning, av spänning och ström för ett SUT. Räcker det att mäta strömmar under 19 mA, så ökar upplösningen till 250 µs. Jag körde Otiin i strömförsörjnings-mod nu, med utspänningen satt till 4.20 V och strömbegränsningen satt till 1.5 A. Se bilden nedan som visar en markerad full cykel i aktiv mod med en strömspik på 1.42 A, när NB-IoT-modemet går igång!
Inställningen var för snål, visade det sig, och funkade inte, för något i mitt SUT drog uppenbarligen mer ström än så. Det visade sig vid detaljstudie av loggen att jag här hade en startströmpuls på strax under 1.5 A (senare mätningar visade att jag som mest hade 1.9 A) under ett par millisekunder.
Pulsen är kort, men icke desto mindre där, som Otiin så enkelt och tydligt visar. Strömpulsen var nog för att sänka matningsspänningen så lågt så att systemet bootade om, vilket var vad som hände i det dessa fall. Inte hade jag kunnat gissa att även NB-IoT-modem, med en teknik som skall vara avsedd för batteridrivna system, drar nästan lika mycket startström som ett ”gammalt” GPRS dito!
Nåväl – efter att ha insett att jag kan leva med startströmspulsen, genom att försäkra mig om tillräckligt låg impedans från spänningsmatningen, så gjorde jag ytterligare mätningar där jag ökade Otiis värde för strömbegränsningen till 3 A (och spänningen till 4.30 V för att kompensera för lite matningsledningsspänningsfall), och se – nu kör systemet.
Men inte som jag tänkt. För loggen visade att, där jag efter c:a 1.5 minut programmerat hela systemet att sova, så drog det fortfarande 110 mA :-/. Se bilden nedan som visar strömförbrukningen under 1 minut (av 30) i ”Sleep mode” för mitt SUT.
Jag hade alltså en medelströmförbrukning i viloläge som hela tiden låg på c:a 110 mA och som mer än väl förklarade batterifenomenen jag sett i insamlade data från fältet. Systemet gick alltså inte ner i sov-läge som det skulle, enligt programkoden. Bilden nedan visar Otiis tolkning av mitt systems sov-läge.
Efter ytterligare studium av manualer, användargruppsinlägg etc., kom jag fram till att jag skall stänga av NB-IoT-modemet helt, mellan mät- och sändningstillfällena. Det kostar visserligen en startströmpuls varje gång, samt tid för komplett uppkoppling, registrering och senare nedkoppling från nätet, men det borde mer än väl kompenseras genom lägre viloström, hoppades jag. Efter övlig omprogrammering så var det dags för en ny test med Otii Arc inkopplad, för att förhoppningsvis verifiera mina teorier. Jag hade åxå minskat systemets samplingsintervall till 3 minuter i stället för 30, för att snabba upp testen.
Resultatet uppfyllde mina förväntningar, som man kan se av nästa bild som visar ström och energiförbrukning för 1 av systemets 30 vilominuter, per cykel.
Viloströmmen blev i genomsnitt 679 µA, och lägre än mitt mål på 1 mA.
Rimlig viloström
Nu hade jag då med Otiis hjälp, verifierat att jag nu fått ner viloströmmen i systemet till väl under 1 mA, vilket jag bedömde som rimligt, utan att spendera ytterligare tid på optimering där. Samtidigt kunde jag verifiera att MPU och mätkort drar c:a 16 mA tillsammans, samt att modemet drar c:a 100 mA i aktiv mod. Detta kan man läsa ur Otiins diagram nedan. Märk väl att denna mätsekvens över 4 mät-, dataöverförings- och viloperioder är hela 12 minuter, med 1 ms upplösning!
En summering av NB-IoT-mätstationens energiförbrukningsegenskaper så här långt, antyder att systemet med nuvarande programmeringsstrategi klarar sig i nästan 2 månader utan solcellsbidrag, t.ex. om solcellen skulle bli insnöad. Eftersom ingen jag pratat med sett snö ligga så länge i Skåne i modern tid, så får den här delen av projektet nu anses som färdig, med uppfyllda mål.
Det visade sig dessutom att Otiin, med sitt användargränssnitt gjorde det mycket enkelt att beräkna energiåtgången för godtyckliga exekveringsavsnitt i grafen – Otii räknar nämligen själv ut åtgången i valt segment i Wh/mWh/µWh – mycket praktiskt. Självklart kan man spara mätningarna, av spänning och ström, för senare studium. Så här i efterhand tror jag inte att jag skulle kunnat göra samma mätningar ens med något av mina moderna minnesoscilloskop. Otii framstår så här långt som den enklaste och bästa logger jag använt för verifikation av energiförbrukningen i detalj, i system avsedda för batteridrift.
Avslutningsvis – kan man köra ett ”rimligt” NB-IoT-system i 10 år på ett ”rimligt” batteri? Den frågan återstår att utreda, nu när jag har fått tillgång till bättre verifikationshjälpmedel än tidigare, och fått mer erfarenhet av tekniken. Sic!
Olle Hydbom, AutoIDExpert Scandinavia
fristående konsult inom områdena mätteknik och logistik
Filed under: SvenskTeknik
