Bezdr´ atov´ a s´ıt’ pro sbˇ er geofyzik´ aln´ıch dat

(1)

Bezdr´ atov´ a s´ıt’ pro sbˇ er geofyzik´ aln´ıch dat

Bakal´ aˇ rsk´ a pr´ ace

Studijn´ı program: B2646 – Informaˇcn´ı technologie Studijn´ı obor: 1802R007 – Informaˇcn´ı technologie Autor pr´ace: Matˇej ˇReh´ak

Vedouc´ı pr´ace: Ing. Zbynˇek Mader, Ph.D.

(2)

Wireless network for the collection of geophysical data

Bachelor thesis

Study programme: B2646 – Information technology Study branch: 1802R007 – Information technology Author: Matˇej ˇReh´ak

Supervisor: Ing. Zbynˇek Mader, Ph.D.

(3)

(4)

(5)

(6)

Podˇ ekov´ an´ı

Chtˇel bych podˇekovat pˇredevˇs´ım vedouc´ımu této práce, Ing. Zbyˇnku Maderovi, Ph.D a konzultantovi práce, Ing. Miloˇsi Hernychovi, za odborné rady. Dále bych rád podˇekoval spoleˇcnosti ˇCEZ, a. s. za poskytnut´ı financ´ı ve výˇsi 8 924 Kˇc, které byly pouˇzity na nákup vývojových prostˇredk˚u, bez nichˇz by tuto práci nebylo moˇzné dokonˇcit.

(7)

Abstrakt

Tato práce ˇreˇs´ı problematiku pˇrenosu namˇeˇrených dat na vzdálenost stovek metr˚u aˇz jednotek kilometr˚u pomoc´ı bezdrátových technologi´ı. Tyto technologie poskytuj´ı mnoho výhod oproti technologi´ım vyuˇz´ıvaj´ıc´ı drátové médium. Mˇeˇren´ı a sbˇer geofyzikáln´ıch dat totiˇz klade na kabelové médium vysoké poˇzadavky na odolnost v˚uˇci vnˇejˇs´ım vliv˚um. Nav´ıc je nutné ˇreˇsit neˇzádouc´ı jevy souvisej´ıc´ı s pˇrenosem elektrického signálu po dlouhých vodiˇc´ıch, coˇz ve výsledku zvyˇsuje poˇrizovac´ı náklady na sbˇer dat.

Z úvodn´ı reˇserˇze vzeˇsly dvˇe vhodné technologie - MiWi od spoleˇcnosti Microchip Technology Inc. a IQRF od ˇceské spoleˇcnosti Microrisc s. r. o. Obˇe technologie byly implementovány pro práci s mikrokontrolérem PIC32MX795F512H a podrobeny test˚um s´ıly signálu v závislosti na vzdálenosti.

Probˇehlé testy odhalily, ˇze se závislost s´ıly signálu na vzdálenosti mˇen´ı v r˚uzných typech prostˇred´ı. Hlavn´ım pˇr´ınosem této práce bude moˇznost centralizovaného sbˇeru a uchováván´ı namˇeˇrených dat v reálném ˇcase.

Kl´ıˇcová slova: PIC32, MiWi, IQRF, MESH s´ıtˇe, bezdátové s´ıtˇe

(8)

Abstract

This report solves the issue of wireless data transmission over distances of hundreds of meters to kilometers using wireless technologies. Wireless technologies provide many advantages compared to methods of wired data transfer. Acquisition of geophysical data puts on cabling high requirements for resistance to external influences.

Moreover, it is necessary to solve the undesirable effects associated with signal transmission over long conductors resulting in increased initial cost of data collection.

From the initial literature search came two useful technologies - MiWi from Microchip Technology Inc. and IQRF from czech com- pany Microrisc s.r.o. Both technologies have been implemented to work with microcontroller PIC32MX795F512H and subjected to tests of signal strength depending on the distance.

Past tests revealed that the dependence of signal strength on the distance varies in different types of environments. The main con- tribution of this work will be centralized collection and storage of measured data in real time.

Keywords: PIC32, MiWi, IQRF, MESH networking, wireless networking

(9)

Obsah

1 Uvod´ 13

2 Reˇserˇse dostupných bezdrátových technologi´ı 14

2.1 Tinymesh . . . 15

2.2 Texas Instruments Sub-1GHz Low Cost Mesh Network . . . 15

2.3 LTP5901 SmartMesh . . . 16

2.4 ESP8266 - WiFi mikrokontrol´er . . . 16

2.5 MiWi - Microchip Wireless . . . 16

2.6 IQRF . . . 17

2.7 Z´avˇereˇcn´e zhodnocen´ı . . . 17

3 Elektronika a hardware 18 3.1 Nap´ajen´ı . . . 18

3.2 Hlavn´ı deska . . . 19

3.3 Adaptéry pro pˇripojen´ı bezdrátových modul˚u . . . 20

4 Technologie MiWi 21 4.1 Typy zaˇr´ızen´ı v s´ıti . . . 22

4.2 Pˇridˇelov´an´ı adres . . . 23

4.3 Datov´y r´amec . . . 24

4.4 Programov´e rozhran´ı protokolu MiWi . . . 25

5 Vývoj bezdrátové aplikace zaloˇzené na technologii MiWi 30 5.1 Obecná struktura projektu v prostˇred´ı MPLAB X . . . 30

5.2 Uprava zdrojov´´ ych k´od˚u pro architekturu PIC32MX . . . 32

5.3 Aplikaˇcn´ı k´od - PAN koordin´ator . . . 33

5.4 Aplikaˇcn´ı k´od - koordin´ator (router) . . . 34

5.5 Aplikaˇcn´ı k´od - koncov´y uzel . . . 35

6 Technologie IQRF 37 7 Vývoj bezdrátové aplikace zaloˇzené na technologii IQRF 39 7.1 Programován´ı modulu IQRF . . . 39

7.2 Programov´an´ı mikrokontrol´eru PIC32MX . . . 41

8 Testován´ı v reálných podm´ınkách 43

(10)

9 Z´avˇer 45

(11)

Seznam obr´ azk˚ u

2.1 Uroveˇ´ n potˇrebn´ych znalost´ı pro jednotliv´e typy elektroniky[2] . . . . 15

3.1 Symbolické znázornˇen´ı schématu . . . 18

3.2 Sch´ema zapojen´ı obvodu MCP16311 . . . 19

3.3 Hlavn´ı deska . . . 20

3.4 Adapt´ery: vlevo IQRF, vpravo MiWi . . . 20

4.1 Porovn´an´ı s´ıt’ov´ych model˚u: vlevo OSI, vpravo model MiWi . . . 21

4.2 Zkrácená (logická) adresa . . . 23

4.3 Struktura datov´eho r´amce . . . 24

4.4 Struktura datov´eho paketu vyobrazen´em v prostˇred´ı Wireless Deve- lopment Studio . . . 25

4.5 Struktura programov´eho rozhran´ı . . . 26

5.1 Struktura projektu v prostˇred´ı MPLAB X¹ . . . 30

5.2 Sloˇzky, ze kterých budou naˇc´ıtány hlaviˇckové soubory . . . 31

6.1 Struktura DPA paketu . . . 37

6.2 S´ıt’ov´a topologie vytvoˇren´a po procesu discovery . . . 38

7.1 Nastaven´ı hardwarov´eho profilu . . . 39

8.1 Závislost s´ıly signálu na vzdálenosti ve volném prostranstv´ı . . . 43 8.2 Závislost s´ıly signálu na vzdálenosti ve vodovodn´ıˇstole v obci Bedˇrichov 44

(12)

Seznam tabulek

4.1 Typy zaˇr´ızen´ı v s´ıt´ıch MiWi . . . 23 7.1 Moˇzn´e odpovˇedi na dotaz SPI CHECK, N_max = 56 . . . 42

(13)

Seznam zdrojov´ ych k´ od˚ u

4.1 Struktura ACTIVE SCAN RESULT . . . 27

4.2 Struktura CONNECTION ENTRY a pole pˇripojen´ych uzl˚u . . . 27

4.3 Struktura RECEIVED MESSAGE . . . 29

5.1 Inicializace pˇreruˇsen´ı . . . 32

5.2 Zdrojový kód pˇredstavuj´ıc´ı roli PAN koordinátora . . . 33

5.3 Zdrojový kód pˇredstavuj´ıc´ı roli koordinátora (routeru) . . . 34

5.4 Zdrojový kód pˇredstavuj´ıc´ı roli koncového uzlu . . . 35

7.1 Ud´alost zavolan´a po pˇrijet´ı DPA poˇzadavku . . . 40

7.2 Událost zavolaná pˇred odeslán´ım DPA odpovˇedi . . . 40

(14)

1 Uvod ´

Uˇćelem této práce je provést analýzu dostupných bezdrátových technologi´ı a zhod- notit jejich vyuˇzitelnost pro sbˇer geofyzikáln´ıch dat, vybrané technologie implementovat tak, aby spolupracovaly s mikrokontrolérem PIC32MX795F512H s ohledem na n´ızkou spotˇrebu a celou sestavu otestovat v reálných podm´ınkách.

Práce se mimo jiné zabývá i porovnán´ım dosahu signálu vybraných technologi´ı v r˚uzných prostˇred´ıch. Porovnán´ı prob´ıhalo ve dvou lokalitách - na volném rovném prostranstv´ı a ve vodovodn´ı ˇstole o celkové délce dvou kilometr˚u v obci Bedˇrichov.

(15)

2 Reˇ serˇ se dostupn´ ych bezdr´ atov´ ych techno- logi´ı

Vybraná technologie, která bude podrobena detailnˇejˇs´ımu studiu by mˇela splˇnovat následuj´ıc´ı podm´ınky:

Vytvoˇren´ı s´ıtˇe typu MESH¹

N´ızk´a spotˇreba (moˇznost reˇzimu sp´anku)

Dosah v ˇr´adu stovek metr˚u aˇz jednotek kilometr˚u

Schopnost obnovy s´ıtˇe po v´ypadku nap´ajen´ı

Rychlost implementace

Dostateˇcnˇe podrobn´a dokumentace

Elektroniku potˇrebnou pro bezdr´atov´y pˇrenos dat lze rozdˇelit do ˇctyˇr skupin:

RF ˇcip

RF modul (RF ˇcip a elektronika potˇrebn´a pro provoz um´ıstˇen´a na jednom modulu)

RF modul s operaˇcn´ım syst´emem (operaˇcn´ı syst´em realizuje logiku s´ıtˇe)

RF modul s operaˇcn´ım systémem a integrovanými protokoly pro pˇrenos dat a ˇr´ızen´ı periferi´ı jiných modul˚u

Uroveˇ´ n znalost´ı v potˇrebných oblastech vývoje bezdrátové aplikace vystihuje Obr. 2.1, z nˇehoˇz vypl´ıvá, ˇze nejvhodnˇejˇs´ı elektronikou pro návrh bezdrátové aplikace bude samostatný RF modul, RF modul s operaˇcn´ım systémem a modul s operaˇcn´ım systémem a integrovaným protokolem pro pˇrenos dat a ˇr´ızen´ı sbˇernic ostatn´ıch modul˚u.

1S´ıt’ typu mesh je bezdrátová s´ıt’, kde je zabezpeˇcena automatická konfigurace struktury s´ıtˇe, spolehlivé smˇerován´ı mezi jednotlivými uzly a automatický pˇr´ıstup nových uzl˚u do s´ıtˇe prostˇrednictv´ım dosavadn´ıch uzl˚u.[1]

(16)

Obrázek 2.1: Úroveˇn potˇrebných znalost´ı pro jednotlivé typy elektroniky[2]

2.1 Tinymesh

Technologie Tinymesh distribuována spoleˇcnost´ı Radiocrafts je zaloˇzena na modu- lech RC11xx-RC232 s integrovaným operaˇcn´ım systémem a protokolem pro pˇrenos dat. Modul je pomoc´ı hostitelského mikrokontroléru ovládán skrze rozhran´ı UART.

Pˇrenos dat je realizován paketovˇe orientovaným protokolem RC232^TM. K dispozici jsou moduly, které pracuj´ı na frekvenci 433 MHz, 868 MHz a 2,4 GHz. Samotný operaˇcn´ı systém disponuje vˇsemi funkcionalitami pro úspˇeˇsné vytvoˇren´ı a správu mesh s´ıtˇe vˇcetnˇe reˇzimu spánku.

Hlavn´ı nevýhodou této technologie je pomˇernˇe vysoká cena. Vývojová sestava obsahuj´ıc´ı dva moduly a pˇr´ısluˇsenstv´ı stoj´ı u distributora RS Components 10 902 Kˇc bez DPH (k 14. 12. 2016). Samotný komunikaˇcn´ı modul stoj´ı u stejného distributora 1075 Kˇc bez DPH (k 14. 12. 2016).

2.2 Texas Instruments Sub-1GHz Low Cost Mesh Ne- twork

Toto ˇreˇsen´ı je postavené na integrovaném obvodu CC1101 od spoleˇcnosti Texas In- struments. Obvod realizuje pouze pˇr´ıstup k fyzické vrstvˇe a samotná logika mesh s´ıtˇe mus´ı být implementována nadˇrazeným systémem. K hostitelskému mikrokontroléru se pˇripojuje pomoc´ı sbˇernice SPI. Obvod je schopen pˇrenáˇset data ve frekvenˇcn´ıch

(17)

pásmech 315/433/868/915 MHz. Výrobce poskytuje k tomuto obvodu softwarové knihovny (tzv. stack), které realizuj´ı logiku s´ıtˇe pomoc´ı nadˇrazeného mikrokont- roléru. Knihovny jsou ale dostupné pouze pro mikrokontrolér MSP430G2533 a vývoj vlastn´ıch knihoven pro platformu PIC32MX by byl zdlouhavý a neefektivn´ı.

2.3 LTP5901 SmartMesh

LTP5901 je modul s integrovaným operaˇcn´ım systémem zaloˇzený na standardu IEEE 802.15.4e. Operaˇcn´ı systém zajiˇst’uje vˇsechny funkcionality potˇrebné k vy- tvoˇren´ı a správˇe mesh s´ıtˇe, data jsou od nadˇrazeného systému pˇrenáˇsena skrze rozhran´ı UART. Vˇsechny uvedené vlastnosti dovoluj´ı rychlou implementaci na platformu PIC32MX.

Jedinou nevýhodou je vysoká cena, která u distributora Farnell Element14 zaˇc´ıná na ˇcástce 3 506 Kˇc bez DPH (k 14. 12. 2016).

2.4 ESP8266 - WiFi mikrokontrol´ er

Mikrokontrolér ESP8266 je zaloˇzen na architektuˇre Tensilica Xtensa LX106 a obsahuje integrovaný TCP/IP stack. Samotný TCP/IP stack zajiˇst’uje pouze standardn´ı funkcionality v rámci TCP/IP (mikrokontrolér m˚uˇze být nastaven jako koncové zaˇr´ızen´ı nebo jako pˇr´ıstupový bod) a logika mesh s´ıtˇe je zajiˇstˇena pomoc´ı programu nahraného do mikrokontroléru. ESP8266 se k nadˇrazenému systému pˇripojuje pomoc´ı rozhran´ı UART a lze jej konfigurovat tzv. AT pˇr´ıkazy.

Hlavn´ı výhodou tohoto mikrokontroléru, resp. modul˚u, je velmi n´ızká cena, která se pohybuje okolo 50 Kˇc za jeden kus. Naopak nevýhodou m˚uˇze být skuteˇcnost, ˇze prvn´ı verze dokumentac´ı byly dostupné pouze v ˇc´ınském jazyce a je tedy moˇzné, ˇze i budouc´ı verze dostupné v anglickém jazyce budou k dispozici se zpoˇzdˇen´ım.

2.5 MiWi - Microchip Wireless

Technologie MiWi je soubor hardwarových a softwarových prostˇredk˚u, které slouˇz´ı vývojáˇri k vytváˇren´ı bezdrátových s´ıt´ı typu mesh. Mezi hardwarové prostˇredky patˇr´ı bezdrátové transceivery, resp. moduly, MRF24J40, MRF89XA a MRF49XA zajiˇst’uj´ıc´ı mj. pˇr´ıstup k fyzické vrstvˇe. Podle zvoleného modulu lze technologii provo- zovat ve frekvenˇcn´ıch pásmech 433/868/915 MHz a 2,4 GHz. Softwarové prostˇredky jsou distribuovány ve formˇe knihoven (tzv. stacku), které jsou nahrány do nadˇrazeného mikrokontroléru a realizuj´ı samotný protokol MiWi.

Výhodou této technologie je zm´ınˇený stack, který je vyv´ıjen spoleˇcnost´ı Microchip pro mikrokonteroléry PIC, tud´ıˇz bude moˇzné jej implementovat na mikrokontroléru uvedeném v zadán´ı. Pˇr´ıznivá je i cena vybraného modulu MRF24J40MA, jehoˇz cena je u distributora Farnell Element14 161 Kˇc bez DPH (k 14. 12. 2016). Problema- tická ale m˚uˇze být jeho implementace, která vyˇzaduje pomˇernˇe rozsáhlé zkuˇsenosti v oblasti programován´ı mikrokontrolér˚u PIC32MX.

(18)

2.6 IQRF

Technologie IQRF pˇredstavuje kompletn´ı platformu zahrnuj´ıc´ı bezdrátové moduly, vlastn´ı vývojové prostˇred´ı, programovac´ı nástroje vˇcetnˇe SDK (Software Development Kit) a pˇripojen´ı do cloudové sluˇzby IQRF Cloud. Samotný modul obsahuje mikro- kontrolér PIC16LF1938 s integrovaným operaˇcn´ım systémem, transceiver SPIRIT1, konfigurovatelné LED diody, teplotn´ı senzor, pamˇet’ EEPROM a napˇet’ový regulátor.

Moduly lze konfigurovat pro vys´ılán´ı ve frekvenˇcn´ıch pásmech 433/868/915 MHz, k hostitelskému mikrokontroléru jej lze pˇripojit skrze rozhran´ı SPI nebo UART.

Zaj´ımavost´ı je i moˇznost bezdrátového programován´ı modul˚u pˇripojených do s´ıtˇe.

Tato platforma vznikla v roce 2004 jako reakce na tehdejˇs´ı komplikované a v mnoha pˇr´ıpadech i zpoplatnˇené protokoly vyˇzaduj´ıc´ı drahý hardware, tud´ıˇz se tato technologie vyv´ıjela tak, aby byla jej´ı implementace snadná, rychlá a cenovˇe do- stupná. Cena vybraného modulu DCTR-72DA u výrobce a souˇcasnˇe distributora, Microrisc s. r. o., ˇcin´ı 579 Kˇc bez DPH (k 14. 12. 2016).

2.7 Z´ avˇ ereˇ cn´ e zhodnocen´ı

Po spoleˇcné diskusi s vedouc´ım a konzultantem práce a zhodnocen´ı poˇzadavk˚u byly vybrány dvˇe technologie: MiWi, jej´ıˇz hardwarové parametry odpov´ıdaj´ı kategorii RF modul˚u dle Obr. 2.1, a IQRF, která dle Obr. 2.1 spadá do kategorie RF modul˚u s integrovaným operaˇcn´ım systémem, protokolem pro pˇrenos dat a vzdálené ˇr´ızen´ı periferi´ı ostatn´ıch modul˚u.

(19)

3 Elektronika a hardware

Schéma zapojen´ı s mikrokontrolérem PIC32MX795F512H ˇcásteˇcnˇe vycház´ı z vývojové desky Microchip MiWi Demo Kit - 2.4 GHz MRF24J40 [4]. Jelikoˇz obˇe vybrané platformy pouˇz´ıvaj´ı pro komunikaci s mikrokontrolérem sbˇernici SPI (Serial Peripheral Interface), výsledná deska ploˇsných spoj˚u je navrˇzena tak, aby byly moduly obou technologi´ı vymˇenitelné. Pro vzájemnou výmˇenu je pouˇzita patice mikroBUS^TM navrˇzená srbskou spoleˇcnost´ı Mikroelektronika d. o. o. Princip vymˇenitelnosti jed- notlivých komponent byl aplikován i na napájec´ı ˇcást, mohou tedy být testovány r˚uzné typy napˇet’ových stabilizátor˚u bez nutnosti tvoˇrit kompletnˇe nový ploˇsný spoj.

Symbolické znázornˇen´ı d˚uleˇzitých komponent popisuje Obr. 3.1.

Obrázek 3.1: Symbolické znázornˇen´ı schématu

3.1 Nap´ ajen´ı

Napájec´ı ˇcást mus´ı zajiˇst’ovat stabiln´ı napˇet´ı 3,3 V, pˇriˇcemˇz vstupn´ı napˇet´ı se bude v ˇcase mˇenit. Dalˇs´ım poˇzadavkem je také vysoká m´ıra energetické úˇcinnosti, která zajist´ı dlouhou výdrˇz baterie. Z tohoto d˚uvodu nebude moˇzné pouˇz´ıt lineárn´ı sta- bilizátor napˇet´ı, proto bude nutné se zamˇeˇrit na zapojen´ı s tzv. DC/DC mˇeniˇcem.

Prvotn´ı koncept napájen´ı byl smˇerován k pouˇzit´ı co nejmenˇs´ıho poˇctu bateriových ˇclánk˚u tak, aby vstupn´ı napˇet´ı bylo bl´ızké napájec´ımu napˇet´ı systému. Tomuto poˇzadavku nejlépe vyhovoval obvod TPS63031, který je schopen generovat napˇet´ı 3,3 V pˇri vstupn´ım napˇet´ı v rozsahu od 1,8 V do 5,5 V (jedná se o tzv. buck-boost

(20)

mˇeniˇc). Obecná architektura buck-boost mˇeniˇce ale vykazuje pomˇernˇe vysoký vlastn´ı odbˇer proudu, který se v pˇr´ıpadˇe obvodu TPS63031 pohybuje kolem 3 mA.

Proto byl zvolen odliˇsný pˇr´ıstup, který poˇc´ıtá pouze s napˇet´ım vyˇsˇs´ım neˇz je napájec´ı napˇet´ı systému, pouˇzitý typ mˇeniˇce tedy bude step-down (buck ), konkrétnˇe obvod MCP16311. Tento mˇeniˇc je schopen dodávat napˇet´ı 3,3V pˇri rozsahu od 4,4 V do 30 V, pˇriˇcemˇz disponuje velmi n´ızkým vlastn´ım odbˇerem proudu, který se pohybuje v rozmez´ı od 55 µA do 140 µA.

Obr´azek 3.2: Sch´ema zapojen´ı obvodu MCP16311

Zapojen´ı na Obr. 3.2 vycház´ı ze schématu uvedeném v [6]. Výsledný ploˇsný spoj je realizován ve formˇe vymˇenitelného modulu, který je pˇripojen k hlavn´ı desce.

3.2 Hlavn´ı deska

Hlavn´ı deska obsahuje následuj´ıc´ı komponenty: konektor pro pˇripojen´ı baterie, sp´ınac´ı propojka, patice pro napájec´ı modul, odporový dˇeliˇc, mikrokontrolér, pamˇet’

25AA02E48T, pamˇet’ 25AA256, patice mikroBUS^TM, 8 MHz krystal a 32,768 kHz krystal.

Odporový dˇeliˇc je pˇripojen na kladný pól baterie a jeho výstup je pˇriveden na vstup A/D pˇrevodn´ıku mikrokontroléru. Jelikoˇz je výˇse zm´ınˇený integrovaný obvod MCP16311 schopen pracovat do napˇet´ı 30 V, je nutné sn´ıˇzit mˇeˇrené napˇet´ı na A/D pˇrevodn´ıku tak, aby nedoˇslo k jeho poˇskozen´ı. Pamˇet’ 25AA02E48T obsahuje výrobcem definované unikátn´ı ˇc´ıslo EUI-48 (Extended Unique Identifier), které pouˇz´ıvá technologie MiWi pro adresaci uzl˚u v s´ıti. Pamˇet’ 25AA256 rovnˇeˇz slouˇz´ı technologii MiWi pro ukládán´ı informac´ı o s´ıti, které jsou obnoveny po výpadku napájen´ı. Primárn´ı hodinový signál je tvoˇren krystalem o pracovn´ı frekvenci 8 MHz, sekundárn´ı hodinový signál tvoˇr´ı krystal o pracovn´ı frekvenci 32,768 kHz a je pouˇzit pro taktován´ı hodin reálného ˇcasu v reˇzimu spánku. Schéma zapojen´ı hlavn´ı desky je uvedeno v pˇr´ıloze.

(21)

Obr´azek 3.3: Hlavn´ı deska

3.3 Adapt´ ery pro pˇ ripojen´ı bezdr´ atov´ ych modul˚ u

Oba adaptéry, resp. pouˇzité moduly, pouˇz´ıvaj´ı pro komunikaci s mikrokontrolérem sbˇernici SPI. Modul IQRF je dle návrhu výrobce pˇripojen pomoc´ı konektoru SIM.

Sch´ema zapojen´ı obou modul˚u je uvedeno v pˇr´ıloze.

Obr´azek 3.4: Adapt´ery: vlevo IQRF, vpravo MiWi

(22)

4 Technologie MiWi

Technologie MiWi je soubor hardwarových a softwarových prostˇredk˚u, protokol˚u a vývojových nástroj˚u, které se souhrnnˇe nazývaj´ı MiWi^TM DE (Development Envi- ronment). Mezi hardware lze zaˇradit pˇr´ısluˇsné moduly (pro tuto práci byl vybrán typ MRF24J40MA), softwarové prostˇredky tvoˇr´ı knihovny, které se souhrnˇe nazývaj´ı stack a do vývojových nástroj˚u lze zaˇradit analyzátor bezdrátovˇe pˇrenáˇsených zpráv Microchip ZENA Wireless Adapter a poˇc´ıtaˇcovou aplikaci Microchip Wireless Deve- lopment Studio urˇcenou pro zobrazován´ı zachycených zpráv. Pro pˇrenos zpráv byly vyvinuty celkem tˇri nezávislé protokoly s následuj´ıc´ımi vlastnostmi:

MiWi P2P

– Podporuje topologie typu P2P (peer-to-peer) a hvˇezda – Pouze jeden pˇreskok zprávy, ˇzádné smˇerován´ı zpráv

MiWi Mesh

– Podporuje topologii mesh s´ıtˇe a smˇerov´an´ı zpr´av

– ˇCtyˇri pˇreskoky (hops) zpráv, max. osm koordinátor˚u v s´ıti, ke kaˇzdému koordinátorovi je moˇzno pˇripojit aˇz 127 uzl˚u

MiWi PRO

– Rozˇs´ıˇren´ı protokolu MiWi Mesh

– Podpora aˇz 64 koordin´ator˚u a aˇz 65 pˇreskok˚u zpr´avy

Obrázek 4.1: Porovnán´ı s´ıt’ových model˚u: vlevo OSI, vpravo model MiWi

(23)

Jak je psáno v [7], protokol MiWi PRO je funkˇcn´ı pouze v bal´ıku Microchip Libraries for Applications v2013-06-15, jehoˇz souˇcást´ı je i MiWi Stack. Souˇcasná verze bal´ıku MLA pouˇzitá v této práci je v2016-08-08, tud´ıˇz pouˇz´ıvaným protokolem bude MiWi Mesh.

MiWi PRO is only functional in the Legacy MLA (2013-06-15). The Legacy MLA is not supported and is not recommend for development.

The current version of the MLA and MCC do not support MiWi PRO.

Earlier versions of the MLA contained the ”miwi pro.c”code but this was mistakenly included. None of the MLA demos depended on this file and if the file was included in a project it would fail to compile as it was just copied directly from the Legacy MLA and was not updated for the current versions of the MLA. [7]

Protokol MiWi je zaloˇzen na standardu IEEE 802.15.4, konkrétnˇe na fyzické vrstvˇe (PHY) a vrstvˇe pˇr´ıstupu k médiu (MAC). Protokol poskytuje funkcionality k vyhledáván´ı, sestaven´ı a pˇripojen´ı k s´ıti, objevován´ı novˇe pˇripojených uzl˚u a smˇerován´ı zpráv. Naopak nepokrývá aplikaˇcnˇe specifické problémy jako je rozho- dován´ı, ke které s´ıti se pˇripojit nebo jak ˇcasto by mˇely být odes´ılány zprávy.

Podobnˇe jako standard IEEE 802.15.4, protokol MiWi pouˇz´ıvá mechanismus potvrzovaných zpráv. Pokud je v odes´ılané zprávˇe aktivován pˇr´ıznak pro odeslán´ı potvrzovac´ı zprávy, protistrana mus´ı toto potvrzen´ı odeslat v pˇredem stanoveném intervalu. Pokud potvrzen´ı nen´ı vˇcas doruˇceno, odes´ılatel znovu odeˇsle p˚uvodn´ı zprávu.

4.1 Typy zaˇ r´ızen´ı v s´ıti

Standard IEEE 802.15.4 definuje dva typy zaˇr´ızen´ı:

Full Function Device (FFD) - zaˇr´ızen´ı poskytuj´ıc´ı vˇsechny funkcionality v rámci s´ıtˇe, které je trvale v aktivn´ım stavu (nepˇrecház´ı do reˇzimu spánku)

Reduced Function Device (RFD) - zaˇr´ızen´ı s omezenými funkcionalitami, ty- picky koncový uzel napájený z baterie

Protokol MiWi definuje celkem tˇri typy zaˇr´ızen´ı. Jejich popis a vztah k typ˚um zaˇr´ızen´ı dle IEEE 802.15.4 vystihuje Tabulka 4.1.

(24)

Typ zaˇr´ızen´ı IEEE Typ Zaˇr´ızen´ı Funkce

PAN Koordin´ator FFD Pouze jeden v s´ıti. Sestavuje s´ıt’, pˇridˇeluje s´ıt’ov´e adresy uzl˚um.

Koordinátor FFD Volitelný typ v rámci s´ıtˇe. Rozˇsiˇruje fyzický dosah s´ıtˇe. Umoˇzˇnuje pˇripojován´ı dalˇs´ıch koncových uzl˚u.

M˚uˇze prov´adˇet prov´adˇet funkcionality uzlu (napˇr. mˇeˇr´ıc´ı nebo ˇr´ıd´ıc´ı funkce).

Koncov´e zaˇr´ızen´ı FFD nebo RFD Prov´ad´ı pouze mˇeˇr´ıc´ı nebo ˇr´ıd´ıc´ı funkce.

Tabulka 4.1: Typy zaˇr´ızen´ı v s´ıt´ıch MiWi

4.2 Pˇ ridˇ elov´ an´ı adres

Miwi pouˇz´ıv´a tˇri typy adres:

Fyzická adresa - tzv. EUI (Extended Organizationally Unique Identifier) adresa je 8 bajt˚u dlouhá a globálnˇe unikátn´ı

PANID - identifikátor PAN (Personal area network) s´ıtˇe, vˇsechny uzly v s´ıti maj´ı stejné PANID, délka 2 bajty

Zkrácená (logická) adresa - dva bajty dlouhá adresa pˇridˇelovaná rodiˇcovským uzlem, unikátn´ı v rámci s´ıtˇe, pouˇz´ıvaná k adresaci zpráv

Logická adresa dlouhá 16 bit˚u je rozdˇelena na ˇcást obsahuj´ıc´ı 3 bity z adresy rodiˇcovského uzlu, jeden bit adresy (RxOffWhenIdle) indikuje, ˇze zaˇr´ızen´ı vyp´ıná transceiver v reˇzimu spánku. ˇCást vyhrazená pro adresaci uzlu je dlouhá 7 bit˚u.

Uspoˇrádán´ı a význam jednotlivých ˇcást´ı popisuje Obr. 4.2.

Obrázek 4.2: Zkrácená (logická) adresa

Z výˇse uvedených informac´ı vyplývá, ˇze v s´ıti mus´ı být právˇe jeden PAN ko- ordinátor, aˇz sedm koordinátor˚u, pˇriˇcemˇz ke kaˇzdému koordinátorovi m˚uˇze být pˇripojeno aˇz 127 koncových uzl˚u. Pˇr´ıkladem mohou být následuj´ıc´ı adresy:

0x0000h - tuto adresu m´a vˇzdy PAN koordin´ator s´ıtˇe

(25)

0x0300h - adresa koordinátora má vˇzdy ˇcást adresy pro koncový uzel a bit RxOffWhenIdle nastaveny na hodnotu 0

0x0531h - adresa koncového uzlu, jehoˇz transceiver je vˇzdy zapnutý, rodiˇcovský koordinátor má adresu 0x0500h

0x07A2h - adresa koncového uzlu, jehoˇz transceiver m˚uˇze být vypnut, rodiˇcovský koordinátor má adresu 0x0700h

0xFFFFh - adresa pro vˇsesmˇerov´e vys´ıl´an´ı (broadcast)

4.3 Datov´ y r´ amec

Datový rámec protokolu MiWi se skládá ze ˇctyˇr ˇcást´ı: hlaviˇcky fyzické vrstvy (PHY), hlaviˇcky vrstvy s´ıt’ového pˇr´ıstupu (MAC), s´ıt’ových informac´ı a samotných dat.

Hlaviˇcka fyzické vrstvy je pouˇzita k synchronizaci komunikace v s´ıti (mechanis- mem unikátn´ıho ˇc´ıslován´ı rámc˚u) a pˇrenáˇsen´ı informac´ı o fyzické vrstvˇe (pouˇzitý komunikaˇcn´ı kanál, s´ıla signálu, kvalita linky).

C´ˇast rámce obsahuj´ıc´ı MAC hlaviˇcku v sobˇe nese ˇr´ıd´ıc´ı bajt, který udává informace o pˇrenáˇseném rámci, napˇr. typ paketu, pouˇzit´ı ˇsifrován´ı nebo poˇzadavek na potvrzen´ı doruˇcen´ı. MAC hlaviˇcka následnˇe pˇrenáˇs´ı data (payload), která jsou inter- pretována vyˇsˇs´ımi vrstvami. Posledn´ı ˇcást, která je pˇrenáˇsena, je kontroln´ı souˇcet.

Strukturu datov´eho r´amce popisuje Obr. 4.3.

Obrázek 4.3: Struktura datového rámce

(26)

C´ˇast rámce obsahuj´ıc´ı data pro vyˇsˇs´ı vrstvy (MAC payload na Obr. 4.3) v sobˇe nese informace o zdrojové a c´ılové adrese, PANID a samotná uˇzivatelem pˇrenáˇsená data. Struktura tˇechto informac´ı je vyobrazena na Obr. 4.4.

Obrázek 4.4: Struktura datového paketu vyobrazeném v prostˇred´ı Wireless Develo- pment Studio

4.4 Programov´ e rozhran´ı protokolu MiWi

Programové rozhran´ı protokolu MiWi (nazývané MiApp) se skládá ze dvou ˇcást´ı:

konfiguraˇcn´ıho souboru a sady funkc´ı pouˇzitých k vývoji. Jak naznaˇcuje Obr. 4.5, programové rozhran´ı umoˇzˇnuje vymˇenitelnost r˚uzných verz´ı protokol˚u a transceiver˚u pouze s minimáln´ı nebo ˇzádnou úpravou aplikaˇcn´ıho kódu. Celé rozhran´ı je rozdˇeleno do pˇeti ˇcást´ı: inicializace, navazován´ı spojen´ı, odes´ılán´ı zpráv, pˇr´ıjem zpráv a speciáln´ı funkce jako je detekce ruˇsen´ı nebo úsporné reˇzimy.

Samotná konfigurace protokolu je realizována pomoc´ı definiˇcn´ıch maker uve- dených v [9] v Tab. 1.

(27)

Obr´azek 4.5: Struktura programov´eho rozhran´ı

N´asleduj´ıc´ı souhrn popisuje vˇsechny funkce programov´eho rozhran´ı MiApp.

BOOL MiApp_ProtocolInit(BOOL bNetworkFreezer);

– Inicializace RF transceiveru a celého stacku. Jediným vstupn´ım parametrem je hodnota typu boolean, která rozhoduje, zda má být naˇcteno pˇredeˇslé nastaven´ı s´ıtˇe z pamˇeti EEPROM. Návratová hodnota poté indikuje, zda byl proces inicializace úspˇeˇsný.

BOOL MiApp_SetChannel(BYTE Channel);

– Nastaven´ı komunikaˇcn´ıho kanálu, jehoˇz hodnota m˚uˇze být v rozsahu 11 aˇz 26. Návratová hodnota indikuje, zda byla operace úspˇeˇsná.

BOOL MiApp StartConnection(BYTE Mode, BYTE ScanDuration, DWORD ChannelMap);

– Funkce pro vytvoˇren´ı PAN s´ıtˇe. Parametr Mode urˇcuje, jestli bude pˇred vytvoˇren´ım s´ıtˇe provedena detekce ruˇsen´ı na pˇr´ısluˇsných kanálech defino- vaných parametrem ChannelMap. Parametr ScanDuration urˇcuje dobu skenován´ı kanál˚u a je dán vztahem scanT ime(µs) = 960∗(2ScanDuration

+ 1).

BYTE MiApp_SearchConnection(BYTE ScanDuration,DWORD ChannelMap);

– Vyhledává dostupné s´ıtˇe, resp. koordinátory, výsledky uloˇz´ı do globálnˇe pˇr´ıstupného pole typu ACTIVE SCAN RESULT uvedeném ve Zdrojovém kódu 4.1. Parametr ScanDuration má stejný význam jako v pˇredcházej´ıc´ı funkci,

(28)

parametr ChannelMap udává, na kterých kanálech bude prob´ıhat vy- hledáván´ı. Návratová hodnota indikuje poˇcet nalezených zaˇr´ızen´ı, ke kterým se lze pˇripojit.

1 t y p e d e f s t r u c t{ 2 B Y T E C h a n n e l ; 3 B Y T E A d d r e s s [];

4 W O R D _ V A L P A N I D ; 5 B Y T E R S S I ;

6 B Y T E LQI ; 7 u n i o n

8 {

9 B Y T E Val ; 10 s t r u c t

11 {

12 B Y T E R o l e : 2;

13 B Y T E S l e e p : 1;

14 B Y T E S e c u r i t y E n : 1;

15 B Y T E R e p e a t E n : 1;

16 B Y T E A l l o w J o i n : 1;

17 B Y T E D i r e c t : 1;

18 B Y T E a l t S r c A d d r : 1;

19 } b i t s ; 20 } C a p a b i l i t y

21 } A C T I V E _ S C A N _ R E S U L T ;

Zdrojov´y k´od 4.1: Struktura ACTIVE SCAN RESULT

void MiApp RemoveConnection(BYTE ConnectionIndex);

– Provede vymazán´ı spojen´ı z tabulky pˇripojen´ı, jej´ıˇz struktura je uvedena ve Zdrojovém kódu 4.2, na pozici udané vstupn´ım parametrem ConnectionIndex. Pokud je vstupn´ı hodnota rovna 0xFFh, jsou z tabulky pˇripojen´ı vymazány vˇsechny záznamy.

1 t y p e d e f s t r u c t _ _ C O N N E C T I O N _ E N T R Y

2 {

3 A P I _ U I N T 1 6 _ U N I O N P A N I D ;

4 A P I _ U I N T 1 6 _ U N I O N A l t A d d r e s s ;

5 u i n t 8 _ t A d d r e s s [ M Y _ A D D R E S S _ L E N G T H ];

6 C O N N E C T I O N _ S T A T U S s t a t u s ;

7 #if A D D I T I O N A L _ N O D E _ I D _ S I Z E > 0

8 u i n t 8 _ t P e e r I n f o [ A D D I T I O N A L _ N O D E _ I D _ S I Z E ];

9 # e n d i f

10 } C O N N E C T I O N _ E N T R Y ; 11

12 e x t e r n C O N N E C T I O N _ E N T R Y C o n n e c t i o n T a b l e [ C O N N E C T I O N _ S I Z E ];

Zdrojový kód 4.2: Struktura CONNECTION ENTRY a pole pˇripojených uzl˚u

(29)

BYTE MiApp EstablishConnection(BYTE ActiveScanIndex, BYTE Mode);

– Funkce naváˇze spojen´ı s jedn´ım nebo v´ıce uzly. Návratová hodnota ukazuje na index v tabulce pˇripojen´ı. Pokud je návratová hodnota rovna 0xFFh, spojen´ı se nezdaˇrilo. Parametr ActiveScanIndex je index pole typu ACTIVE SCAN RESULT. Pokud je tato hodnota rovna 0xFFh, pak se funkce pokus´ı navázat spojen´ı se vˇsemi dostupnými uzly zaznamenané v uvedeném poli. Parametr Mode udává zp˚usob pˇripojen´ı. Ten m˚uˇze být bud’ formou pˇr´ımého rádiového dosahu nebo v nepˇr´ımého.

void MiApp ConnectionMode(BYTE Mode);

– Funkce nastav´ı reˇzim pˇrij´ım´an´ı poˇzadavk˚u o spojen´ı od ostatn´ıch uzl˚u:

pˇr´ıjem vˇsech poˇzadavk˚u, pˇr´ıjem poˇzadavk˚u pouze od uzl˚u, které byly uloˇzeny v pamˇeti EEPROM, pˇr´ıjem pouze skenovac´ıch poˇzadavk˚u a zakázán´ı vˇsech poˇzadavk˚u.

void MiApp FlushTx(void);

– Tato funkce resetuje ukazatel na pole, do kterého se nahrávaj´ı odes´ılaná data.

void MiApp WriteData(BYTE OneByteTxData);

– Nahraje jeden bajt zprávy daný vstupn´ı hodnotou OneByteTxData do pole (bufferu), pomoc´ı kterého se odes´ılaj´ı data. Obvykle je nejprve za- volána funkce MiApp FlushTx, následnˇe MiApp WriteData a poté pˇr´ısluˇsná funkce pro odeslán´ı zprávy bud’ ve formˇe vˇsesmˇerového vys´ılán´ı (broadcast) nebo ve formˇe c´ıleného vys´ılán´ı.

BOOL MiApp BroadcastPacket(BOOL SecEn);

– Odeˇsle data uloˇzená v transportn´ım poli pomoc´ı vˇsesmˇerového vys´ılán´ı.

Návratová hodnota indikuje zda byl proces úspˇeˇsný. Parametr SecEn nastavuje moˇznost ˇsifrován´ı. odeslaného paketu.

BOOL MiApp UnicastConnection(BYTE ConnectionIndex, BOOL SecEn);

– Odeˇsle data uloˇzená v transportn´ım poli, c´ılový uzel je dán parametrem ConnectionIndex, který udává pozici v poli pˇripojených uzl˚u.

BOOL MiApp UnicastAddress(BYTE *Address,BOOL PermanentAddr, BOOL SecEn);

– Odeˇsle data uloˇzená v transportn´ım poli, c´ılový uzel je dán parametrem PermanentAddr, který udává c´ılovou adresu.

BOOL MiApp MessageAvailable(void);

– Funkce vrac´ı hodnotu, která indikuje novou doruˇcenou zprávu pˇripravenou k dalˇs´ımu zpracován´ı. Zpráva je uloˇzena v promˇenné rxMessage, která je typu RECEIVED MESSAGE ve Zdrojovém kódu 4.3.

(30)

1 t y p e d e f s t r u c t

2 {

3 u n i o n

4 {

5 u i n t 8 _ t Val ; 6 s t r u c t

7 {

8 u i n t 8 _ t b r o a d c a s t : 2;

9 u i n t 8 _ t a c k R e q : 1;

10 u i n t 8 _ t s e c E n : 1;

11 u i n t 8 _ t r e p e a t : 1;

12 u i n t 8 _ t c o m m a n d : 1;

13 u i n t 8 _ t s r c P r s n t : 1;

14 u i n t 8 _ t a l t S r c A d d r : 1;

15 } b i t s ; 16 } f l a g s ; 17

18 A P I _ U I N T 1 6 _ U N I O N S o u r c e P A N I D ; 19 u i n t 8 _ t * S o u r c e A d d r e s s ;

20 u i n t 8 _ t * P a y l o a d ; 21 u i n t 8 _ t P a y l o a d S i z e ; 22 u i n t 8 _ t P a c k e t R S S I ; 23 u i n t 8 _ t P a c k e t L Q I ; 24 } R E C E I V E D _ M E S S A G E ;

Zdrojov´y k´od 4.3: Struktura RECEIVED MESSAGE

void MiApp DiscardMessage(void);

– Zavolán´ım této funkce dáváme najevo, ˇze pˇr´ıchoz´ı paket byl zpracován a jsme pˇripraveni pˇrijmout dalˇs´ı.

BYTE MiApp TransceiverPowerState(BYTE Mode);

– Zp˚usob´ı usp´an´ı nebo probuzen´ı transceiveru podle vstupn´ı hodnoty Mode.

Návratová hodnota indikuje, zda byl proces úspˇeˇsný.

(31)

5 V´ yvoj bezdr´ atov´ e aplikace zaloˇ zen´ e na tech- nologii MiWi

Jak jiˇz bylo naznaˇceno v Tab. 4.1, technologie MiWi rozeznává tˇri typy zaˇr´ızen´ı, proto budou vyvinuty tˇri projekty: PAN koordinátor, koordinátor a koncové zaˇr´ızen´ı.

Vývoj zdrojového kódu prob´ıhal v prostˇred´ı MPLAB X IDE v3.45 za pomoci kom- pilátoru MPLAB XC32 v1.42 a sady knihoven Microchip libraries for Applications (MLA) v2016-08-08 obsahuj´ıc´ı MiWi stack.

5.1 Obecn´ a struktura projektu v prostˇ red´ı MPLAB X

Struktura projektu vycház´ı z pˇr´ıkladové úlohy nacházej´ıc´ı se v uvedeném bal´ıku knihoven a je ilustrována na Obr. 5.1.

Obr´azek 5.1: Struktura projektu v prostˇred´ı MPLAB X¹

1Struktura uvedená na Obr. 5.1 neodpov´ıdá reálné struktuˇre sloˇzek na pevném disku.

Tzv. virtu´aln´ı sloˇzky slouˇz´ı pˇredevˇs´ım pro lepˇs´ı pˇrehlednost projektu.

(32)

Zdrojové a hlaviˇckové soubory MiWi stacku jsou fyzicky uloˇzeny v bal´ıku MLA, který je obvykle instalován do sloˇzky C:\microchip\mla. Tyto soubory jsou v projektu zaˇclenˇeny do virtuáln´ı sloˇzky framework. Projektovˇe specifické soubory jsou zaˇrazeny do virtuáln´ı sloˇzky system config a fyzicky uloˇzeny v projektové sloˇzce.

Dále je nutné ve vlastnostech projektu (Project properties → XC32-gcc → Pre- processing and messages → Include directories) nastavit sloˇzky, ze kterých budou naˇc´ıtány hlaviˇckové soubory.

Obrázek 5.2: Sloˇzky, ze kterých budou naˇc´ıtány hlaviˇckové soubory

Konfigurace konkrétn´ı aplikace a stacku je rozdˇelena na nˇekolik ˇcást´ı. V souboru system config.h jsou pˇredevˇs´ım definovány názvy konkrétn´ıch pin˚u, které jsou následnˇe pouˇz´ıvány celým stackem. Jejich název tedy mus´ı být striktnˇe dodrˇzován.

V souboru system.h jsou definovány taktovac´ı frekvence pˇr´ısluˇsných souˇcást´ı mi- krokontroléru. Soubor miwi config.h obsahuje konfiguraci aplikaˇcn´ı vrstvy stacku (napˇr. typ pouˇzitého protokolu, role uzlu v s´ıti, délka adresy, PAN ID, velikost buffer˚u, typ pouˇzitého komunikaˇcn´ıho modulu atd.). Soubor miwi config mesh.h definuje chován´ı logiky mesh s´ıtˇe a vrstvy pˇr´ıstupu k médiu (MAC). Jedná se hlavnˇe o ˇcasové limity jednotlivých operac´ı. Posledn´ı konfiguraˇcn´ı soubor config 24j40.h definuje vlastnosti fyzické vrstvy jako je napˇr´ıklad ˇsifrovac´ı kl´ıˇc nebo dodateˇcná nastaven´ı konkrétn´ıch modul˚u. Za zm´ınku stoj´ı i konfigurace sbˇernice SPI, jej´ıˇz názvy funkc´ı mus´ı být také striktnˇe dodrˇzovány nebot’ jsou pouˇz´ıvány stackem pro komunikaci s modulem. D˚uleˇzité je i nastaven´ı ˇcasovaˇce. Konkrétnˇe byly pouˇzity ˇcasovaˇce Timer2 a Timer3, které dohromady tvoˇr´ı jeden 32bitový ˇcasovaˇc. Ten je nastaven dle poˇzadavku standardu IEEE 802.15.4. Tento standard totiˇz definuje základn´ı ˇcasové kvantum (tzv. symbol) o délce 16 µs, coˇz je nastavená perioda inkrementace ˇcasovaˇce.

Zdrojové soubory jsou rozdˇeleny stejnˇe jako hlaviˇckové, tedy na ˇcást tvoˇr´ıc´ı stack a na ˇcást realizuj´ıc´ı konkrétn´ı aplikaci vˇcetnˇe podp˚urných soubor˚u. Soubor system.c obsahuje nastaven´ı konfiguraˇcn´ıch bit˚u mikrokontroléru a funkci, která ini- cializuje vˇsechny potˇrebné periferie. Funkce pro inicializaci a ˇcten´ı hodnoty ˇcasovaˇce jsou definovány v souboru symbol.c. Hodnota ˇcasovaˇce je ukládána do struktury MIWI TICK. Definice funkc´ı pro pouˇz´ıván´ı sbˇernice SPI se nacházej´ı v souboru spi.c.

V souboru eeprom.c jsou definov´any funkce pro ˇcten´ı adresy EUI-48 z pamˇeti

(33)

EEPROM. Soubory delay.c, console.c a button.c obsahuj´ı pomocné funkce pro generován´ı zpoˇzdˇen´ı, obsluhu sbˇernice UART a tlaˇc´ıtek. Zálohován´ı informac´ı o s´ıti a jejich zpˇetné naˇc´ıtán´ı zajiˇst’uj´ı funkce definované v souboru miwi nvm.c. Logiku s´ıtˇe, resp. fungován´ı s´ıt’ové vrstvy, obstarávaj´ı funkce definované v souboru miwi mesh.c.

Vrstvu pˇr´ıstupu k médiu a fyzickou vrstvu vˇcetnˇe komunikace s modulem zajiˇst’uj´ı funkce v souboru drv mrf 24j40.c. Samotná aplikaˇcn´ı logika je poté v hlavn´ım souboru main.c.

5.2 Uprava zdrojov´ ´ ych k´ od˚ u pro architekturu PIC32MX

Jelikoˇz je MiWi stack distribuován pouze pro osmibitové mikrokontroléry, bylo jedn´ım z úkol˚u této práce pˇrizp˚usobit stack tak, aby mohl fungovat i na archi- tektuˇre PIC32MX. Hlavn´ı zmˇeny byly provedeny v oblasti pouˇz´ıván´ı systémových zdroj˚u mikrokontroléru jako napˇr. úprava ˇcasovaˇc˚u nebo zmˇeny v pˇreruˇsen´ı.

Zat´ımco osmibitové mikrokontroléry pouˇz´ıvaj´ı systém s jedn´ım vektorem pˇreruˇsen´ı (v kódu je definována pouze jedna funkce, ve které jsou kontrolovány pˇr´ısluˇsné pˇreruˇsovac´ı pˇr´ıznaky), architektura PIC32MX pouˇz´ıvá v´ıce-vektorový systém pˇreruˇsen´ı.

To znamená, ˇze kód pro mikrokontrolér PIC32MX m˚uˇze obsahovat v´ıce funkc´ı obslu- huj´ıc´ı pˇreruˇsen´ı, pˇriˇcemˇz se zavolá funkce, která obsluhuje daný pˇreruˇsovac´ı vektor.

Nav´ıc pouˇz´ıvá architektura PIC32MX systém priorit, který obsluhuje pˇreruˇsen´ı vy- volaná ve stejný okamˇzik. Výslednou inicializaci pˇreruˇsen´ı popisuje Zdrojový kód 5.1.

Ve zdrojovém kódu drv mrf miwi 24j40.c je poté nutné nahradit definici pˇreruˇsovac´ı funkce void interrupt high isr (void) definic´ı void ISR( EXTERNAL 0 VECTOR, IPL1AUTO) RxInterrupt(void). Velkou pozornost je nutné vˇenovat nastaveným prioritám. Pokud má pˇreruˇsen´ı nastavenou jinou prioritu neˇz pˇreruˇsovac´ı vektor, nedojde k aktivaci pˇreruˇsen´ı.

1 // p o u z i t i v i c e v e k t o r o v e h o p r e r u s e n i

2 I N T C o n f i g u r e S y s t e m ( I N T _ S Y S T E M _ C O N F I G _ M U L T _ V E C T O R );

3 // p o v o l e n i p r e r u s e n i 4 I N T E n a b l e I n t e r r u p t s ();

5 // v y n u l o v a n i p r i z n a k u p r e r u s e n i na p i n u I N T 0 6 I N T C l e a r F l a g ( I N T _ I N T 0 );

7 // p o v o l e n i e x t e r n i h o p r e r u s e n i ,

8 // v y v o l a n i p r e r u s e n i na s e s t u p n o u h r a n u

9 C o n f i g I N T 0 ( F A L L I N G _ E D G E _ I N T | E X T _ I N T _ E N A B L E );

10 // n a s t a v e n i p r i o r i t y 11 I P C 0 S E T = 0 x 0 4 0 0 0 0 0 0 ; 12 // p o v o l e n i p r e r u s e n i

13 I N T E n a b l e ( I N T _ I N T 0 , I N T _ E N A B L E D );

Zdrojov´y k´od 5.1: Inicializace pˇreruˇsen´ı

Dalˇs´ı oblast´ı, která vyˇzadovala úpravu, byl ˇcasovaˇc. Osmibitové mikrokontroléry disponuj´ı pouze 16bitovými ˇcasovaˇci a rozˇs´ıˇren´ı na 32 bit˚u je ˇreˇseno softwarovou cestou. U architektury PIC32MX je moˇzné spojit dva 16bitové ˇcasovaˇce (v tomto pˇr´ıpadˇe Timer 2 a Timer3) a vytvoˇrit tak jeden 32bitový. Dále je nutné nastavit

(34)

korektnˇe hodnotu ONE SECOND v souboru system.h, jej´ıˇz hodnota se ˇr´ıd´ı vztahem

1(s)

perioda inkrementace casovace(s). V tomto pˇr´ıpadˇe je perioda inkrementace ˇcasovaˇce 16 µs, výsledné ˇc´ıslo je tedy 62 500. Ve stejném souboru je nutné upravit i pˇrevodn´ı makra SYMBOLS TO TICKS(a) a TICKS TO SYMBOLS(a). Pojem tick v tomto kontextu zna- mená jeden takt ˇcasovaˇce, zat´ımco pojem symbol znamená jiˇz zm´ınˇené ˇcasové kvantum o délce 16 µs. Pokud perioda taktu ˇcasovaˇce nen´ı rovna 16 µs, je nutné uplatnit pˇrevodn´ı vztah pro pˇrevod tˇechto jednotek. Pokud je takt ˇcasovaˇce roven jednomu symbolu (coˇz je tento pˇr´ıpad), pak mohou tato makra m´ıt tvar

#define SYMBOLS TO TICKS(a) a.

5.3 Aplikaˇ cn´ı k´ od - PAN koordin´ ator

Zdrojový kód koordinátora vycház´ı z doporuˇcené sekvence pˇr´ıkaz˚u uvedené v [9].

Aby uzel zastával roli koordinátora, je nutné v hlaviˇckovém souboru miwi config.h zavést definici #define NWK ROLE COORDINATOR.

Nejprve je inicializován veˇskerý potˇrebný hardware a poté je naˇctena EUI-48 adresa. Následnˇe je zahájena inicializace protokolu vˇcetnˇe transceiveru, dále je nastaven komunikaˇcn´ı kanál a reˇzim pˇripojen´ı uzl˚u, zahájen provoz s´ıtˇe a poté je v nekoneˇcné smyˇcce kontrolováno, zda byla pˇrijata zpráva. Pokud byla zpráva pˇrijata, je na sbˇernici UART vypsána zdrojová adresa zprávy a jej´ı obsah. Uvedený Zdrojový kód 5.2 zjednoduˇsenˇe vystihuje posloupnost pˇr´ıkaz˚u.

1 v o i d m a i n (v o i d)

2 {

3 // i n i c i a l i z a c e d e s k y 4 S Y S T E M _ I n i t i a l i z e ();

5 // n a c t e n i EUI -48 a d r e s y 6 R e a d _ M A C _ A d d r e s s ();

7 // i n i c i a l i z a c e p r o t o k o l u a t r a n s c e i v e r u 8 M i A p p _ P r o t o c o l I n i t ( f a l s e );

9 // n a s t a v e n i k o m u n i k a c n i h o k a n a l u 10 M i A p p _ S e t C h a n n e l ( m y C h a n n e l );

11 // n a s t a v e n i r e z i m u p r i p o j o v a n i u z l u 12 M i A p p _ C o n n e c t i o n M o d e ( E N A B L E _ A L L _ C O N N );

13 // v y t v o r e n i s i t e

14 M i A p p _ S t a r t C o n n e c t i o n ( S T A R T _ C O N N _ D I R E C T , 0 , 0);

15 w h i l e(1)

16 {

17 if( M i A p p _ M e s s a g e A v a i l a b l e ())

18 {

19 int i = 0;

20 C O N S O L E _ P u t S t r i n g (" New m e s s a g e a v a i l a b l e ");

21 s p r i n t f ((c h a r *) buf2 ,

22 (c h a r*)" S o u r c e a d d r e s s : < A d d r : % 0 2 x %02 x > ", 23 r x M e s s a g e . S o u r c e A d d r e s s [1] ,

24 r x M e s s a g e . S o u r c e A d d r e s s [ 0 ] ) ;

(35)

25 C O N S O L E _ P u t S t r i n g ( b u f 2 );

26 for( i = 0; i < r x M e s s a g e . P a y l o a d S i z e ; i ++)

27 {

28 buf [ i ] = r x M e s s a g e . P a y l o a d [ i ];

29 }

30 C O N S O L E _ P u t S t r i n g ( buf );

31 M i A p p _ D i s c a r d M e s s a g e ();

32 }

33 }

34

35 }

Zdrojový kód 5.2: Zdrojový kód pˇredstavuj´ıc´ı roli PAN koordinátora

5.4 Aplikaˇ cn´ı k´ od - koordin´ ator (router)

Zdrojový kód koordinátora (neplést s PAN koordinátorem) je v urˇcitých ohledech stejný, zvláˇstˇe v inicializaci a konfiguraci, která prob´ıhá stejnˇe jako u koordinátora.

Hlavn´ı rozd´ıl spoˇc´ıvá v zahájen´ı vyhledáván´ı okoln´ıch uzl˚u a následném pˇripojen´ı ke koordinátor˚um, které maj´ı hodnotu s´ıly signálu vyˇsˇs´ı neˇz 50. ˇCást programu routeru je uvedena ve Zdrojovém kódu 5.3.

1 v o i d m a i n (v o i d)

2 {

3 .

4 .

5 i n i c i a l i z a c e

6 .

7 .

8

9 u i n t 8 _ t s c a n R e s u l t = M i A p p _ S e a r c h C o n n e c t i o n (10 , 10 M i W i _ C H A N N E L );

11 for( i = 0; i < s c a n R e s u l t ; i ++)

12 {

13 if( A c t i v e S c a n R e s u l t s [ i ]. R S S I V a l u e > 50)

14 {

15 if ( M i A p p _ E s t a b l i s h C o n n e c t i o n ( i , 16 C O N N _ M O D E _ I N D I R E C T ) != 0 xFF )

17 {

18 ...

19 }

20 e l s e if ( M i A p p _ E s t a b l i s h C o n n e c t i o n ( i , 21 C O N N _ M O D E _ D I R E C T ) != 0 xFF )

22 {

23 ...

24 }

25 e l s e

(36)

26 {

27 s p r i n t f ( buf , " F A I L E D to c o n n e c t to 0 x %02 x %02 x ", 28 A c t i v e S c a n R e s u l t s [ i ]. A d d r e s s [1] ,

29 A c t i v e S c a n R e s u l t s [ i ]. A d d r e s s [ 0 ] ) ; 30 C O N S O L E _ P u t S t r i n g ( buf );

31 }

32 }

33 }

34

35 w h i l e (1)

36 {

37 if ( M i A p p _ M e s s a g e A v a i l a b l e ())

38 {

39 M i A p p _ D i s c a r d M e s s a g e ();

40 }

41 }

42 }

Zdrojový kód 5.3: Zdrojový kód pˇredstavuj´ıc´ı roli koordinátora (routeru)

5.5 Aplikaˇ cn´ı k´ od - koncov´ y uzel

Koncový uzel se od koordinátor˚u liˇs´ı pˇredevˇs´ım v konfiguraci. V souboru miwi config.h by mˇela být zavedena definice #define NWK ROLE END DEVICE a #define ENABLE SLEEP.

V aplikaˇcn´ım kódu je opˇet standardn´ı inicializace aˇz na nastaven´ı pˇripojován´ı kon- cových uzl˚u, která je zakázaná. Zkrácený program je uveden ve Zdrojovém kódu 5.4 1 v o i d m a i n (v o i d)

2 {

3 .

4 .

5 i n i c i a l i z a c e

6 .

7 .

8 M i A p p _ C o n n e c t i o n M o d e ( D I S A B L E _ A L L _ C O N N );

9 u i n t 8 _ t s c a n R e s u l t = M i A p p _ S e a r c h C o n n e c t i o n (10 , 10 M i W i _ C H A N N E L );

11 for( i = 0; i < s c a n R e s u l t ; i ++)

12 {

13 if( A c t i v e S c a n R e s u l t s [ i ]. R S S I V a l u e > 50)

14 {

15 if ( M i A p p _ E s t a b l i s h C o n n e c t i o n ( i , 16 C O N N _ M O D E _ I N D I R E C T ) != 0 xFF )

17 {

18 ...

19 }

20 e l s e if ( M i A p p _ E s t a b l i s h C o n n e c t i o n ( i ,

(37)

21 C O N N _ M O D E _ D I R E C T ) != 0 xFF )

22 {

23 ...

24 }

25 e l s e

26 {

27 s p r i n t f ( buf , " F A I L E D to c o n n e c t to 0 x %02 x %02 x ", 28 A c t i v e S c a n R e s u l t s [ i ]. A d d r e s s [1] ,

29 A c t i v e S c a n R e s u l t s [ i ]. A d d r e s s [ 0 ] ) ; 30 C O N S O L E _ P u t S t r i n g ( buf );

31 }

32 }

33 }

34

35 w h i l e(1)

36 {

37 A D C S a m p l e ();

38 M i A p p _ F l u s h T x ();

39 M i A p p _ W r i t e D a t a ( A D C D a t a [ 1 ] ) ; 40 M i A p p _ W r i t e D a t a ( A D C D a t a [ 0 ] ) ;

41 M i A p p _ U n i c a s t A d d r e s s (0 x0000 , f a l s e ); // a d r e s a k o o r d i n a t o r a 42 A D C O f f ();

43 M i A p p _ T r a n s c e i v e r P o w e r S t a t e ( P O W E R _ S T A T E _ S L E E P );

44 i n i t R T C C ();

45 P o w e r S a v e S l e e p (); // zde se p r o g r a m z a s t a v i

46 M i A p p _ T r a n s c e i v e r P o w e r S t a t e ( P O W E R _ S T A T E _ W A K E U P );

47 A D C O n ();

48 }

49 }

Zdrojový kód 5.4: Zdrojový kód pˇredstavuj´ıc´ı roli koncového uzlu

(38)

6 Technologie IQRF

Technologie IQRF pˇredstavuje kompletn´ı platformu, která zahrnuje ˇsiroké portfolio bezdrátových transceiver˚u (v této práci bude pouˇzit modul DCTR-72DA), USB programátor a debugger, vlastn´ı vývojové prostˇred´ı a SDK (Software Development Kit) umoˇzˇnuj´ıc´ı vytváˇret poˇc´ıtaˇcové programy v jazyce Java a C++.

Moduly DCTR lze ˇr´ıdit dvˇema zp˚usoby:

Pomoc´ı protokolu DPA (Direct Peripheral Access) - Protokol DPA lze aktivovat nahrán´ım rozˇsiˇruj´ıc´ıho kódu, který v závislosti na verzi vytvoˇr´ı z modulu bud’ koordinátora s´ıtˇe nebo uzel, který má ovˇsem moˇznost smˇerovat zprávy ostatn´ım uzl˚um. Koordinátor s´ıtˇe poté m˚uˇze ovládat periferie ostatn´ıch modul˚u pouze pomoc´ı definovaného datového protokolu pˇrenáˇseného po sbˇernici SPI. Pˇr´ıpadnou úpravu funkcionalit lze ˇreˇsit pomoc´ı tzv. Custom DPA Han- dleru.

Programován´ım v jazyce C - Chován´ı modulu lze upravovat pouhým progra- mem bez implementace protokolu DPA. K tomuto úˇcelu disponuje operaˇcn´ı systém IQRF OS sadou funkc´ı popsanou v [10].

Chceme-li pouˇz´ıt protokol DPA, vˇsechny uzly mus´ı být pˇripojeny do s´ıtˇe a m´ıt na- hraný pˇr´ısluˇsný hardwarový profil. Pˇripojen´ı uzlu do s´ıtˇe se v terminologii IQRF nazývá bonding. Tento proces lze aktivovat bud’ pomoc´ı vývojového prostˇred´ı nebo protokolem DPA. Po úspˇeˇsném pˇripojen´ı vˇsech modul˚u je vhodné tyto moduly rozm´ıstit na pˇr´ısluˇsné m´ısto a poté provést tzv. node discovery, coˇz je v podstatˇe proces optimalizace s´ıtˇe. Tento proces, stejnˇe jako ostatn´ı funkce, lze spustit bud’ pomoc´ı vývojového prostˇred´ı nebo zaslán´ım DPA paketu pˇres rozhran´ı SPI. Výsledná s´ıt’ová topologie m˚uˇze být zobrazena v prostˇred´ı IQRF IDE tak jak je ilustrováno na Obr. 6.2.

Obr´azek 6.1: Struktura DPA paketu

Jak naznaˇcuje Obr. 6.1, DPA paket se skládá z adresy uzlu (2 bajty), iden- tifikátoru periferie (1 bajt), identifikátoru pˇr´ıkazu (1 bajt), identifikátoru hardwa- rového profilu (2 bajty) a volitelnˇe i dat. Úplný výˇcet vˇsech periferi´ı, pˇr´ıkaz˚u a jejich pouˇzit´ı je uvedeno v [11]. V reˇzimu DPA je maximáln´ı poˇcet uzl˚u omezen na 240,

(39)

pˇriˇcemˇz adresa 0xFFh je vyhrazena pro broadcast, adresa 0x00h je vyhrazena pro koordin´atora s´ıtˇe a adresa 0xFCh je vyhrazena pro lok´aln´ı rozhran´ı (tzv. loopback).

Obrázek 6.2: S´ıt’ová topologie vytvoˇrená po procesu discovery

(40)

7 V´ yvoj bezdr´ atov´ e aplikace zaloˇ zen´ e na tech- nologii IQRF

Bezdrátová aplikace zaloˇzená na technologii IQRF se skládá ze dvou ˇcást´ı: vývoje programu pro bezdrátový modul a vývoje programu pro mikrokontrolér.

7.1 Programov´ an´ı modulu IQRF

Po vytvoˇren´ı projektu je zapotˇreb´ı nahrát do jednoho modulu hardwarový profil ko- ordinátora a do zbylých modul˚u nahrát profil uzlu. Následnˇe je nutné provést konfiguraci vˇsech modul˚u, tj. nastaven´ı frekvence, komunikaˇcn´ıho kanálu a pˇredevˇs´ım nastaven´ı hardwarového profilu podle Obr. 7.1.

Obr´azek 7.1: Nastaven´ı hardwarov´eho profilu

(41)

D˚uleˇzitá je v tomto ohledu poloˇzka Custom DPA Handler, jej´ıˇz povolen´ı nám umoˇzn´ı ˇcásteˇcnˇe modifikovat chován´ı transceiveru v urˇcitých situac´ıch. Tato konfigurace je následnˇe nahrána do vˇsech transceiver˚u. Dalˇs´ım krokem pro úspˇeˇsný pˇrenos dat je vytvoˇren´ı zdrojového souboru, který bude zachytávat události souvisej´ıc´ı s protokolem DPA. Jedná se napˇr´ıklad o události vyvolané pˇred odeslán´ım paketu, pˇred uspán´ım modulu atd. Zdrojový soubor ve formˇe pˇredlohy obsahuj´ıc´ı vˇsechny tyto události je dostupný v bal´ıku IQRF Startup Package. V tomto souboru byly modifikovány dvˇe události. Prvn´ı je událost DpaEvent ReceiveDpaRequest, která je zavolána po pˇrijet´ı paketu a pokud paket obsahuje pˇr´ıkaz k uspán´ı transceiveru je ˇcást paketu nesouc´ı informaci dobˇe spánku zkop´ırována na sbˇernici SPI spolu se tˇremi znaky ”SLP”, které mikrokontrolér vyhodnot´ı jako pˇr´ıkaz k uspán´ı. Ukázka této modifikace je ve Zdrojovém kódu 7.1.

1 c a s e D p a E v e n t _ R e c e i v e D p a R e q u e s t :

2 // C a l l e d a f t e r DPA r e q u e s t was r e c e i v e d

3 if( _ P N U M == P N U M _ O S && _ P C M D == C M D _ O S _ S L E E P )

4 {

5 m e m o r y L i m i t = 2;

6 c o p y B u f f e r R F 2 C O M ();

7 b u f f e r C O M [2] = ’ S ’;

8 b u f f e r C O M [3] = ’ L ’;

9 b u f f e r C O M [4] = ’ P ’;

10 s t a r t S P I ( 5 ) ; 11 m e m o r y L i m i t = 0;

12 }

13 b r e a k;

Zdrojový kód 7.1: Událost zavolaná po pˇrijet´ı DPA poˇzadavku

Druhou modifikovanou událost´ı je DpaEvent BeforeSendingDpaResponse. Tato událost je zavolána pˇred odeslán´ım DPA odpovˇedi (response). V této konkrétn´ı mo- difikaci uvedené ve Zdrojovém kódu 7.2 transceiver ˇceká na dva bajty (hodnota naˇctená z A/D pˇrevodn´ıku) odeslané mikrokontrolérem, které zaˇclen´ı do DPA od- povˇedi.

1 c a s e D p a E v e n t _ B e f o r e S e n d i n g D p a R e s p o n s e :

2 // C a l l e d b e f o r e s e n d i n g DPA r e s p o n s e b a c k to o r i g i n a t o r 3 // of DPA r e s p o n s e

4

5 if( _ P N U M == P N U M _ S P I )

6 {

7 e n a b l e S P I (); // M a s t e r is a l l o w e d to t r a n s m i t f r o m now 8 R e c e i v e :

9 c l r w d t ();

10 if ( g e t S t a t u s S P I ()) // W a i t u n t i l SPI is not b u s y 11 g o t o R e c e i v e ;

12 if ( _ S P I R X ) // A n y t h i n g r e c e i v e d ?

13 { // Yes :

14 // B u f f e r C O M is a u t o m a t i c a l l y p r o t e c t e d now

(42)

15 // not to be o v e r w r i t t e n by n e x t SPI p a c k e t . 16 // Thus , s t o p S P I is not n e c e s s a r y h e r e .

17 // P a c k e t l e n g t h is in S P I p a c k e t L e n g t h .

18 c o p y B u f f e r C O M 2 I N F O (); // S t o r e r e c e i v e d p a c k e t

19 s t a r t S P I ( 0 ) ; // and t h e n a l l o w M a s t e r to t r a n s m i t a g a i n .

20 }

21 e l s e

22 g o t o R e c e i v e ; 23

24 _ D p a D a t a L e n g t h = _ D p a D a t a L e n g t h + 2;

25 F S R 0 = _ D p a M e s s a g e . R e s p o n s e . P D a t a + _ D p a D a t a L e n g t h - 2;

26 s e t I N D F 0 ( b u f f e r I N F O [ 0 ] ) ;

27 F S R 0 = _ D p a M e s s a g e . R e s p o n s e . P D a t a + _ D p a D a t a L e n g t h - 1;

28 s e t I N D F 0 ( b u f f e r I N F O [ 1 ] ) ;

29 }

30 b r e a k;

Zdrojový kód 7.2: Událost zavolaná pˇred odeslán´ım DPA odpovˇedi

Po zkompilován´ı a nahrán´ı zdrojového souboru budou uzly schopny odpov´ıdat na datové poˇzadavky koordinátora a interpretovat pˇr´ıkaz k uspán´ı uzlu a mikrokon- troléru souˇcasnˇe.

7.2 Programov´ an´ı mikrokontrol´ eru PIC32MX

Pro mikrokontrolér PIC32MX byly vytvoˇreny dva programy. Prvn´ı program realizuje koordinátora s´ıtˇe. Mikrokontrolér nejprve provede inicializaci potˇrebných sbˇernic, poté m˚uˇze volitelnˇe provést objevován´ı uzl˚u a optimalizaci jejich cest (discovery).

Následnˇe mikrokontrolér odeˇsle jednomu vybranému uzlu poˇzadavek na stav baterie a cca kaˇzdých 10 ms odes´ılá dotaz (SPI CHECK), který má hodnotu 0x00h, transceiver souˇcasnˇe vys´ılá jednu z hodnot uvedených v Tab. 7.2. Podrobný popis zp˚usobu pˇrenáˇsen´ı zpráv pomoc´ı sbˇernice SPI je uveden v [12] na str. 5. Jakmile je odpovˇed’

doruˇcena, stav baterie daného uzlu je odeslán na sbˇernici UART. Tento proces se opakuje pro vˇsechny uzly. Pokud uzel neodpov´ı do pˇeti sekund, je vynechán. Po ukonˇcen´ı sbˇeru dat mikrokontrolér odeˇsle broadcast obsahuj´ıc´ı pˇr´ıkaz k uspán´ı na stanovenou dobu. Kompletn´ı zdrojový kód je uloˇzen na DVD pˇr´ıloze ve sloˇzce IQRF.

Druhý program realizuje uzel, který provád´ı mˇeˇren´ı napˇet´ı na baterii. Program vys´ılá kaˇzdých cca 10 ms pˇr´ıkaz (SPI CHECK). Pokud jsou naˇctena nová data, je provedena jejich analýza a obsahuj´ı-li posloupnost znak˚u GD (Get Data), je spuˇstˇena konverze AD pˇrevodn´ıku a naˇctená hodnota je ve formˇe dvou bajt˚u odeslána do transceiveru. Pokud pˇrijatá data obsahuj´ı posloupnost znak˚u SLP (sleep), je ze zprávy naˇctena hodnota doby spánku, která je pˇrepoˇc´ıtána tak, aby bylo moˇzné j´ı nastavit alarm hodin reálného ˇcasu, který vyvolá pˇreruˇsen´ı a probud´ı tak mikro- kontrolér a transceiver z reˇzimu spánku. Kompletn´ı zdrojový kód je uloˇzen na DVD pˇr´ıloze ve sloˇzce IQRF.

(43)

Hodnota hex Stav SPI

00 SPI nen´ı aktivn´ı

07 SPI je pozastavena

3F SPI nen´ı pˇripravena (plný buffer, CRC souˇcet v poˇrádku) 3E SPI nen´ı pˇripravena (plný buffer, CRC souˇcet nen´ı v poˇrádku 40 aˇz 40 + N_max SPI je pˇripravena, v bufferu jsou data,

d´elka dat = tato hodnota - 0x40 80 SPI je pˇripravena - komunikaˇcn´ı reˇzim 81 SPI je pˇripravena - programovac´ı reˇzim 82 SPI je pˇripravena - reˇzim ladˇen´ı

FF SPI nen´ı aktivn´ı (chyba v hardwaru)

Tabulka 7.1: Moˇzn´e odpovˇedi na dotaz SPI CHECK, N_max = 56

(44)

8 Testov´ an´ı v re´ aln´ ych podm´ınk´ ach

Testován´ı s´ıly signálu prob´ıhalo na dvou lokalitách: na volném rovinatém prostranstv´ı a ve vodovodn´ı ˇstole v obci Bedˇrichov. Transceivery byly po celou dobu mˇeˇren´ı v pˇr´ımém dohledu ve výˇsce cca 150 cm nad zem´ı.

Obrázek 8.1: Závislost s´ıly signálu na vzdálenosti ve volném prostranstv´ı Jak naznaˇcuje Obr. 8.1, technologie IQRF ve vzdálenosti 330 m disponuje s´ılou signálu kolem hodnoty 60, coˇz je pro stabiln´ı spojen´ı dostateˇcné, zat´ımco technologie MiWi má v této vzdálenosti s´ılu signálu pod hodnotou 20, coˇz pro stabiln´ı spojen´ı nen´ı dostateˇcné.

Naproti tomu mˇeˇren´ı s´ıly signálu ve vodovodn´ı ˇstole prokázalo zcela opaˇcné výsledky. Technologie IQRF, aˇc mˇela signál dostateˇcnˇe silný, nedokázala stabilnˇe komunikovat ani na vzdálenost 150 m, technologie MiWi naopak prokázala schopnost stabilnˇe komunikovat aˇz do vzdálenosti 750 m, kde se hodnota s´ıly signálu ustálila na hodnotˇe 50, coˇz je pro stabiln´ı spojen´ı dostateˇcné.

(45)

Obrázek 8.2: Závislost s´ıly signálu na vzdálenosti ve vodovodn´ıˇstole v obci Bedˇrichov D˚uvodem této anomálie m˚uˇze být existence tzv. Fresnelových zón. Prvn´ı fresne- lova zóna je oblast, kterou se ˇs´ıˇr´ı zhruba 90 % energie signálu a má tvar elipsoidu. Jej´ı pr˚umˇer lze spoˇc´ıtat vztahem r₁[m] =^q^λd_D¹^d², pˇriˇcemˇz λ [m] je vlnová délka signálu, d₁ [m] a d₂ [m] jsou vzdálenosti od pˇrekáˇzky (pokud jsou si d₁ a d₂ rovny a souˇcasnˇe se rovnaj´ı polovinˇe D, pak se jedná o nejˇsirˇs´ı m´ısto zóny) a D [m] je vzdálenost vys´ılaˇc˚u. Pomoc´ı uvedeného vztahu lze spoˇc´ıtat, ˇze pr˚umˇer r₁ pˇri vzdálenosti 700 m a frekvenci 2,4 GHz je 4,67 m, zat´ımco pˇri frekvenci 868 MHz je hodnota r₁ 7,78 m.

(46)

9 Z´ avˇ er

Byla provedena reˇserˇse, ze které vzeˇsly dvˇe technologie: MiWi a IQRF. Obˇe technologie prokázaly moˇznost vytvoˇren´ı s´ıtˇe typu mesh. Liˇs´ı se pˇredevˇs´ım ve zp˚usobu implementace. Jak ukazuje Obr. 2.1, pro kategorii RF modul˚u je tˇreba expertn´ıch programátorských znalost´ı a zkuˇsenost´ı, coˇz se u protokolu MiWi potvrdilo. Je nutné podrobnˇe znát a pochopit vˇsechny souˇcásti tohoto protokolu. Tyto vlastnosti v koneˇcném d˚usledku prodluˇzuj´ı dobu vývoje.

Naopak pomoc´ı technologie IQRF je moˇzné postavit mesh s´ıt’ bˇehem jednoho dne, coˇz dokazuje technologickou vyspˇelost této platformy. Nicménˇe fyzikáln´ı moˇznosti nedovoluj´ı provoz této technologie v prostˇred´ı vodovodn´ı ˇstoly, proto z praktického hlediska v´ıtˇez´ı technologie MiWi.

U platformy MiWi je tˇreba sn´ıˇzit odbˇer proudu transceiveru v reˇzimu sp´anku.

Souˇcasná hodnota odbˇeru ˇcin´ı 1,1 mA, coˇz pro systém napájený z baterie nen´ı pˇrijatelné. Dalˇs´ıho sn´ıˇzen´ı odbˇeru lze doc´ılit pˇripojen´ım tranzistoru na napájec´ı vodiˇc transceiveru a provádˇet jeho úplné vypnut´ı v reˇzimu spánku. Po zapnut´ı staˇc´ı provést reinicializaci modulu a celý systém m˚uˇze pokraˇcovat ve své funkci.

Spotˇreba obou technologi´ı v reˇzimu sp´anku, vˇcetnˇe vlastn´ıho odbˇeru DC/DC mˇeniˇce, nepˇresahuje hodnotu 200 µA. V aktivn´ım reˇzimu spotˇreba nepˇrevˇsuje hodnotu 40 mA.

(47)

Literatura

[1] HYN ˇCICA, Ondˇrej (ed.). Bezdrátové s´ıtˇe typu mesh. ˇCasopis Automa [online]. 2005 [cit. 2016-12-13]. Dostupné z: http://automa.cz/cz/casopis- clanky/bezdratove-site-typu-mesh-2005 12 30826 1141/

[2] IQRF - bezdrátová technologie, která láme bariéry. In: Pandatron.cz - Elektrotechnický magaz´ın [online]. 2013 [cit. 2016-12-13]. Dostupné z:

https://pandatron.cz/?3673&iqrf - bezdratova technologie, ktera lame bariery [3] Malé, chytré, ˇceské. . . Bezdrátová platforma IQRF. In: Vývoj.HW.cz — Vˇse o elektronice a programován´ı [online]. 2010 [cit. 2016-12-17]. Dostupné z:

http://vyvoj.hw.cz/rf/male-chytre-ceske-bezdratova-platforma-iqrf.html [4] MICROCHIP TECHNOLOGY INC. MiWi Demo KitUser’s Guide [on-

line]. 2012 [cit. 2016-12-17]. ISBN 978-1-62076-575-3. DS70687A. Dostupn´e z:

http://ww1.microchip.com/downloads/en/DeviceDoc/70687A.pdf

[5] Sub-1GHz Low Cost Mesh Network. Texas Instruments [online]. [cit.

2016-12-14]. Dostupn´e z: http://www.ti.com/tool/TIDM-SUB1GHZ-MESH- NETWORK

[6] MCP16311/2 30V Input, 1A Output, High-Efficiency,Integrated Synchronous Switch Step-Down Regulator [online]. 2013 [cit.

2016-12-18]. ISBN 978-1-63276-806-3. SLVS696C. Dostupn´e z:

http://ww1.microchip.com/downloads/en/DeviceDoc/20005255B.pdf

[7] Support for MiWi Pro. In: Microchip Support Community [online]. 2016 [cit.

2016-12-20]. Dostupn´e z: https://www.microchip.com/support/

[8] FLOWERS, David a Yifeng YANG. Microchip MiWi Wi- reless Networking Protocol Stack [online]. 2010 [cit. 2016- 12-20]. ISBN 978-160932-346-2. AN1066. Dostupn´e z:

http://ww1.microchip.com/downloads/en/AppNotes/AN1066%20-

%20MiWi%20App%20Note.pdf

[9] YANG, Yifeng. Microchip Wireless (MiWi) Application Programming In- terface – MiApp [online]. 2009 [cit. 2016-12-21]. AN1284. Dostupn´e z:

http://ww1.microchip.com/downloads/en/AppNotes/01284A.pdf

(48)

[10] IQRF OS Operating System: Version 3.08D for (DC)TR-7xD Reference Gu- ide [online]. 2016 [cit. 2016-12-23]. Ref Guide IQRF-OS-308D TR-7xD 160921.

Dostupn´e z: http://www.iqrf.org/weben/downloads.php?id=156

[11] IQRF DPA Framework Technical Guide: Version v2.28 IQRF OS v3.08D [online]. 2016 [cit. 2016-12-23]. Dostupn´e z:

http://www.iqrf.org/weben/downloads.php?id=481

[12] SPI Implementation in IQRF For (DC)TR-7xD Techni- cal guide [online]. 2015 [cit. 2016-12-23]. Dostupn´e z:

http://www.iqrf.org/weben/downloads.php?id=85

(49)

Pˇ r´ılohy

Pˇ r´ıloha 1 - Sch´ emata adapt´ er˚ u bezdr´ atov´ ych modul˚ u

(50)

(51)

Pˇ r´ıloha 2 - Sch´ ema hlavn´ı desky

(52)

Pˇ r´ıloha 3 - DVD

DVD obsahuje n´asleduj´ıc´ı sloˇzky:

MIWI - obsauje vˇsechny projekty pro MPLAB X

IQRF - obsahuje vˇsechny projekty pro MPLAB X a IQRF IDE

HARDWARE - obsahuje sch´emata navrˇzen´a v prostˇred´ı Eagle 7.2.0

zprava - obsahuje tento dokument ve form´atu .PDF a .TEX vˇcetnˇe obr´azk˚u