Videoen kan bruke opp til et par minutter på å laste inn.
Avsluttende oppdatering
Oppgaven er levert.
Resultatet av oppgaven er todelt. Den ene delen er en programvareløsning der vi blant annet har utarbeidet en kommunikasjonsprotokoll. Protokollen reduserer sendetid og dermed strømforbruk ved å sende data så komprimert som mulig.
Den andre delen er en maskinvareløsning som består av mikrokontrolleren, sensorene og en innkapsling.


Oppdatering uke 20 og 21
Rapportskrivingen er i full gang.
Vi har et røft førsteutkast til teorikapittelet som må sorteres, men innholdet er på plass.
Nå kan vi endelig skrive om hva vi faktisk har gjort og ikke bare teorien som ligger til grunn.
Oppdatering uke 19
Vi er ferdig med den praktiske delen av prosjektet.
Etter noen iterasjoner har vi også en prototype av innkapslingen. Disse er 3d-printet slik at vi har noe håndfast å vise.

Hvis vi får tid vil denne utbedres, men nå er det rapportskriving som står i fokus.
Vi har allerede skrevet noen sider, men vi er langt fra ferdig. Teorikapittelet begynner å ta form og vi gleder oss til å skrive om hva vi har gjort.
Oppdatering uke 18
Forrige uke skrev vi at vi hadde problemer med SPI-grensesnittene. Vi fant ut at problemet kom av at LoRa-radio driverne formaterte SPI-bussen på en måte som gjorde at sensordriverne våre ikke fungerte.
Etter vi fikk løst dette problemet fungerte alle driverne som de skulle, da fungerte også kodingen som blir gjort av sensordataen som skal sendes over LoRa-nettet. Nå kan altså alle sensorene slås av og på som ønsket i programmet, og pakkestørrelsen på LoRa-sendingen blir justert avhengig av hvor mange sensorer som er satt på.
Neste oppgave var å gjøre det mulig å ta i mot sendinger fra kommunen. Dette var for at kommunen skal ha mulighet til å sende innstillinger til de forskjellige sensorene over Lora-nettet, i stedet for å laste opp ny kode til mikrokontrolleren hver gang noe skulle endres. Det var ønskelig å kunne justere periodetid for alle sensorene. Altså at det kan settes en periodetid for f.eks temperatur fra en sensor, samtidig som det blir satt en helt annen periodetid for lufttrykk fra en annen sensor. På denne måten kan pakkestørrelsen bli holdt så liten som mulig, da info som ikke endrer seg så ofte heller ikke blir sendt ofte.
Da dette fungerte var hele programmeringsdelen av prosjektet ferdig! Vi jobber fremdeles med innkapsling til alle delene, men annet enn det så er den fysiske delen av prosjektet ferdig.
Oppdatering uke 17
Vi har fullført sensordriverene, men sliter med at det er en konflikt på SPI-grensesnittene. Vi tror det er konflikt mellom en av sensorene og LoRa-radioen. I mbed har brukeren begrenset tilgang på LoRa-grensesnittet, så vi får ikke sett akkurat hva som skjer.
Kodingen av meldingene har tidligere vært ASCII-kode på heksadesimalt format. Dette er veldig ineffektivt, så vi har jobbet med å lage vår egen protokoll.
Denne uken har vi også jobbet med innkapsling til systemet. Her er førsteutkastet:

Vi har noen ideer om hvordan vi skal legge til rette for sensorene, men har ikke bestemt oss for en løsning enda. Førsteutkastet viser om ikke annet at målene er riktige for mikrokontrolleren.
Oppdatering uke 16
Vi har så og si fullført sensordriverene. Vi mangler kun driver for én sensor som vi er godt i gang med. Validering av målingene er litt utfordrende da vi ikke har noe forhold til hvor store verdiene skal være. UV-sensoren måler synlige og infrarøde bølgelengder og bruker disse verdiene til å kalkulere UV. Derfor er det ikke så rart at avlest UV avviker litt fra det som rapporteres på nett. Forskjellige nettsteder rapporterer også forskjellig UV-indeks. Vi vet imidlertid at vanlig UV-indeks går fra 1-11+ og at rekorden ligger rundt 40.

Her så vi på synlig lys. Disse målingene var også annerledes enn forventet, men i ettertid innså vi at sensoren ikke var kalibrert disse målingene. For vårt bruk er ikke dette så nøye da vi bare er ute etter UV-indeks og fokus for oppgaven er trådløs kommunikasjon med LoRa.
Vi har også testet å måle og sende innetemperaturen i en bil.

Vi vet at denne sensoren er riktig kalibrert, slik at eventuelle feil ville være relatert til sending. Sendingene ble mottatt i kommunenettet uten problemer. I dette eksperimentet fikk vi også prøvd å drive mikrokontrolleren med batteri som var en nyttig erfaring.
Oppdatering Uke 15
Denne uken har vi sendt meldinger til The Things Network (TTN). Vi brukte eksempelkoden fra MBED som sender fiktive sensorverdier.
I konsollen i TTN vises de dekrypterte meldingene slik:
Meldingene er heksadesimale koder for ASCII-tegn. Når vi dekoder disse, ser vi den opprinnelige meldingen.
Vi har også prøvd en funksjon for å kartlegge LoRaWAN-dekningen som kalles TTNmapper. Her er et utsnitt av resultatet vi fikk i Lillestrøm.
Oppdatering Uke 14
Sammen med en av våre veiledere, ble vi i forrige uke enig om å bruke MBED i stedet for ST. MBED er noe enklere å bruke og forstå, så denne uken har vi jobbet med programmering i MBED.
Nå sitter vi å tester en av sensorene vi skal sende data fra over LoRaWAN. Dette er en nivåmåler, som monteres under vannbeholdere og måler nivået i denne ved hjelp av ultralyd. Den gir ut et nivå mellom 0 og 400 i millimeter.
Her vises resultatet av målingen i Tera Term.
Oppdatering Uke 13
Sammen med våre veiledere har vi blitt enig om å skifte fokusområde. Vi har tidligere hatt fokus på PCB-design, men vil nå sette fokuset på software-utvikling.
Vi har kjørt et eksempelprogram fra ST, og fikk til noen sendinger over LoRaWAN.
Foreløpig er vi ikke i mål og har noen problemer med å forstå programmene fra ST, men det jobbes med.