EXAMENSARBETE Trådlös, beröringsfri temperatursensor med insamlingssystem Förbättring/vidareutveckling av prototyp Oskar Ederlöv 2013 Högskoleingenjörsexamen Elektroteknik Luleå tekniska universitet Institutionen för system- och rymdteknik
Trådlös, beröringsfri temperatursensor med insamlingssystem Förbättring/vidareutveckling av prototyp Oskar Ederlöv Högskoleingenjörsexamen Elektroteknik 13 september 2013
Sammanfattning Mitt uppdrag var att undersöka om det fanns potential att förbättra en befintlig prototyp som Actegra AB hade utvecklat. Prototypen är ett system för att övervaka delar i konstruktioner, t.ex. takstolar, broar med mera. Detta sker genom avläsning av en rad trådlösa givare som sedan skickar data till en gateway som är ansluten till Internet. Gatewayen har i sin tur en websida där användaren enkelt kan läsa av datat via dator eller t.ex. smartphone. De förbättringarna som efterfrågades var framförallt en radio-modul som även var programmerbar samt hade lägre strömförbrukning än den befintliga radio-modulen. Eftersom delar av systemet är batteridrivna så är strömförbrukningen en viktig del. Prototypen hade endast en IR-sensor för temperaturavläsning och uppdragsgivaren önskade både en accelerometer och någon form av trådtöjningsgivare samt möjlighet att ansluta ytterliga sensorer. En annan del i uppdraget var att undersöka om hårdvaran för gatewayen gick byta ut till en annan. Skälet till detta var att befintlig hårdvara hade ett förhållandevis högt inköpspris och bättre alternativ fanns. Till sist skulle jag göra några mindre visuella ändringar på websidan som visar datat.
Innehållsförteckning 1 Introduktion... 1 2 Teori... 3 2.1 Radio-moduler... 3 2.2 JenNet/ZigBee PRO... 3 2.3 Sensorer... 5 2.4 Eagle CadSoft... 6 3 Prototyp... 7 3.1 Fas ett... 7 3.2 Fas två... 8 3.2.2 Funktion... 9 3.2.3 Strömförbrukning... 9 3.3 Fas tre... 13 4 Resultat... 14 4.1 Radio-modul... 14 4.2 Gateway/hemsida... 15 5 Analys... 16 5.1 Diskussion... 16 5.2 Slutsats... 16 5.3 Fortsatt arbete... 17 Referenslista... 18
1. Introduktion Bakgrund: Det finns många tillfällen där trådlös dataöverföring kan vara att föredra. T.ex. i denna prototyp där mätningar ska göras på mer eller mindre svåråtkomliga platser. Produktidéen innefattar en eller flera radio-moduler med ett antal givare anslutna. Företaget jag har gjort mitt examensarbete hos heter Actegra AB och är ett litet lokalt företag i Skellefteå som arbetar främst med utveckling av trådlösa sensor-enheter för en rad olika applikationer. Företaget är relativt nystartat och består idag av två personer. Ett system av den befintliga prototypen innefattar en koordinatornod som tar emot data från alla mätnoder. Mätnoderna som sitter monterade på önskade mätplatser samlar in data från sina sensorer och skickar sedan informationen trådlöst till koordinatorn. Vid samma plats som koordinatornoden finns en gateway som är ansluten till Internet genom ett GSM-modem. Datat som koordinatorn samlar in vidarebefodras sedan via seriell-usb kabel till gatewayen som med ett python-skript lagrar det i en databas. Gatewayen har även en webserver installerad med en hemsida för att användaren enkelt ska kunna övervaka mätdatat systemet samlat in. Hemsidan visar både aktuella data och grafer på hur datat ändrats över tid. Det finns flera tekniker för den korta radiokommunikationen, exempelvis Zigbee, JenNet, Bluetooth, NFC, WiFi. Nuvarande prototyp bygger på en radio-modul utvecklad av Digi International med namnet XBee. Nämnda radio-modul finns i många olika upplagor men eftersom prototypen är batteridriven så används modellen på 1mW. Eftersom XBee modellen som används saknar programmeringsmöjligheter styrs givaren av en Atmel AtTiny2313 microprocessor. Givaren som är ansluten på den befintliga prototypen är en IR-sensor för beröringsfri mätning av temperatur. Gatewayen i befintlig prototyp är ett FoxG20 system [10] från Acme Systems. Uppdragsgivaren har gett mig i uppdrag att undersöka om XBee är rätt val för de önskemål de har på radio-modulen och även undersöka om det går ersätta den befintliga hårdvaran för gatewayen med en Raspberry Pi [9] från Raspberry Pi Foundation istället för FoxG20-gatewayen. Kraven för radio-modulen är: Låg strömförbrukning Programmeringsbar I²C samt-dio möjligheter Rätt prisläge Tillräcklig räckvidd 1
Syfte: Rapporten ämnar undersöka vilket val av radio-modul som är bäst lämpat för uppgiften. Samt redovisa mitt tillvägagångssätt i utveckligen av en ny förbättrad prototyp med stöd för ytterligare givare implementerat. Även att undersöka om det är möjligt att ersätta den befintliga gateway-enheten med en baserad på Raspberry Pi som är en betydligt mer prispressad hårdvara. Dessutom skulle några mindre visuella förändringar göras på webplatsen som körs internt i gatewayen. Målgrupp: Rapporten är skriven på ett sådant sätt att vissa förkunskaper inom elektronik, mikroprocessorer samt trådlös kommunikation är förutsatt. 2
2. Teori 2.1 Radio-moduler Arbetet inleddes med att undersöka om det fanns någon XBee modell som var programmeringsbar och som i sådana fall skulle ersatt den befintliga prototypens radiosändare. En programmeringsbar modell av XBeen identifierades, dock fanns dessa endast i en s.k. PRO version med strömförbrukning på 115mW istället för versionen på 1mW som användes på befintlig prototyp. Eftersom prototypen är batteridriven så lämpades inte denna radio-modul. Första frågetecknet var därmed besvarat, programmeringsbara XBees för ändamålet fanns inte att tillgå för denna tillämpning. Nästa steg blev att genomsöka marknaden efter radio-moduler som hade allt som prototypen behövde. Följande radio-moduler valdes ut och jämfördes. TX RX Sleep USRP* Frekvensband Räckvidd Radioprotokoll XBee [1] 45mA 50mA 10-50 µa 2.4GHz 100m Zigbee, Multipoint XRF RF [2] 36.2mA 23.8mA 0.2µA 868.3MHz 300m Multipoint/Mesh JN5148 [3] 15mA 17.5mA 2.6µA 2.4GHz 1km JenNet, ZigBee RFM73 [4] 30mA 23mA 3µA 2.4GHz 80m 1:6 Star network RN-41 [5] 65mA 35mA 2.5mA 2.4GHz 100m Bluetooth ZigBit [6] 18mA 19mA 6µA 2.4GHz 1km ZigBee *USRP User programmable Tabell 1 Alternativen med Bluetooth räknade jag bort ganska fort då de både var dyrare och hade högre strömförbrukning. Fick tidigt upp ögonen på Jennic JN5148 som verkade uppfylla samtliga önskemål, den var programmeringsbar, hade lägre strömförbrukning än konkurrenterna och hade alla ingångar och utgångar som prototypen behövde. Den modul som kunde konkurrera med JN5148 var ZigBit modulen från Atmel. Men som går att utläsa utav tabell 1 så har JN5148 något bättre specifikationer och därför valdes denna radio-modul. 2.2 JenNet / ZigBee PRO Valet av radio-protokoll stod mellan proprietära JenNet[7] och ZigBee[8] för JN5148 modulen. JenNet Proprietärt protokoll baserat på IEEE802.15.4 standard Stöder Star, Tree och linjära topologier Stöd för upp till 500 noder i samma nät Sleep-mode för slut noder lämpar sig för batteridrift ZigBee Bygger på IEEE802.15.4 standard Bygger på Mesh topologi Stöd för upp till 64000 noder i samma nät Sleep-mode för slut noder lämpar sig för batteridrift 3
Uppdragsgivaren önskade att jag skulle använda mig utav Jennics egna protokoll JenNet. I figurerna figur 1, figur 2 och figur 3 illustreras flödet i de olika rollerna som finns i JenNet protokollet. Koordinator: Basen i nätverket, finns bara en koordinator per nätverk. Loopar Starta Anslut till Ta emot data Skicka data nätverket noder från noder till webserver Figur 1 - Flödesschema för Koordinatorn Router: Mellannod, kan ha egna slavnoder som den får data från och sedan vidarebefodrar till koordinatorn. Kan även samla egen data som den skickar separat. Loopar Anslut till Ta emot data Samla Skicka datan nätverket från noder mätdata till Koordinatorn Figur 2 - Flödesschema för Router End device: Slutnod, typiskt den nod som samlar data. Kan gå ner i sleep-mode för att spara ström och med bestämda intervall vakna, samla in data och ansluta till router eller koordinator för att skicka informationen den samlat in. Loopar Anslut till Samla Skicka data Sov i X antal nätverket mätdata till Koordinatorn minuter eller router Figur 3 - Flödesschema för slut nod 4
2.3 Sensorer Prototypen ska kunna avläsa temperatur, accelerationsmätning i X, Y, Z för att känna svängningar i mätobjektet. Önskemål om en trådtöjningsgivare för att kunna mäta/övervaka yttre belastning på mätobjeketet, i form av snö, vind, fallande träd med mera, finns också. De första två sensorerna var enkla att bestämma, uppdragsgivaren hade redan en IR-sensor av modell Melexis MLX90614 som funkade bra för uppgiften och efter lite diskussion med uppdragsgivaren så önskade de att jag skulle använda mig utav en accelerometer av modell Analog Devices ADXL345. När det kom till trådtöjningsgivaren så läste jag på lite om dess funktion och undersökte hur man på bästa sätt kopplade upp dessa. Beslöt mig för att försöka balansera upp en trådtöjningsgivare med hjälp av en Wheatstone-brygga med tre motstånd och en trådtöjningsgivare. Även en operationsförstärkare och en multimeter användes för laborationen som illustreras i figur 4. Figur 4 - Testmiljö för trådtöjningsgivaren Det visade sig ganska snabbt att detta var ett svårt uppdrag. Att med endast en trådtöjningsgivare få stabila värden var väldigt svårt, då dessa är väldigt känsliga för yttre störningar t.ex. i form av förändringar i temperatur, luftfuktighet, material den är monterad på och så vidare. En Wheatstonebrygga med fyra trådtöjningsgivare istället för en trådtöjningsgivare och tre motstånd visade sig vara ett bättre alternativ för att få ett tillförlitligt mätresultat. Men även med den tekniken får man en givare som är väldigt känslig för störningar. Problemet med störningar medför att det är stor risk att att mätdatan driver iväg och tillslut ger helt felaktiga värden. Färdiga lastceller finns även som ett alternativ men även dessa använder sig av samma Wheatstone-teknik och dessa har en klassifiering i hur mycket mätdatat driver iväg över tid. Min efterforskning i ämnet visade att det är mycket svårt att få en tillförlitlig trådtöjningsgivar-lösning [12]. Inköpspriset på färdiga lastceller är dessutom väldigt högt. Efter lite diskussion med uppdragsgivaren bestämde vi oss för att söka efter andra möjliga lösningar för att kunna övervaka detta. Idéer fanns, men ingen som hann förverkligas under projektets tid. 5
2.4 CadSoft Eagle PCB För att kunna rita upp ett mönsterkort använde jag mig av ett program som heter CadSoft Eagle PCB [11], en programvara som är utvecklat av CadSoft Computers de. Själva programnamnet är en förkortning av Easily Applicable Graphical Layout Editor. Eagle är ett CAD-program som är väldigt populärt, dels hos mindre företag tack vare ett förhållandevis lågt pris för licenser, men även hos hobby-utvecklare då företaget erbjuder en freeware-version som har full funktionalitet förutom vissa begränsningar på hur stora kort man kan konstruera. När jag började använda Eagle hade jag ingen tidigare erfarenhet av programmet, men tack vare ett enkelt gränssnitt så var det relativt enkelt att sätta sig in och börja använda funktionerna direkt. En annan fördel med programmet är att man kan skapa gerberfilerna direkt i programmet. Gerberfiler är ritningsfiler som man i sin tur skickar in till mönsterkortstillverkaren som tillverkar korten. 6
3. Prototyp Prototypen utvecklades i olika faser, som beskrivs i de olika faserna nedan. Gemensamt för alla är att koden är skriven i programspråket C, utvecklad i utvecklingsmiljön Eclipse och kompilerad i ANSI C-kompilatorn gcc. Arbetet delades upp i olika faser för att först bekanta mig med hårdvaran och sedan arbeta mot en slutgiltig prototyp. 3.1 Fas ett Målet med fas ett var att få kontakt med JN5148 via seriell-usb kabel och skriva en enklare kod till den. Valet av testapplikation föll på att tända och släcka en lysdiod via en av modulens tjugo digitala in/utgångar. Figur 5 Kretsschema för fas ett För denna fas som var en enkel test-uppkoppling med lösa trådar använde jag mig utav en kopplingsbräda där jag kopplade upp en lysdiod med ett motstånd samt en spänningsregulator för att konvertera USB kabelns 5V till 3.3V som modulen behöver. Själva modulen är av ytmonteringstyp så trådar fick försiktigt lödas fast på den för att provköra. Koden skrevs sedan i Eclipse och flashades över till modulen genom programvaran Jennic flash programmer. När lysdioden blinkade på önskvärt sätt var det dags för fas två. 7
3.2 Fas två Målet med fas två var att upprätta trådlös kommunikation mellan två JN5148 moduler. Kretschemat i figur 6 visar anslutningarna som användes till slutnoden vars uppdrag var att samla datat från sina givare och skicka detta trådlöst till koordinatorn som i sin tur visade det på en laptop via terminalprogrammet Putty. Koordinatorns kretsschema är detsamma men utan givararna som ses till vänster på kretsschemat. Figur 6 Kretsschema för fas två I denna fas beslutades det även att göra en lite mer användarvänlig prototyp. Därför löddes modulen med alla komponenter fast på demokort med rätt offset. Två tryckströmbrytare monterades på kortet, en för att aktivera modulens programmeringsläge och den andra för att starta om modulen. På kortet som skulle agera slutnod, så löddes även en IR-sensor fast på kortet. Accelerometern som användes i denna fas var monterad på ett experimentkort och löddes endast fast med kablar för funktionstest och för att inte förstöra den för framtida bruk. 8
3.2.2 Funktion För att slutnodens givare skulle fungera krävdes det en del initiering. Båda givarna kommunicerar via I²C och spänningsmatas via radio-modulens digitala utgångar. Initieringen som görs varje gång modulen startar eller vaknar upp efter en sömnperiod är följande: DIO20 sätts till hög utgång för att ge matningsspänning till accelerometern. Samma gäller DIO19 för IR-sensorn och för DIO13, 17 och 18 om ytterligare givare anslutits. På DIO5, 14 och 15 återaktiveras pull-up som avaktiveras för att spara ström under sömn. Flashminnet startas och I 2 C bussen initieras med rätt inställningar och startas upp. 3.2.3 Strömförbrukning Eftersom att hålla nere strömförbrukningen var viktigt lades relativt mycket tid på att både mäta upp och testa olika inställningar för att uppnå så låg förbrukning i inaktivt läge som möjligt. Denna del gäller endast slut-noden då det bara är den som kan gå ner i sleep-mode. Koordinatorn måste alltid vara vaken enligt JenNet-protokollet. Eftersom sensorenheten är ämnad att läsa av värden en gång i halvtimmen så var det viktigaste att få ner förbrukningen i sleep-mode. Många olika inställningar testades innan slutgiltiga inställningarna hittades. Följande görs varje gång före sleep-mode aktiveras för att spara ström: DIO13, 17, 18, 19 och 20 sätt som ingång med avaktiverad pull-up samt att pull-up avaktiveras på DIO5, 14 och 15. Flashminnet, I 2 C bussen och UART avaktiveras. Med dessa inställningar fick jag ned strömförbrukningen i sovande läge till väldigt låga nivåer. Förbrukningsnivåerna som tas upp på nästa sida är uppmätt med en Fluke 45 multimeter inkopplad mellan USB kabelns 5V och utgången från spänningsregulatorn som reglerar spänningen till 3.3V. Vid denna mätning uppmättes strömmen under sömn till 4µA. Enligt databladet för JN5148 så ska modulen ha en förbrukning vid aktiv sömn på endast 2.6µA, något jag inte lyckades uppnå men de uppmätta 4µA så var förbrukningen nere i så pass låga nivåer så jag avslutade mina tester för att optimera förbrukningen. Det är värden som är klart bättre än den gamla prototypen kunde erbjuda enligt datablad. Batteriet som används i prototypen är på 2600mAh och figur 7 visar den beräknade batterilivslängden för de två olika varianterna om dessa skulle vara sovande hela tiden. XBeens förbrukning vid sömn är 50µA med den inställning som används på den gamla prototypen. 9
År Standby tid i år 80 70 60 50 40 30 20 10 XBee JN5148 0 Tid XBee Tid JN5148 Figur 7 - XBee 6år och JN5148 74år I praktiken så sover inte modulerna hela tiden, utan de önskemål jag fick av uppdragsgivaren var att modulen skulle ta mätdata en gång var trettionde minut. Figur 7 visar en tydlig skillnad och var enkelt att mäta upp exakt. För att få fram den faktiska driftstiden på ett batteri måste vi anta lite värden att räkna med och tappar lite precision. Vad vi vet exakt är att modulen skall göra mätningar var trettionde minut, jag uppskattar, och räknar med att det tar 300 millisekunder för modulen att göra sina uppgifter innan den sover igen. Av de mätningar jag gjorde med Fluke 45 kunde jag se att modulen tar cirka 22mA i drift och 4µA i sovande läge. Av detta får vi följande uträkning: En periodtid på trettio minuter, i 300 millisekunder av dessa förbrukar den 22mA. Tillsammans ger det en duty-cycle. Förbrukning Duty cycle (%) Summa I drift 22mA 0.016 ~3.66µA I sleep 4µA 99.984 ~4µA Total förbrukning under en mätperiod: ( ) Driftstid per batteri: ( ) 10
Driftstid i år Figur 8 illustrerar driftstiden på ett batteri beroende på antal aktiveringar per timme. I figuren kan vi se en mycket hög driftstid per batteri, även vid många mätningar per timme. 60 JN5148 - Tid i drift / aktivering 50 40 30 20 Tid i drift / aktivering 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Antal aktiveringar / timme Figur 8 - Driftstidskurva för JN5148 Motsvarande kurva för XBee-prototypen visas i figur 9, värt att påpeka om denna är graf är att inga mätningar är gjorda på XBee modulen utan endast värden från databladet för radio-modulen samt Atmel AtTiny2313 är använda. Modulen i denna prototyp är enligt uppdragsgivaren aktiv i tre sekunder varje gång den vaknat, att det tar så mycket längre tid för den gamla prototypen att göra en aktivering beror på att den synkroniserar modulernas interna klockor vid varje aktivering. Uppdragsgivaren har provkört prototypen över längre perioder och ett batteri räckte endast sex månader med en periodtid på trettio minuter. Att uppdragsgivarens tester inte stämmer överrens med grafen kan bero på diverse inställningar som eventuellt har missats före sömnperioden aktiveras eller en längre tid i aktivt läge än de tre sekunderna som med i beräkningarna för grafen. Sömn-inställningen som används för att sätta XBeen i sleep-mode är cyclic sleep och den förbrukar som tidigare nämndes 50µA med den inställningen för sömn. 11
Driftstid i år Driftstid i år XBee + Atmel - Tid i drift / aktivering 3,5 3 2,5 2 1,5 Tid i drift / aktivering 1 0,5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Antal aktiveringar / timme Figur 9 - Driftstidskurva för XBee + Atmel Graferna illustrerar en tydlig förbättring i driftstid på den nya prototypen. Först vid så många aktiveringar som 48 per timme för JN5148 så ligger driftstiden på samma nivå som XBeen har vid en aktivering per timme. Figur 10 visar en sammanställning av dessa två grafer för en tydligare bild av driftstiden för dom olika prototyperna. 60 JN5148 vs XBee - Tid i drift / aktivering 50 40 30 20 JN5148 XBee 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Antal aktiveringar / timme Figur 10 - Driftstidskurva för JN5148 vs XBee 12
3.3 Fas tre Målet med fas tre var att i så stor utsträckning som möjligt göra en fungerande prototyp redo för produktion. För detta behövdes det konstrueras ett mönsterkort, som jag ritade i programmet CadSoft Eagle. Figur 11 visar det färdiga kortet direkt från mönsterkortstillverkaren utan några komponenter monterade. Figur 11 - Kretskortet utan komponenter För att programmera prototypen så löds en 6 pins kontakt fast uppe till vänster på kortet för att kunna ansluta en seriell kabel, beroende på om man har en seriell kabel av 5V eller 3.3V typ så monteras två brygg-kontakter fast och den man vill använda bryggas. Vid 5V spänningsmatning används en spänningsregulator för att reglera ner spänningen till 3.3V. För batteridrift så löds två tunna batterihållare fast i kortet [BH1] [BH2], för att batteriet skall sitta fast på ett bra sätt så skruvas en batteriklämma fast i kortet [BH3]. Nere i vänster hörn så monteras en bryggkontakt fast som ska bryggas för att sätta radio-modulen i programmeringsläge. Sensorerna som monteras på kortet är som nämdes i kaptitel 2.3 en accelerometer och en IR-sensor. Accelerometern i mitten till höger på kortet [IC3] och IR-sensor lite till vänster om mitten [IC2]. Radio-modulen monteras nere till höger väldigt nära kanten för att ge så mycket plats som möjligt över till andra komponenter [IC1]. För att enkelt möjliggöra montering av ytterligare sensorer monteradas PicoBlade kontakter [K1]-[K3]. Lådan som kortet skulle monteras i behövde viss modifikation för att passa med det nya kortet, detta för att antenn-anslutningen behövde flyttas i förhållande till hur den var monterad på den tidigare prototypen. 13
4. Resultat 4.1 Radio-modul För att få en så funktionell och praktisk slutprodukt som möjligt valdes en montering av batterihållare på kretskortet. Detta gjorde konstruktionen av mönsterkortet ganska utmanande, eftersom de flesta batterihållarna som fanns på marknaden var för stora för att rymmas på det relativt kompakta kortet. Uppdragsgivarens tidigare modell hade en batterihållare i locket på lådan som kortet satt monterat i, vilket hade sina nackdelar med risk för kabelbrott, svårare montering med mera. Dessutom monterades tre stycken kontakter av typ PicoBlade för att kunna eftermontera nya givare på ett enkelt sätt. Dessa kontakter har GND, I²C/CLK, I²C/DATA samt en unik DIO utgång för matningsspänning. Tanken med det var att man enkelt kan montera nya givare på kortet och sedan i enkelt i mjukvaran aktiverar utvalt DIO för att driva den nya givaren och enkelt kunna avvaktivera den igen före sömn-perioden för att minimera strömförbrukningen. När mönsterkorten kom från tillverkaren så konstruerades en stencil för att enkelt kunna applicera lodpasta. Med lodpastan på plats monterades kondensatorer, radio modul, accelerometer och picoblade kontakter för att lödas fast i en reflowugn. Efter detta löddes IR-sensor samt genomgående kontakter fast med en vanlig lödstation. Figur 12 samt 13 visar resultatet. Figur 12 Färdiga prototyper, i överkant koordinatorn och i underkant slutnoden. 14
Figur 13 - Slutnod Bilderna visar att det finns plats kvar på kortets yta och möjligheten för ytterligare komponenter på en senare revision av mönsterkortet finns. Största utmaningen med att konstruera mönsterkortet var att rymma montering av batteri på kortet, något som blev riktigt bra och möjliggör ett enkelt byte av batteri även med kortet monterat i lådan. 4.2 Gateway/hemsida Uppdragsgivaren hade en önskan om att byta hårdvara för gatewayen. Den bestod i befintlig prototyp av en FoxG20 med ett högt inköpspris. Jag blev ombedd att försöka att ersätta denna med en Raspberry PI som endast kostade en femtedel av priset för FoxG20. Uppdragsgivaren hade redan införskaffat en Raspberry Pi eftersom den hade alla anslutningar och den funktionalitet som krävdes. För att bekanta mig med Raspberryn kopplade jag upp den till en skärm, Internet och ett tangentbord. Sedan installerades alla paket som behövdes för att skapa en webserver. Följande paket installerades. Lighttpd en enkel och snabb websever PHP5 Programmeringspråket som websidan bygger på SQLite3 en liten lätt databas När alla paket var installerade återstod lite ändringar i inställningarna för att få allt att fungera som det skulle. När jag kunde ladda upp och besöka websidan på den nya webservern var förflyttningen från FoxG20 utförd. Raspberry Pin gick använda som webserver på samma sätt som FoxG20n. 15
5. Analys 5.1 Diskussion Med tanke på att XBee radio-modulen var något utdaterad så fanns det många vägar att gå för att lyckas förbättra prototypen. Det finns möjligtvis alternativ på radio-moduler som jag missat som kunde varit bättre för prototypen, men jag känner mig trygg i den fördjupning jag gjorde i ämnet före jag bestämde mig för JN5148. En fördel med XBeen är dock att det finns ett stort nätverk som använder sig utav den och möjligheten att hitta svar på eventuella problem under konstruktionen är större än för JN5148 som är en ganska ny produkt som inte så många har provat på ännu. Hur det ser ut om några år dock, kan bara framtiden utvisa. Att rita ett kretskort var inget som var med i specifikationen för mitt examensarbete men när den möjligheten kom så kändes det som något både väldigt lärorik och roligt även om det tog ett tag att få allt genomtänkt. Energieffektivisering är ju något som går fördjupa sig i nästan gränslöst, jag nöjde mig med mina uppmätta 4µA i sovande läge då jag kände att förbättringen från föregående prototyp var så pass stor, men nog fanns det möjligen utrymme för ytterligare optimering där. Databladet utlovade ju som tidigare nämnt 2.6µA. JenNet presenterade en begränsning i det att koordinatorn inte får sova. Detta var något som uppdragsgivaren bad mig kolla upp noggrannare, det hanns dessvärre aldrig med under arbetets tid. Som systemet ser ut nu där en gateway står och broadcastar all data behövs det fast spänningsmatning ca 1km (line of sight) ifrån slutnoden som samlar all data. Tack vare detta upplägg så går det enkelt mata koordinatorn direkt från elnätet och behovet för sömn på den är då inte särskilt stort. 5.2 Slutsats Rapporten visar att det fanns utrymme för förbättring i den befintliga prototypen. Den nya prototypen möjliggör en enklare produktion då all mjukvara ligger i samma modul, jämför med tidigare prototyp då radio-modul och microprocessor var separat. I enlighet med önskemålet som uppdragsgivaren hade. Dessutom, en kraftig ökning i driftstid på prototypen jämfört med föregångaren, något som alltid var prioriterat med tanke på att modulen kommer vara monterad på svåråtkomliga ställen. Detta togs upp under kapitlet Strömförbrukning [3.2.3]. Dessutom är hårdvaran som används till prototypen markant billigare än föregångaren, den nya radio-modulen har ett inköpspris på knappt hälften av föregångaren som dessutom behövde en separat microprocessor. Utrymme till förbättringar fanns och har utförts på ett bra sätt utifrån de önskemål jag fick i början av mitt arbete, det vill säga att hitta en radio-modul som var programmeringsbar, hade en låg strömförbrukning och lågt inköpspris och sedan bygga en ny prototyp runt den. Den andra delen i projektet var att byta ut hårdvaran för gatewayen, något som var relativt enkelt och inget som tog upp speciellt mycket tid av arbetet. Detta på grund av att uppdragsgivaren redan hade valt ut Raspberry Pi som de alternativ de ville testa och inga förstudier om andra alternativ behövdes göras. Syftet med bytet var främst att sänka kostnaden samt öka tillgängligheten och förhoppningen var endast att Raspberry Pi skulle gå använda på samma sätt som FoxG20. 16
5.3 Fortsatt arbete Det som inte hann lösa sig under arbetets tid var problematiken med trådtöjningsgivaren. Det fanns några idéer som bör undersökas vidare. Montering av andra möjliga givare får också vara något för denna rubrik. Att hitta en lösning för att få koordinatorn att sova är också något för framtiden. Lyckades hitta information i ett elektronikforum som tydde på att det fanns användare som hade lyckas med det, så troligen finns det en lösning. 17
Referenslista 1 XBee datablad. Hämtat 05/2013 från https://www.sparkfun.com/datasheets/wireless/zigbee/xbee-datasheet.pdf 2 XRF wireless RF datablad. Hämtat 05/2013 från http://ciseco.co.uk/downloads/documents/datasheet%20-%20xrf%20v1-6.pdf 3 Jennic JN5148 datablad. Hämtat 05/2013 från http://www.jennic.com/files/product_briefs/jn-ds-jn5148mo-1v4.pdf 4 HopeRF RFM73 datablad. Hämtat 05/2013 från http://www.hoperf.com/upload/rf/rfm73_datasheet.pdf 5 Rouving Networks RN-41 datablad. Hämtat 05/2013 från http://dlnmh9ip6v2uc.cloudfront.net/datasheets/wireless/bluetooth/rn-41-ds-v3.3r.pdf 6 Atmel ZigBit datablad. Hämtat 05/2013 från http://www.atmel.com/images/doc8226.pdf 7 JenNet protocol stack. Hämtad 05/2013 från http://www.jennic.com/products/protocol_stacks/jennet 8 ZigBee specifications. Hämtat 05/2013 från http://www.zigbee.org/specifications/zigbee/overview.aspx 9 Raspberry Pi Hämtad 04/2013 http://www.raspberrypi.org/ 10 FoxG20 Hämtad 04/2013 http://www.acmesystems.it/foxg20 11 Cadsoft Eagle Hämtad 05/2013 http://www.cadsoftusa.com 12 Strain Gage Thermal Output and Gage Factor Variation with Temperature hämtad 04/2013 http://www.vishaypg.com/docs/11054/tn504.pdf 18