Önálló laboratórium zárójegyzőkönyv

1. 1
Budapesti Műszaki és Gazdaságtudományi Egyetem
Méréstechnika és Információs Rendszerek Tanszék
NFC P2P, Bluetooth Low Energy adó-vevő készülék Androidos
készülékhez
Önálló laboratórium zárójegyzőkönyv
2016/17. II. félév
Mayer Tamás
III.évf, villamosmérnök szakos hallgató
Bsc, Beágyazott információs rendszerek ágazat
Konzulens:
Benesóczky Zoltán
(Méréstechnika és Információs Rendszerek Tanszék)

2. 2
Tartalomjegyzék
1.Bevezetés..................................................................................................................3
2.Hardware kiválasztás................................................................................................4
2.1. Optimális méretű hardware-ek....................................................................4
2.2. Végső hardware-ek.....................................................................................6
2.3. Végső terv...................................................................................................7
2.4. Hardware blokkdiagram..............................................................................7
3. Software...................................................................................................................8
3.1. Fejlesztőkörnyezet és kiegészítők…………………………………………….8
3.2. Simplelink Academy....................................................................................9
3.3. Példaprogramok és keretrendszerek..........................................................9
3.3.1. Bluetooth Low Energy...................................................................9
3.3.2. Near Field Communication..........................................................16
3.3.3. PC-s kliensprogram .NET és C# felhasználásával.....................20
4. Összefoglalás............................................................ ............................................21

3. 3
1. Bevezetés
Feladatom célja egy NFC, Bluetooth Low Energy adó vevő készülék létrehozása volt és
e technológiákkal való megismerkedés.
Olyan eszközöket ─ nevezetesen 2 ilyen eszközt ─ kívántam létrehozni melyek
egymással NFC technológia segítségével kommunikálnak, a ’lokális szerver’ pedig egy-
egy androidos telefon lett volna (mindenkinek a sajátja), melyre a kicserélt információ
beérkezett volna. Az android készülék a beérkezett információkat feldolgozza, majd másik
eszköz tulajdonosának email címére küld egy visszaigazoló üzenetet. Ez egy aránylag
egyszerű funkcionalitással rendelkező program melynek egy értelme van, mégpedig hogy
segítsen megismerni a 2 technológiát.
Meglátásom szerint e két technológia közös használatában sok potenciál lehet az
ambiens rendszerek és az IOT területén. Persze Bluetooth helyett lehet használni más rövid
hatótávolságú, adatcseréhez használt, nyílt, vezetéknélküli szabványt (Pl.:Zegbee,
WLAN).Az NFC képes lehet jelentősen megegyszerűsíteni az egyes lokális hálózatokhoz
való kapcsolódást, mint ezt láthattuk már a régebbi Samsung készülékeknél. Ez az
egyszerűsítés persze nem a villamosmérnökök hétköznapjait fogja megkönnyíteni hanem
azoknak akik az elektronikai eszközök területén nem igen jártassak, például idősebbek, de
sima átlagfelhasználókra is gondolhatunk akiknek nem olyan erős az elektronikai
eszközökhöz való affinitásuk.
Android
eszköz
BLE/NFC
eszköz
BLE/NFC
eszköz
Android
eszköz

4. 4
2. Hardware kiválasztás
Az ötlet megvalósításának első lépése a hardverek kiválasztása volt. Ez, mint később
kiderült egy elég nehéz folyamat. Nagyon sok helyen kerestem a céljaimnak megfelelő
modult, de szinte sehol sem találtam, álltalában a mérete volt a gond. Fontos hogy olyan
modulra volt szükségem ami képes az NFC P2P módjában működni azaz képes az ISO/IEC
18092-es protokollra. Végül találtam néhány ígéretes példányt:
2.1. Optimális méretű hardverek
2.1.1. BM019: SERIAL TO NEAR FIELD COMMUNICATION
Ez volt az első ígéretes modul, ezen a honlapon bukkantam rá:
http://www.solutions-cubed.com/bm019/
Nem vagyok benne biztos, hogy tényleg tudja azt amit akarok, elég homályos volt a
katalógus a P2P-rel kapcsolatban.
BM019
A méretre viszont majdhogynem tökéletes lett volna, de később rájöttem, hogy az önálló
laboratórium keretein belül elég lesz, ha egyelőre csak a funkcionalitást valósítom meg.

5. 5
2.1.2. Tau
 32bit
 48MHz
 ARM Cortex M0+
 Arduino Zero compatible
microcontroller
 28mm x 15mm
2.1.3. Bluetooth V4.0 HM-11 BLE Module
 Microprocessor: CC2541
 Outline Dimension: 13.5mm x
18.5mm x 2.3mm
 Power supply:3.3V
Tau
HM-11

6. 6
2.2. Végső Hardverek
Itt a méretet nem már csak a funkcionalitást figyeltem
2.2.1. CC2650 Wireless MCU LaunchPad Kit
 ARM® Cortex®-M3
 128KB Flash
 8KB of SRAM for Cache
 2.4-GHz RF Transceiver
 Multi-standard
2.2.2. MSP430F5529 LaunchPad
 MSP430 processor
 128KB flash
 8KB RAM
2.2.3. DLP-7970ABP NFC Transceiver Booster Pack
 13.56MHz HF RFID Reader/Writer
 Supports ISO 15693, 18000-3,
 14443A/B, and FeliCa
 RFID/NFC Reader, NFC Peer,
 or in Card Emulation mode
 NFCIP-1 (ISO/IEC 18092)
 and NFCIP 2 (ISO/IEC 21481)
 On-board Antenna
CC2650
MSP430 FF5529
DLP-7970ABP

7. 7
2.3. A végső terv
A végső tervben az NFC és BLE modulok külön kártyákra kerültek, így
egyszerűsítve a végső feladatot, az android készülék helyét pedig felcserélte agy
PC. Ez nem feltétlenül egyszerűsítés, lehetne erről is vitatkozni hogy a C#/.NET
vagy Java/Android a nehezebb, én azért döntöttem az előbbi mellett mert az év
folyamán ezt más tárgyból is tanultam és jól tudtam már használni.
Folyamatábra
2.4. Hardver blokkdiagram
Amint a diagramon is látható az MSP és az NFC modul egy tüskesoron
kapcsolódnak egymáshoz , a modul egy TI által forgalmazott Booster Pack. A modul
és az MSP SPI-on keresztül kommunikálnak, az MSP és a CC2650 UART-on és a
PC-hez kapcsolódást USB/UART konverterek oldják meg a debugger áramkörökben.

8. 8
Blokkdiagram
3. Szoftver
A szoftver megvalósításában fontos lépések voltak, a fejlesztőkörnyezet megismerése, a
megfelelő kiegészítők megkeresése a környezethez, a library-k és példaprogramok
megismerése, megértése és átírása.
3.1. Fejlesztőkörnyezet és a kiegészítők
3.1.1. Code Composer Studio
Fejlesztőkörnyezetnek a TI saját IDE-ját a Code Composer Studio-t használtam
ennek is a legújabb verzióját. Nekem nem lett a kedvenc fejlesztő környezetem, más
eclipse alapú fejlesztő környezetnél nagyságrendekkel lassabb.
Telepítésnél meg kell adni a processzortípusokat amivel használni fogom, utána
is ad rá de nekem nem működött, úgyhogy egy másik processzornál újra kellett
telepítenem az egészet.
A példa projektnél fontos lehet hogy azzal a compilerrel fordítsunk amivel
megírták a projectet, erre warningot is kapunk, a régebbi compilerek telepítése a
következő linken elérhető:
http://processors.wiki.ti.com/index.php/Compiler_Updates
Predefined Symbols-t mindig meg kell nézni hogy megfelelően be vannak állítva
ha példaprogramot használunk.
3.1.1.1. Resource Explorer
Itt találhatók meg minden TI-s Board-hoz a pédaprogramok, elég
hiányos de azért tud segíteni, hasznosabb programokat a githubon lehet
találni
Pl.: https://github.com/ti-simplelink/ble_examples/tree/ble_examples-
2.2

9. 9
3.1.2. BLE SDK
Bluetooth-os fejlesztéshez elengedhetetlen a BLE SDK, ez letölthető a texas
honlapjáról de a CCS-ben a View /CCS App Center alatt is elérhető .
3.1.3. TI-RTOS
BLE SDK-val együtt települ.
3.1.4. BLE Device Monitor
Ez abban segít hogy service-jainkat számítógép segítségével is tudjuk tesztelni.
3.2. Simplelink Acedemy
Ez egy nagyon hasznos kis szolgáltatás a Texastól, megkönnyíti a megismerkedést
a BLE Stack –kel és a TI-RTOS-szel.
Link: http://software-dl.ti.com/lprf/simplelink_academy/overview.html
Ehhez tartozik egy külön könyvtár melyet csakugyan a TI honlapjáról lehet
leszedni, erre épülnek a különböző tutorial-ok.
3.3. Példaprogramok és keretrendszerek
3.3.1. Bluetooth Low Energy
3.3.1.1. Project Zero
Fontos, hogy először a project_zero_stack –et kell lefordítani aztán csak
a project_zero_appot. IOS-re és Androidra van egy ehhez szükséges
alkalmazás Simplelink Starter néven, amivel az eszközön futó program
feature-jei („Service declaration”) grafikusan elérhetőek. A project zero-nál
ezek többek között led villogtatás, gomb kiolvasás.
A legátláthatóbb képet akkor kapjuk, ha a BLE Device Monitor-t vagy
pedig a Btool-t használjuk, ezek PC-s alkalmazások, ezekre épül a Simplelink
Academy-s tanfolyam eleje.
A PC-s alkalmazásokhoz kell egy külön Texasos BLE USB dongle, vagy
pedig egy másik CC2650. Nekem az utóbbi konfiguráció áll
rendelkezésemre. Erre egy host-test nevű programot kellet feltöltenem, hogy
a PC-n azon belül a BLE Device Monitorral hozzá férjek a céleszközömhöz,
amin ugye a project zero fut. Ezt CCS-val rá lehet fordítani az eszközre.
Nekem ez nem vált be, a másik lehetőség hogy magát a .hex fájlt flasheljük.
Mind a 2 lehetőséghez a fájlokat a C:/ti/simplelink/ble_sdk/examples alatt
találtam.
Flash-eléshez a CCS- telepítő felajánl egy külön texasos szoftvert az
Uniflash-t, nekem ez bejött. Amikor egyszerre több eszköz is rá van csatolva
a számítógépre(mint a jelen esetben), akkor további teendőink vannak, ha

10. 10
nem akarjuk, hogy véletlenszerűen válasszon a CCS hogy melyik eszközre
kerüljön a program. A következő linken ez is részletezve van:
http://software-
dl.ti.com/lprf/simplelink_academy/modules/ble_01_basic/ble_01_basic.html
3.3.1.2. BLE Stack, ATT és GATT
A BLE témakörben az ATT és GATT nagyon fontos fogalmak
 ATT (Attribute Protocol)
Az ATT vagyis attribútum protokoll a BLE eszközök közti
kommunikáció vezénylésére hivatott.
 GATT(Generci Attributes)
Ez egy szolgáltatás keretrendszer, hierarchikusan épül föl, az ATT fölött
található. BLE fejlesztéshez elsőként ezzel kell megismerkedni.
LED (service)
Green
LED(characteristics)
Declaration
Value
White
LED(characteristics)
Declaration
Value
Display(servide) Write text
Declaration
Value
GATT profile
BLE Stack

11. 11
 Attribútum: A legkisebb címezhető egység
 Részei:
o Handle
o UUID
o Value(dinamikus hozzárendelődnek az egyes
attribútumokhoz ahogy azok regisztrálva lettek a GATT
serveren)
 Kommunikáció
A két eszköz(peer device és a GATT server) attribútumokkal beszélget
egymással. A küldő oldal a feature-jeit így tudatja a fogadó oldallal.
Az attribútumok a küldő oldalon hierarchiába vannak rendezve, ahogy
a felső ábra is mutatja(minden kocka egy attribútum) és olyan meta-adatok
szerepelnek bennük(UUID), hogy a küldés után a fogadó is fel tudja építeni
a hierarchiát.
Mindig az UUID alapján döntjük el hogy milyen attribútum érkezett.
Az kapcsolatfelvétel után többnyire Value típusú attribútumok
cserélődnek.(Led villogtatás, nyomógomb lekérdezés stb.)
 Services és Characteristics
 Characteristics
Két attribútumból tevődik össze, Value és Declaration. A Value is egy
attribútum tehát van egy value mezője.
Declaration: leírja hogy az adott value attribútumot írni kell vagy
olvasni. Tartalmazza az Characteristic UUID-ját.
Characteristics

12. 12
A peer device a következő UUID-kat keresi „a levegőben”0x2800 ->Primary Service
Declarations és 0x2803 -> Characteristic Declarations és ezek segítségével térképezi föl a
GATT server képességeit.
 Attribútum tábla
Alulról felfele…. a service UUID(ez írja le hogy milyen típusú a Service) egy
simpleProfileServiceUUID tömbben található, erre egy gattAttrType struktúra
segítségével hivatkozunk(pointer), amiben az UUID mérete is szerepel. Erre a
struktúrára pedig az Attribute Table-ből hivatkozunk, ez lesz az adott attribútum value
értéke.
Tehát a Service Attribute type mezőjében van a Primary Service Atribute ez
mindig 0x2803 ez mondja meg hogy attribútumról van szó, és az adott attribútumra
jellemző információt a „sima ” Service UUID hordozza amely pedig az attribútum
Value mezőjében található.
A characteristic-nél a characteristick UUID nem a value-ban van hanem
közvetlenül hivatkozunk rá az attribute table-ből, ő lesz az attribútum type-ja.(ahogy a
service-nél a primaryserviceUUID)
Characteristics
Declaration értelmezése

13. 13
3.3.1.3. UART implementálása
Ez a feladat okozta a legtöbb problémát számomra, alapvetően a TI-RTOS
nehezítette meg a dolgomat, maga az inicializálás egy elég triviális folyamat
volt.
Először 2 keretrendszerrel próbálkoztam az NPI és SDI –vel. Ezek előre
megírt keretrendszerek melyet elvileg bármely projektbe be lehet illeszteni ,
nekem ez nem sikerült. Az volt a probléma hogy az RTOS-ek terén hiányos
volt a tudásom. Az implemetnálást alapvetően úgy próbáltam megoldani hogy
egy külön taskot akartam indítani mely lekezeli az UART-ot interrupt esetén ,
ezen elv alapján voltak megírva az előbb említett keretrendszerek. Ez kb. 4
hetemet vette el, általánosságban az volt a probléma hogy minden taskom le
volt tiltva, a makrókat megfelelően beállítottam. Egy másik házi feladatomból
jött az ötlet hogy egyszerűbben kéne megoldani , és kis ügyeskedéssel egy
sima megszakításos UART-ot tudtam impelementálnom a project_zero-ba.
Persze ezzel az volt a probléma hogy a PC oldalon ez a megfelelő
applikációval kommunikál ezért ott nem tudom lekérdezni az adatokat.
Eközben találtam egy példaprogramot a Serial Port Profile nevezetű
UART/BLE hidat. Ezt eleinte nem tudtam lefordítani , de egy

14. 14
fejlesztőkörnyezet újratelepítés és régebbi compilerek próbálgatásával sikerült
végül lefordítani.
3.3.1.4. SPP_BLE a megoldás
A program egy server és egy client eszközt igényel és egy UART/BLE
bridge-t alkot. A kapcsolódás egy a kliens kódba makróként implementált
címmel történik a szerverhez .
négy hét sikertelen próbálkozás kudarcai

15. 15
Client
Auto
connecting
Found serial
service
Connect
Send/Reicive
Data
Server
Advertising
Connect
Send/Reicive
Data
spp_ble folyamatábra

16. 16
3.3.2. Near Field Communication
3.3.2.1. Aktív és Passzív NFC
 Aktív NFC-ről beszélünk ha mind2 eszköz maga körül EMC teret hoz
létre és így történik meg az adatátvitel. Minden protokollban találhatunk
erre példát, például léteznek aktív tagek melyek nem csak NFC-n
keresztül írhatók és olvashatóak hanem egyéb vezetékes kapcsolaton.
 Passzív NFC-ről beszélünk amikor csak az egyik eszköz kelt EMC teret
és ez ad energiát a passzív eszköznek, ennek segítségével olvashatóak
ki az adatok.
3.3.2.2. Protokollok
 Read/Write mode
Ezek olyan eszközök melyek aszimmetrikus kommunikációban vesznek
részt. Egyik oldalon általában egy Író/Olvasó eszköz áll míg a másikon egy
Írható/ Olvasható tag, vagy olyan eszköz melyből adatot lehet kiolvasni vagy
beleírni, tehát a „slave eszköz nem tud se írni se olvasni ő csak az információt
tárolja”.
 ISO/IEC 14443 A&B
 FeliCa
 ISO/IEC 15693
Read/Write mode

17. 17
 Card Emulation
Alapvetően itt a biztonságon van a hangsúly, fizetésnél és más titkosított
kommunikációnál használják. Az NFC rövid hatótávolsága miatt is alkalmas
biztonságkritikus alkalmazásoknál.
 NFC Forum Tag Types
 Peer to peer
Ezt használom én, az a legfontosabb tulajdonsága hogy itt 2 egyenértékű
eszköz van. Ezek szerepváltásokkal cserélik ki egymás között az
információt. Elsőként az 1. eszköz lesz az INITIATOR a 2.eszköz pedig
a TARGET(a nevek alapján az információ iránya triviális).Ezután
szerepváltás és fordítva is megismétlődik a folyamat. Van aktív és
passzív módja, én az aktív módot használom.
 ISO/IEC 18092
Read/Write mode

18. 18
3.3.2.3. Az NFC program
A SLOA192 a P2P technológia tesztelésére lett megírva MSP430F5529-
es mikrokontrollerre. Ehhez egy UART kommunikációs interface-t kellett
implementálni. Sajnos nem az alap MSP430-as könyvtárat használta a program
(MSP430Ware driver library) így azt használva nem sikerült az UART
inicializálása.
A bit szintű inicializálással viszont sikerrel jártam, de egy elég nehéz
munka volt.
void bcUartInit(void)
{
UCA0CTL1 |= UCSWRST; // állapotgép reset
UCA0CTL1 |= UCSSEL__SMCLK; // smclk óra használata
// baud 921000
UCA0BR0 = 0x1B;
UCA0BR1 = 0x00;
UCA0MCTL = 0x08;
// gpio beállítás TXD/RXD
P3SEL |= BIT3+BIT4;
P3REN |= BIT3+BIT4;
UCA0CTL1 &= ~UCSWRST;
UCA0IE |= UCRXIE;
SLOA192 folyamatábra
kódrészlet a myuart.c ből

19. 19
}
A program egyébként egy PC-s kliensalkalmazással is rendelkezik(NFC Tool) ez a
következőképpen néz ki.
Inicializáló menü
P2P menü
(Ez az EMC tér érzékelésénél egyből felugrik)
Egy figyelmetlenségből eredő problémám is volt ennél a résznél. Azt gondoltam hogy amikor
a debugger nem használja a CC2650 nél az UART-ot akkor ott High Z állapot van, de ez nem
így volt és az UART Rx lábam végig fel volt húzva mikor az MSP430 ról akartam csomagot
küldeni.

20. 20
A probléma az oszcilloszkóp képen is jól látható
A problémát a megfelelő jumper eltávolításával orvosoltam.
Fontos még megjegyezni, hogy az MSP430 Uart inicializálásnál egy nagyobb
probléma volt, hogy az A0 modulon van a p3.3 és p3.4 en kivezetett Uart. Nekem az A1 volt
beállítva első próbálkozásaim során, miután ezt javítottam működött a dolog. A baudrate-et
nehézkes beállítani 3 változó szolgál rá + a beállított mcu clk sebességtől is függ. Nekem a
CLK sebessége 25 MHZ-re van állítva, úgyhogy az adatlapból l kikeresve a fenti beállításokkal
el tudtam érni a 9600-as majd a 921000-as baudrate-et.(Ezt oszcilloszkópon is ellenőriztem)
3.3.3. PC-s kliensprogram. NET és C# felhasználásával
Ahogy azt már korábban is említettem, az androidot lecseréltem PC-re , ennek nem
volt különösebb oka, minthogy más tantárgyból ez volt terítéken, és elég jól ment(ha
lehet ilyet mondani 2-3 hónap után).
Egy aránylag egyszerű program dolgozik a kliens oldalon, melynek feladata hogy
ha releváns információ érkezik azt feldolgozza. Az SPP_BLE program mielőtt még
küldi az adatot egy elég karaktereket küld ezért a releváns információ kezdetét ’&’ jelzi
a végét ’%’ eszerint 2 állapot és az egyik állapoton belül még egy if van tehát
mondhatnám azt is hogy 2,5 állapot van.
HALT
RUN_SdRUN_Rv

21. 21
 HALT
Itt várakozik a program a ’&’ karakterre azaz a releváns információ
megérkezésére
 RUN_Rv(Receive)/ RUN_Sd(Send)
Ez a két művelet egy állapotba tartozik. Receive-ben érkeznek a releváns
karakterek ha ’%’ karakter jön akkor végrehajtódig a Send művelet és az adott
emailcímre elmegy a Hello üzenet.
4. Összefoglalás
A tervezett idő többszörösébe került a projekt megvalósítása de gyakorlatilag 100%-ig
elkészült.
 Segítségem:
o https://e2e.ti.com/ Összesen 43 fórumkérdést
kezdeményeztem
o http://processors.wiki.ti.com/
Sok segítségégem származott innen de a vakvágányok száma a
duplája volt, valószínű a tapasztalatlanságom miatt tartott ilyen
sokáig a problémák megoldása, de megoldásukkal nagyon sok
tapasztalatot gyűjtöttem.
 Problémáim forrásai
o RTOS-ek még hiányos ismerete
o BLE Stack hiányos ismerete
o
 Mit tanultam
o RTOS-ek(TI RTOS) megismerése
o BLE Stack/GATT/ATT megismerése
• Service létrehozása
o NFC stack megismerése
• Protokollok/technológia/program
o Nagyon sok ötletet merítettem a Mikrokontroller Laboratórium című
tárgyamból