Smart Bolig P4 Projekt Gruppe 414 Elektronik & IT Aalborg Universitet Den 27. maj 2014

Transkript

1 Smart Bolig P4 Projekt Gruppe 414 Elektronik & IT Aalborg Universitet Den 27. maj 2014

2

3 Institut for Elektroniske systemer Elektronik og IT Fredrik Bajers Vej 7B 9220 Aalborg Øst Tlf.: (+45) Titel: Smart Bolig Projekt: P4 projekt - Design af Digitale Systemer Projektperiode: Februar Maj 2014 Projektgruppe: 414 Gruppemedlemmer: Anders Toft Kopi Sambulingam Ole Høj Mariendal Jørgensen Simon Boelt Jensen Steffen Raahede Søren Martinsen Synopsis: I denne rapport vil problemstillingen, hvorvidt det er muligt at udvikle et system der kan styre en bolig, med særlig fokus på temperatur, tyverialarm og overvågning af vandgennemstrømning. For at underbygge idéer og forslag er der i projektforløbet tilegnet viden gennem informationssøgning. Til udviklingen af prototypen er der taget udgangspunkt i eksisterende teknologier indenfor de respektive områder. I projektforløbet er der som tidligere nævnt ikke produceret et fuldt udviklet produkt, men en prototype der demonstrerer modulernes funktionaliteter og principper. Vejleder: Flemming B. Frederiksen Oplagstal: 8 Sidetal: 378 Appendiks: 4 Bilag: 11 Afsluttet Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

4

5 Forord Denne rapport er udarbejdet af gruppe 414 på 4. semester. Der rettes tak til gruppens vejleder Flemming Bjerge Frederiksen, som gennem projektet er kommet med kommentar og vejledning til projektet. Projektet har forløbet i perioden 2. februar til 27. maj 2014, med projekttemaet Design af Digitale Systemer. Denne rapport har hovedtemaet Styring af Sommerhus, hvor der har været fokus på styring af temperatur, overvågning af vandgennemstrømning samt tyverialarm. Dette styres af en FPGA, som er koblet op til et WiFi-modul. Systemet styres fra en lokal terminal eller en webside, som via en server er koblet op til WiFi-modulet. Derudover rettes der også tak til afdelingen for Radio Access Technology hos Institut for Elektroniske systemer, der har udlånt WiFi-modulet. Læsevejledning I det følgende vil der gives en beskrivelse af hvordan rapporten er opbygget. Der vil indledningsvist blive analyseret på problemstillingen og eksisterende teknologier som påvirker projektets videre forløb. Efterfølgende bliver der opstillet krav som skal bruges til at udvikle modulerne og brugerfladerne i systemet. Der vil herefter gives en forklaring af systemets fysiske og tekniske opbygning samt dertilhørende illustrationer og eksempler i passende omfang. For at teste modulerne og brugerfladerne er der i slutningen af hvert afsnit i systemdesign foretaget tests der tester de respektive funktionaliteter. Der er herefter foretaget en samlet systemtest for at efterprøve modulerne og brugerfladerne i et samspil. Afslutningsvist er der perspektiveret og konkluderet på projektforløbet. Rapportens forløb er som følger af figur 1. v

6 Gruppe 414 Indledning Kravspecifikation Systemdesign Accepttest Konklusion Figur 1. Struktur i rapporten. Der vil igennem rapporten fremtræde kildehenvisninger, som er samlet bagerst i rapporten i en kildeliste. Kilderne er skrevet iht. IEEE standarden. I teksten refereres en kilde med [et tal]. Dette tal indikerer hvilket nr. kilden har i kildelisten. I kildelisten er bøger angivet som: [forfatter, titel, udgave og forlag]. Internetsider er angivet som: [Titel, forfatter, hjemmeside, benyttet måned og år]. Avisartikler er angivet som: [Forfatter, tidsskrift, titel, kilde, udgivelsesdato, måned og år]. Figurer, tabeller og programkode er nummeret iht. deres respektive kapitler. Eksempelvis vil første figur i kapitel 1 hedde figur 1.1, dernæst 1.2 osv. Til hver illustration vil der være forklarende tekst. I det tilfælde at ingen data er tilgængelig til en given tabelrude, vil N/A blive anvendt. De vedlagte appendiks og bilag er angivet i kursiv, hvor appendiks er angivet med et bogstav og bilag er angivet med et nummer. Der er udover IEEE også valgt at anvende ISO Anders Toft Kopi Sambulingam Ole Høj Mariendal Jørgensen Simon Boelt Jensen Steffen Raahede Søren Martinsen vi

7 Indholdsfortegnelse Kapitel 1 Indledning Problemformulering Eksisterende teknologi Programmerbart/Intelligent hus Trådløs teknologi FPGA - Field-Programmable Gate Array Kapitel 2 Kravspecifikation Moduloversigt Overordnede krav Brugerflader Terminal Webside Overvågning af vandgennemstrømning Tyverialarm Temperatur Grænseflader Styring Brugerflader I/O enheder Kapitel 3 Systemdesign Systemoversigt Temperaturmodul Temperatursensor Varmekilde segment display Modultest Vandgennemstrømningsmodul Modultest Tyverimodul Modultest Webside Netværksprotokol Modultest - Webside Modultest - WiFi kommunikation Seriel Terminal VGA Synkronisering vii

8 Gruppe 414 Indholdsfortegnelse Tastatur Random Access Memory Generering af tekst Statisk tekst Samlet oversigt Modultest Systemscenarie Kapitel 4 Accepttest 69 Kapitel 5 Perspektivering 71 Kapitel 6 Konklusion 73 Litteratur 75 Appendiks A Målejournaler 79 A.1 Temperatursensor A.1.1 Formål A.1.2 Opsætning A.1.3 Materielliste A.1.4 Fremgangsmåde A.1.5 Resultater A.1.6 Fejlkilder og afvigelser A.2 Opvarmningsmodul A.2.1 Formål A.2.2 Opsætning A.2.3 Materielliste A.2.4 Fremgangsmåde A.2.5 Resultater A.2.6 Fejlkilder og afvigelser A.3 Tyverimodul A.3.1 Formål A.3.2 Opsætning A.3.3 Materielliste A.3.4 Fremgangsmåde A.3.5 Resultater A.3.6 Fejlkilder og afvigelser A.4 Vandgennemstrømningsmodul A.4.1 Formål A.4.2 Opsætning A.4.3 Materielliste A.4.4 Fremgangsmåde A.4.5 Resultater A.4.6 Fejlkilder og afvigelser A.5 Webside A.5.1 Formål A.5.2 Opsætning viii

9 Indholdsfortegnelse Aalborg Universitet A.5.3 Materielliste A.5.4 Fremgangsmåde A.5.5 Resultater A.5.6 Fejlkilder og afvigelser A.6 WiFi kommunikation A.6.1 Formål A.6.2 Opsætning A.6.3 Materielliste A.6.4 Fremgangsmåde A.6.5 Resultater A.6.6 Fejlkilder og afvigelser A.7 Terminal A.7.1 Formål A.7.2 Opsætning A.7.3 Materielliste A.7.4 Fremgangsmåde A.7.5 Resultater A.7.6 Fejlkilder og afvigelser A.8 Accepttest A.8.1 Formål A.8.2 Opsætning A.8.3 Materielliste A.8.4 Fremgangsmåde A.8.5 Resultater A.8.6 Fejlkilder Appendiks B Diagrammer 97 B.1 Diagrammer B.1.1 Temperaturdiagram B.1.2 Vandgennemstrømningsdiagram B.1.3 Tyverimoduldiagram Appendiks C Webside scenarier 101 C.1 Website scenarier Appendiks D FPGA Pinout 103 D.1 Pinout Bilag 1 RTX4100 Bilag 2 MAX3232CPE Bilag 3 7-segment display Bilag 4 AD7524 Bilag 5 ADC0820 Bilag 6 IRL530N ix

10 Gruppe 414 Indholdsfortegnelse Bilag 7 LE33 Bilag 8 LM35 Bilag 9 Spartan 3 Bilag 10 2Y0A021 Bilag S5 Bilag S5 x

11 1 Indledning I projektet ønskes der at udarbejde et digitalt system der kan fjernstyre en bolig. Dette system kan vise sig særligt fordelagtigt, hvis der ikke er nogen til stede i boligen. Denne mangel på tilstedeværelse kan lede til tvivl om hvorvidt der er slukket for varmen eller elektroniske apparater. Denne bekymring kan lede til ønsket om at kunne føre tilsyn med boligen når ingen er i hjemmet. Hvis tvivlen er berettiget, leder dette endvidere til unødvendigt varme eller strømforbrug. Et ønske brugeren kan have, er at få boligen forvarmet til en bestemt temperaturværdi inden brugeren kommer hjem. Med den teknologi der i dag findes, er det muligt at give en kommando til et elektronisk system der herefter udfører den ønskede handling. Denne løsning er dog ikke implementeret i størstedelen af de danske hjem, da teknologien er dyr at implementere.[1] Disse problemer samt ønsker leder til den initierende problemstilling: Hvordan kan sensorerne/målerne i hjemmet udnyttes til at styre hjemmet, ved hjælp af en kontrolenhed? For at kunne løse dette problem, skal der som omtalt udarbejdes et elektronisk system. Systemet skal være i stand til at aflæse en given værdi i hjemmet, sammenligne denne med brugerens ønskede værdi og tilpasse systemet på baggrund af dette. Der findes i dag, et utal af elementer i hjemmet der kan kontrolleres elektronisk. På tabel 1.1 fremgår nogle af de mest kendte. Temperatur Lys Fugt Alarmsystem Ventilation Radio/fjernsyn Vinduer Spa/sauna Gardiner Havevanding Overvågning af vandgennemstrømning Gulvvarme Hårde hvidevare Stikkontakter Tabel 1.1. Tabel over emner der kan kontrolleres i en bolig For at få en forståelse af hvordan elementerne i tabel 1.1 fungerer i praksis, er der opstillet et scenarie over en hændelse af produktets funktionalitet. Hvis der antages at en familie er på vej til deres sommerhus og de ønsker at huset er forvarmet til 21 C, kan de sende en kommando fra deres enhed med internetadgang. Denne kommando bliver 1

12 Gruppe 414 Indledning herefter videresendt til en styringsenhed som er forbundet til den pågældende hus varmesystem. Styringsenheden vil nu, alt afhængig af dens input, regulere temperaturen. I projektet vil der ikke blive arbejdet med samtlige punkter som ses på tabel 1.1. Der vil derfor blive afgrænset til hhv. alarmsystem, temperatur og overvågning af vandgennemstrømning. Disse områder vil der blive arbejdet med i den tekniske udførelse af projektet. For at kunne undersøge hvilke problemer der vil blive arbejdet med, er der i det følgende blevet udarbejdet en problemformulering. 1.1 Problemformulering I dette afsnit er der udarbejdet en problemformulering med henblik på at løse de tidligere omtalte problemstillinger. Problemformuleringen tager udgangspunkt i den initierende analyse og indledning. Problemformuleringen vil fremadrettet danne grundlag for projektets tekniske del. Hvordan kan et elektronisk system designes til at styre hjemmets apparater, enheder og målere. Der er nu blevet afgrænset til de moduler der ønskes at arbejde videre med i projektet. Ud fra problemformuleringen vil der blive undersøgt hvilke problemstillinger der skal løses og hvordan produktet skal konstrueres. 1.2 Eksisterende teknologi I dette afsnit vil der gives et overblik over de eksisterende teknologier, der vurderes at have indflydelse på de problemstillinger som udspringer af problemformuleringen. Teknologien bag nogle af de eksisterende teknologier vil indgå i den løsningsorienterende del af projektfasen Programmerbart/Intelligent hus For at kunne opbygge et system til styring af et hus, er det relevant at kigge på eksisterende teknologier til dette. Herunder vil de mest udbredte produkter på det danske marked blive beskrevet, for at give et indblik i hvad der allerede findes. Typer af styrbare huse Der findes i dag tre forskellige typer af teknologiske huse; kontrollerbare, intelligente og programmerbare huse. Disse typer vil kort blive ridset op i dette afsnit. Derefter vil afsnittet komme med eksempler på hvor de forskellige typer er anvendt. -Kontrollerbare huse Et hus med et kontrollerbart system indebærer at husets medieplatforme kan styres fra et centralt kontrolpanel. Dette kan fx være at panelet styrer fjernsyn, højtalere eller andre medier, som sidder i huset. Det der også kendetegner systemet er at det interagerer med stemmen eller bevægelse.[2] Et eksempel på et sådant system er fx B&Os Master Control Panel 5500, der er et system fra starten af 1990 erne. Dette system fra B&O, er et eksempel på et kontrollerbart system, som styres ved hjælp af knapper på et panel. Panelet styrer lyden i forskellige rum, og er forbundet med kabler.[3] -Intelligente huse Et intelligent hus kendetegnes ved at det kan reagere uden input fra brugeren. Dette medfører 2

13 1.2. Eksisterende teknologi Aalborg Universitet at huset lærer brugerens rutiner og adfærd og på baggrund af dette styres husets apparater. Dette består ikke blot af forskellige elektroniske moduler, men også en database hvori brugerens foregående rutiner bliver lagret. Ud fra disse rutiner lærer det intelligente hus, hvad brugeren i fremtiden ønsker. Herved kan der siges at det intelligente hus fungerer uden menneskelig indblanding. Intelligente huse er dog ikke lige så udbredte, som kontrollerbare og programmerbare huse. [2] -Programmerbare huse Programmerbare systemer er programmeret til at følge et bestemt program. Dette program styres af sensorer som modtager et input. Programmet tester herefter om inputtet matcher den ønskede værdi i programmet. Dermed kan systemet være sat op til forskellige værdier, som brugeren på forhånd har valgt. Disse værdier kan efterfølgende styre eksempelvis lys og fjernsyn. Herunder gives to eksempler på programmerbare huse.[2] Intelligent House Concept - IHC Denne udgave af programmerbart hus kontrol er produceret af Lauritz Knudsen og dækker et bredt område af kontrol muligheder. Herunder kommer en illustration af opbygningen i IHC på figur 1.1 og efterfølgende en liste af de kontrol muligheder der findes til IHC. [4] Figur 1.1. Principdiagram over IHC [5] Styring af: Lys Stikkontakter Varme Internet/LAN Alarm B&O - AV-produkter 3

14 Gruppe 414 Indledning Ventilation Gardiner, Vinduer m.v. Fordele og ulemper ved IHC: Fordele: Det er et populært system, hvilket medfører at der findes mange muligheder for tilkobling af udstyr. Det er muligt at styre husinstallationen over en mobil applikation eller via internettet. Må monteres af alle autoriserede elektrikere, dvs. det kræver ingen yderligere tilladelse at montere dette system. Ulemper: Det er påkrævet at der er et kabel fra kontrolenheden og ud til hver afbryder i huset. Økonomi Smart House Smart House startede med at lave varmestyringer, dette har resulteret i at deres varmestyring har været igennem en længere udviklingsproces end de fleste konkurrenters og er derfor mere stabil og præcis. Smart House systemet fungerer vha. et BUS-netværk, hvilket vil sige at der principielt set kan føres ét kabel rundt i huset til alle afbrydere, hver af disse afbrydere tildeles en BUS-adresse. Herunder kommer en illustration af opbygningen i Smart House på figur 1.2 og efterfølgende en liste af de muligheder der findes af kontrol ved et Smart House system: [6] Figur 1.2. Principdiagram over Smart House [7] 4

15 1.2. Eksisterende teknologi Aalborg Universitet Styring af: Lys Stikkontakter Varme Alarm Ventilation Gardiner, Vinduer m.v. Fordele og ulemper ved Smart House: Fordele: Da systemet kører over et BUS-netværk er det forholdsvist nemt at sætte nye enheder på. Det er muligt at styre husinstallationen over en mobil applikation eller via internettet. Ulemper: Da systemet ikke er udbredt i samme grad som IHC, findes der ikke standard løsninger til lige så mange ting. Ud fra ovenstående informationer om IHC og Smart House kan der konkluderes at et BUSnetværk er en god idé, da det er nemt at udvide installationen på dette. Derfor er der valgt at konstruere et system der er baseret på et BUS-netværk. Der vil ydermere blive udarbejdet et online interface så systemet kan tilgås over alt i verden. Systemet der fremadrettet arbejdes på, er baseret på de principper som det programmerbare hus er bygget på Trådløs teknologi I dag findes der forskellige teknologier som gør det muligt at kommunikere mellem forskellige elektroniske enheder trådløst. Dette afsnit har til hensigt at kortlægge forskellige former af disse teknologier, deres ulemper og fordele. Der tages udgangspunkt i de mest kendte former for trådløse teknologier. Infrarød Figur 1.3. Infrarød forbindelse mellem to enheder Infrarød fungerer ved at en lysdiode morser signaler til en modtager. Modtageren reagerer herefter i forhold til de signaler den modtager. Denne metode er billig, men har dog begrænset rækkevidde, da det ikke er muligt for lyset at passere igennem mure, træer og andre genstande som blokerer signalet.[8] Bluetooth 5

16 Gruppe 414 Indledning Figur 1.4. Bluetooth forbindelse mellem to enheder Bluetooth er en trådløs teknologi, som er meget anvendt til overførelse af data indenfor en rækkevidde op til 10 meter. Hvis der ønskes at anvende en rækkevidde større end 10 meter kan hardwaren forstærkes og rækkevidden derved ligeledes større, så alt afhængig af implementeringen kan rækkevidden forlænges. Bluetooth er en populær teknologi som er integreret i de fleste computere og telefoner, og det er en billig løsning med en rækkevidde som er bedre end infrarød. Bluetooth bruger ikke meget strøm og er derfor ideel til små mobile enheder. Fordelen ved Bluetooth er at det er muligt at parre enheder, hvor det samtidigt kan gøres sikkert med en adgangskode. Bluetooth fungerer over et frekvensbånd på 2.4 GHz til GHz, hvilket gør at Bluetooth i forhold til infrarød har en bedre evne til at gennemtrænge genstande der kan blokere signalet, som beskrevet i forrige afsnit om infrarød.[9] 6

17 1.2. Eksisterende teknologi Aalborg Universitet WLAN - Wireless Local Area Network Figur 1.5. WiFi forbindelse til et access point Wireless Local Area Network er en teknologi, der gør det muligt at sende data over forholdsvis store afstande med en lille sender, trådløst. Dette kan lade sig gøre fordi senderen i enheden ikke selv skal sende dataen til modtageren. Senderen i enheden skal kun sende data til et access point, der som oftest er tæt på enheden. Dette betyder at senderen i enheden ikke skal være i stand til at sende data over store afstande og den kan derfor gøres mindre. Access pointet er herefter forbundet til en server hos en internetudbyder. Dette betyder at WLAN fungerer som en kæde, der starter med en enhed som sender data til et access point, der igen sender dataen til en internetudbyder og herefter er dataen på internettet. [10] GSM - Global System for Mobile Communications Figur 1.6. GSM forbindelse til en sendemast GSM er en forkortelse for Global System for Mobile Communications hvilket er en teknologi som blev lavet til telekommunikation. GSM bliver brugt i 2G som er anden generation for mobile netværk, hvor der i dag, oftest anvendes 3G som bruger teknologien UMTS og 4G LTE. GSM er afhængig af en sendemast som oftest ejes af en teleudbyder, for at kommunikere til andre GSM enheder. Masterne gør det muligt at sende data over længere afstande, hvilket er en fordel indenfor mobilnetværk. GSM er dog ikke en billig løsning, eftersom der betales for dataforbruget over sendemasterne. Det er derfor nødvendigt med et dataabonnement fra en udbyder. [11] [12] 7

18 Gruppe 414 Indledning Fordele: Ulemper: Infrarød Bluetooth WLAN GSM Pris ($10x2) Strømforbrug Implementation Sikkerhed Rækkevidde Ikke kendt i enheder Pris ($15) Strømforbrug Kendt i enheder Implementation Rækkevidde Sikkerhed Rækkevidde Sikkerhed Kendt i enheder Pris ($30) Implementation Strømforbrug Rækkevidde Strømforbrug Kendt i enheder Pris ($60) Implementation Sikkerhed Tabel 1.2. Fordele og Ulemper Ud fra ovenstående er WLAN blevet valgt som den teknologi der vil blive brugt i projektet til at transportere brugerens ønsker til husets kontrolenhed. Dette er valgt da både infrarød og Bluetooth har begrænset rækkevide, mens at GSM er blevet mere og mere udfaset i forhold til internettet FPGA - Field-Programmable Gate Array I dette afsnit ønskes der at beskrive funktionaliteten af en FPGA samt dens berettigelse i projektet. FPGA en består af konfigurerbare logiske blokke som er forbundet af programmerbare koblinger. Disse egenskaber gør at FPGA en fungerer som en primitiv men hurtig mikroprocessor.[13] Der er valgt at anvende en Xilinx Spartan 3 FPGA som kontrolenhed. Som der ses på 1.7 vil FPGA en indgå i en direkte forbindelse mellem internettet og boligen. Her vil FPGA en tolke signaler modtaget over internettet og/eller terminalen, som indeholder kommandoer fra brugeren, og derefter eksekvere dem. Figur 1.7. Forbindelsen mellem FPGA og internettet. At anvende en FPGA som kontrolenhed har visse fordele og ulemper. Der er forholdsvist lave omkostninger ved at anvende en FPGA til prototyper, hvilket har stor betydning, hvis der ikke forventes at produktet bliver solgt i store mængder. En FPGA er fleksibel, da den er konfigurerbar både før og i brugsstadiet. Dette gør det muligt at finjustere og forbedre produktet i de afsluttende faser. Ulemperne ved brug af FPGA er som følger: Da en FPGA ikke er designet specifikt til ét produkt, har den lav ydeevne i forhold til specifikt designede kontrolenheder. I produktion af meget store mængder, bliver stykprisen for FPGA er 8

19 1.2. Eksisterende teknologi Aalborg Universitet højere i forhold til specifikt producerede kontrolenheder. Der kunne i projektet have været overvejet at udvikle en brugerdefineret kontrolenhed. Dette kunne være gjort i form af en ASIC - Application Specific Integrated Circuit, som er et integreret kredsløb der designes af producenten specifikt til et produkt og dermed ikke er rekonfigurerbar. I dette projekt vil der ikke blive udviklet en ASIC eller lignende, da det ikke er forsvarligt med hensyn til hverken pris, ydeevne eller tid. [14] Der er nu givet et indblik i hvilken problemstilling der er valgt at arbejde ud fra, samt hvilke teknologier og produkter der findes indenfor disse områder af projektets problemstilling. Der vil i næste afsnit blive beskrevet hvad der skal til for at løse disse problemstillinger, dette kan der læses mere om i næste afsnit Kravspecifikation. 9

20

21 2 Kravspecifikation I dette kapitel vil kravene for produktet blive beskrevet. Kravene er udarbejdet således, at de skal være grundlag for projektets videre forløb. Kravene er inddelt i hver deres respektive områder, alt afhængig af om kravene beskriver funktionaliteten eller teknikken. Kravspecifikationens hovedformål er at underbygge problemformuleringen og afslutningsvis indgå i accepttesten. 2.1 Moduloversigt Der udvikles en prototype som styrer enheder, hvor enhederne simulerer boligkontrol. Hertil er der valgt at udarbejde og implementere tre moduler der skal indgå i prototypen. Der skal udvikles et modul der skal kunne overvåge vandgennemstrømningen, et tyverimodul som der skal kunne styres og et modul som skal kunne styre temperaturen. Lokalt er der et modul med to 7-segment displays, som viser den nuværende temperatur i prototypen. Brugeren af systemet skal have mulighed for at fjernstyre systemet, dette gøres muligt via netværket vha. WLAN og et access point. Direkte betjening af systemet skal være muligt ved brug af en terminal som tilgås ved lokalt tastatur og display. Der ønskes i dette afsnit at give en oversigt over det samlede system, opdelt i moduler. Til dette formål er der lavet et blokdiagram. 11

22 Gruppe 414 Kravspecifikation input Betjening Styring output Figur 2.1. Overordnet blokdiagram over systemet Der er som forklaret i indledningen valgt en FPGA som kontrolenhed og er repræsenteret i blokdiagrammet ved Styring. Dette modul kan tage inputs fra enhederne, der kontrollerer de valgte elementer i boligen. Den har også mulighed for at give output, som er tekst til brugeren på det lokale display, eller besked på længere afstand via WiFi og internettet. Betjeningsmodulet repræsenterer de to interfaces som kan bruges til at betjene systemet, hhv. webside eller PS/2 tastatur og lokalt display Overordnede krav Følgende tabel 2.1 beskriver de overordnede funktionelle krav til produktet. Nr: Funktionalitet Krav: 1 Fjernstyring af bolig: Vandgennemstrømningen skal kunne overvåges. - Tyverialarmen skal kunne overvåges samt tændes og slukkes. - Temperaturen skal kunne overvåges og reguleres. 2 Lokal styring af bolig: Vandgennemstrømningen skal kunne overvåges. - Tyverialarmen skal kunne overvåges samt tændes og slukkes. - Temperaturen skal kunne overvåges og reguleres. Tabel 2.1. Tabel af de overordnede krav i projektet. Hvor: Kravene til Fjernstyring af bolig skal kunne udføres hvor som helst, hvis der er adgang til 12

23 2.2. Brugerflader Aalborg Universitet internettet. Kravene til Lokal styring af bolig skal kunne udføres ved en lokal terminal. 2.2 Brugerflader For at kunne anvende produktet på den tiltænkte måde, er det nødvendigt at have en brugerflade der gør det muligt at interagere med systemet. Denne brugerflade er i projektet delt op i to dele, hhv. en lokal terminal og en ekstern webside. Den lokale brugerflade er placeret ved FPGA en og består fysisk af et tastatur, et lokalt display og to 7-segment displays. Med disse enheder skal det være muligt at kunne sende og modtage informationer om systemets tilstande. Den eksterne webside har samme funktionaliteter som den lokale terminal, dog kan denne kommunikere med systemet over internettet og er derfor afhængig af en internetforbindelse Terminal Herunder kommer et tilstandsdiagram over terminalens funktionaliteter, se figur 2.2 FPGA Respons Passiv (a) Forespørgelse Input modtaget intet input PS2-Tastatur (b) Subsystemer (g) Behandler Input (d) VGA-Monitor (f) Forespørgelse Send data (e) Respons Figur 2.2. Tilstandsdiagram over terminalen Terminalen vil normalt befinde sig i tilstanden passiv (a) hvis der ikke kommer et input fra tastaturet (b), eller andre subsystemer (g). Når tilstanden passiv (a) er aktiv tjekker systemet kontinuert om der kommer inputs, når et input registreres kommer systemet over i behandler input (d) tilstanden, hvor inputtet bliver bearbejdet af systemet og derefter skifter systemet 13

24 Gruppe 414 Kravspecifikation tilstand til send data (e), i denne tilstand kan dataen enten blive sendt til det lokale display (f) eller til andre subsystemer (g) i FPGA en. Herunder kommer en række krav til den lokale terminal i tabel 2.2: Nr: Tilstands Tilstands navn: Krav: bogstav: 1 (b) PS/2-Tastatur Input fra tastatur 2 (f) VGA-Monitor Output til skærm 3 (g) Subsystemer Korrespondance med systemets moduler Tabel 2.2. Tabel over krav til den lokale terminal 1. Input fra tastatur via PS/2 port på FPGA en. 2. Output til displayet via VGA port på FPGA en. 3. Korrespondance med systemets moduler vha. interne signaler i FPGA en Webside Herunder ses et tilstandsdiagram over websidens funktionaliteter, se figur 2.3 Respons Passiv (a) Forespørgelse Bruger godkendelse (c) Input modtaget Intet input WIFI (f) Behandler Data (d) Bruger (b) Input behandlet Forespørgelse Send data (e) Respons Figur 2.3. Tilstandsdiagram over websiden Websiden vil normalt befinde sig i tilstanden passiv (a) hvis der ikke kommer inputs fra bruger (b) eller WiFi (f). Så snart et input registreres går systemet fra tilstand (a) til tilstand i behandler data (d), her bliver inputtet bearbejdet af systemet og derefter skifter systemet til tilstand send data (e). I denne tilstand kan dataen enten blive sendt til brugeren (b), eller til WiFi (f). På tabel 2.3 ses de respektive krav for websiden. 14

25 2.2. Brugerflader Aalborg Universitet Nr: Tilstands Tilstands navn: Krav: bogstav: 1 (b) Bruger Input fra mus/touch 2 (b) Bruger Output til displayet 3 (b) Bruger Fjernstyring over internettet 4 (e) Send data Korrespondance med WiFimodul 5 (c) Bruger godkendelse Adgangskontrol Tabel 2.3. Tabel over krav til den eksterne webside 1. Input fra mus/touch på stationære og mobile enheder 2. Output til displayet på ekstern enhed 3. Korrespondance med WiFi-modul, der er placeret ved FPGA en 4. Fjernstyring over internettet 5. Adgangskontrol til bruger identificering samt validering Ud fra ovenstående krav til den lokale terminal og den eksterne webside, er der mulighed for at udvikle et system der kan anvendes til styring af en FPGA både lokalt og eksternt. WiFi kommunikation For at kunne kommunikere over netværket mellem FPGA en og websiden, er det nødvendigt at have en netværksforbindelse. I dette projekt er der fokus på at have en trådløs forbindelse til omverdenen, hvilket gør det nødvendigt at have et WiFi modul, som kan forbinde til et Access Point. WiFi modulet skaber derved forbindelsen til webserveren, hvor websiden er lokaliseret. Dette gør det muligt at forbinde til FPGA en over et lokalt netværk eller over internettet. På figur 2.4 ses et tilstandsdiagram over WiFi-kommunikationen. Respons Forespørgelse Passiv (a) Data modtaget Ingen data FPGA (e) Behandler data (c) Webside (b) Data behandlet Send data (d) Forespørgelse Respons Figur 2.4. Tilstandsdiagram over WiFi modulet 15

26 Gruppe 414 Kravspecifikation WiFi modulet vil som udgangspunkt befinde sig i tilstanden passiv (a) hvis der ikke kommer data fra webside (b) eller FPGA (e). Når tilstanden passiv (a), modtager data, skifter systemet over i tilstanden, behandler data (c), hvor dataen bliver bearbejdet af systemet og derefter skifter systemet til tilstanden send data (d). Fra tilstand (d) kan dataen enten blive sendt videre til webside (b) eller til FPGA (e). På tabel 2.4 er kravene for WiFi-kommunikationen skitseret. Nr: Tilstands Tilstands navn: Krav: bogstav: 1 (e) FPGA Sende og modtage data 2 (b) Webside Sende og modtage data 3 (c) Behandler data Fortolke data 4 (c) Behandler data Responstid Tabel 2.4. Tabel over krav til WiFi modulet 1. Sende og modtage data til og fra FPGA en 2. Sende og modtage data til og fra Websiden 3. Behandle data der kan sendes videre til FPGA en eller Websiden 4. Fra tilstand (c) til tilstand (d) skal der i et støjfrit miljø være en maksimal responstid på 1 sekund. 5. Fra tilstand (c) til tilstand (d) skal der i et miljø med støj være en maksimal responstid på 10 sekunder. Ud fra de ovenstående krav for WiFi modulet, vil dette modul i produktet indgå i en internetforbindelse og der vil derfor ikke blive taget højde for LAN forbindelser. Dette gør det muligt at tilgå WiFi modulet trådløst og bruge WiFi modulet som mellemled i en trådløs kommunikation mellem FPGA en og websiden. Dette betyder at der kan modtages/sendes forespørgelser og respons data til både FPGA en og websiden. 2.3 Overvågning af vandgennemstrømning Dette afsnit har til hensigt at give en forståelse af modulet til overvågning af vandgennemstrømning, samt dets funktion. Dette modul fungerer ved at en DC-motor sidder med en mølle i et vandrør, her vil vandstrømmen få DC-motoren til at generere en spænding, som bliver aflæst af kontrolenheden. Hvis denne spænding har været for høj i for lang tid, vil kontrolenheden give brugeren besked. Systemet til overvågning af vandgennemstrømning fungerer ifølge det viste tilstandsdiagram som ses på figur

27 2.3. Overvågning af vandgennemstrømning Aalborg Universitet Overvågning (a) Aflæs gennemstrømning Gennemstrømning Ingen gennemstrømning Ingen gennemstrømning Overvågning af gennemstrømning (b) Gennemstrømningen forbliver Der har i en givet tidsperiode været gennemstrømning Alarm (c) Gennemstrømning forbliver Figur 2.5. Tilstandsdiagram for systemet til overvågning af vandgennemstrømning. Der ses på figur?? at systemet til overvågning af vandgennemstrømning kan være i 3 forskellige tilstande. (a) tilstanden er overvågningstilstanden, denne tilstand bruges hvis systemet ikke er aktivt, men bare aflæser gennemstrømningen i vandrøret. (b) tilstanden er overvågning af vandgennemstrømning, i denne tilstand aflæser modulet fortsat gennemstrømningen, og hvis der forbliver gennemstrømning i en fastsat tidsperiode skiftes til tilstand (c). Hvis gennemstrømningen derimod stopper inden tidsgrænsen er nået, vil systemet skifte til tilstand (a). Tilstand (c) er alarmtilstanden, systemet forbliver i denne tilstand hvis der fortsat er gennemstrømning. Hvis gennemstrømningen ophører skiftes der til tilstand (a). Nr.: Tilstands bogstav: Tilstands navn: 1 (b) Overvågning af vandgennemstrømning Krav: Der ligger en målbar spænding på outputtet af DC motoren. 2 (c) Alarm Alarmsignal sendes til kontrolenhed, hvis der er vandgennemstrømning i en fastsat tidsperiode. 17

28 Gruppe 414 Kravspecifikation 1. Hvis der er vandgennemstrømning skal motoren producere en given strøm. 2. Hvis der har været vandgennemstrømning i en forudbestemt tidsperiode skal der sendes en alarm til kontrolenheden I produktet vil der blive anvendt en DC-motor som generator. Hvordan der kan udvikles et modul til overvågningen af vandgennemstrømningen, kan der læses mere om i kapitel Tyverialarm Dette afsnit har til hensigt at give en beskrivelse af alarmsystemet, samt hvilke krav der er sat til dette. Alarmsystemet vil fungere ved at en afstandsmåler, måler afstanden og hvis denne ændres udsendes alarm. På figur 2.6 kan der ses et tilstandsdiagram over alarmsystemet. Tænd (a) Inaktiv (b) Alarm ikke tændt Tænd Sluk Alarm slukket Signal ikke brudt Aktiv (c) Sluk (f) Signal brudt Alarm (d) Alarm ikke slukket Sluk alarm (e) Figur 2.6. Tilstandsdiagram for alarmsystemet. Der ses på figur 2.6 kan alarmsystemet være i 3 forskellige tilstande. I tilstand (b) er modulet inaktivt og vil ikke foretage sig noget. I tilstand (c) er systemet aktivt, her vil systemet ikke foretage sig noget, medmindre afstanden ændres. Systemet går videre fra tilstand (c) til tilstand (d), hvis signalet brydes. I denne tilstand udsendes et alarmsignal til brugeren. Brugeren kan her vælge at slukke alarmen, hvilket skifter til tilstand (b). 18

29 2.5. Temperatur Aalborg Universitet Nr.: Tilstands bogstav: Tilstands navn: Krav: 1 (b) Slukket Intet signal udsendes. 2 (b) Passiv Intet signal må sendes 3 (c) Aktiv Måler afstanden. 4 (c) Aktiv Alarmsignal 5 (d) Alarm Alarmsignal sendes til kontrolenhed, hvis afstanden ændres. 1. Hvis alarmen er i tilstand (b) skal der ikke udsendes signaler på noget tidspunkt. 2. Hvis alarmen er i tilstand (c) må der ikke sendes alarmsignal, medmindre signalet aktivt bliver afbrudt. 3. Hvis alarmen er i tilstand (c) skal afstanden måles. Alarmen vil udelukkende blive udløst i tilfælde af at afstanden ændres. 4. Hvis alarmen er i passiv tilstand (c) skal der i tilfælde af at systemet mister forsyning gå videre til tilstand (d). 5. Hvis signalet brydes i tilstand (d) sendes et alarmsignal til kontrolenheden. 2.5 Temperatur I dette afsnit ønskes der at give en beskrivelse af temperaturmodulet. I afsnittet er der udarbejdet et tilstandsdiagram til at give et grafisk overblik over modulets forskellige tilstande. Funktionaliteten af dette modul er at aflæse og regulere temperaturen. For at give et overblik over modulets funktionalitet er der på figur 2.7 opstillet et tilstandsdiagram. Ønsket Temperatur (a) Aflæs temperatur 7-segment Tjek temperatur (b) Nedjustering gennemført For høj For lav Opjustering gennemført Nedjuster (c) Opjuster (d) Figur 2.7. Tilstandsdiagram over temperaturmodulet. Som der ses på figur 2.7 er der opstillet et tilstandsdiagram der beskriver modulets tilstande. I tilstand (a) modtager modulet et input som er den ønskede temperatur, modulet skal reguleres 19

30 Gruppe 414 Kravspecifikation til. På baggrund af input (a) går modulet til tilstand (b). I tilstand (b) bliver temperaturen aflæst. Alt afhængig af temperaturen der aflæses, vil systemet opretholde denne temperaturværdi med den ønskede temperatur fra input (a). Modulet vil herefter gå videre til tilstand (c) eller (d). I tilstand (c) vil temperaturen blive nedjusteret. Dette vil finde sted hvis der i tilstand (c) bliver aflæst en for høj temperatur. Når tilstand (c) er færdig med at nedjustere, går modulet tilbage til tilstand (b). Modulet vil gå fra tilstand (b) til tilstand (d) hvis der bliver aflæst en for lav temperatur. Når tilstand (d) er færdig med at opjustere, går modulet til tilstand (b). I tabel 2.5 er kravene for temperaturmodulet opstillet. Nr: Tilstandsbogstavnavn: Tilstands- Krav: 1 (a) Ønsket temperatur 2 (b) Ønsket temperatur til beregning 3 (b) Tjek temperatur 7 segment display 4 (c) Nedjuster Systemet skal kunne nedjustere temperaturen 5 (d) Opjuster Systemet skal kunne opjustere temperaturen Tabel 2.5. Tabel over kravene til lys og temperaturkontrol Der er for hvert krav i tabel 2.5 givet en uddybende forklaring. 1. I tilstand (a) er der ikke krav til den ønskede temperatur 2. I tilstand (b) kræves det at omgivelsestemperaturen vises på et 7 segment display med en maksimal afvigelse på 1 C ift. inputtet fra tilstand (a). 3. Tilstand (d) og (c) skal kunne afvikle et brugerinput fra tilstand (a). 4. Outputtet fra tilstand (c) og (d) må have en maksimal afvigelse på 1 C ift. den ønskede temperatur. Der vil blive anvendt en halogenpære som varmekilde i prototypen. Der er valgt en halogenpære da der er mulighed for at kontrollere temperaturen af denne. Der er nu givet en beskrivelse af modulets funktionalitet samt dets krav. Afsnittet vil blive brugt til den tekniske udførelse af systemet og indgå i accepttesten. 20

31 I/O Enheder Brugerflade 2.6. Grænseflader Aalborg Universitet 2.6 Grænseflader Dette afsnit giver en beskrivelse af grænsefladerne og af signalerne imellem modulerne. Afsnittet indeholder tabeller og diagrammer med tilhørende beskrivelser. Styring Brugerflade I/O Enheder Terminal Website Segment Tyverialarm Vandgennemstrømning Temperatur Figur 2.8. Blokdiagram over systemet Styring Der gives i dette afsnit en gennemgang af grænsefladerne i styring. På figuren 2.9 herunder, ses de grænseflader som er mellem modulerne og styringsmodulet. Til figuren er der en tilhørende tabel, som giver et overblik over grænsefladerne. CLK Reset Styring 3 4 Figur 2.9. Blokdiagram over styringsmodulet Styring på figur 2.9 er forbundet med to inputsignaler, et fra brugerflade og et fra I/O Enheder. Derudover er der to outputsignaler til hhv. brugerflade og I/O Enheder. Forbindelse 1 er inputsignalet bf_out og outputsignalet bf_in er forbindelse 2, begge er forbundet til Brugerflade. Signalerne 3 og 4 er hhv. Inputsignal I/O_out og Outputsignal I/O_in, som er forbundet til I/O Enheder. Til styring er der to inputsignaler, signal 5 fra FPGA ens interne clock og signal 6 fra en reset knap. 21

32 Gruppe 414 Kravspecifikation Nr: Signalnavn: Signaltype: Kommunikationstype: 1 bf_out Binær vektor på Input 40 bit 2 bf_in Binær vektor på Output 24 bit 3 I/O_out Binær vektor 40 Input bit 4 I/O_in Binær vektor 24 Output bit 5 CLK Binær værdi Input 6 Reset Binær værdi Input Tabel 2.6. Tabel over grænseflader i styring. Tabellen ovenfor viser de forskellige grænseflader mellem modulerne, samt en navngivning af signalerne, som er beskrevet i de efterfølgende afsnit. Der er også defineret signaltype, som giver et overblik over hvordan de enkelte moduler kommunikerer med hinanden Brugerflader Dette afsnit giver en gennemgang af grænsefladerne til og fra brugerflade. Her lægges der vægt på grænsefladerne mellem undermodulerne til denne blok. Derudover vil grænsefladerne mellem dette modul og styring blive omtalt. Der vil i afsnittet optræde en række blokdiagrammer som giver et grafisk overblik over modulerne. Brugerflade : Herunder gives en gennemgang af grænsefladerne til og fra brugerflade, først kommer en grafisk oversigt over in/outputs på figur 2.10, dernæst kommer en forklaring af de forskellige forbindelser. 22

33 2.6. Grænseflader Aalborg Universitet Styring 1 Brugerflade Terminal Webside 7-segment Figur Grænseflader i brugerflade På figuren ses en oversigt over in/outputs til brugerflade, der er i alt 4 signaler hvor signal 1 består af et input signal kaldet bf_in og et output signal kaldet bf_out. Disse signaler indeholder alt information til brugerflade fra styring. Signal 2 består af inputtet term_out og outputtet term_in der er hhv. inputtet og outputtet fra terminal. Den samme opbygning gør sig gældende ved signal 3 hvor dette består af inputtet wifi_out og outputtet wifi_in fra webside. Der er ligeledes et signal 4 til 7-segment, dette signal indeholder information om hvad der skal skrives på to 7-segment displays. Herunder kommer en tabel over de forskellige signaler, samt deres type, se tabel 2.7. Nr: Signalnavn: Signaltype: Kommunikationstype: 1 bf_in Binær vektor på Input 40 bit 1 bf_out Binær vektor på Output 24 bit 2 term_in Binær vektor på Output 48 bit 2 term_out Binær vektor på Input 24 bit 3 web_in Binær vektor på Output 48 bit 3 web_out Binær vektor på Input 24 bit 4 temp_out Binær vektor på 8 bit Output Tabel 2.7. Tabel over grænseflader til brugerflade 23

34 Gruppe 414 Kravspecifikation Terminal Herunder gives en gennemgang af grænsefladerne til og fra terminal, først vises en grafisk oversigt over in/outputs på figur 2.11, dernæst kommer en forklaring af de forskellige signaler. Brugerflade 2 VGA 1 3 Terminal Tastetur Figur Grænseflader til terminal Som det ses af figuren er der tre forbindelser ind og ud af terminal, forbindelsen 1 er en VGAforbindelse ud til et lokalt display. Denne består af tre forskellige signaler, hhv. h_sync, v_sync og rgb. Forbindelse 2 er kommunikationen med brugerflade-modulet, denne består af et input kaldet term_in og et output kaldet term_out, disse to signaler er begge kombinationer af flere signaler. Den sidste forbindelse 3 er input signalet fra tastaturet, dette består af to signaler ps2c og ps2d. Alle signalerne vil blive forklaret yderligere i kapitel 3 Systemdesign. Nr: Signalnavn: Signaltype: Kommunikationstype: 1 h_sync Binær værdi Output 1 v_sync Binær værdi Output 1 rgb Binær vektor på 3 Output bit 2 term_in Binær vektor på Input 24 bit 2 term_out Binær vektor på Output 48 bit 3 ps2c Binær værdi Input 3 ps2d Binær værdi Input Tabel 2.8. Tabel over grænseflader til terminal Webside Herunder gives grænsefladerne til og fra webside, først kommer en grafisk oversigt over in/outputs på figur 2.12, dernæst kommer en forklaring af de forskellige forbindelser. 24

35 2.6. Grænseflader Aalborg Universitet Brugerflade 1 WiFi 2 Webside 3 Bruger I/O Figur Blokdiagram over webside Som det ses af figuren er der fire blokke forbundet til hinanden, formålet med grænsefladerne er at kunne sende og modtage data til og fra webside. Forbindelsen 1 skal sende og modtage data mellem brugerfladen og WiFi-modulet, denne består af et modtagesignal web_in og sendesignal web_out. Forbindelse 2 består af endnu to data signaler, disse er mellem WiFi-modulet og webside, hhv. et input WiFi_Rx og output WiFi_Tx. Kommunikationen mellem webside og Bruger I/O er signalet 3, dette indeholder input fra og output til en bruger. Signalerne beskrevet kan ses i tabel 2.9 herunder. Nr: Signalnavn: Signaltype: Kommunikationstype: 1 web_in Binær vektor på Input 48 bit 1 web_out Binær vektor på Output 24 bit 2 WiFi_Rx std logic Input 2 WiFi_Tx std logic Output 3 N/A N/A Output/Input Tabel 2.9. Tabel over grænseflader i webside 7-segment For at kunne vise outputtet af temperaturen skal der laves et modul til visning af denne på to 7-segment displays, herunder kommer en figur der viser hvordan dette modul interagerer med brugerflade, se figur

36 Gruppe 414 Kravspecifikation Brugerflade 1 7-segment Figur Grænseflade i 7-segment Det ses af figuren at der er et signal til 7-segment, dette signal 1 indeholder informationer om temperaturen, herunder kommer en tabel der viser specifikationerne på signalet, se tabel Nr: Signalnavn: Signaltype: Kommunikationstype: 1 Temp_out Binær vektor på 8 Input bit Tabel Tabel over grænseflade i 7-segment I/O enheder Input- og Output modulet omhandler de signaler som sender et in/output signal til styring. Der vil ligeledes gives en beskrivelse af grænsefladerne mellem I/O enheder og dets undermoduler. Til sidst i afsnittet vises en samlet tabel over signalerne. I/O enheder I dette afsnit vil de samlede signaler til og fra modulerne og I/O enheder blive beskrevet. Der er givet en grafisk afbildning af de samlede signaler på figur Temperatur modul Styring 1 2 I/O enheder 5 4 Tyveri alarm 3 Vand gennemstrømningen Figur Blokdiagram over de samlede signaler mellem modulene og I/O enheder. Som der ses på figur 2.14 sender og modtager I/O enheder en række in/outputs. I/O enheder modtager med signal 1 et signal fra styrings. Dette signal bliver gennem I/O enheder distribueret til det respektive undermodul alt afhængig af formålet. I/O enheder modtager 26

37 2.6. Grænseflader Aalborg Universitet ligeledes inputs fra de tre moduler gennem signalerne 7, 5 og 3. Disse signaler bliver samlet i I/O enheder og videresendt til styring som er illustreret ved signal nr. 2. På tabel 2.11 vises en samlet oversigt over signalerne og deres typer. Nr: Signalnavn: Signaltype: Kommunikationstype: 1 I/O_in Binær vektor på 24 bit Input 2 I/O_out Binær vektor på 40 bit Output 3 gns_out Binær vektor på 8 bit Output 4 tyv_out Binær vektor på 8 bit Output 5 tyv_in Binær vektor på 8 bit Input 6 temp_out Binær værdi på 8 bit Output 7 temp_in Binær værdi på 16 bit Input Tabel Tabel over signalerne mellem modulerne, I/O blokken og styring. Temperaturmodul På figur 2.15 ses en grafisk afbildning af signalerne mellem temperaturmodulet og I/O Enheder. Temperatur modul I/O enheder Figur Blokdiagram over temperaturmodulet. Tyverimodul På figur 2.16 ses et blokdiagram af signalerne mellem tyverimodulet til I/O enheder. Tyveri alarm I/O enheder Figur Blokdiagram over tyverimodulet. Vandgennemstrømningsmodul På figur 2.17 ses et blokdiagram over signalerne mellem vandgennemstrømningsmodulet til I/O enheder. 27

38 Gruppe 414 Kravspecifikation Vandgennemstrømning I/O enheder Figur Diagram over grænseflader i vandgennemstrømningsmodulet. Der er nu givet en beskrivelse af de forskellige moduler samt deres krav og funktionaliteter. Med de opstillede krav er det nu muligt at udarbejde de fysiske udformninger af modulerne. I næste afsnit bliver der beskrevet, hvordan modulerne er udformet, for at kunne fungere efter hensigten. 28

39 3 Systemdesign I dette kapitel ønskes der at give en beskrivelse af de respektive moduler. Der vil i kapitlet også indgå forklaringer af hvordan modulerne fungerer i projektet. Der vil i passende omfang optræde relevante figurer og diagrammer, for at give en forståelse af hvordan modulerne er opbygget. 3.1 Systemoversigt I dette afsnit vil det samlede system blive beskrevet med tilhørende illustrationer. Systemet består af moduler, som er dokumenteret i dette kapitel. Der anvendes en webserver, med dertilhørende webside, som er koblet på et access point. Til at modtage kommandoer fra websiden, er der koblet et WiFi modul til FPGA en. I I/O enheder-blokken er der tre undermoduler, Temperaturmodulet, Tyverimodulet og Vandgennemstrømningsmodulet. Til kommunikation mellem FPGA en og WiFi modulet sidder et konverteringsmodul, dette oversætter signalerne til og fra TTL og RS232. Den lokale adgang til styringsmodulet sker via en skærm og et PS/2 tastatur, denne kaldes terminal. Der anvendes to 7-segment displays til at vise den nuværende temperatur lokalt. På figur 3.1 ses et blokdiagram af det samlede system. For dybere gennemgang samt beskrivelse af grænsefladerne mellem modulerne, kan der læses mere i afsnit 2.6. Styring Brugerflade I/O Enheder Terminal Website Segment Tyverialarm Vandgennemstrømning Temperatur Figur 3.1. Blokdiagram over systemet I Brugerflade bliver signalerne fra Terminal og Website samlet i ét signal. Hvordan datastrengen fra Website til Brugerflade eksempelvis kan se ud, er der uddybet i afsnittet 3.5. Fra Brugerflade bliver der sendt en samlet bitstreng videre til Styring og videre til I/O 29

40 Gruppe 414 Systemdesign Enheder, hvor signalet tolkes og bliver delt ud i de respektive I/O moduler hhv. Temperatur, Vandgennemstrømning og Tyverialarm. 3.2 Temperaturmodul Formålet med dette afsnit er at beskrive temperaturmodulet. Modulets funktion er at måle og tilpasse temperaturen. Figur 3.2. Temperatursensor og varmekilde. På figur 3.2 ses den basale funktionalitet af temperaturmodulet. En styringsenhed bruger varmekilden til at tilpasse temperaturen i rummet. Dette sker på baggrund af den målte værdi som temperatursensoren leverer. Følgende underafsnit giver en beskrivelse af temperatursensoren og varmekilden Temperatursensor I dette afsnit bliver temperatursensoren samt dens funktion beskrevet. På figur 3.3 er der givet en skitse over temperatursensoren. 30

41 3.2. Temperaturmodul Aalborg Universitet +Vs LM35 OUTPUT 0mV + 10, 0mV/ C Figur 3.3. Grafisk overblik over temperatursensoren LM35. Se bilag 8. Som det ses af figur 3.3 giver temperatursensoren en output spænding svarende til 10 mv C med et offset på 0 volt. Det betyder at forholdet mellem outputspændingen og temperaturen er 100 C V, eksempelvis ved en spænding på 270 millivolt vil temperaturen være 27 C. Da FPGA en ikke kan aflæse analoge værdier skal outputspændingen konverteres til et digital signal, som det fremgår af figur 3.4. Figur 3.4. Temperatursensor og varmekilde. For at konvertere den analoge spænding til et digitalt signal er der valgt at anvende en Analog til Digital Converter (ADC) af typen ADC0820, se bilag 5 for datablad og appendiks B for opkobling. ADC en gør det muligt for FPGA en at aflæse værdien som kommer ud af temperatursensoren. For at genfinde outputtet fra temperatursensoren på FPGA en, er det nødvendigt at vide hvor mange millivolt hvert bit modtaget fra ADC en svarer til. Da ADC0820 er en 8 bit ADC betyder det at den har 255 intervaller til opdeling af inputspændingen. Der er valgt en reference spænding V ref på 3,3 volt, denne reference spænding er valgt da FPGA en kan levere denne. Dette betyder at den højeste spænding som ADC en kan repræsentere er 3,3 volt, svarende til et digitalt output på 255, da den højeste værdi for en unsigned 8 bit vektor er 255. I formel 3.1 er der givet et eksempel på hvad den største spænding fra ADC en er i en 8 bit sammenhæng. Spændingen pr. bit udregnes på følgende måde: 0, 013V = 3, 3V 255 = V bit [V] (3.1) Da spændingen pr. bit er fundet og FPGA en er i stand til at udregne spændingen fra 31

42 Gruppe 414 Systemdesign temperatursensoren. Dette gøres ved formlen 3.2. C 3, 3V 100 T = ADC out V 255 [ C] (3.2) Hvor: ADC out er bit værdien fra ADC0820. [1] 3, 3 er referencespændingen. [V] 255 er opløsningen for ADC0820. [1] 100 en skaleringsfaktor. [ C V ] T er temperaturen. [ C] Som tidligere omtalt giver temperatursensoren et output som svarer til 10 mv C. Derfor vil outputtet fra temperatursensoren i tilfælde af en omgivelsestemperatur på 26 C være 260 millivolt. De 260 millivolt sendes ind i ADC en. Fra formel 3.1 kan spændingen pr. bit findes. De 260 millivolt skal nu fordeles over spændingen pr. bit. 20 = 260mV 13mV [1] (3.3) De 20 som nu er fundet er værdien som FPGA en indlæser i en binær repræsentation. Udregningen af temperaturen vil nu se således ud ved at indsætte de kendte værdier i formel , 78 = 20 3, [ C] (3.4) I VHDL koden er der ikke taget højde for decimalerne på temperaturen, hvilket betyder at temperaturen afrundes til 26 C repræsenteret ved en binær værdi. Figur 3.5. Kodeudsnit af beregning af temperatur. På figur 3.5 vises et kodeudsnit af omregningen af 8-bit vektoren til reel temperaturværdi. Her er TempADC 8-bit vektoren der modtages fra ADC0820. Den typecastes til en unsigned værdi således at der kan udføres beregninger på den. Herefter lægges værdien i en 16-bit unsigned vektor kaldt TempADC_unsigned. Grunden til dette er, at beregningen der efterfølgende udføres på værdien kan få tallet til at overskride 8-bit vektorens maksimumværdi. Herefter anvendes formlen på figur 3.2 på værdien og lægger den over i en ny unsigned vektor, CurrentMath. Til sidst lægges det 32

43 3.2. Temperaturmodul Aalborg Universitet i en 8 bits vektor kaldet CurrentTemp, hvilket er en binær repræsentation af den nuværende temperatur. Derved er det muligt for FPGA en at beregne temperaturen på baggrund af den aflæste værdi fra temperatur sensoren Varmekilde I det endelige produkt kan varmekilden eksempelvis være et ventilationsanlæg med varmeflade, men for at teste princippet om temperatur styring er der anvendt en 20 Watt halogenpære som varmekilde i stedet. Da der anvendes en halogenpære er der ikke mulighed for nedjustering af temperaturen. For at styre halogenpæren fra FPGA en, er der valgt at anvende en IRL 530N FET som kan ses i bilag 6. FET en gør det muligt at indstille lysstyrken, hvilket betyder at udstrålingsvarmen fra pæren ligeledes bliver styret. For at kunne styre temperaturen med FET en kræver den en analog spænding på 3 volt mellem Gate og Source benene, som det ses af figur 3.7. Da FPGA en ikke kan levere en analog spænding kræver det en Digital til Analog Converter (DAC), som det frem går af figur 3.6. Der anvendes en DAC af typen AD7524JN se bilag 4 for tekniske specifikationer, samt figur 3.7 for opkobling. Figur 3.6. Diagram over opvarmningsmodul 33

44 Gruppe 414 Systemdesign Figur 3.7. Diagramudsnit over opvarmningsmodul DAC ens input er 8 bit og på baggrund af størrelsen af dette giver den en tilsvarende outputspænding. Der er valgt kun at arbejde med unipolære output signaler. Det vil sige at der ved et input på 0 også vil være en output spænding på 0 volt og ved et input på 255 vil output spændingen være den maksimale reference spænding, altså 3,3 volt. Dette valg gør at alle outputs er inverteret og da FET en kræver et positivt spændingsfald fra Gate til Source for at åbne, betyder dette at alle outputs igen skal inverteres. Dette gøres ved en inverterende operationsforstærker kobling. Denne samlede opstilling gør at FPGA en er i stand til at styre strømmen som løber gennem pæren og dermed også den varme som bliver udsendt fra den. Herunder vises et stykke VHDL kode til regulering af temperatur. Figur 3.8. VHDL kode til temperaturregulering. For at kunne illustrere styringen af en DAC er der valgt at vise et kodeudsnit som ses på figur 34

45 3.2. Temperaturmodul Aalborg Universitet 3.8. Her er CurrentTemp den nuværende temperatur og RequestTemp er den ønskede temperatur. Hvis der antages at RequestTemp er 5 C eller højere end CurrentTemp, vil programmet sørge for at varme systemet op ved maksimal effekt. Hvis RequestTemp er op til 5 C højere end CurrentTemp, vil programmet sørge for at varme op med det halve af den maksimale effekt og temperaturen vil herefter kunne stige i et mere moderat tempo. Hvis RequestTemp er lig eller mindre end omgivelserne, vil programmet ikke forsøge at opvarme. På figur 3.9 ses et billede af test prototypen, som det ses er både halogenpære og temperatursensor isoleret i et lukket rum. Dette gøres da opvarmningen fra pæren sker meget langsomt. Figur 3.9. Temperatursensor og varmekilde. Der er i det forrige afsnit blevet udviklet et system der gør FPGA en i stand til at aflæse og regulere omgivelsestemperaturen segment display I dette afsnit vil 7-segment displayene blive beskrevet, og hvilken funktion de har med dertilhørende kode eksempler. I temperaturmodulet ønskes der at kunne regulere temperaturen i omgivelserne. For at danne sig et overblik over hvilken temperatur der er i det regulerede område, er det relevant at kunne aflæse denne temperatur. Der anvendes to 7-segment displays af typen Kingbright SC56-11EWA, se bilag 3. For at kommunikere med de enkelte elementer på de to displays, ses der af figur 3.10 en grafisk afbildning af opbygningen over 7-segment displayet. 35

46 Gruppe 414 Systemdesign Figur segment display pinout. Som der ses på figur 3.10 har hvert element på displayet sit eget inputben. For at få det ønskede element på 7-segment displayet til at lyse, sendes et højt signal ind på det matchene ben. De to 7-segment displays modtager signaler i form af to 8-bit vektorer fra FPGA en. Disse repræsenterer hhv. tiere og enere i decimaltal som temperaturmodulet har målt. Disse to tal kommer fra et enkelt 8-bit signal, som udgør et to-cifret decimaltal, der modtages fra temperaturmodulet. Dette er splittet i FPGA en ved VHDL kode. Et udklip af dette ses af figur 3.11: Figur VHDL kode til opdeling af decimaltal. Hvor: CurrentTemp er den nuværende temperatur i binær repræsentation. LoNum er enerne til decimaltallet. 36

47 3.2. Temperaturmodul Aalborg Universitet HiNum er tierne til decimaltallet. På det overstående kodeeksempel, er der opsat en if-kæde som tjekker den indlæste værdi fra temperatursensoren. Denne variable er en unsigned 8-bit vektor som er navngivet CurrentTemp. Hvis værdien af vektoren eksempelvis er mellem 19 og 30, sættes LoNum til CurrentTemp -20 for at udlede 1 erne til det andet decimal på displayet. Det første decimal bliver sat efter hvor mange tiere der er, så i tyverne sættes den til 2 og derfor sættes HiNum, det første decimal, til Dette er sat op for alle tal mellem 0 og 100. Et eksempel på en temperatur i binær værdi kunne være der svarer til 24 C. Her trækkes så 20 fra og 4 bliver sendt til LoNum, det andet, lave decimal. Derefter sættes HiNum, det første, høje decimal til 2 da 24 ligger i mellem 19 og 30. Figur VHDL kode til output af nuværende temperatur. I ovenstående kode 3.12 oversættes de to decimaltal, HiNum og LoNum, til at tænde segmenterne der tilsvarer decimalværdien. Herunder på figur 3.13 ses en illustration af hvordan HiNum eller LoNum vises på et display. Figur Illustration af HiNum eller LoNum på 7 segmentet. 37

48 Gruppe 414 Systemdesign På figur 3.14 ses implementeringen af 7-segment displayene i projektet. Displayet til venstre på billedet er Segment1 hvor værdien HiNum vises, og displayet til højre er Segment2 hvor LoNum vises. Figur segments displayet i projektet: Modultest I dette afsnit blive kravene til temperatursensoren beskrevet og testet. Der har været fokus på at teste modulets stabilitet og funktionalitet. For flere detaljer om måleresultaterne læs mere i appendiks A. Nr. Testobjekt Krav Resultat 1 7 segment displays. Omgivelsestemperaturen målt af Dette virker. temperatursensoren skal vises på et 7-segment display. 2 Temperatursensor. Outputtet som sendes til 7 segment Dette virker. displays må ikke afvige med mere end 1 C ift. omgivelsestemperaturen. 3 Opvarmningsmodul. Opvarmningsmodulet skal kunne Dette virker. modtage en brugerdefineret ønsket temperatur, og afvikle derefter. 4 Opvarmningsmodul. Omgivelsestemperaturen må maksimalt have en afvigelse på 1 C ift. den ønskede temperatur efter opvarmning. Dette virker. Tabel 3.1. Tabel over måleresultaterne 38

49 3.3. Vandgennemstrømningsmodul Aalborg Universitet 1. Omgivelsestemperaturen kunne vises på 7-segment displays. Dette blev verificeret ved at måle omgivelsestemperaturen med et IR-termometer. 2. Temperatursensoren afveg med mindre end 1 C, og bestod derved vores krav. Dette blev verificeret ved at måle omgivelsestemperaturen med et IR-termometer. 3. Opvarmningsmodulet kan både modtage ønsket temperatur fra terminalen og websiden, den kan også afvikle kommandoen. 4. Opvarmningsmodulet kan opvarme til den ønskede temperatur, og fastholde denne indenfor 1 C. Dette blev verificeret ved at måle omgivelsestemperaturen med et IR-termometer. 3.3 Vandgennemstrømningsmodul Formålet med dette afsnit er at beskrive vandgennemstrømningsmodulet. Modulet har til opgave at måle om der er vandgennemstrømning i længere tid end en forudbestemt periode, og herefter give brugeren besked. Der er set på et flowmeter, fra virksomheden Omega Engeering inc. De producerer et flowmeter, som kommer med et output mellem 4 og 20mA [15]. I prototypen anvendes en DC-motor på en turbine og motorens output konverteres til et digitalt signal som sammenlignes med en forudbestemt værdi på FPGA en, se figur 3.15 for illustration af sammenkoblingen imellem turbinen og DC-motoren. Figur D model af turbine og DC-motor sammensætning. På figuren herunder vises princippet i vandgennestrømningsmodulets funktionalitet. 39

50 Gruppe 414 Systemdesign Figur Skitse af vandgennemstrømning På figur 3.16 ses en skitse af systemet. Det ses at der anvendes en vandpumpe til at pumpe vand rundt i et lukket kredsløb. Vandets bevægelse vil få turbinen til at dreje rundt og dermed producerer DC-motoren strøm. Dette betyder at der kun er spænding på motoren, hvis der er gennemstrømning i kredsen. Da spændingen fra motoren ikke er digital, benyttes en tilsvarende ADC som ved temperaturmodulet, se opkobling i appendiks B, således at FPGA en kan læse outputtet. Figur VHDL kode til vandgennemstrømningsmodulet. Hvor: FlowCount er en unsigned vektor på 30 bit, som tjekker flowet en gang i sekundet. 40

51 3.3. Vandgennemstrømningsmodul Aalborg Universitet AlarmTimer tæller op til 3, som svarer til 3 sekunder, hvis MathFlow er over 15. MathFlow er inputtet fra ADC en, som konverteres til en 8 bit unsigned vektor. Ovenfor på figur 3.17 ses et udsnit af koden til behandling af inputtet der fås fra DC-motorens tilhørende ADC. Den første variabel der mødes, FlowCount, tæller på FPGA ens interne clock, og som argument i if-kæden bliver den sand når den når clock-cyklusser. Outputtet ligger som en vektor i MathFlow, der sammenlignes med tallet 15. Dette tal er en værdi målt ud af ADC en ved mindst mulig gennemstrømning, hvor der stadig er output fra DC-motoren. Hvis outputtet er en værdi over 15 vil variablen AlarmTimer tælle op. Værdien 3 er en forudbestemt værdi til test af modulet svarende til tidsrummet i sekunder mellem Idle og Alarm. Hvis der bliver talt op til den forudbestemte værdi, vil variablen Gns_out sende en binær vektor der svarer til ASCII værdien for A, som står for Alarm. Så længe MathFlow er 15 eller derunder vil Gns_out repræsentere ASCII værdien for I, som står for Idle. Figur Vandgennemstrømningsmodulet i projektet På figur 3.18 ses et billede af prototypen, hvor der er valgt at 3D-printe en kasse hvori turbinen er implementeret, se figur

52 Gruppe 414 Systemdesign Figur D model af den printede kasse. Samtidigt anvendes en vandpumpe, se bilag 10, denne har til opgave at pumpe vandet fra beholderen igennem systemet og derved skabe gennemstrømning i turbinen. Vandpumpen er drevet af en ekstern forsyning Modultest I dette afsnit bliver kravene til vandgennemstrømningen beskrevet og testet. Der har været fokus på at teste modulets stabilitet og funktionalitet, med mindst mulig afvigelse. For flere detaljer om måleresultaterne læs mere i appendiks A. Nr. Testobjekt Krav Resultat 1 DC-motor. Overvågning af vandgennemstrømning Dette virker. ved at kunne måle spænding på outputtet af DC-motoren. 2 Alarmoutput. Ved høj vandgennemstrømning over en brugerdefineret periode skal der sendes et alarmsignal. Dette virker. Tabel 3.2. Tabel over måleresultaterne 1. En spænding kunne måles ud af DC-motoren ved vandgennemstrømning. 2. Testen blev udført med en tidsperiode sat til 30 sekunder. Da modulet havde målt høj vandgennemstrømning i 30 sekunder sendte modulet alarmsignal 3.4 Tyverimodul I dette afsnit vil tyverimodulet blive beskrevet. Modulets funktionalitet er at registrere aktivitet indenfor dets område. På figur 3.20 ses et eksempel på et sådant scenarie. 42

53 3.4. Tyverimodul Aalborg Universitet Figur Funktionalitet af tyverimodul. Sensoren som ses til venstre på figur 3.20 del (a), som måler afstanden fra punkt A til B, hvis afstanden ændrer sig aktiveres alarmen. Et eksempel på dette kan ses på del (b) af figur For videre forståelse af rapporten vises her et billede af sensoren monteret i prototypen, se figur Figur Tyverimodulet i projektet Der er valgt at anvende en afstandsmåler af typen 2Y0A021, se bilag 10 for tekniske specifikationer. På figur 3.21 ses den fysiske udformning af afstandsmåleren i tyverimodulet. Efter at have monteret sensoren i prototypen, som vist på figuren herover, måles outputtet, dette er målt til at svinge mellem 0,74 volt og 0,70 volt i stilstand. Ved ændring af afstanden, ændrer spændingen sig. Da der anvendes samme ADC som ved de andre I/O moduler, se appendiks B for opkobling, kan de digitale signaler findes på følgende måder: 43

54 Gruppe 414 Systemdesign Grænseværdierne ses herunder: 56, 9 = 0, 74 0, 013 [1] (3.5) 53, 8 = 0, 70 0, 013 [1] (3.6) Hvor: 0,013 er spændingen pr. bit ud af ADC en, V bit. [V] 0,74 og 0,70 er maksimum og minimum outputspændingen fra sensoren i stilstand. [V] 56,9 og 53,8 er outputtet fra ADC en i stilstand. [1] Da der i VHDL ikke kan tages højde for decimaler afrundes disse to tal til 57 og 53. Derfor vides det at det digitale signal til FPGA en i Idle tilstand er mellem disse to værdier. Det vides også at hvis værdien ikke er mellem 57 og 53, er signalet blevet brudt og derfor skal alarmen aktiveres. Dette er beskrevet ved følgende kode: Figur Udsnit af kode til tyverimodul. Hvor: TyvCount er den optalte værdi, som går høj hvert 100ms. Tyv in definerer om alarmen er slukket eller tændt. Buzzer er om den tilsluttede buzzer skal være tændt eller slukket. Tyv out definerer alarmens tilstand, som ses på websiden og terminalen. TyvTemp sikre at alarmen er Idle. 44

55 3.4. Tyverimodul Aalborg Universitet Kodeudsnittet starter ved at variablen TyvCount tæller op til på den interne clock på FPGA en, det svarer til at if-kæden aktiveres 100 gange i sekundet. Så snart den bliver aktiveret vil kæden tjekke om værdien Tyv_in er F for Off eller I for Idle. Hvis Tyv_in er I går programmet ind i den næste if-kæde, hvor der spørges om variablen MathAlarm er større end 57 eller mindre end 53. Hvis den er det tæller variablen Timer op til 3. Timer er en variabel som sikrer at støj ikke aktiverer alarmen. Når Timer har nået 3 vil den eksekvere et output i form af Tyv_out og Buzzer, hvor Tyv_out sender ASCII værdien A ud for Alarm, og Buzzer sætter en output port, som er sat til en buzzer, høj. Hvis MathAlarm derimod er mindre end 58 og MathAlarm er større end 52, hvilket er normaltilstanden for modulet, vil TyvCount og Timer blive nulstillet og intet andet vil foretage sig Modultest I dette afsnit bliver kravene til tyverialarmen beskrevet og testet. Der har været fokus på at teste modulets stabilitet og funktionalitet, med mindst mulig afvigelse. For flere detaljer om måleresultaterne læs mere i appendiks A. Nr. Testobjekt Krav Resultat 1 Slukket tilstand. Hvis modulet er slået fra, skal intet Dette virker. signal udsendes. 2 Passiv tilstand. Hvis modulet er i passiv tilstand Dette virker. skal det afvente indtil dets udsendte signal bliver brudt, og hvis det gør skal det gå i alarmtilstand. 3 Alarmtilstand. Hvis modulet er i alarmtilstand skal Dette virker. det udsende et alarmsignal. 4 Passiv tilstand. Hvis sensoren mister forsyning i Dette virker. passiv tilstand, skal modulet gå i alarmtilstand. Tabel 3.3. Tabel over måleresultaterne 1. Modulet sender ikke signaler hvis det er slukket. Dette er testet ved at holde det i slukket tilstand over en time. 2. Modulet afventer i passiv tilstand indtil det udsendte signal bliver brudt. Dette er testet ved, at lade modulet være i passiv tilstand i en time, og derefter bryde dets signal. Modulet gik først i alarmtilstand da signalet blev brudt. 3. Modulet sender alarmsignal hvis det er i alarmtilstand. Dette er testet ved at tvinge det i alarmtilstand og sætte outputtet for alarmsignalet til en buzzer. Buzzeren hyler når modulet er i alarmtilstand. 4. Hvis sensorens forsyning bliver afbrudt går modulet i alarmtilstand. Dette testes ved at afbryde forsyningen til sensoren imens modulet er i passiv tilstand. 45

56 Gruppe 414 Systemdesign Der er i de foregående afsnit blevet beskrevet og dokumenteret funktionerne i I/O-modulerne. De næste afsnit omhandler brugerfladen, som starter med den serielle kommunikation, mellem FPGA en og WiFi modulet. 3.5 Webside For at kunne oprette en forbindelse via netværket, i dette tilfælde en online Apache webserver til et RTX4100 WiFi modul, se bilag 1, skal der anvendes en protokol der understøtter forsendelse af datapakker til og fra klient/server. Protokoller til dette formål kan være de to mest kendte; User Datagram Protocol (UDP) eller Transmission Control Protocol (TCP) Netværksprotokol I dette projekt er der valgt at anvende TCP protokollen fremfor UDP, grunden til dette er at TCP opretter en forbindelse og fastholder denne for at sikre at datapakkerne bliver overført korrekt. Dette gør den via en tre-vejs kommunikation; synkronisering, synkronisering-acknowledgement og acknowledgement. TCP protokollen tjekker om det overførte data er modtaget korrekt og i den korrekte orden. TCP protokollen benytter sig også af flow kontrol af dataen, dette gør den via acknowledgement signalet, hvor den har styr på hvilken data der bliver overført og om den er parat til at modtage mere data, for ikke at skabe buffer overflow. UDP opretholder ikke en forbindelse og tjekker ikke hvis der skulle gå data tabt, UDP protokollen er hurtigere idet at den ikke skal tjekke om dataen er korrekt overført, hvilket er grunden til UDP ikke er valgt som overførelses protokol i dette projekt. TCP understøtter acknowledgement signal (ACK) som har til formål at indikere at alle datapakker er overført uden tab. ACK fungerer ved at, hvis feedback signalet til TCP serveren ikke er positivt kan det skyldes at datapakken ikke er blevet overført indenfor et given tidsinterval eller hvis dataen helt er gået tabt. TCP vil derfor overføre dataen endnu engang hvis data skulle være tabt, for at sikre sig alt data er overdraget til modtageren.[16] Hvis en klient opretter forbindelse til en TCP server, og sender data vil der blive skabt en adresse i hver ende, dette er kaldet en socket. En socket forbinder klienten med serveren, derved ved TCP serveren også hvor den skal returnere data. En socket kan kendetegnes ved: <TCP, Lokal IP, Lokal port, Fjern IP, Fjern port> I dette projekt er der en TCP klient som er en webside og en TCP server som er et RTX4100 WiFi modul. En illustration af TCP socket forbindelsen kan ses på figur

57 3.5. Webside Aalborg Universitet Webside klient WiFi server Open Socket Open socket Connect Bind socket Listen socket Accept klient Tx/Rx (send/recieve) Tx/Rx (send/recieve) Close socket Close socket Figur Diagram over TCP socket forbindelsen For at give en forståelse af de forskellige socket funktioner, som ses på figur 3.23, er der på tabel 3.4 givet en beskrivelse af disse. Funktion Open socket Bind socket Listen socket Accept socket Connect socket Send og receive Close socket Beskrivelse Opretter en ny endpoint kommunikation Associerer en lokal adresse med en socket Tjekker om der skulle være nogle indkomne forbindelser Passivt etablerer indkomne forbindelser Aktivt forsøger at etablere en forbindelse Sender og modtager data over forbindelsen Lukker forbindelsen Tabel 3.4. Tabel over socket funktioner [17] Full duplex er også supporteret af TCP protokollen. Dette vil sige, at TCP protokollen understøtter at sende og modtage data samtidigt, se figur Tx Klient Rx Server Figur Diagram over full duplex WiFi modulet supporterer, som i dette tilfælde er TCP serveren, kun half duplex. I modsætning til full duplex kan half duplex kun sende en vej af gangen, altså enten TX eller RX, se figur

58 Gruppe 414 Systemdesign Klient Tx eller RX Server Figur Diagram over half duplex Kommunikationen imellem websiden og WiFi modulet vil være en række ASCII værdier. WiFi modulet tolker ikke på det data den får ind, men sender det blot videre til FPGA en via en seriel kommunikation. Data strengen som bliver sendt fra websiden kan ses i tabel 3.5. Blok Funktion ASCII Beskrivelse Verifikation Adgangskode: KoDe Adgangskontrol til ændring af data på FPGA en Læs / skriv Tyverialarm Temperatur ønsket Læs: Skriv: Aktiv: Idle: Slukket: R W A I F Identifikation om hvorvidt der skal læses fra eller skrives til FPGA en Identifikation omkring de tre tilstande tyveri modulet kan befinde sig i Talværdi: Fra 00 til 99 Den ønskede temperatur som sendes fra klient siden Tabel 3.5. Tabel over TX data til FPGA en Som det ses i tabel 3.5, er der fire blokke, disse har hver deres funktion som skal tolkes hos FPGA en. En typisk datastreng som bliver sendt fra websiden kunne se således ud: KoDeWI25 Hvor de første fire ASCII karakter, indikeret som KoDe verificerer klienten, for at sikre at det ikke er en ukendt klient som prøver at sende data til FPGA en, og derved ændre på modulerne i boligen. Den femte ASCII karakter W, indikere at der skal skrives data til FPGA en. Den sjette ASCII karakter I, Alarmmodulets ønskede tilstand, i dette tilfælde er det Idle. Den syvende og ottende ASCII karakter er den ønskede temperatur, som i dette tilfælde er 25 C. Når FPGA en har modtaget dataen og tolket det, skal den sende en datastreng som repræsenterer de ønskede tilstande tilbage til WiFi modulet. Se tabel

59 3.5. Webside Aalborg Universitet Blok Funktion ASCII Beskrivelse Alarm Aktiv: Idle: Slukket: A I F Identifikation omkring de tre tilstande alarm modulet kan befinde sig i Vandgennemstrømning Temperatur ønsket Temperatur nuværende Aktiv: Idle: A I De to tilstande vandgennemstrømningen kan befinde sig i Talværdi: Fra 00 til 99 Den ønskede temperatur som sendes til websiden Talværdi: Fra 00 til 99 Den nuværende temperatur som sendes til websiden Tabel 3.6. Tabel over RX data fra FPGA en For at få en forståelse af datasyntaksen vil der blive opstillet tre scenarier. For at foretage ændringer på websiden, kræver det brugeradgang med brugernavn og adgangskode. Der er på figur 3.26 vist et billede af log-in skærmen. Figur Billede af log-in skærmen Scenarie 1 Hvis man gerne vil have ændret temperaturen i sin bolig til 25 C og tyveri alarmen på forhånd er slukket, vil data strengen man sender over se sådan ud: KoDeWF25 49

60 Gruppe 414 Systemdesign Hvor de første fire ASCII karakter indikeret som KoDe, verificerer klienten. Den femte ASCII karakter W, indikere at der skal skrives en ændring til boligens moduler. Den sjette ASCII karakter indikere boligens tyveri alarm, hvor F betyder at tyveri alarmen skal slukkes. Den syvende og ottende ASCII karakter indikere den ønskede temperatur man ønsker at have i boligen. Datastrengen som WiFi modulet modtager fra FPGA en, indeholde datasyntaksen fra 3.6. Et eksempel kunne være: FI2523 Den første ASCII karakter F illusterer at tyverialarm er slukket. Den næste karakter I illustrerer at vandgennemstrømningen er idle. De næste to karakterer 25 illusrerer den ønskede temperatur som blev sendt fra datastrengen De sidste to karakterer 23 illusterer den nuværende temperaturværdi i boligen. Et eksempel på visning af modulernes status på websiden, kan ses i appendiks C. Scenarie 2 Hvis man gerne vil have aktiveret tyveri alarmen i sin bolig og gerne vil beholde sin ønskede temperatur fra Scenarie 1, vil data strengen man sender se således ud: KoDeWI20 Hvor de fire første karakter igen bruges til klient verifikation. Den femte ASCII karakter, W indikere at der skal ændres tilstande i boligen og den sjette, I som indikerer at tyveri alarmen skal aktiveres. Syvende og ottende ASCII karakter vil blive hentet fra den forrige ønskede temperatur, da man i dette scenarie ikke ønskede at ændre temperaturen i forhold til hvad den var i scenarie 1. Et eksempel på datastrengen som WiFi modulet modtager fra FPGA en kan se således ud: IA2014 Den første karakter I illustrerer at tyverialarmen er idle. Den næste karakter A illustrerer at vandgennemstrømningen er aktiv, hvilket kan betyde at der muligvis er sket en lækage. De næste to karakterer 20 illustrerer den ønskede temperatur. De sidste to karakterer 14 illustrerer den nuværende temperatur. Et eksempel på visning af modulernes status på websiden, kan ses i appendiks C. Scenarie 3 Hvis man kun ønsker at hente den nuværende status i boligen, vil man kunne sende en streng der ser således ud: KoDeRI25 50

61 3.5. Webside Aalborg Universitet Hvor de fire første karakter igen bruges til klient verifikation. Den femte karakter, R indikerer at der blot vil aflæses modulernes status. De sidste tre ASCII karakter, I25, vil ikke blive brugt, de er der kun fordi FPGA en forventer et 8 byte signal når den modtager data. Datastrengen som WiFi modulet modtager fra FPGA en kan se således ud: FI2426 Den første karakter F illustrerer at tyverialarmen er slukket. Den næste karakter illustrerer at vandgennemstrømningen er Idle. De to karakterer 24 illustrerer den ønskede temperatur. De sidste to karakterer 26 illustrerer den nuværende temperatur. Der kan fra terminalen ligesom fra websiden foretages ændringer. Dette betyder at datastrengen som WiFi modulet modtage fra FPGA en kan ændre sig på baggrund af et input fra terminalen. Et eksempel på visning af modulernes status på websiden, kan ses i appendiks C Modultest - Webside I dette afsnit bliver kravene til websiden beskrevet og testet. Der har været fokus på at teste websides evne til at kommunikere til wifimodulet og videre til de respektive moduler. For flere detaljer om måleresultaterne læs mere i appendiks A. Nr. Testobjekt Krav Resultat 1 Webside Der skal kunne modtages input fra Dette virker. enten klik på mus eller touch. 2 Adgangskontrol Der skal være adgangskontrol til Dette virker. websiden. 3 Fjernstyring Websiden skal kunne tilgås over Dette er ikke testet. internettet. 4 Datasending Der skal kunne sendes data til WiFimodulet via internettet. Dette er ikke testet. Tabel 3.7. Tabel over måleresultaterne 1. Der er mulighed for input ved mus og touch. Der er knapper på websiden som kan trykkes ved mus eller touch. 2. Der er adgangskontrol til websiden. Der skal inputtes brugernavn og adgangskode for tilgang til websiden. 3. Websiden kan ikke fjernstyres da der ikke er en ekstern IP til rådighed. 4. Dette kunne ikke testes af samme årsag som punkt Modultest - WiFi kommunikation I dette afsnit bliver kravene til WiFi kommunikation beskrevet og testet. Der har været fokus på at teste WiFi kommunikationens responstid mellem websiden og WiFi-modulet. For flere detaljer om måleresultaterne læs mere i appendiks A. 51

62 Gruppe 414 Systemdesign Nr. Testobjekt Krav Resultat 1 WiFi kommunikation WiFi modulet skal kunne sende og Dette virker. modtage data fra FPGA en vha. Websiden. 2 Databehandling Dataen der sendes og modtages skal kunne behandles af FPGA en. Dette virker. 3 Responstid Dataen skal kunne sendes og modtages inden for 10 sekunder i et miljø med støj, og indenfor 1 sekund i et miljø uden støj. Tabel 3.8. Tabel over måleresultaterne Dette virker for et miljø med støj, men ikke for et miljø uden støj. 1. WiFi-modulet kan sende og modtage data fra og til FPGA en. Dette testes ved at sende en datastreng til FPGA en og afvente respons. 2. Data FPGA en modtager fra WiFi-modulet kan behandles. Dette testes ved at sende en kommando i en datastreng til FPGA en og se om den udfører kommandoen. Der sendtes en datastreng der bad om en ønsket temperatur på 27 C. 3. Responstiderne specificeret i kravene er overholdt for et miljø med støj, men ikke for et uden. Der sendes datastrenge fra websiden og en gennemsnitlig responstid på 9,08 sekunder blev opnået i et miljø med støj. En gennemsnitlig responstid på 6,71 sekunder blev opnået i et radiodødt rum uden støj. En tabel over målingerne og udregningerne af de gennemsnitlige responstider vises i tabel A.13 i appendiks A. 52

63 3.5. Webside Aalborg Universitet Seriel Kommunikationen mellem FPGA en og WiFi modulet sker gennem en seriel forbindelse. På figur 3.27 ses et blokdiagram over den serielle forbindelse mellem FPGA en og WiFi-modulet. Figur Blokdiagram over den serielle forbindelse. På figur 3.27 ses en Universal Asynchronous Receiver/Transmitter (UART) enhed. UART en er en konverteringschip placeret på FPGA en, der gør det muligt for FPGA en at kommunikere med andre enheder via den serielle kommunikation. UART en overfører dataen bit for bit ved en given baud rate, denne er valgt til at være For at opnå den ønskede baud rate med FPGA en, er der beregnet en counterværdi, kaldet baud_count, på baggrund af FPGA ens interne clock. Herunder i formel 3.7 ses hvordan denne beregning er lavet: baud_count = Internclock Ønsket baud rate [1] (3.7) Hvor: baud_count er counterværdien der bruges for at opnå den ønskede baud rate. Intern clock er hastigheden på FPGA ens interne clock. Ønsket baud rate er den ønskede baud rate. [ Hz Bd ] [Hz] [Bd] I formel 3.8 ses ovenstående formel med værdier indsat = [1] (3.8) Den beregnede baud_count fra formel 3.8 er så brugt til at bestemme hvornår FPGA en skal sende(tx) og modtage(rx) data, dette ses af figur 3.28 herunder. 53

64 Gruppe 414 Systemdesign Figur Baud rate cirkel På figur 3.28 vises der hvordan baud raten er opbygget samt hvornår FPGA en sender og modtager data. Værdierne for Rx og Tx er bestemt på baggrund af funktionaliteten der ønskes. Da der altid vil blive modtaget data fra websiden inden der sendes retur, er det valgt at modtage(rx) når baud_count har værdien 2605 og sende(tx) ved Dette betyder at der går 5203 ticks, efter modtaget data, inden FPGA en returnere en værdi. På figur 3.29 ses hvordan baud_count er brugt i VHDL koden. Figur VHDL kode til baud rate Tx. Hvor: TX_SEND er et flag der bliver sat høj hvis data er klar til afsendelse. baud_count er counterværdien der skal bruges for at opnå den ønskede baud rate. TX_SEND_OK er et flag der bliver sat høj hvis baud_count =2600. TX_SEND_COUNT er en counter til at styre hvor mange gange baud_count har haft værdien

65 3.5. Webside Aalborg Universitet Det ses af VHDL koden på figur 3.29 at det eneste tidspunkt TX_SEND_OK bliver sat høj, er når baud_count har værdien Det betyder at FPGA en nu sender med en baud rate på Når der skal modtages(rx) data til FPGA en, vil der sekventielt blive indlæst en byte af gangen som bliver samlet til én variabel, DATA. Et eksempel på indlæsningen kan ses på figur Figur VHDL kode til indlæsning af RX data Hvor: RX_COUNT tæller hvor mange bytes der er indlæst. DATA er den samlet variable hvor de modtagne bytes bliver indlæst. DATAFLL er den variabel hvor det modtagne bytes fra WiFi modulet bliver gemt midlertidigt. Figur Diagram af dataoverførslen i UART en. På figur 3.31 er der givet et eksempel på hvordan overførslen af en 8 bit datastreng fra UART en kunne se ud. Dataoverførslen finder sted ved at der sendes et start bit i form af et 1 efterfulgt af en bit datastreng startende fra den mindst betydende bit og slutter med et stop bit i form af et 0. For at datastrengen fra UART en kan sendes videre gennem RS232 stikket kræver det en konvertering af spændingsniveauet. Spændingsniveauet fra TTL seriel til RS232 standarden bliver konverteret af en MAX3232CPE, se bilag 2, som er indbygget på FPGA en. RS232 stikket er herefter forbundet til et serielt modul, se figur 3.27, som der er valgt at bygge til WiFi modulet med henblik på at få WiFi modulet til at kommunikere med FPGA en. Det serielle modul består 55

66 Gruppe 414 Systemdesign af en MAX3232CPE som konverterer det modtagende RS232 spændingsniveau til et TTL seriel spændingsniveau der kan håndteres af WiFi modulet. I databladet for WiFi modulet, ses der at det er kompatibelt med protokollen for RS485. RS485 stikket kører som standard med half duplex.[18]. FPGA en er dog ikke kompatibelt med et RS485 stik men et RS232 stik, som kører med full duplex.[19]. Disse to protokoller giver en udfordring, som der i VHDL koden løses ved at give Rx og Tx forskellige sende/modtage tidspunkter. Da MAX3232CPE kræver en forsyningsspænding mellem 3 volt og 5 volt, er der valgt at anvende en lineær regulator af typen LE33, se bilag 7, til at fastholde en spænding på 3,3 volt. Det serielle modul er tilsluttet TXD og RXD gennem WiFi modulets TTL pins. De to pins CTS og RTS anvendes ikke, da port 7 og 8 på RS232 på FPGA en ikke er tilsluttet. På diagrammet, se appendiks B, er der to kondensatorer, hhv. C2 og C5, som er koblet op som en spændingsdoubler der inverterer V CC således at der ligger ±3, 3 volt på hhv. V+ og V. Dette gør at der på RS_TXD og RS_RXD portene, vil ligge ±3, 3 volt som definerer høj og lav på port 2 og 3 på RS232 stikket. På tabel 3.9 ses de respektive spændingsniveauer. I de næste to tabeller er V OL for output lav og V OH for output høj, for hhv. seriel modul og WiFi modulet. For input gælder følgende at V IL er input lav og V IH er input høj. MAX3232 spændingsniveauer TTL RS-232 V OL 0V +3,3V V OH 3V -3,3V V IL 0V +3,3V V IH 0V -3,3V Tabel 3.9. Tabel over spændingsniveauerne i det serielle modul For TTL seriel gælder der typisk følgende spændingsniveauer V OH = 3, 4 volt og V OL = 0, 2 volt for output signalerne. Til input gælder V IH = 2 volt og V IL = 0, 8 volt.[20]. På tabel 3.10 ses hvilke krav der gælder for minimum og maksimum spændingerne for WiFi-modulet. Dette er taget ud fra databladet se bilag 1. Da der anvendes to 1,5 volt batterier, som forsyning til WiFi-modulet er V CC = 3, 0 volt. TTL-WiFi Formel Værdi V OH 0, 95 V CC Min 2,85V V OL 0, 05 V CC Max 0,15V V IH 0, 07 V CC Min 2,1V V IL 0, 3 V CC Max 0,9V Tabel Tabel over de maksimale spændingsniveauer på WiFi-modulet I dette afsnit er der givet en forklaring af hvordan FPGA en kommunikere med WiFi modulet. 56

67 3.6. Terminal Aalborg Universitet 3.6 Terminal For at styre systemet lokalt, anvendes en 60 Hz skærm, se bilag 11, og et PS/2 tastatur til styring af en lokalterminal. Dette giver brugeren mulighed for at kunne se og tilpasse temperaturen, tænde og slukke tyverimodulet samt overvåge vandgennemstrømningsmodulet. Idet at brugeren anvender en lokal brugerflade, som kun kan tilgås ved direkte tilkobling til FPGA en, er adgangskode til brug af terminalen unødvendig. VHDL koden til terminalen er opdelt i adskillige blokke, hvor inputtet fra brugeren kommer fra et PS/2 tastatur som er tilsluttet FPGA en. Dette input behandles i de individuelle blokke og sendes derefter ud på en skærm via FPGA ens VGA port. Følgende underafsnit beskriver de mest relevante blokke og deres funktioner VGA Synkronisering VGA synkroniseringen er en blok, som sørger for at tælle pixels i VHDL koden, denne blok gør det muligt at placere bogstaver og tegn de rigtige steder på skærmen. Der er valgt at anvende en opløsning på 640x480 pixels dette valg er taget på baggrund af FPGA ens specifikationer, se bilag 9. Skærmen opdateres ved hjælp af to countere, h_sync og v_sync. h_sync tæller på en 25 MHz clock og v_sync tæller én op hver gang h_sync har scannet en hel linje. h_sync tæller horisontalt på skærmen, mens v_sync tæller vertikalt. Det tager 640 clock slag plus front porch, sync pulse og back porch for at scanne den horisontale linje. v_sync skal tælle 480 gange plus front porch, sync pulse og back porch for at scanne den vertikale linje. Front porch, sync pulse og back porch udgør en blank synkroniserings periode, som er en serie af sorte pixels som sendes efter billedsignalet er sendt. Ved et 640x480 signal forlænger denne blanke periode mængden af pixels der skal sendes fra 640x480 til 800x525 [21], dette kan ses på figur Figur Illustration af VGA synkronisering. 57

68 Gruppe 414 Systemdesign 25 MHz clocken er udregnet til at opdatere skærmen 60 gange i sekundet ved følgende ligning: FPS = Clock h_sync v_sync (3.9) Hvor: FPS er hastigheden som skærmen opdaterer med [Hz] Clock er den beregnede clock [Hz] h_sync er den horisontale opløsning plus de blanke synkroniserings parametre. [1] v_sync er den vertikale opløsning plus de blanke synkroniserings parametre. [1] Da vi ved hvad v_sync og h_sync er sat til, samt at vi ønsker en FPS på 60 Hz, indsættes disse og clocken isoleres og udregnes. 25, 2 = 60 ( ) [MHz] (3.10) Herved ses det at en 25 MHz clock sørger for en FPS på 60 Hz Tastatur Der anvendes et PS/2 tastatur som input fra brugeren i terminalen. Tastaturet er tilsluttet FPGA ens PS/2 port, hvor et tastatur tryk modtages i form af en key_code, denne er en hexadecimalværdi. Da der modtages en key_code fra PS/2 tastaturet, er det nødvendigt at oversætte den trykkede tasts værdi til den tilhørende ASCII kode, da denne skal bruges til et senere modul. Eksempelvis har bogstavet K key_code decimalværdien 66 som svarer til ASCII decimalværdien 75, se figur

69 3.6. Terminal Aalborg Universitet Figur Udsnit af en ASCII tabel [22] til venstre, samt et tastatur med key_codes til højre [23]. Siden key_code ikke har en lineær sammenhæng som ASCII tegn har, skal de oversættes enkeltvis. Kodeudsnittet herunder giver et eksempel på hvordan det kan gøres. 59

70 Gruppe 414 Systemdesign Figur Kodeudsnit til oversættelse af key_code. Hvor: key_code er inputtet fra PS/2 tastaturet. ascii_code er ASCII værdien, repræsenteret binært, der tilsvarer key_code Random Access Memory Der anvendes en Random Access Memory (RAM) IP-blok, kaldet video_ram, til at gemme de genererede ASCII værdier fra PS/2 tastaturet. Disse gemte værdier bliver kaldt hver gang skærmen opdateres dvs. 60 gange i sekundet, dette gør at brugerens input ses på skærmen som en permanent karakter. Samtidigt er det også RAM-blokken der læses i for at indhente kommandoer fra brugeren, dette sker ved at VHDL koden læser de indtastede værdier fra RAM-blokken ned i variabler, og sammenligner dem med prædefinerede strenge. Hvis sammenligningerne stemmer overens, vil FPGA en udføre den ønskede funktion. Eksempelvis hvis kommandoen TEMP25 indtastes, aktiveres regulering af temperaturen og den ønskede temperatur sættes til 25 C. Et eksempel på indlæsning af disse karakterer ses i kodeudsnittet herunder. 60

71 3.6. Terminal Aalborg Universitet Figur Kodeudsnit til indlæsning af karakterer. Hvor: letter# er variablerne hvor værdierne gemmes. Term_Temp_Req er den ønskede temperatur. I figur 3.35 anvendes if-kæderne til at undersøge om de fire første karakterer er TEMP og om de to sidste er tal. Hvis disse kæder bliver sande, vil de to sidste karakterer sættes som ny ønsket temperatur i systemet. Hvis de ikke går sande, vil intet foretage sig Generering af tekst Til generering af tekst på skærmen anvender VHDL koden de tidligere nævnte ASCII værdier fra RAM-blokken, samt en rækkeadresse fra vga synkroniseringen. ASCII værdien og rækkeadressen udgør adressen for karakteren i FONT-ROM blokken. FONT-ROM en er en samling af bitmønstre, der grafisk repræsenterer ASCII værdien der er læst fra RAM-blokken. Et stykke af FONT-ROM en kan ses i understående kodeudsnit. 61

72 Gruppe 414 Systemdesign Figur Kodeudsnit af FONT-ROM blokken Hvor: char_addr er karakterens ASCII værdi og bitmønstrets adresse. row_addr er adresserne på linjerne i bitmønstret Statisk tekst Der er skrevet en IP-blok, kaldet pixel_unit, til generering af tekst som skal forblive uændret på skærmen. Den er også designet til at kunne indlæse variabler fra andre IP-blokke, således at den kan udskrive status og værdier fra andre moduler. Den fastholder tekst på et forudbestemt område af skærmen, som ikke kan ændres fra andre IP-blokke. Dette område dedikeres ved at en bestemt mængde pixels kodes til kun, at kunne ændres i denne IP-blok. Dette kan ses ved understående kodeudsnit: 62

73 3.6. Terminal Aalborg Universitet Figur Kodeudsnit af dedikering af pixels. Hvor: char_addr er variablen hvori ASCII karakteren ligger, og hvorfra den senere læses ud på skærmen. static_font er en midlertidig variabel hvor de ønskede statiske karakterer læses ned i. superpixel_x er ASCII-karakter pladsen i den horisontale linje på skærmen. superpixel_y er ASCII-karakter pladsen i den vertikale linje på skærmen. På figur 3.37 ses det, at static_font indlæses på char_addr i de pixelområder som begrænsningerne for superpixel_x og superpixel_y beskriver. superpixel_x og superpixel _y udgør tilsammen alle pladser til ASCII karakterene på skærmen. superpixel_x består af stykker på 8 pixels, og superpixel_y består af stykker på 16 pixels. Dette gør at ASCII karakterer har en fontstørrelse på 8x16 pixels på skærmen. Inde i pixel_unit IP-blokken bestemmes hvad der skal læses ind i static_font og dermed det dedikerede område. Understående kode viser et udsnit af, hvilke ASCII karakterer som bliver indlæst i static_font på hvilke pladser. 63

74 Gruppe 414 Systemdesign Figur Kodeudsnit af indlæsning af ASCII karakterer til static_font. Hvor: Temp_Req er en indlæst variabel fra en anden IP-blok. Ud fra figur 3.38 ses det, at hver enkel superpixel får tillagt sin egen ASCII værdi, og dermed sin egen karakter på skærmen. Det ses også, at en værdi indlæst fra en anden IP-blok, her i form af Temp_Req, kan udskrives på en ønsket superpixel. Eksempelvis hentes ASCII værdierne for den nuværende temperatur ind i pixel_unit, og skrives ud ind i bestemte superpixels og derefter ud på skærmen via static_font Samlet oversigt For at give et samlet overblik over terminalen, kommer her en gennemgang af et scenarie der viser hvordan de forskellige blokke reagerer på et input. Herunder kommer en figur som viser opbygningen af Terminalen, se figur

75 3.6. Terminal Aalborg Universitet Figur Samlet oversigt over associationerne i Terminalen. Som det ses af figuren er der et tastatur tilkoblet FPGA ens PS/2 port, fra dette tastatur kommer der, som tidligere nævnt, et input kaldet key_code, der eksempelvis kunne være et K med key_code decimalværdien 66. Dette input bliver i KeyToASCII konverteret til en ASCII decimalværdi på 75. Denne ASCII værdi bliver så gemt i video_ram blokken, på den adresse som hører til positionen, hvor den ønskede karakter skal skrives. Herefter er det muligt for text_gen blokken at kalde denne ASCII værdi, når dette er nødvendigt. text_gen blokken modtager så to inputs fra VGA synkroniseringen kaldet pixel_x og pixel_y disse inputs er indikationer af hvor på skærmen VGA synkroniseringen er nået til. pixel_x og pixel_y bruges til at bestemme hvilken adresse der skal læses fra i video_ram blokken, dette betyder at text_gen altid modtager det samme input fra video_ram når der opdateres et bestemt sted på skærmen. Eksempelvis hvis det førnævnte K er skrevet på plads nummer tre i pixel_x retningen og plads nummer fem i pixel_y retningen vil dette blive skrevet her hver gang skærmen opdateres, se figur

76 Gruppe 414 Systemdesign Figur Billede af Terminalen. For at karakteren kan vises på skærmen, er tidligere nævnte FONT_ROM blevet implementeret, for yderligere gennemgang af dennes funktion se afsnit Når signalet fra FONT_ROM blokken modtages af text_gen blokken bliver dette sendt til FPGA ens VGA Port og vises derved på skærmen Modultest I dette afsnit bliver kravene til terminalen beskrevet og testet. Der har været fokus på at testet kommunikationen mellem terminalen og systemets moduler. For flere detaljer om måleresultaterne læs mere i appendiks A Nr. Testobjekt Krav Resultat 1 PS/2 tastatur. Modulet skal kunne modtage input Dette virker. fra et PS/2 tastatur. 2 Skærm. Skærmen skal kunne vise inputtet Dette virker. fra tastaturet. 3 I/O moduler. Terminalen skal kunne læse og udføre kommandoer på I/O modulerne. Dette virker. Tabel Tabel over måleresultaterne 1. Modulet modtager input fra tastaturet. Dette testes ved at indtaste karakterer på PS/2 tastaturet. 2. Skærmen viser input fra tastaturet. Dette testes ved at se på skærmen mens der tastes på tastaturet. 3. Terminalen kan læse og udføre kommandoer til og fra I/O moduler. Dette testes ved at sende en værdi fra terminalen. Værdien TEMP27 sendes, denne værdi skal regulere opvarmningsmodulet til 27 C. 66

77 3.7. Systemscenarie Aalborg Universitet 3.7 Systemscenarie I dette scenarie sættes en temperatur på 28 C TEMP28 på terminalen og vil blive fulgt igennem hele systemet. Dette scenarie er opstillet for at kunne se hvad der sker, når en kommando indtastes. Figur Eksempel på indtastning af en kommando i terminalen. Ved indtastning af TEMP28 på terminalen, se figur 3.41, sendes den ønskede temperatur til Brugerflade, se figur 3.42, som to ASCII værdier hhv. 2 og 8. I Brugerflade bestemmes der om websiden eller terminalen har første prioritet til at skrive, hvilket i dette tilfælde er terminalen. Temperaturværdien sendes derefter videre til styringsmodulet, som sender den til I/O modulet uden anden indvirkning. I/O modulet sender ASCII værdierne til temperaturmodulet, hvor værdierne konverteres til en binær værdi, for at kunne sammenligne med den aktuelle temperatur. I dette eksempel er den nuværende temperatur på 25 C, hvis binære repræsentation er Dette betyder at den ønskede temperatur er højere end den nuværende temperatur, og derfor tændes halogenpæren så rumtemperaturen stiger. For at brugeren kan følge temperaturændringen, sendes den nuværende temperatur fra temperaturmodulet til I/O modulet, det samme gør sig gældende for den ønskede temperatur på 28 C. Disse signaler er i dette tilfælde, hhv. 28 C repræsenteret binært og 25 C repræsenteret som ASCII værdier. Fra I/O modulet sendes de til styrings modulet og derefter til Brugerflade. I Brugerflade sendes den nuværende temperatur til 7 segment modulet, hvor denne bliver konverteret til en ASCII værdi og en segment værdi, ASCII værdien sendes til Brugerflade, hvorimod segmentværdien aktiverer de to 7 segment displays der så viser den nuværende temperatur. Dette betyder at der nu er to ASCII repræsentationer af hhv. den ønskede temperatur og den nuværende temperatur i Brugerflade, de bliver parallelt sendt til websiden og terminalen, så der begge steder vises den samme værdi for ønsket og nuværende temperatur. 67

78 Gruppe 414 Systemdesign Figur Illustration af temperaturskifte. Der er nu givet et indblik i hvordan systemets respektive moduler er opbygget. Der er også blevet beskrevet hvilke funktionaliteter modulerne har. Da der nu er givet et indblik i systemets udformning, er det essentielt at foretage tests af disse moduler, for at se om modulerne opfylder de opstillede krav, dette vil blive uddybet i næste afsnit. 68

79 4 Accepttest I dette kapitel bliver de overordnede krav til produktet beskrevet og testet. Kravene er taget direkte ud fra kravspecifikationen og indebærer overordnede funktionelle krav til produktet. Nr: Funktionalitet Krav: Resultat 1 Fjernstyring af bolig: Vandgennemstrømningen skal kunne overvåges. - Tyverialarmen skal kunne overvåges samt tændes og slukkes. - Temperaturen skal kunne overvåges og reguleres. Dette virker delvist. Dette virker delvist. Dette virker delvist. 2 Lokal styring af bolig: Vandgennemstrømningen skal kunne overvåges. - Tyverialarmen skal kunne overvåges samt tændes og slukkes. - Temperaturen skal kunne overvåges og reguleres. Dette virker. Dette virker. Dette virker. Tabel 4.1. Tabel af de overordnede krav i projektet. 1. Til fjernstying af bolig blev der kun testet med lokal IP, og derved var der ikke mulighed for at teste fjernstyringen af boligen udover på det lokale netværk. Dette gør selvfølgelig testen ufuldstændig, men der bør tages i mente at ingen ekstern IP var tilgængelig og derfor var der ingen reel mulighed for at gøre testen komplet. Opsætningen til at fuldføre systemet med en ekstern IP er allerede forberedt. Derfor ville systemet kunne færdiggøres hurtigt hvis en ekstern IP blev tilgængelig. Mere kan læses om dette i modultestene for WiFi-kommunikation og Webside. 2. Den lokale styring af bolig blev testen udført og virker som planlagt. Produktet kan styres som kravene specificerer via terminalen. Mere kan læses om dette i modultesten for terminalen. 69

80

81 5 Perspektivering I dette kapitel vil der perspektiveres på projektet. Der vil blive redegjort og undersøgt i en samfundsmæssig sammenhæng, hvorvidt prototypen i projektet har mulighed for at etablere sig i på det danske marked. Som der er blevet undersøgt i afsnit 1 er de to største produkter i Danmark indenfor intelligente hus teknologi, hhv. IHC og Smart House. Som der også er nævnt udvikler disse virksomheder dog oftest løsninger som brugeren i de fleste tilfælde kan erhverve sig som separate moduler. I mange år har virksomheder som Dansikring udviklet løsninger til både private og erhverv indenfor tyverialarmer.[24]. Ligeledes er det en egenskab i mange intelligente hus systemer at tilkoble en tyverialarm og styre den. Det interessante i sådan et tilfælde er at mange af disse tilvalg allerede er på markedet, udarbejdet af virksomheder som specialiserer sig indenfor de respektive områder. Derfor ville det for en bruger være mere interessant at have muligheden for at kontrollere utraditionelle men ofte anvendte områder af boligen, eksempelvis en kaffemaskine, opfyldning af karbad, fjernstyring af lys med mere. I projektet er der dog valgt at lave en prototype af de traditionelle elementer for at demonstrere og eftervise princippet af et fuldt udarbejdet produkt. For at have et konkurrencedygtigt produkt kræver det, at produktet har den rette pris, og stadig give et overskud der gør det rentabelt for virksomheden. Priserne for intelligente husinstallationer varierer alt afhængig af hvor stor en installation der ønskes at implementere i sin bolig. For et system fra IHC koster de respektive installationer fra 1500 kr. til kr.[25]. Ulempen ved at lave en løsning som bygger på at sælge pakkeløsninger, som IHC gør, er at forbrugeren tvinges til enten at købe de billige løsninger med få installationer, eller installere de store løsninger som kan indeholde løsninger som ikke kommer forbrugeren til gode. En mulighed i dette tilfælde ville være, at give forbrugeren mulighed for at købe en kontrolenhed der er fundamentet for hele systemet. Dette vil give forbrugeren mulighed for at tilvælge moduler som forbrugeren ønsker at kontrollere og overvåge. Hvis forbrugeren skal have fuld frihed til at til- og fravælge moduler kræver det, at systemet bygges så systemets grundsystem ikke er afhængig af modulerne så snart systemet bliver implementeret i boligen. En udfordring som af mange virksomheder har er at implementere intelligent hus teknologi i eksisterende huse. Op mod 20% af alle IHC installationer finder sted i eksisterende boliger, dog er denne løsning dyrere for at få implementeret i eksisterende boliger kontra nye boliger.[26]. Dette kan som tidligere nævnt være en konsekvens af at de løsninger som bliver tilbudt forbrugeren er pakkeløsninger. Hvis prototypen i projektet blev fuldt udviklet, kunne produktet have sin berettigelse på det danske marked. En salgsmodel kunne som tidligere diskuteret være en løsning med en 71

82 Gruppe 414 Perspektivering kontrolenhed der under alle omstændigheder skal installeres. Herefter kan forbrugeren tilvælge forskellige moduler alt afhængig af behov. Denne løsningsmodel kan vise sig at være en fordelagtig fremgangsmåde. Dette skyldes at da teknologien stadig er relativ ny i Danmark, kunne det tænkes at virksomhederne som er at finde på det danske marked udnytter deres position til at udforme og strukturerer løsninger og produkter efter deres behov. Men med den omtalte salgsmodel kan de etablerede og større virksomheder være tvunget til at ændre deres strategi, hvilket vil give en øget konkurrence og forbrugeren får i højere grad mulighed for at vælge den virksomhed som de vil køber deres produkter hos. Kontrolenheden kunne i et fuldt udviklet produkt laves på baggrund af en ASIC, som der også kan læses mere om i afsnit En fordel ved at implementere intelligent teknologi i boligen er at forbrugeren får muligheden for at styre de dele af huset som der ønskes. Dette betyder at brugeren har mulighed for at kontrollere lys, standby forbruget med mere. Denne adgang til husstandens enheder giver anledning til at der kan spares på boligens strømforbrug. Dette leder videre til at der kunne ydes en større indsats for, at gøre borgerne i Danmark bedre informerede om fordelene og ulemperne ved at gøre boligen intelligent. Et centralt sted hvor der kunne gøres en indsats kunne være hos Energistyrelsen. Her kunne der investeres penge i at få oplysningen ud til samfundet i forlængelse af deres i forvejen eksisterende tiltag på hjemmesiden Sparenergi.dk.[27]. En måde at udvide tilgængeligheden af produktets funktionaliteter er ved at udvikle en app. Appen kan udvikles til en smartphone og/eller en computer. Fordelen ved at anvende en app, er at den kan fungere uden internet og derved fungere over et lokalt netværk i boligen. Dette betyder at i tilfælde af at websiden er ude af drift eller at der ikke opnås internetadgang, kan appen opnå forbindelse gennem det lokale netværk. Da vi har en TCP-forbindelse samt datasyntaks er det nemt at udvide til andre applikationer, fordi disse applikationer kun kræver en indkodet TCP klient. Der kan diskuteres hvorvidt intelligent teknologi er en fordel eller ulempe, dette afhænger alt sammen af behov og/eller penge. For nogen har betydningen af penge ikke indflydelse på beslutningen om at implementere systemet i boligen. For andre har betydningen om pengene de investerede kan tjenes ind igen. Dette kan netop lade sig gøre da systemet giver anledning til lavere strømforbrug, dog er det vigtigt at have besluttet sig for, hvor stor en tidsperiode det tager at tjene investeringen hjem. 72

83 6 Konklusion Der vil i dette kapitel blive konkluderet på projektets problemstilling, projektforløbet samt de indsamlede resultater. Projektets problemstilling lyder som følger; Hvordan kan et elektronisk system designes til at styre hjemmets apparater, enheder og målere. Der blev valgt at udarbejde en prototype der kunne demonstrere de væsentligste principper. Systemet endte med at bestå af 3 I/O enheder, en webside og en terminal. For at en given bruger kunne tilgå systemet via websiden, blev der arbejdet med WiFi kommunikationen mellem websiden og FPGA en. For at sikre at modulerne fungerede efter de krav der var opsat til dem, blev der løbende foretaget tests. Indledningsvist blev I/O enhederne bygget på et breadboard og herefter på baneprint og afslutningsvist på et PCB. Dette tiltag gjorde at der løbende kunne fejlfindes, da det ellers ville kræve væsentligt længere tid at udvikle et PCB. Som der kan læses i Appendiks A blev I/O enhederne, terminal, webside samt WiFi kommunikationen testet ift. de krav som blev udarbejdet i kravspecifikationen. I/O enhederne kunne eftervises efter den ønskede hensigt, dog havde temperaturmodulet nogle afvigelser som gav anledning til unøjagtige måleresultater. Som der blev nævnt i målejournalen om temperaturmodulet, var det ikke muligt at måle, omgivelsestemperaturen med IR termometeret, men derimod temperaturen af pladen bag sensoren. I vandgennemstrømningsmodulet gør det sig gældende, at det udviklede modul ikke vil være anvendeligt i en bolig som et fuldt udviklet produkt. Dette skyldes at der på markedet i forvejen eksisterer et produkt som vil fungere bedre end løsningen der blev udarbejdet i projektet. Projektets løsning bygger på at et vandmøllehjul som begynder at dreje når der er vandgennemstrømning igennem møllen. Ulempen med denne løsning er at der skal en forholdsvis stor mængde vand igennem møllen, før den begynder at registrere vandgennemstrømningen. I et færdigudviklet produkt vil det være et krav til produktet at modulet begynder at overvåge vandgennemstrømningen så snart dette er tilstede. Der er i projektet blevet anvendt forskellige former for planlægningsværktøjer for at skabe et overblik over den tid der har været tilgængelig under projektforløbet. Der har overordnet set været brugt tre forskellige værktøjer. Det ene værktøj der blev gjort brug af var en af tavlerne i grupperummet. På tavlen blev skemaet for den pågældende uge skitseret op. Dette gjorde det lettere at danne sig et overblik, over hvor meget tid der kunne afsættes til projektet, alt afhængig hvor mange kurser der ville være den pågældende uge. Et andet værktøj der blev gjort brug af var en månedskalender. Her blev der sat deadlines for hvornår de overordnede kapitler, såsom 73

84 Gruppe 414 Konklusion indledning, kravspecifikation med flere skulle være færdige. Det sidste værktøj der blev brugt var Google Drev, her kunne de enkelte gruppemedlemmer skrive deres navn på en arbejdsopgave og sætte en deadline for hvornår opgaven skulle være udarbejdet. 74

85 Litteratur [1] J. R. Virén and Kristine. (2014, Feb.) Generelt om intelligente boliger. [Online]. Available: [2] A. I. AS. (2014, Feb.) Hvad er hjem til fremtiden. [Online]. Available: [3] T. J.. P. McEvedy. (2014, Feb.) Master control panel [Online]. Available: [4] S. E. D. AS. (2014, Feb.) Fakta om ihc-familien. [Online]. Available: Lauritz+Knudsen/privat/det-intelligente-hjem/Fakta-om-IHC-familien.page? [5] TEKNORDISK. (2014, May) Hvad er ihc og hvad kan det? [Online]. Available: [6] S. H. ITcms. (2014, Feb.) Duplines smart house eller lk ihc. [Online]. Available: [7]. (2014, May) Prinsippdiagram for smart-house. [Online]. Available: [8] OneRemote. (2014, Feb.) Fjernbetjening infrarød. [Online]. Available: [9] I. Bluetooth SIG. (2014, Feb.) A look at the basics of bluetooth technology. [Online]. Available: [10] T. N.. M. Valle. (2014, Feb.) How does wlan work? [Online]. Available: [11] G. Americas. (2014, Feb.) Understanding 1g vs. 2g vs. 3g vs. 4g. [Online]. Available: [12] K. Pahlavan. (2014, Feb.) Gsm and tdma technology. [Online]. Available: [13] X. Inc. (2014, Feb.) Field programmable gate array (fpga). [Online]. Available: [14]. (2014, Feb.) Fpga vs. asic. [Online]. Available: [15] O. E. inc. (2014, May) All-plastic vortex flow meter for corrosive liquids. [Online]. Available: 75

86 Gruppe 414 Litteratur [16] L. Parziale, D. T. Britt, C. Davis, J. Forrester, W. Liu, C. Matthews, and N. Rosselot, TCP/IP Tutorial and Technical Overview, 8th ed. Vervante, 2006, isbn: [17] J. Kleist, Distributed systems and network: Lecture 4, dsn-e13-lec4.pdf, Aug. 2013, filen ligger på cden som dsn-e13-lec4.pdf. [18] B. E. Mfg. (2014, May) Basics of the rs-485 standard. [Online]. Available: Basics-of-the-RS-485-Standard.aspx [19] I. Mosaic Industries. (2014, May) Understanding serial communications. [Online]. Available: rs232-serial-rs485-protocol-uart-usart/understanding-serial-communications [20] L. M. Andersen and K. Rundblad, Digital og mikroprocessor teknik, 4th ed. Erhvervsskolernes Forlag, 2009, pp , isbn: [21] N. Ickes. (2014, may) Vga video output. [Online]. Available: [22] A. Courteau. (2014, May) Table ascii -i. [Online]. Available: [23] C. Peacock. (2014, May) Interfacing the at keyboard. [Online]. Available: [24] Dansikring. (2014, May) Vores alarmsystemer. [Online]. Available: tyverialarm-standard.html [25] L. Knudsen. (2012, Jul.) Priser: Ihc bolig. [Online]. Available: Knudsen/privat/det-intelligente-hjem/kampagne-ihc-bolig/priser.page [26] Bolius. (2014, May) Shh... vores taeppe snakker. [Online]. Available: [27] Energistyrelsen. (2014, May) N/a. [Online]. Available: [28] J. Nielsen. (1993, Jan.) Response times: The 3 important limits. [Online]. Available: [29] J. Kleist, Distributed systems and network: Lecture 5, dsn-e13-lec5.pdf, Aug. 2013, filen ligger på cden som dsn-e13-lec5.pdf. [30] N. Semiconductor. (2000, Nov.) Lm35 precision centigrade temperature sensors. [Online]. Available: http: // [31] Bolius. (2013, Nov.) Hold husets rør varme og undgaa frostspraengninger. [Online]. Available: [32] H. Buch. (2014, May) Produkt katalog. [Online]. Available: 76

87 Litteratur Aalborg Universitet [33] P. P. Chu, FPGA Prototyping By VHDL Examples, 3rd ed. Wiley Interscience, 2008, p. 292, isbn:

88

89 A Målejournaler A.1 Temperatursensor Gruppe 414 Den 6. maj 2014 A.1.1 Formål Formålet med dette afsnit er at teste kravene fra kapitel 2 der vedrører temperaturmodulet. Der er fokus på præcisionen af modulet og om det er i stand til over en længere periode at måle omgivelsestemperaturen ift. de opstillede krav. A.1.2 Opsætning Figur A.1. Diagram over temperaturmodulet. A.1.3 Materielliste Instrumenter AAU-no. Type Kommentarer FPGA Spartan 3 XC3S200 Multimeter Fluke and Philips 37 IR temperaturmåler N/A KC-180A Kølespray N/A Freeze 75 Tabel A.1. Tabel over materialer anvendt under testen. 79

90 Gruppe 414 Målejournaler A.1.4 Fremgangsmåde 1. Forbind temperaturmodulet til FPGA en gennem expansion-connectoren B1. 2. Forbind temperaturmodulet til 3,3V porten på FPGA en. 3. Forbind temperaturmodulet til et multimeter og mål outputtet på temperatursensoren. 4. Åben programmet "Xilinx", indtast følgende indstillinger til FPGA en. Family: Spartan 3 Device: XC3S200 Package: FT256 Speed: -4 Synthesis Tool: XST (VHDL/Verilog) Simulator: ISim (VHDL/Verilog) Preferred Language: VHDL Property Specification in Project File: Store all values VHDL Source Analysis Standard: VHDL Kompiler programmet. 6. Den pågældende temperatur der er i temperaturmodulet kan aflæses på 7-segmentdisplayet. 7. Følgende kan udføres som led i en verifikation af systemet Ønskes der at nedkøle temperatursensoren sprøjtes kølesprayen på temperatursensoren. A.1.5 Resultater Krav Omgivelsestemperaturen målt af temperatursensoren skal vises på et 7-segment display. Outputtet som sendes til 7 segment displays må ikke afvige med mere end 1 C ift. omgivelsestemperaturen. Resultat Dette virker. Dette virker. Tabel A.2. Tabel over måleresultaterne A.1.6 Fejlkilder og afvigelser En fejlkilde ved målingen af temperaturen er at IR termometeret målte på bagvæggen af rummet hvori temperatursensoren var placeret men ikke i "omgivelsen". 80

91 A.2. Opvarmningsmodul Aalborg Universitet A.2 Opvarmningsmodul Gruppe 414 Den 6. maj 2014 A.2.1 Formål Formålet med dette afsnit er at teste de opstillede krav til opvarmningsmodulet som ses i afsnit 2. Der er lagt fokus på stabilitet, da det ønskes at teste om modulet er i stand til at opvarme sine omgivelser konsistent. A.2.2 Opsætning Figur A.2. Diagram over opvarmningsmodulet. A.2.3 Materielliste Instrumenter AAU-no. Type Kommentarer Strømforsyning Hameg Triple 3 Supply HM7042 FPGA Spartan 3 XC3S200 Tabel A.3. Tabel over materialer anvendt under testen A.2.4 Fremgangsmåde 1. Forbind opvarmningsmodulet til strømforsyningen. 2. Forbind opvarmningsmodulet til FPGA en gennem expansion-connectoren A2. 3. Åben programmet "Xilinx", indtast følgende indstillinger til FPGA en. Family: Spartan 3 Device: XC3S200 Package: FT256 Speed: -4 Synthesis Tool: XST (VHDL/Verilog) Simulator: ISim (VHDL/Verilog) 81

92 Gruppe 414 Målejournaler Preferred Language: VHDL Property Specification in Project File: Store all values VHDL Source Analysis Standard: VHDL-93 Afhængig af hvor høj en temperatur der ønskes, kan dette justeres vha. websiden eller terminalen. 4. Kompiler programmet. A.2.5 Resultater Krav Opvarmningsmodulet skal kunne modtage en brugerdefineret ønsket temperatur, og reagere på baggrund af dette. Omgivelsestemperaturen må maksimalt have en afvigelse på 1 C ift. den ønskede temperatur efter opvarmning. Resultat Dette virker. Dette virker. Tabel A.4. Tabel over måleresultaterne A.2.6 Fejlkilder og afvigelser Da kassen som modulet er monteret i ikke er isoleret, har der været anledning til at der kunne sive varme ud gennem revner og lignende. Dette har betydet at afmålingen af omgivelsestemperaturen kan have haft en afvigelse og derved ikke været repræsentativ ift. de forventede måleresultater. 82

93 A.3. Tyverimodul Aalborg Universitet A.3 Tyverimodul Gruppe 414 Den 6. maj 2014 A.3.1 Formål Formålet med dette afsnit er at teste de udarbejdede krav til tyverimodulet, se kapitel 2. Der vil i denne test være specielt fokus på om der udsendes alarm hvis afstanden ændres eller strømmen fjernes fra modulet. Stabiliteten af modulet måles ved at der ikke på noget tidspunkt må udsendes alarm hvis afstanden ikke ændres. A.3.2 Opsætning Figur A.3. Diagram over tyverimodulet. A.3.3 Materielliste Instrumenter AAU-no. Type Kommentarer FPGA Spartan 3 XC3S200 Tabel A.5. Materialer anvendt under testen A.3.4 Fremgangsmåde 1. Forbind tyverimodulet til FPGA en gennem expansions-connectoren A1. 2. Åben programmet "Xilinx", indtast følgende indstillinger til FPGA en. Family: Spartan 3 Device: XC3S200 Package: FT256 Speed: -4 Synthesis Tool: XST (VHDL/Verilog) Simulator: ISim (VHDL/Verilog) Preferred Language: VHDL Property Specification in Project File: Store all values VHDL Source Analysis Standard: VHDL-93 83

94 Gruppe 414 Målejournaler 3. Kompiler programmet. 4. Afbryd herefter signalet med et objekt. Der vil nu blive sendt et output ud fra FPGA en og en alarm vil blive aktiveret. A.3.5 Resultater Krav Hvis modulet er slået fra, skal intet signal udsendes. Hvis modulet er i passiv tilstand skal det afvente indtil dets udsendte signal bliver brudt, og hvis det gør skal det gå i alarmtilstand. Hvis modulet er i alarmtilstand skal det udsende et alarmsignal. Hvis sensoren mister forsyning i passiv tilstand, skal modulet gå i alarmtilstand. Resultat Dette virker. Dette virker. Dette virker. Dette virker. Tabel A.6. Tabel over måleresultaterne A.3.6 Fejlkilder og afvigelser For at finde niveauet for afstanden mellem sensoren og væggen af modulet, gav sensoren forskellige værdier mellem 0,7 og 0,74 volt som output, dette er et resultat af unøjagtigheder i implementeringen af sensoren i modulet og støj fra omgivelserne. 84

95 A.4. Vandgennemstrømningsmodul Aalborg Universitet A.4 Vandgennemstrømningsmodul Gruppe 414 Den 6. maj 2014 A.4.1 Formål Formålet med denne test er at teste de opstillede krav i kapitel 2. Fokus i denne test vil ligge i om alarm, rettidigt sendes efter for høj vandgennemstrømning i for lang tid. A.4.2 Opsætning Figur A.4. Diagram over vandgennemstrømningsmodulet. A.4.3 Materielliste Instrumenter AAU-no. Type Kommentarer Strømforsyning Hameg Triple 3 Supply HM7042 FPGA Spartan 3 XC3S200 Tabel A.7. Tabel over materialer anvendt under testen. A.4.4 Fremgangsmåde 1. Forbind vandgennemstrømningsmodulet til FPGA en på expansions-connectoren B1. 2. Åben programmet "Xilinx"og indtast følgende specifikationer til FPGA en. Family: Spartan 3 Device: XC3S200 Package: FT256 Speed: -4 Synthesis Tool: XST (VHDL/Verilog) Simulator: ISim (VHDL/Verilog) Preferred Language: VHDL Property Specification in Project File: Store all values VHDL Source Analysis Standard: VHDL Kompiler programmet. 85

96 Gruppe 414 Målejournaler 4. Forbind vandpumpen til strømforsyningen og indstil forsyningen til 7,3V. 5. Hvis vandgennemstrømningsmodulet overskrider en forudbestemt tærskelværdi over en bestemt tidsperiode, sendes et alarmsignal til FPGA en. A.4.5 Resultater Test Krav Resultat DC-motor Ved vandgennemstrømning Dette virker. skal motoren kunne levere en spænding Output Modulet skal kunne udsende et alarmsignal Dette virker. Tabel A.8. Tabel over testresultaterne A.4.6 Fejlkilder og afvigelser En fejlkilde ved dette modul er at der skal et større vandgennemløb igennem modulet, før der kan trækkes en spænding ud af DC-motoren, og derved sendes et alarmsignal ud til brugeren. 86

97 A.5. Webside Aalborg Universitet A.5 Webside Gruppe 414 Den 21. maj 2014 A.5.1 Formål Formålet med dette afsnit er at teste kravene til websiden fra kapitel 2. Fokus ligger i om kommandoer fra websiden bliver tolket efter hensigten af I/O moduler og om ændringer af værdier på websiden fører til ændringer af værdier i terminalen. A.5.2 Opsætning Figur A.5. Diagram over webside opstilling. A.5.3 Materielliste Instrumenter AAU-no. Type Kommentarer Mus N/A USB mus Smartphone (mobil N/A N/A enhed) FPGA Spartan 3 XC3S200 Tabel A.9. Materialer anvendt under testen A.5.4 Fremgangsmåde 1. Åben programmet "Xilinx", indtast følgende indstillinger til FPGA en. Family: Spartan 3 Device: XC3S200 Package: FT256 Speed: -4 Synthesis Tool: XST (VHDL/Verilog) Simulator: ISim (VHDL/Verilog) Preferred Language: VHDL Property Specification in Project File: Store all values VHDL Source Analysis Standard: VHDL Kompiler programmet. 3. Åben websiden og log in med brugernavn og adgangskode. 4. For at ændre temperaturen, indtast den ønskede temperatur og tryk på knappen "Ændre temperatur!". 5. For at ændre tilstanden for tyverialarmen, tryk på knappen "Aktiveret/Deaktiveret" 6. For at kende statussen på vandgennemstrømningen, aflæs dette af websiden.. 87

98 Gruppe 414 Målejournaler A.5.5 Resultater Krav Der skal kunne modtages input fra enten klik på mus eller touch. Der skal være adgangskontrol til websiden. Websiden skal kunne styres over internettet. Websiden skal kunne styres over internettet. Resultat Dette virker. Dette virker. Dette er ikke testet. Dette er ikke testet. Tabel A.10. Tabel over måleresultaterne A.5.6 Fejlkilder og afvigelser Støj fra måleapparater og laboratorieudstyr mm. har betydning for hvor hurtigt der kan sendes kommandoer fra websiden og til at websiden modtager et feedback. Derfor kan der være afvigelser i responstiden alt afhængig af hvilket miljø der testes under. Det har ikke været muligt at teste websiden over internettet da det ikke har været muligt at få tildelt en ekstern IP, som er et krav for at have websiden på en online webserver. 88

99 A.6. WiFi kommunikation Aalborg Universitet A.6 WiFi kommunikation Gruppe 414 Den 21. maj 2014 A.6.1 Formål Formålet med dette afsnit er at teste kravene til WiFi kommunikation fra afsnittet 2. Fokus ligger ved responstider. A.6.2 Opsætning Figur A.6. Diagram over WiFi opsætningen. A.6.3 Materielliste Instrumenter AAU-no. Type Kommentarer FPGA Spartan 3 XC3S200 Websiden N/A N/A Webside IP WiFi modul RTX4100 Router N/A Linksys WRT54G version7 Firmware v Tabel A.11. Materialer anvendt under test A.6.4 Fremgangsmåde 1. Åben programmet "Xilinx", indtast følgende indstillinger til FPGA en. Family: Spartan 3 Device: XC3S200 Package: FT256 Speed: -4 Synthesis Tool: XST (VHDL/Verilog) Simulator: ISim (VHDL/Verilog) Preferred Language: VHDL Property Specification in Project File: Store all values VHDL Source Analysis Standard: VHDL Kompiler programmet. 3. Åben websiden og log in med brugernavn og adgangskode. 4. Indtast i feltet Develop console ønskede datastrenge der skal sendes videre til FPGA en. Læs mere i tabel 3.6 og tabel

100 Gruppe 414 Målejournaler A.6.5 Resultater Krav WiFi modulet skal kunne sende og modtage data fra FP- GA en vha. Websiden. Dataen der sendes og modtages skal kunne behandles af FPGA en. Dataen skal kunne sendes og modtages inden for 10 sekunder i et miljø med støj, og indenfor 1 sekund i et miljø uden støj. Resultat Dette virker. Dette virker. Dette virker delvist. Tabel A.12. Tabel over måleresultaterne Datastreng KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 Responstid. 6,01 sek 11 sek 6,46 sek 5 sek 11,79 sek 8,85 sek 12,82 sek 12,25 sek 6,68 sek 9,22 sek Tabel A.13. Repsonstid fra websiden til WiFi modul i støj Datastreng KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 KoDeWI25 Responstid. 4,5 sek 13,34 sek 8,36 sek 2,05 sek 7,82 sek 2,02 sek 7,75 sek 7,38 sek 5,67 sek 8,17 sek Tabel A.14. Repsonstid fra websiden til WiFi modul uden støj 90

101 A.6. WiFi kommunikation Aalborg Universitet A.6.6 Fejlkilder og afvigelser For at teste responstiden fra websiden til WiFi modulet blev testen bl.a. foretage i et radiofrit miljø. Ud fra de målte responstider kan det ses at de er meget varierende. Derfor er der lavet pingtests, á 64 byte datapakker, mellem en kablet computer til access punktet, der har en trådløs forbindelse til WiFi modulet. Disse tests viste en meget ustabil forbindelse, med et minimum delay på 14 ms, et gennemsnitligt delay på 64 ms, og et maksimalt delay på 115 ms. Disse tests kan ses på billederne herunder. Figur A.7. Udsnit af ping test 1 Figur A.8. Udsnit af ping test 2 91

102 Gruppe 414 Målejournaler A.7 Terminal Gruppe 414 Den 21 maj 2014 A.7.1 Formål Formålet med dette afsnit er at teste kravene til terminalen fra kapitel 2. Fokus vil ligge ved kommandoerne fra terminalen, bliver tolket efter hensigten af I/O moduler. A.7.2 Opsætning Figur A.9. Diagram over terminalen. A.7.3 Materielliste Instrumenter AAU-no. Type Kommentarer Tastatur N/A PS2 tastatur Skærm N/A VGA skærm FPGA Spartan 3 XC3S200 Tabel A.15. Materialer anvendt under testen A.7.4 Fremgangsmåde 1. Forbind VGA-skærmen på FPGA ens VGA-port 2. Forbind PS/2 tastatur på FPGA ens PS/2-port 3. Åben programmet "Xilinx", indtast følgende indstillinger til FPGA en. Family: Spartan 3 Device: XC3S200 Package: FT256 Speed: -4 Synthesis Tool: XST (VHDL/Verilog) Simulator: ISim (VHDL/Verilog) Preferred Language: VHDL Property Specification in Project File: Store all values VHDL Source Analysis Standard: VHDL Kompiler programmet. 92

103 A.7. Terminal Aalborg Universitet 5. For at ændre temperaturen indtast TEMP efterfulgt af den ønskede temperatur fra 00 til For at sætte tyverialarmen på passiv tilstand indtast ALARM TAEND. 7. For at slukke tyverialarmen indtast ALARM SLUK. 8. For at kende statussen af vandgennemstrømningen, aflæs dette på skærmen. A.7.5 Resultater Krav Modulet skal kunne modtage input fra et PS/2 tastatur. Skærmen skal kunne vise inputtet fra tastaturet. Terminalen skal kunne læse og udføre kommandoer på I/O modulerne. Resultat Dette virker. Dette virker. Dette virker. Tabel A.16. Tabel over måleresultaterne A.7.6 Fejlkilder og afvigelser Der er ikke mødt fejl eller afvigelser under testen af terminalen. 93

104 Gruppe 414 Målejournaler A.8 Accepttest Gruppe 414 Den 23. maj 2014 A.8.1 Formål Formålet med accepttesten er at teste de overordnede krav til det endelige produkt. De overordnede krav består af nogle generelle funktionelle krav til både fjernstyring og lokal styring af bolig. A.8.2 Opsætning Figur A.10. Opsætning af accepttesten 94

105 A.8. Accepttest Aalborg Universitet A.8.3 Materielliste Instrumenter AAU-no. Type Kommentarer Strømforsyning Hameg Triple 3 Supply HM7042 Strømforsyning Hameg Triple 3 Supply HM7042 FPGA Spartan 3 XC3S1000 WIFI-modul N/A RTX4100 Server N/A Samsung N220 Vandpumpe N/A BILTEMA Pantrypumpe Router N/A Linksys WRT54G version7 Firmware v Skærm Dell Ultrasharp 1702fp 17", Hz Tastatur N/A Fujitsu Siemens KBPC S2 PS/2 tastatur Tabel A.17. A.8.4 Fremgangsmåde 1. Forbind modulerne, tastaturet og skærmen til FPGA en som vist på pinoutet i appendiks D. 2. Åben programmet "Xilinx", indtast følgende indstillinger til FPGA en. Family: Spartan 3 Device: XC3S1000 Package: FT256 Speed: -4 Synthesis Tool: XST (VHDL/Verilog) Simulator: ISim (VHDL/Verilog) Preferred Language: VHDL Property Specification in Project File: Store all values VHDL Source Analysis Standard: VHDL Kompiler programmet. 4. Test produktet via terminalen vha. tastatur og skærm. 5. Test produktet via websiden. 95

106 Gruppe 414 Målejournaler A.8.5 Resultater Test Krav Resultat Overvågning af vandgennemstrømning Overvågning af vandgennemstrømning Overvågning af tyverialarm Overvågning af tyverialarm Overvågning af temperaturmodul Overvågning af temperaturmodul Der skal kunne foretages overvågning af vandgennemstrømning via websiden. Der skal kunne foretages overvågning af vandgennemstrømning via terminalen. Der skal kunne foretages overvågning, slukning og tænding af alarm via webside. Der skal kunne foretages overvågning, slukning og tænding af alarm via terminal. Der skal kunne foretages overvågning og regulering af temperatur via webside. Der skal kunne foretages overvågning og regulering af temperatur via terminal. Dette virker delvist, da der kun er mulighed for at teste med en lokal IP. Funktionaliteten for at teste med ekstern IP er opsat, men ikke testet da ingen er til rådighed. Dette virker. Dette virker delvist af samme årsag som vandgennemstrømning. Dette virker. Dette virker delvist af samme årsag som vandgennemstrømning og tyverialarm. Dette virker. A.8.6 Fejlkilder Da ingen ekstern IP er tilgængelig er det umuligt at fuldføre tests med fjernstyring af produktet via en webside. 96

107 B Diagrammer B.1 Diagrammer I dette appendiks vises de diagrammer som er designet i Altium Designer release 10, og anvendt i prototypens I/O moduler. B.1.1 Temperaturdiagram På figur B.1, herunder ses et diagram over temperatur sensoren, som det ses er sensoren forbundet til jord og en forsyning på 3,3 Volt. Output benet fra sensoren er koblet til en ADC som beskrevet i kapitel 3. Figur B.1. diagram over opkoblingen til temperatursensoren 97

108 Gruppe 414 Diagrammer B.1.2 Vandgennemstrømningsdiagram På figur B.2, herunder ses et diagram over temperatur sensoren, som det ses er sensoren forbundet til jord og en forsyning på 3,3 Volt. Output benet fra sensoren er koblet til en ADC som beskrevet i kapitel 3. Figur B.2. diagram over opkoblingen til vandgennemstrømningsmodulet B.1.3 Tyverimoduldiagram På figur B.3, herunder ses et diagram over temperatur sensoren, som det ses er sensoren forbundet til jord og en forsyning på 3,3 Volt. Output benet fra sensoren er koblet til en ADC som beskrevet i kapitel 3. 98

109 B.1. Diagrammer Aalborg Universitet Figur B.3. diagram over opkoblingen til tyverimodul 99

110

111 C Webside scenarier C.1 Website scenarier Eksempler på visning af modulernes status på websiden. Scenarie 1 Figur C.1. Visning af webside data, fra scenarie 1 101

112 Gruppe 414 Webside scenarier Scenarie 2 Figur C.2. Visning af webside data, fra scenarie 2 Scenarie 3 Figur C.3. Visning af webside data, fra scenarie 3 102

113 D FPGA Pinout D.1 Pinout Figur D.1. Spartan Pinout 103

114 Bilag 1 Datablad for WiFi-modul Gruppe 414 RTX4100 Wi-Fi Module Datasheet DS1 Datasheet RTX4100 Wi-Fi Module 1 1

115 Bilag 1 Datablad for WiFi-modul Aalborg Universitet CONTENT 1 Introduction Document History Document References General Description Device Features Key Applications Overview HW Architecture Block-diagram Pin-out and port overview Application processor IO functionality SW Architecture Co-Located Application SW Blocks Module Firmware SW Blocks Application Reserve RTX4100 development kits Development kit (DVK) In- circuit Debugger (RTX2040 Unity-II) Design and Operation Guide Central Design Considerations Specifications and Characteristics Specifications Standards supported SW features HW components Physical dimensions Electrical Characteristics Absolute Maximum Ratings Recommended Operating Conditions Current Consumption DC Electrical Characteristics Module IO Oscillators Radio Received Characteristics Radio Transmitter Characteristics Datasheet RTX4100 Wi-Fi Module 2 2

116 Bilag 1 Datablad for WiFi-modul Gruppe Internal antenna Characteristics Assembly information Recommended soldering data for ROHS using SAC alloy Recommended soldering profile Tape-and-Reel specification Product Approvals Ordering Information Variants Sales offices Abbreviations Liability Disclaimer Datasheet RTX4100 Wi-Fi Module 3 3

117 Bilag 1 Datablad for WiFi-modul Aalborg Universitet 1 Introduction 1.1 Document History V2.4 Application Reserver table updated to match release 1.6. V2.3 Added missing dimensions on recommended pad layout in section 3.1 V2.2 Updated contact information V2.1 Added section updated physical dimensions. Tape and Reel specifications added. Misc. editorial changes V2.0 Added section Internal antenna Characteristics V1.9 Updated section 2.1.2: Added description of module pins used by the module firmware V1.8 Updated section 4.2.2: Added parameter VIO, external load. Updated section 4.2.4: Added note on Total output current sourcing V1.7 Updated section 6.1: notes on existing variants added V1.6 Updated section Pin-out and port overview : added ADC0_CH4 V1.5 New section: Product Approvals V1.4 Updates to section: Blockdiagram V1.3 Updates to section: Electrical Characteristics, Assembly information, Block diagram, Pin-out and port overview New section: Application processor alternate pin functionality, Assemply in Datasheet RTX4100 Wi-Fi Module 4 4

118 Bilag 1 Datablad for WiFi-modul Gruppe 414 formation V1.2 Official release Disclaimer: This document can be subject to change without prior notice. Datasheet RTX4100 Wi-Fi Module 5 5

119 Bilag 1 Datablad for WiFi-modul Aalborg Universitet 1.2 Document References [AN4]. RTX4100_Application_Note_Regulatory_Approvals_AN4.docx. [IS1]. AmelieApi_Vxxxx.pdf. Datasheet RTX4100 Wi-Fi Module 6 6

120 Bilag 1 Datablad for WiFi-modul Gruppe General Description The RTX4100 Wi-Fi Module is a small form-factor, single stream, b/g/n Wi-Fi module with on-board low power application processor. It is targeted at applications that send infrequent data packets over the network. Typically, these applications will place a higher priority on system cost, power consumption, ease of use, and fast wakeup times as compared to high throughput. The RTX4100 has been optimized for client applications in the home, enterprise, smart grid, home automation and control that have lower data rates and transmit or receive data on an infrequent basis. The RTX4100 Wi-Fi Module also enables rapid application development of ultra low power devices with the complete application SW on-chip (battery or mains powered devices). The module utilizes the combination of the energy friendly Energy Micro Gecko EFM32G230F128 microcontroller and the flexible low power single stream Atheros AR4100 Wi-Fi (b/g/n) SiP. This combination makes the RTX4100 Wi-Fi Module an ideal solution for low power automation and sensor solutions because of its high efficiency and low power consumption. Current consumption with the application processor active with an OS tick results in a current consumption of a few A. In this mode the application processor can monitor peripherals such as eg. sensors. Furthermore, due to the encryption capabilities of the module, it is also suitable for security applications. The RTX4100 Wi-Fi Module integrates all Wi-Fi functionality into a low-profile, 18 mm x 30 mm SMT module package that can be easily mounted on a low-cost main PCB with application specific circuits. The RTX4100 Wi-Fi Module supports a development platform that reduces development time through multiple interfaces and power supply options. The reference hardware, showing an application example using the RTX4100 module, is designed to reduce design efforts by supporting a the necessary development interfaces, sensor interfaces etc. Furthermore, developers can also choose from a wide range of different software packages and reference applications with well-documented API s. The RTX4100 Wi-Fi Module can be used to design applications using b/g/n communication protocols. The module includes an integrated antenna. Variants for connecting external antenna consist of U.fl and via edge connector. The module offers, via edge connectors, a flexible interface to the carrier board. This interface includes power supply pins, ADC ports, DAC ports, analog comparator, GPIO ports, SPI, I2C and UART ports. 1.4 Device Features b/g/n single 2.4 GHz Supports WEP, WPA/WPA2 and WPS modes of security (Wi-Fi drivers and WPA supplicant) On-board application processor with flexible interfaces Designed for ultra low power operation through use of Energy Micro Gecko EFM32G230F128 MCU and Atheros AR4100 Wi-Fi SiP Datasheet RTX4100 Wi-Fi Module 7 7

121 Bilag 1 Datablad for WiFi-modul Aalborg Universitet Avaliable antenna variants : integrated antenna, U.fl connector and edge connector Can be powered from an unregulated power supply, and hence, suitable for both battery powered and mains powered devices Compact surface mount module 18x30mm Full IPv4 and IPv6 stack FCC and IC Certified RoHS and CE compliant Wide range of connector ports including ADC ports, DAC ports, analog comparators, GPIO ports, SPI, I2C and UART ports. 1.5 Key Applications In essence the RTX4100 Wi-Fi Module enables rapid development of sensors for smart energy, security and automation demonstrators through a comprehensive Software Development Kit. The RTX4100 Wi-Fi Module targets a wide range of application areas including: Sensors and multi-input sensors (Industrial / Medical) White Goods and Appliances Building Automation Home Automation / Home Security Larger applications (including MMI) Actuators Portable Units Datasheet RTX4100 Wi-Fi Module 8 8

122 Bilag 1 Datablad for WiFi-modul Gruppe Overview 2.1 HW Architecture Block-diagram RTX4100 Wi-Fi Module VCC2 LDO 3.3V VCC1 VIO LDO 3.0V LDO 1.8V RESETn I/O (19) GND(4) EFM32G230 Application Processor SPI Flash AR4100 Wi-Fi IN EX EC RTX4100-IN: Built-in Antenna RTX4100-EX: Antenna U.Fl connector RTX4100-EC: Antenna edge connector GND(2) The RTX4100 Wi-Fi Module contains an Atheros AR4100 Wi-Fi SIP chip and an Energy Micro EFM32G230F128 application processor. The application processor has internal Flash and RAM. The Wi-Fi module boots from a serial Flash. The processor is powered by an LDO with low power consumption to keep the total standby current very low. Furthermore, the application processor controls two additional LDO s to power the Wi-Fi module and the serial Flash. The Wi-Fi AR4100 chip can be turned off to save power when the Wi-Fi functionality is not required. A number of I/O s are available to allow a wide range of applications. These include timers, serial communication interfaces, analog comparators, Analog-to-Digital Converters, Digital-to-Analog Converters, crystal oscillators and a debug interface. Datasheet RTX4100 Wi-Fi Module 9 9

123 Bilag 1 Datablad for WiFi-modul Aalborg Universitet Pin-out and port overview Pin no. Pin name Type Processor pin no. 1 GND GND Function 2 PA0 I/O 1 PA0/TIM0_CC0/I2C0_SDA 3 PA1 I/O 2 PA1/TIM0_CC1/I2C0_SCL/CMU_CLK1 4 VCC2 VCC2 VCC2 supply input 5 GND GND 6 VCC1 VCC1 VCC1 supply input 7 VIO O Application processor I/O supply output 8 PA3/PC1 I/O 4 and 10 PA3/TIM0_CDTI0 PC1/ACMP0_CH1/PCNT0_S1IN/US1_RX US1_RX: Used by module firmware for RTX EAP UART debug interface, can be disabled in the module firmware and used from the CoLA. 9 PA4/PC0 I/O 5 and 9 PA4/TIM0_CDTI1 PC0/ACMP0_CH0/PCNT0_S0IN/US1_TX US1_TX: Used by module firmware for RTX EAP UART debug interface, can be disabled in the module firmware and used from the CoLA. 10 PB7 I/O 15 PB7/LFXTAL_P/US1_CLK 11 PB8 I/O 16 PB8/LFXTAL_N/US1_CS 12 GND GND 13 RESETn I-PU 20 RESETn 14 PB12 I/O 22 PB12/DAC0_OUT1/LETIM0_OUT1 15 PB13 I/O 24 PB13/HFXTAL_P/LEU0_TX PB13 : Can be used by the module firmware to enable an external DC/DC voltage step-up on 2 cell designs. This feature can be enabled from the CoLA. 16 PB14 I/O 25 PB14/HFXTAL_N/LEU0_RX 17 GND GND 18 PD5 I/O 33 PD5/ADC0_CH5/LEU0_RX 19 PC6 I/O 37 PC6/ACMP0_CH6/LEU1_TX/I2C0_SDA LEU1_TX: Used by module firmware for RTX EAP UART debug interface, can be disabled in the module firmware and used from the CoLA. Datasheet RTX4100 Wi-Fi Module 10 10

124 Bilag 1 Datablad for WiFi-modul Gruppe PC7 I/O 38 PC7/ACMP0_CH7/LEU1_RX/I2C0_SCL 21 PC5/PB11 I/O 14 and PC4/PD4 I/O 13 and 32 LEU1_RX: Used by module firmware for RTX EAP UART debug interface, can be disabled in the module firmware and used from the CoLA. PC5/ACMP0_CH5/LETIM0_OUT1/PCNT1_S1IN/ US2_CS PB11/DAC0_OUT0/LETIM0_OUT0 PC4/ACMP0_CH4/LETIM0_OUT0/PCNT1_S0IN/ US2_CLK PD4/ADC0_CH4/LEU0_TX 23 PC2 I/O 11 PC2/ACMP0_CH2/US2_TX 24 PC3 I/O 12 PC3/ACMP0_CH3/US2_RX 25 PF0 I/O 49 PF0/LETIM0_OUT0/DBG_SWCLK DBG_SWCLK: may be used for advanced application debugging using the RTX2040 Unity II debugger 26 PF1 I/O 50 PF1/LETIM0_OUT1/DBG_SWDIO DBG_SWDIO: may be used for advanced application debugging using the RTX2040 Unity II debugger 27 PF2 I/O 51 PF2/ACMP1_O/DBG_SWO 28 GND GND 29 ANT I/O Only used in RTX4100-EC. This pin should be connected to GND for other variants. 30 GND GND The Processor pin no. refers to the pin numbers of the Energy Micro EFM32G230F128 in the QFN64 package. Moreover, the Functions in the above table refer to the pin names used in the EFM32G230F128 data sheet. The pin numbers shown in Figure 1 close to the edges refer to the pin numbers of the SMT pads. Datasheet RTX4100 Wi-Fi Module 11 11

125 Bilag 1 Datablad for WiFi-modul Aalborg Universitet Figure 1: RTX4100 pin numbering Datasheet RTX4100 Wi-Fi Module 12 12

126 Bilag 1 Datablad for WiFi-modul Gruppe Application processor IO functionality The Application processor on RTX4100 offers a rich set og IO options. The below table shows an overview of the interfaces available. Please observe that all IO option are not available at the same time as the alternate functions are muxed onto a limited number of module pins, see section For additional information please see the data sheet for the Energy Micro EFM32G230F128. For functionality occupied by the platform firmware please refer to section Functionality Digital to Analog Converter output channel Amount EFM32 alternate pin descriptions 2 DAC0_OUT1, DAC0_OUT0 Analog to digital converter input 2 ADC0_CH4, ADC0_CH5 channel Analog comparator input 8 ACMP0_CH0, ACMP0_CH1, ACMP0_CH2, ACMP0_CH3, ACMP0_CH4, ACMP0_CH5, ACMP0_CH6, ACMP0_CH7 Analog comparator digital output Timer Capture Compare input / output channel Timer Complimentary Deat Time Insertion channel Low Energy Timer output channel 1 ACMP1_O 2 TIM0_CC0, TIM0_CC1 2 TIM0_CDTI0, TIM0_CDTI1 2 LETIM0_OUT1, LETIM0_OUT0 Pulse Counter input 3 PCNT0_S1IN, PCNT0_S0IN, PCNT1_S1IN I2C0 Serial Data interface 1 I2C0_SDA, I2C0_SCL Universal Synchronous Asynchronous serial Receiver and Transmitter (USART). Supporting UART communication, RS- 485, SPI, MicroWire and 3- wire, ISO7816 and IrDA Low Energy Universal Asynchronous Receiver and Transmitter (LEUART) 2 US1_RX, US1_TX, US1_CLK, US1_CS US2_RX, US2_TX, US2_CLK, US2_CS 2 LEU0_TX, LEU0_RX LEU1_TX, LEU1_RX Low Frequency Crystal 1 LFXTAL_P, LFXTAL_N High Frequency Crystal 1 HFXTAL_P, HFXTAL_N Clock Management Unit clock output 1 CMU_CLK1 Debug-interface 1 DBG_SWCLK, DBG_SWDIO, DBG_SWO Datasheet RTX4100 Wi-Fi Module 13 13

127 Bilag 1 Datablad for WiFi-modul Aalborg Universitet 2.2 SW Architecture The RTX4100 contains two major components; the Wi-fi module and the Application Micro Controller Unit (MCU). The Application MCU contains all the necessary software components to implement a complete Wi-Fi device, including the application. Figure 2 conceptually illustrates the software architecture of the application MCU. The complete module firmware is split in the following two parts: The user application Also known as a Co-Located Application (CoLA). The RTX Platform Firmware. The RTX4100 module comes pre-loaded with the Platform Firmware which has support for Co-Located Applications. The application developer can then build his/her own Co- Located Application using the API s defined by the Platform and the CoLA framework. The Application can be download into the module for execution without having to modify the rest of the Platform Firmware. User Application (CoLA) API API API API Application protocol X Application protocol Y Networking Application X Networking Application Y CoLA framework API Operating System Firmware Management NVS Management WiFi Management Power Management DNS client HTTP Networking stack Drivers and Hardware Abstraction Layer Figure 2 Overview of the SW Architecture on the Application MCU Datasheet RTX4100 Wi-Fi Module 14 14

128 Bilag 1 Datablad for WiFi-modul Gruppe Co-Located Application SW Blocks The different parts of the Co-Located Application are briefly described below. User Application: This is the component implementing the application functionality of the Wi-Fi device. It is normally written by the application programmer / developer using the API availiable. Application Protocols: These are optional product specific functional layers implementing protocols for a specific functionality like e.g. CoAP or MQTT. The application protocol offloads the application developer by implementing a number of translation protocols like XML coding / decoding for message payloads, parsing of incoming messages and construction of outgoing messages. Application protocols are a part of the RTX SDK, and are available as either source code or a binary library. Networking Applications: These are optional product specific functional components implementing a variety of networking application, SNTP, HTTP, Web server etc. Networking protocols are a part of the RTX SDK, and are available as either source code or a binary library Module Firmware SW Blocks The different parts of the Module Firmware are briefly described below. Co-Located Application (CoLA) Framework: This component implements a programming model where the application is dynamically linked with the services provided by the lower layers. The application is compiled and linked as a separate program that at runtime is loaded and run as a task under the Operating System. API: This is the interface exposed by the Platform Firmware. It exposes all functionality needed by the application to implement a Wi-Fi device, like a sensor or actuator device. A detailed description of all the API s available can be found in ([IS1]). All the API s are mail based. Operating System: RTX low power operating system implementing the necessary functionality to host internal tasks as well as the Co-Located Application Networking Stack: This is a functional layer implementing the UDP, TCP/IP networking stack for IPv4 and IPv6 networking DNS Client: The DNS client is used to translate domain names to IP address by querying a DNS server. HTTP: Common HTTP server and client implementation. The HTTP server implementation includes TCP connection handling, parsing of HTTP request messages, generation/sending of HTTP response messages, and storing of HTTP resources (WEB pages) represented by path string and a call back function used to generate the content. The Datasheet RTX4100 Wi-Fi Module 15 15

129 Bilag 1 Datablad for WiFi-modul Aalborg Universitet HTTP client implementation includes TCP connection handling, generation/sending of HTTP request messages, and parsing of HTTP response messages. WiFi Management: This component handles all aspects of Wi-Fi connection to an WiFi acces point including security and key handling to secure the wireless connection, Wi-Fi power management etc. Power Management: This component handles the MCU internal clock trees as well as module power management. It ensures that any MCU internal part or external peripheral is only running for the appropriate amount of time to preserve power. Firmware Management: This component implements functionality to perform firmware update of the Co-Located Application. NVS Management: This component implements a None Volatile Storage (NVS) in a part of the internal FLASH in the MCU. Drivers: This is a functional layer implementing a number of hardware drivers for MCU peripherals as well as the physical interface to the Wi-Fi sub-component Application Reserve The flash / RAM space left for the application depends on the configuration of the protocol and stack. The following table shows the available flash / RAM for the CoLA: SW Version CoLA flash available CoLA RAM available Platform V1.3.0.x 32 kbytes 3 kbytes static RAM ~3 kbytes dynamic (heap) ~1000 bytes stack 512 bytes NVS Datasheet RTX4100 Wi-Fi Module 16 16

130 Bilag 1 Datablad for WiFi-modul Gruppe RTX4100 development kits Development kit (DVK) The RTX4100 DVK (Development Kit) allows a connection from a PC to a Wireless Sensor Application Board (WSAB) to control the WSAB Wi-Fi operation. The terminal application included in the RTX4100 module provides means to connect to another client or server on the network through a Wi-Fi Access Point and send data power efficiently over the network. If two DVKs are available, connection to another RTX4100 on the same network is possible. The DVK includes a WSAB (Wireless Sensor Application Board) containing a RTX4100-IN module and carrier board, a docking station and USB cable, and batteries. The SDK, available from the RTX download page can be used together with the RTX4100 DVK (Development Kit) and includes a comprehensive Application Programming Interface (API), a rich set of demonstration applications supplied as source code, and an embedded firmware development suite with download tools. The SDK enables a developer to run a collocated application (CoLA) directly on a RTX4100 Wi-Fi module. No external MCU is required In- circuit Debugger (RTX2040 Unity-II) The RTX In-Circuit Debugger provides a generic target interface for RISC MCU architectures. It facilitates debugging of software running on RISC cores that includes Serial Debug Interface Plus (SDI+) logic. The RTX-2040 Unity-II comes with a interface cables and is useful for the full range of RTX modules. Datasheet RTX4100 Wi-Fi Module 17 17

131 Bilag 1 Datablad for WiFi-modul Aalborg Universitet 3 Design and Operation Guide 3.1 Central Design Considerations Recommended pad layout. All dimensions are in mm. There should be a good ground plane on the main PCB to provide a reference for the antenna. This is particularly important when using the on-board antenna. The antenna area should be kept free of metal parts, other PCB base material, plastic etc. to ensure optimum conditions for the on-board antenna to work. Datasheet RTX4100 Wi-Fi Module 18 18

132 Bilag 1 Datablad for WiFi-modul Gruppe Specifications and Characteristics 4.1 Specifications Standards supported Compliance: IEEE802.11b/g/n IEEE802.11i (WPA/WPA2) Connectivity: Single stream 2.4 GHz with support for WEP security mode as well as WPA/WPA2 WPS support SW features RTX Software Development Kit Wi-Fi drivers and WPA supplicant Low power RTOS and drivers Full IPv4 and IPv6 stack HW components Components: Atheros AR4100SIP Wi-Fi SIP Energy Micro Gecko EFM32G230F128 MCU RAM & Flash: 128 kbyte flash, 16 kbyte RAM (total values) Antenna options: Integrated antenna U.fl connector edge connector Datasheet RTX4100 Wi-Fi Module 19 19

133 Bilag 1 Datablad for WiFi-modul Aalborg Universitet Physical dimensions Module variant RTX4100-IN RTX4100-EC RTX4100-EX Physical dimensions Length (typ.): 30 mm Width (typ.): 18 mm Height (Max.): 2.2 mm Length (typ.): 30 mm Width (typ.): 18 mm Height (Max.): 2.5 mm 4.2 Electrical Characteristics Absolute Maximum Ratings Parameter Conditions Min. Typ. Max. Unit Storage temperature range C Supply voltage VCC1 and VCC2 0 6 V Internal supply voltage VIO V Voltage on any I/O pin -0.3 VIO Recommended Operating Conditions Parameter Conditions Min. Typ. Max. Unit VCC1, Operating Supply input voltage 2.2 (1) V VCC2, Operating Supply input voltage 3.4 (1) V VIO, Application processor supply output voltage VCC1 = 3.5V to 5.25V VIO, external load (2) VCC1 = 3.5V to 5.25V Operating temperature range low datarate Operating temperature range high datarate WiFi Transmitter duty cycle up to 60%, VCC2 < 5.25V WiFi Transmitter duty cycle up to 100%, VCC2 < 4.5 V V 3.0 V 15 ma C C (1) Minimum voltage based on unregulated power supply (2) Module performance may be influenced by noise from external loads attached to VIO Datasheet RTX4100 Wi-Fi Module 20 20

134 Bilag 1 Datablad for WiFi-modul Gruppe Current Consumption Conditions: VCC1=VCC2=3.5V, Below current figures represent the sum on supply currents (VCC1+VCC2). Parameter Conditions Min. Typ. Max. Unit Supply current, standby Supply current, WiFi active and associated, IEEE PS Application processor dynamic OS tick Listening interval 1000ms Listening interval 100ms TX Supply current, peak peak current during TX RX Supply current, peak peak current during RX DC Electrical Characteristics Module IO Please refer to EFM32 datasheet for details. 2.7 ua 0.76 ma 2.6 ma 300 ma 100 ma Parameter Conditions Min. Typ. Max. Unit Output high voltage (3) Sourcing 0.95*VIO V 6mA Output low voltage Sinking 6mA 0.05*VIO V Input high voltage 0.7*VIO V Input low voltage 0.3*VIO V Input leakage current +/- 25 na I/O pull up resistor 40 kohm I/O pull down resistor 40 kohm (3) Total output current sourcing may not exceed 60mA Oscillators Parameter Conditions Min. Typ. Max. Unit LFRCO frequency (4) T = 25 C khz HFRCO frequency T = 25 C 28 MHz (4) The LFRCO drives the timersystem in the software operatingsystem. The LFRCO is calibrated against HFRCO. Calibration intervals can be initiated by the application software to suit the application needs. Please refer to the EFM32 datasheet for LFRCO and HFRCO specifications. Datasheet RTX4100 Wi-Fi Module 21 21

135 Bilag 1 Datablad for WiFi-modul Aalborg Universitet Radio Received Characteristics Parameter Conditions Min. Typ. Max. Unit Received Input Frequency range MHz Sensitivity b, CCK, 1 Mbps dbm b, CCK, 11 Mpbs g OFDM, 6 Mbps g OFDM, 54 Mpbs n, HT20, MSC n, HT20, MSC Adjacent Channel Rejection b, CCK, 1 Mbps db b, CCK, 11 Mpbs g, OFDM, 6 Mbps g, OFDM, 54 Mpbs n, HT20, MSC n, HT20, MSC Conditions: Measurements done conducted using the RTX4100-EX U.fl connector, VCC1=VCC2=3.5V, T=25 C Radio Transmitter Characteristics Parameter Conditions Min. Typ. Max. Unit Transmitter Output Frequency range MHz Output Power FCC/IC region b dbm g 6-36 Mbps g Mbps n MCS n MCS n MCS7-8 - Output Power EU region b dbm g 6-36 Mbps g Mbps n MCS n MCS n MCS7-8 - Accuracy of Power Leveling Loop - ±1.5 - db Conditions: Measurements done conducted using the RTX4100-EX U.fl connector, VCC1=VCC2=3.5V, T=25 C Internal antenna Characteristics Parameter Conditions Min. Typ. Max. Unit RTX4100-IN Peak Antenna Gain 1.9 dbi Datasheet RTX4100 Wi-Fi Module 22 22

136 Bilag 1 Datablad for WiFi-modul Gruppe Assembly information Recommended soldering data for ROHS using SAC alloy Parameter Conditions Min. Typ. Max. Unit Peak temperature C TAL (Time above liquidus) s SOAK time (150 C+185 C) s Rising slope 3 C/s Falling slope 5 C/s Recommended soldering profile Figure 3 Recommended solder profile (based on Solder Paste: Alpha CVP-390) Figure 4 Module temperature measurement positions Below the characteristics of the recommended soldering profile is tabulated. Measurement position Max. Rising Slope [ C/s] Max. Falling Slope [ C/s] Soak Time C [s] Reflow time /221 C [s] Peak temp. [s] IC PCB_TEMP Datasheet RTX4100 Wi-Fi Module 23 23