Examensarbete 30 hp Juni 2019
DMX-communication over Bluetooth low energy mesh network
Thomas Danielsson
Teknisk- naturvetenskaplig fakultet UTH-enheten
Besöksadress:
Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0
Postadress:
Box 536 751 21 Uppsala
Telefon:
018 – 471 30 03
Telefax:
018 – 471 30 00
Hemsida:
http://www.teknat.uu.se/student
Abstract
DMX-communication over Bluetooth low energy mesh network
Thomas Danielsson
With the addition of mesh capability to Bluetooth low
energy(BLE) in 2017 new possibilities open up for the Internet of Things applications of Bluetooth. With the rapidly increasing
number of connected devices a few new standards are competing for being the standard protocol for low power mesh communication. BLE is mostly aimed towards low bandwidth data such as sensor readings or light control. However, this thesis attempts to investigate the viability of adapting BLE mesh nodes to communicate DMX-data which is a protocol widely used in lightning and stage effects.
The system is implemented on Bluetooth development kits and the latency and power consumption are measured. The results show that the latency is significant and with high variance if the full DMXframe is transmitted, rendering the application non-applicable on
many real-time applications. It can however be justified in some applications due to Bluetooth's well established eco-system of devices and functionality where the nodes could extend their capabilities by implementing already established BLE models. By only transmitting the updated channels the latency can be lowered to values that would in some applications be indistinguishable
from wired connection. The energy consumption of BLE mesh suffers greatly with the addition of mesh due to its constant scanning but by implementing low power nodes which keep the radio off during certain intervals this consumption could be greatly decreased. The results also show a high variance of latency depending on the node configuration regarding to the placements and the number of hops required to reach the intended recipient.
ISSN: 1401-5757, UPTEC F 19046 Examinator: Tomas Nyberg Ämnesgranskare: Ping Wu Handledare: Tomas Fredriksson
Popul¨ arvetenskaplig sammanfattning
Bluetooth har l¨ange varit standardprotokollet f¨or kommunikation mellan tv˚a stycken enheter. 2017 kom till¨agget med mesh till Bluetooth. Mesh inneb¨ar att andra enheten i n¨arheten ska skicka vidare meddelanden och d¨arigenom till˚ata kommunikation mellan enheter som ¨ar utanf¨or direkt radiokontakt. DMX ¨ar ett protokoll som anv¨ands inom ljus- och scenef- fekter. Bluetooth mesh ¨ar utformat f¨or att skicka sm˚a datam¨angder som till exempel sensordata eller styra gl¨odlampor. Denna uppsats kommer utv¨ardera om det ¨ar anv¨andbart att skicka DMX-data ¨over Bluetooth mesh.
En implementation gjordes p˚a Bluetooth utvecklingskort och resultatet visar p˚a en signifikant f¨ordr¨ojning och med h¨og varians vid ¨overf¨oring av alla DMX-kanaler, vilket inneb¨ar att denna implementation inte ¨ar anv¨andbar vid m˚anga anv¨andningsomr˚aden. Men trots det kan den vid vissa fall vara anv¨andningsbar, mycket till hj¨alp av Bluetooths billiga och utbyggda ekosystem av produkter och till¨aggsfunktioner. Eftersom Bluetooth mesh byggs in i en del befintliga byggnader kan de uppof- fringar man f˚ar g¨ora vid ¨overf¨oringar av DMX-data vara acceptabel d˚a man kan uttnyttja befintliga n¨at. Str¨omf¨orbrukningen ¨okar avsev¨art vid mesh j¨amf¨ort med klassisk l˚agenergi Bluetooth d˚a mesh m˚aste skanna radiotrafiken konstant. Vid implementationen av l˚agenergi noder kan dock radio vara i stand-by och starta endast vid speciella tidpunkter och man kan d¨arigenom f˚a avsev¨art l¨agre str¨omf¨orbrukning, med uppoffrin- gen att DMX-datan inte kan ¨overf¨oras omg˚aende. Det visade sig ocks˚a att noduppst¨allningen kraftigt p˚averkade variansen i ¨overf¨oringshastighet och att detta m˚aste ta i h¨ansyn vid valet om DMX ¨over Bluetooth mesh
¨
ar anv¨andbart i just det fallet.
iii
iv
Acknowledgments
Firstly I would like to thank my supervisor at Tritech, Tomas Fredriksson for your support, feedback and always being avail- able and staying positive throughout this thesis. A large thanks to the rest of the colleagues at Tritech for a warm welcome and introduction to an inspiring environment.
I also like to thank Ping Wu at Uppsala University for be- ing my subject reviewer and providing helpful feedback.
Finally a huge thanks to all my friends and family for the con- tinued support throughout this thesis and my academic years.
With my warmest regards, Thomas Danielsson Uppsala, Sweden, 17th June, 2019
Contents
Acknowledgments iv
Glossary xiii
Acronyms xv
1 Introduction 1
1.1 Background . . . 1
1.1.1 Company background . . . 2
1.2 Purpose and goals . . . 2
1.3 Task and delimitations . . . 3
1.3.1 Tasks . . . 3
1.3.2 Delimitations . . . 3
1.4 Method . . . 3
1.5 Disposition . . . 4
2 Background theory 5 2.1 Bluetooth overview . . . 5
2.2 BLE architecture . . . 6
2.2.1 Physical Layer . . . 7
2.2.2 Direct Test Mode . . . 8
2.2.3 Link Layer . . . 8
2.2.4 Host Controller Interface (HCI) . . . 10
2.2.5 Logical Link Control and Adaptation Protocol (L2CAP) 10 2.2.6 Security Manager . . . 11
2.2.7 Attribute Protocol (ATT) . . . 11
2.2.8 Generic Attribute Profile (GATT) . . . 12
2.2.9 Generic Access Profile (GAP) . . . 12
2.2.10 Application layer . . . 13
2.2.11 Packet format . . . 13
2.3 BLE mesh architecture . . . 14
2.3.1 Bearer layer . . . 15
v
vi CONTENTS
2.3.2 Network layer . . . 15
2.3.3 Transport layer . . . 15
2.3.4 Access layer . . . 16
2.3.5 Mesh models . . . 16
2.3.6 Provisioning . . . 16
2.3.7 Topology & nodes . . . 16
2.3.8 Publish-subscribe . . . 18
2.4 BLE mesh operation . . . 18
2.4.1 Provisioning . . . 19
2.4.2 Timing schedule and congestion control . . . 21
2.4.3 Mesh packet format . . . 23
2.4.4 Segmentation and Reassembly (SAR) . . . 23
2.4.5 Mesh models & elements . . . 24
2.4.6 Heartbeat . . . 26
2.4.7 Performance and network size . . . 27
2.5 DMX . . . 28
2.5.1 DMX512 overview . . . 28
2.5.2 DMX signal . . . 29
2.5.3 Data format . . . 29
3 Implementation 31 3.1 Hardware . . . 31
3.1.1 Bluetooth development kits . . . 31
3.1.2 DMX-conversion . . . 33
3.2 Software . . . 35
3.3 Custom model . . . 36
3.4 Data acquisition . . . 37
3.4.1 Latency measurement . . . 37
3.4.2 Power consumption measurement . . . 37
3.4.3 Congestion measurements . . . 38
3.4.4 Data processing . . . 38
3.5 Testing methodology . . . 38
4 Result and discussion 41 4.1 Energy consumption . . . 41
4.2 Latency measurments . . . 42
5 Conclusion and future work 47 5.1 Research Question 1 . . . 47
5.2 Research Question 2 . . . 48
5.3 Future work . . . 48
CONTENTS vii
Bibliography 51
A Decision for Bluetooth hardware 59
viii CONTENTS
List of Figures
2.1 Bluetooth low energy architecture . . . 7
2.2 Bluetooth low energy frequency bands . . . 7
2.3 Link layer state machine . . . 9
2.4 GAP state . . . 12
2.5 Packet format of Bluetooth 4.2 . . . 13
2.6 Bluetooth Low Energy (BLE) mesh architecture next to grayed out BLE architecture . . . 15
2.7 Bluetooth Energy mesh topology . . . 17
2.8 The three different authentication procedures [34, p.254-] 20 2.9 NetworkProtocol Data Unit (PDU) of BLE mesh . . . . 23
2.10 Mesh device element and model description . . . 25
2.11 5-pin DMX connector . . . 29
2.12 DMX data packet [41] . . . 29
2.13 Oscilloscope measurement of a DMX-signal showing con- tinous transfer of DMX value 128 each starting with start bits and followed by stop bits. In this case Mark Time Between Frames (MTBF) is set to 0 bits . . . 30
3.1 nRF52832 DK . . . 33
3.2 nRF52840 DK . . . 33
3.3 nRF52840 dongle . . . 33
3.4 Illustation of the MAX485 chip used. . . 34
3.5 Wiring of MAX485 chip where the pin 7,8 and 9 of the MAX485 chip connects to the DMX connector. Pin 4 to a nRF GPIO output for DMX transmitting and pin 1 to a nRF GPIO input for detecting power losses. . . 34
3.6 Test plan for quantitative measurements . . . 40
4.1 Time for receiving last acknowledgment during without mesh event flag . . . 42
4.2 Node setup for measuring hop latency. . . 43
ix
x LIST OF FIGURES
4.3 Time for last acknowledgment for different hop count and 7 channels per message. . . 44 4.4 Time for last acknowledgment for different amount of nodes
where server and client are stationary. . . 45 4.5 Time for last acknowledgment for different hop count and
7 channels per message. . . 45 4.6 Time for last acknowledgment for different amount of DMX
channels per message and 1 hop. . . 46
List of Tables
3.1 Decision table for hardware choice . . . 32
3.2 Custom models . . . 36
3.3 Test cases . . . 39
A.1 Decision table for hardware choice . . . 60
xi
xii LIST OF TABLES
Glossary
Asynchronous Asynchronous means that the transmitter and receiver does not share the same clock and the data is not synced between transmitter and receiver. Each byte is sent one by one instead of sending a single stream of data.
Balanced transmission Balanced transmission consists of two wires where one is inverse of the other, used to minimize the risk of interference.
Bidirectional nodes can only send data one way and bidirectional can both send and receive data.
DMX universe refers to a full frame of all 512 DMX channels
Half duplex Half duplex means that the transfer if bi-directional, but the data can only be sent in one direction at a time.
Unidirectional nodes can only send data one way and bidirectional can both send and receive data.
xiii
xiv Glossary
Acronyms
1:1 One to one ADV Advertising
AES Autenticated Encryption Al- gorithm
AFH Adaptive Frequency Hopping ATT Attribute Protocol
BLE Bluetooth Low Energy BR Basic Rate
CD Channel Data
CPU Central Processing Unit CRC Cyclic Redundancy Check CTL Network control message in-
dication
dBm decibel-milliwatt DK Development Kit DMX Digital Multiplex DST Destination
DTM Direct Test Mode EDR Enhanced Data Rate
EMI Electromagnetic interference FCC Federal Communications
Commission
FHSS Frequency-hopping spread spectrum
FSK Frequency Shift Keying GAP Generic Access Profile GATT Generic Attribute Profile GFSK Gaussian Frequency Shift
Keying
GPIO General-purpose in- put/output
GUI Graphical User Interface HCI Host Controller Interface HFCLK High-Frequency Clock HSL Hue, Saturation, Lightness ID Identifier
IO Input Output IoT Internet of Things
ISM Industrial, Scientific and Medical
IV Initialization Vector
L2CAP Logical Link Control and Adaptation Protocol
LDO Low-dropout regulator LE Low Energy
LED Light Emitting Diode LFCLK Low-Frequency Clock LL Link Layer
LPN low power node m:m Many to many MAB Mark After Break Mb/s Megabit per second MIC Message Integrity Check MTBF Mark Time Between
Frames
MTBP Mark Time Between Pack- ets
NFC Near Field Communication NOP No Operation
OOB Out Of Band
PAN Personal Area Network PDU Protocol Data Unit
xv
xvi Acronyms
PHY Physical Layer QR Quick Response
RSSI Recieved Signal Strength In- dex
RTT Real Time Terminal
SAR Segmentation and Reassem- bly
SC Start Code
SDIO Secure Digital Input Output SDK Software Development Kit SEQ sequence
SES SEGGER Embedded Studio SIG Special Interest Group SoC System on a chip SRC Source
TTL Time To Live TX Transmit
UART Universal Asynchronous Receiever/Transmitter USB Universal Serial Bus
UUID Universally Unique Identi- fier
Chapter 1 Introduction
1.1 Background
For many years Bluetooth have been the go to standard for One to one (1:1) communication between devices. Since the introduction of Blue- tooth in 1999 multiple improvements have been implemented. One of the larger improvements in regards to power consumption came in 2010 with the introduction of Bluetooth low energy, drastically lowering the power consumption while used in application with occasional need to send small packets of data [1, 2]. Multiple attempts at creating a mesh network over Bluetooth were made but no standardized protocol for Bluetooth mesh existed. That changed in July 2017 when Bluetooth Special Inter- est Group (SIG) introduced mesh topology for Bluetooth Low Energy (BLE) enabling Many to many (m:m) communication in the Bluetooth standard [3]. BLE mesh is mostly aimed at sensor data and lightning applications which utilizes small data packets sent intermittently [4].
Digital Multiplex (DMX) is a protocol used mostly for stage lightning and effects. The standard dates back to 1986 and was introduced to solve the problem with each manufacture using their own proprietary protocol.
Its electrical characheristics are based on TIA/EIA-485 standard, which is a balanced, rugged transmission line making it commonly used as the physical layer in industry communication [5, 6]. The DMX protocol was intended for dimmers when it was introduced but due to its adaptable nature it is now used in multiple different scenarios, both in architectural lightning as well as nightclubs, concerts and stage effects. The details on DMX will be more thoroughly presented in section 2.5.
Currently most solutions for wireless DMX on the market are either based on proprietary protocols, is based on 1:1 communication or require a base station. In certain applications, for example mobile architectural
1
2 CHAPTER 1. INTRODUCTION
lightning where latency is not an important factor a BLE mesh solution that is focused on low power could be beneficial. This would provide a scalable, low cost system where the wireless area could be large as long as the nodes are close enough to each other. This could be utilized as a system where a large area without existing infrastructure with multiple lightning fixtures could be controlled through a Bluetooth mesh enabled device.
1.1.1 Company background
The thesis will be performed at Tritech Technology AB1 which is a con- sulting firm specialized in embedded systems and Internet of Things (IoT) both regarding hardware and software.
1.2 Purpose and goals
Since BLE mesh is relatively new few implementations have been re- searched and most are aimed at sending sensor data and controlling smart lightning. These devices are designed from the start to work for the data loads and profiles in the Bluetooth protocol. If legacy protocols, such as DMX could be implemented on BLE mesh new possibilities would open up to enable older hardware to be implemented with low-cost and low- power together with the current array of Bluetooth enabled devices.
The goal of this thesis is therefore an implementation of a Bluetooth transceiver, a microcontroller for DMX-conversion and a female DMX- connector. Since BLE mesh is bidirectional the nodes could return data of their power state as well as warnings if one bluetooth node senses power loss in the fixtures it is connected to. With this implementation together with the background study a evaluation of DMX over BLE mesh will be evaluated.
The following research questions have been formed:
• RQ1: Could BLE mesh be viable for transferring data related to an older protocol, such as DMX512? Why/why not?
• RQ2: What compromises could be made to improve the perfor- mance in regards to latency and power consumption of DMX over
1http://www.tritech.se/
1.3. TASK AND DELIMITATIONS 3
BLE mesh?
1.3 Task and delimitations
1.3.1 Tasks
The scope of this project will mostly be aimed towards latency and power consumption of a BLE mesh enabled DMX transmitting node, however a few different other considerations will be made, such as adaptability to existing networks and viability of the concept of DMX over BLE mesh.
The tasks of this thesis are therefore first to perform a theory study on regular BLE, BLE mesh and DMX. The studied theory will be used to implement wireless DMX over BLE mesh together with transmitting DMX from the receiving node to a lightning fixture via cable. The per- formance of the transfer will be studied and discussed if BLE mesh is viable for transferring DMX data.
1.3.2 Delimitations
The following limitations had to be made and will not be included in the project.
• Bluetooth classic research other than small background study
• Testing using other competing technologies such as Thread [7] or ZigBee [8]
• Development of hardware or a finished product
• Development or investigation into proprietary Bluetooth mesh so- lutions
• Investigate the most power effecient wired DMX-transfer
1.4 Method
The thesis will commence with a planning phase to set up a clear work structure and timeplan. The next phase is research aimed at gaining knowledge regarding Bluetooth low energy and BLE mesh. A custom Bluetooth model will be created during the implementation phase. The implementation will be on multiple BLE mesh development kit acting as nodes in the network. These nodes will send the data between each other,
4 CHAPTER 1. INTRODUCTION
in different setups to evaluate the performance in different scenarios. A conversion to wired DMX will implemented on the receiving node. This setup will be tested and evaluated based on range, power consumption and latency. The test results will be analyzed and discussed to try to answer the given research questions.
1.5 Disposition
This chapter includes the introduction of the project together with its purpose. The following chapter will go more in depth with the back- ground theory, both regarding DMX and BLE mesh as well as a brief overview of Bluetooth classic. Chapter 3 will be the implementation part discussing how the mesh network are realized on the development kits. Chapter 4 will be about the measured results and these will be discussed in chapter 5.
Chapter 2
Background theory
This section will give a begin with a brief overview over Bluetooth basics, then give an insight in to BLE, BLE mesh and the DMX protocol. It will also evaluate the different hardware choices and give details regarding these.
2.1 Bluetooth overview
Bluetooth was standardized by the SIG with the first version - Bluetooth 1.0 formally announced in May 1998 from a joint effort of Intel, Erics- son and Nokia. It is named after the Danish king Harald Bl˚atand(eng.
Bluetooth), the name refers to his success in uniting Scandinavia. The same way Bluetooth were meant to unite and standardize short range wireless technologies [9]. One suggested name before Bluetooth were es- tablished as the official name was Personal Area Network (PAN). This name describes the function of Bluetooth well as a network established in a small area by the device itself. Blutooth operates in the license free 2.4GHz Industrial, Scientific and Medical (ISM) frequency band. The ra- dio bands are specified by Federal Communications Commission (FCC).
It consists of 79 bands, each 1MHz wide between 2402MHz and 2480MHz.
It is called the 2.45GHz band which is a heavily populated radio band where Wi-Fi and many other proprietary wireless solutions operate [10, p. 172]. To overcome this congestion it uses Frequency-hopping spread spectrum (FHSS), which means that Bluetooth can change the frequency band up to 1600 times per second [11]. FHSS both help with congestion but increases the security as well since only the connected device have the hopping schedule. Bluetooth were originally used for communicat- ing with peripherals such as headphones or keyboards where continuous streaming of data is used. In 2010 BLE was introduced as a subset in
5
6 CHAPTER 2. BACKGROUND THEORY
Bluetooth 4.0 which divided Bluetooth in to two classes, BLE and Basic Rate (BR)/Enhanced Data Rate (EDR).
Bluetooth BR/EDR, or Bluetooth classic is used for continuous con- nection. It supports data rate 1Megabit per second (Mb/s) for basic rate and up to 3Mb/s for EDR. It uses all 79 available channels for transmis- sion but can skip certain frequencies where interference exist [11, p. 181-].
BLE, formerly known as Bluetooth smart support data rate up to 1Mb/s but 500kb/s or 125kb/s when error correction is used. It is mostly aimed at sensor data or implementations which sends small data packages in- termittently. BLE uses 40channels, each 2MHz wide, where 3 of these is used as beaconing/advertising channels introduced with BLE [11, p. 183- ].
Bluetooth classic modules are not forward compatible with the newer Bluetooth Low Energy (LE). This means that a Bluetooth chip sup- porting Bluetooth classic can not communicate over BLE. There exist however transceivers that supports both BR/EDR and LE are these are called dual mode transceivers [12].
2.2 BLE architecture
The BLE architecture consist of different layers. Data is traveled through the stack from the application layer down to the physical layer for sending data from an application and vice versa for receiving data. BLE 1:1 and BLE mesh shares the same application and controller layers, the host layer is specific to BLE 1:1 and will therefore just be mentioned briefly in this thesis. The architecture of the Bluetooth stack is shown in Figure 2.1 [13].
2.2. BLE ARCHITECTURE 7
Figure 2.1: Bluetooth low energy architecture
2.2.1 Physical Layer
The Physical Layer (PHY) is the part that are responsible for transmit- ting and receiving the bits over the 2.4GHz radio. It uses the modulation technique Gaussian Frequency Shift Keying (GFSK) described later in this section as well as Adaptive Frequency Hopping (AFH), described in section 2.2.3. BLE uses 40 frequency channels spaced between 2400GHz to 2480GHz, shown in Figure 2.2. 3 of these channels are advertising channels while 37 are data channels. The advertising channels are placed in their respective frequency to minimize overlapping with 802.11/Wi-Fi bands [14]. The data channels are used for connected transmission, while the advertising channels are used for non-connected transmission.
Figure 2.2: Bluetooth low energy frequency bands
8 CHAPTER 2. BACKGROUND THEORY
Gaussian Frequency Shift Keying
GFSK is based in Frequency Shift Keying (FSK) which is a modulation technique where the carrier frequency wc are altered to represent either a binary zero or binary one bit. By increasing the frequency compared to to wc the signal is interpreted as a binary one and by decreasing it it is interpreted as a binary zero [15]. For example a signal transmitted on the 2404GHz band with a frequency deviation fd = 0.1575 a frequency of f = 2403.8425 would be regarded as a binary zero and a frequency of f = 2404.1575 would be regarded as a binary one [16] .The Gaussian part of GFSK is due to a Gaussian filter is beeing applied to the FSK.
2.2.2 Direct Test Mode
Most other wireless standards have no built in method to test the PHY, this results in that manufacturers have to implement their own pro- prietary testing solutions. This can cause incompatibility issues while switching silicon suppliers and harder to compare different PHYs. The method BLE uses is the Direct Test Mode (DTM) implemented in the BLE stack. The DTM allows all BLE device testers to use the same test method, these include sending and receiving test packets and could be used both for quality testing as well as testing the radio for tweaking [13].
2.2.3 Link Layer
A BLE node can be both bidirectional and unidirectional. Unidirectional nodes can only send data one way and bidirectional can both send and receive data. For unidirectional data the master transmits on the ad- vertising channels, while for bidirectional the nodes discovers each other through the advertising channels before they connect through the data channels [17]. The Link Layer (LL) consists of a state machine with five states, shown in Figure 2.3.
2.2. BLE ARCHITECTURE 9
Figure 2.3: Link layer state machine
Standby state is the idle mode used when the host have nothing to re- ceive or transmit, can be exited or entered by request from the host layer.
One of the reason BLE can be optimized for lower power consumption is enabling higher percent of the standby state.
Advertising state is the state used for transmitting advertising packets as well as responding to other devices scan requests. From this state it can either go to the standby state or as a slave to the connection state if another device have sent a connection request. This mode is also used while the device is used as a beacon.
Scanning state can be divided in to two states, active and passive:
• Passive scanning
Used for passively listening to other devices advertisements.
• Active scanning
The active addition is used for sending scan requests to the adver- tiser to request additional data [18].
Initiating state is the state where the device listens for the advertise- ments from the device it attempt to connect to, if it is found it will send a connect request and if successful it will change to connection state as the master.
Connection state is after a successful connection, either as a master or slave it it is in connection state. Even in connected state the slave can sleep to conserve energy, but the master is required to send packets at certain intervals to remain connected.
10 CHAPTER 2. BACKGROUND THEORY
Adaptive Frequency hopping
As mentioned the ISM frequency band are congested with multiple dif- ferent protocol using it. To deal with this Bluetooth LE uses AFH. The frequency hopping which is part of the PHY layer decides next frequency in the following manner:
fn+1 = (fn+ hop)mod37 (2.1) where hop is a variable in the range 5-16 exchanged between the devices when connecting [19]. The adaptive part of AFH is a part of the LL mapping which frequencies are being congested to avoid these. A channel map is created with bits indicating whether or not that channel is used or not. If Equation (2.1) selected a used channel the LL remaps this channel to an unused channel. The channel map is shared between connected devices [20].
2.2.4 Host Controller Interface (HCI)
The HCI interfaces the host and the controller layer of the Bluetooth stack. The benefits of having a standardized interface between the host and controller is that it is possible to develop these parts individual, for example a controller from on a USB-dongle one manufacturer could be connected to a PC from another manufacturer running the application and host layers [21, p. 62]. This connection could be made with Univer- sal Asynchronous Receiever/Transmitter (UART), Universal Serial Bus (USB) or Secure Digital Input Output (SDIO) [22]. The host and con- troller could both be implemented on different microcontroller as well as being on a single chip.
2.2.5 Logical Link Control and Adaptation Protocol (L2CAP)
L2CAP have two main responsibilities. Multiplexing of channels as well as segmentation and reassembly of packets larger than the lower layer can handle [23].
• Multiplexing of channels
Since the upper layer can consist of multiple controllers the L2CAP handles the multiplexing of these different protocols for the HCI.
• Segmentation and reassembly of packets
L2CAP is also responsible for segmentation packets when trans- mitting and reassemble while receiving. The reason why a packet
2.2. BLE ARCHITECTURE 11
is segmented could be because of a payload is to large for the radio or latency specification requires segmentation.
2.2.6 Security Manager
The security manager handles pairing, authentication and encryption of data transfers. When devices are pairing the first step is a pairing request is transmitted from the master, the slave responds with a pair- ing response. Next step is to generate an encyption key which is being distributed between the devices which will encrypt the data transferred between the devices. The pairing depends also depends on the Input Output (IO) capabilites of the device. The different capabilities could consist of buttons for ’yes’ or ’no’, keyboard for entering numeric value or a device without IO capabilities [24].
2.2.7 Attribute Protocol (ATT)
ATT is a protocol used for communication of attributes between a client and server. Attributes are pieces of data containing a attribute handler of 2 octets, attribute type of 2 to 16 octets and an attribute value of 0 to 512 octets. The attribute type refer to a specific entity, for example a temperature sensor. Attribute type refer to the different types of data, this can include Boolean, temperatures, states etc. The attribute type is identified by a 128 bit Universally Unique Identifier (UUID). ATT consists of six different operations:
• Request: Client sends a request to a server and requesting attribute from the server.
• Response: Sent as response from the server to the client after it have received an request.
• Command: Sending attribute command from the client to the server.
• Indication: Sent from the server to the client about a attribute value.
• Confirmation: Sent from client to server as response to the indica- tion.
• Notification: Sent from server to client notifying about a specific attribute value, similar to indication without requiring a confirma- tion [13].
12 CHAPTER 2. BACKGROUND THEORY
2.2.8 Generic Attribute Profile (GATT)
The GATT sets up the defined attributes into structures. It introduces a hierarchy of attributes. This hierarchy is due to easily address the correct attribute, for example if a device contains temperature sensor as well as a battery. The battery could itself contain a temperature sensor so when requesting the temperature there are two temperature available.
The battery’s temperature sensor is placed under the battery service in the hierarchy and is therefore not addressed when the devices top level temperature are requested [13]. The top level of the hierarchy is called the Profile. The profile contains one or multiple services which in turn contains characteristics. The characteristics contains an UUID indicating the type, a value and can also include descriptors describing things such as valid range, data format etc [25]. Another type of hiearchy is primary and seconday services. In the above example the device temperature sensor would be a primary service. The battery service would also be a primary service including a secondary servery for the battery temperature sensor [26].
2.2.9 Generic Access Profile (GAP)
GAP handles the connection between devices, such as visibility, discovery, connection and advertise information about the device. The GAP could be split up as a state machine such as in Figure 2.4. GAP also handles privacy and can broadcast privately by constantly changing addresses which only can be seen by trusted devices knowing how to resolve the address [13]. Other features for the GAP is setting up the connection interval, slave latency to give the slave the ability to skip some connection attempts, and supervision time-out which defines how often the devices need to connect before the connection are terminated [27].
Figure 2.4: GAP state
2.2. BLE ARCHITECTURE 13
2.2.10 Application layer
The application layer is the software side often seen by the end user.
It can be divided in to two different types of devices, central and pe- ripheral. The central device is the main device for the user containing more processing power and a user interface, typically a computer or a phone. The peripheral is a device often designed to perform a single, lighter task, such as a sensor reading and transmitting a temperature and optimized for being energy efficient. This optimization can be done in multiple different ways but the most important aspect is the use of different connection modes described later in this section. The first task for the central device is to scan for peripheral, this can be done by using either active or passive scanning, described in section 2.2.3. The infor- mation aquired during the scanning can include the name of the device as well as the device UUID. A quick connection can be made to the de- vice to aquire more information. Additionally, if the peripheral device includes the Transmit (TX) power in the advertisement the path loss can be calculated using the following equation:
∆D = P − RSSI (2.2)
where P is the TX-power and ∆D is the path loss which often translates to the distance to the device. This information can be used as a help to determine which is the desired device to connect. The next step for the central and peripheral device can take different directions, the peripheral are discovered by the central and connections is made or the peripheral is broadcasting data that the central is listening to.
2.2.11 Packet format
The packet format have variations depending on which Bluetooth version is regarded, the following format in Figure 2.5 is based on Bluetooth 4.2.
Figure 2.5: Packet format of Bluetooth 4.2
14 CHAPTER 2. BACKGROUND THEORY
• Preamble Consist of alternating 1’s and 0’s. This is used for automatic setting up the gain as well as synchronizing the frequency [28].
• Access Adress Since the preamble alternating sequence can occur due to white noise the access adress is to make sure that the received bits are a legit transfer. On a data channel the access adress changes each connection and on the advertising channels the access adress is a fixed value [13].
• Protocol Data Unit (PDU)
– Header contains a few different fields, these are informations such as a sequence (SEQ) number used to remove the risk of processing incoming packets that are retransmissions, one field indicating whether the transmitter have more data to transmit and if the connection should remain active. The header also includes the next expected sequence bit, which indicates what the next sequence number should be and used for an additional verification that the received data packet is not a retransmission [13].
– Payload the desired data transmitted between the devices, it is encrypted via Autenticated Encryption Algorithm (AES) by using the encryption key.
– Message Integrity Check (MIC) is used for security and is a value generated during the encryption of the payload data.
The MIC is used to verify that the payload received is from the actual desired sender [29].
• Cyclic Redundancy Check (CRC) is a value calculated based on the packet and used to see that the received packet is correct have not changed during the airtime.
2.3 BLE mesh architecture
Bluetooth mesh (or Bluetooth mesh networking) is a protocol based upon BLE that allows for many-to-many communication over Bluetooth radio.
It was adopted on July 13, 2017. It is a flood network in which the mes- sages are relayed using a flooding technique instead a routing technique.
The BLE mesh stack uses the core from regular BLE described in sec- tion 2.2 with the same LL and PHY while changes the middle layer as is shown in Figure 2.6.
2.3. BLE MESH ARCHITECTURE 15
Figure 2.6: BLE mesh architecture next to grayed out BLE architecture
2.3.1 Bearer layer
The bearer layer defines two different types, Advertising (ADV) bearers and GATT bearers. GATT bearers are implemented in proxy nodes and used for communicating with devices not supporting ADV bearer used withing the mesh network. GATT is described in section 2.2.8.
ADV bearer are used within the mesh network and utilizes the GAP advertising and scanning function for sending and receiving PDUs [30].
2.3.2 Network layer
Defines which network interface to be used such for a specific data packet for example in a proxy node which support both ADV and GATT. It also defines whether or not incoming messages should be delivered to the network layer, used for relay nodes [30].
Addresses
in BLE mesh each device uses an UUID which it is given in the provi- sioning process used for unicast messages. It can also receive a group address used for messages intended for multiple nodes.
2.3.3 Transport layer
The transport layer consist of the upper- and lower transport layer. The lower layer handles segmentation of outgoing messages and reassembly
16 CHAPTER 2. BACKGROUND THEORY
in incoming messages if the payload of the packets are to large, for BLE mesh the largest payload it can handle is 12 bytes [31]. In section 2.4.4 a more in-depth view on segmentation and reassembly will be presented.
The upper handles decryption, encryption and authentication of data as well as handles messages such as heartbeats, described in section 2.4 [30].
2.3.4 Access layer
The access layer sits between the technical layers and the application lay- ers and formats the data, controlling which encrypton/decryption pro- cess to use as well as verify the incoming data from the transport layer is correct [30].
2.3.5 Mesh models
The mesh stack consist of two types the model layer and the founda- tion model layer. The model layer is responsible for implementing the models, described in depth in section 2.4.5 while the foundation model layer implement said models but with regards to the configuration and management of the mesh network [30].
2.3.6 Provisioning
Provisioning is when new nodes are added to the network and can there- fore skip the layers related to data packets, provisioning is described in-depth in section 2.4.1.
2.3.7 Topology & nodes
BLE uses a managed flooding scheme. The flooding part means that all relay nodes will relay all messages it have received. The managed part is adding some exceptions explained in section 2.4.2 when messages will not be relayed, such as a message Time To Live (TTL). The benefits of using managed flooding instead of other routing scheme is mostly two reasons: while other routing schemes can be self healing after one node is lost, a flooding scheme will not have to recalculate a new path since the flooding can loose one node and will not be affected as long as another node is in reach to relay the message. The second reasons is the simplic- ity of a flooding scheme which minimizes the need of processing power in the nodes for path calculation as well as conserving energy needed for this calculations.
2.3. BLE MESH ARCHITECTURE 17
BLE mesh topology consist of 5 different types of nodes. In Figure 2.7 node H is configured as a proxy node, which function as a gateway be- tween GATT-enabled devices and the mesh BLE network. M,N and P are relays which relays the message received forward. L and O are friend nodes storing data for the low power node (LPN) K, R, F and G which only connects to their friend when needed to conserve radio duty cycle.
The rest of the nodes are configured as clients, Each node type described in detail below.
Figure 2.7: Bluetooth Energy mesh topology
• Low-Power node(LPN)
Battery constrained devices can be implemented as a LPN. This means that they only receive or transmit data at specific intervals and are not required to constantly scan the network for advertise- ments. Low-Power nodes are implemented with a friend node. This results in a node that can sleep long time and have close to 0% duty cycle. A LPN can be a transceiver but could also, for economically reasons be just a transmitter, in the case of temperature sensor or receiver in the case for a lamp without state feedback.
• Friend node
A friend node is implemented together with a low-power node. The friend node saves data aimed for the low-power node and relays the data to the LPN when that node wake up.
18 CHAPTER 2. BACKGROUND THEORY
• Relay node
Relay nodes are the nodes constantly scanning and advertising in the network relaying messages. It is often non power constraint.
• Proxy node
Proxy nodes are the gateways between a GATT-enabled device, such as a smartphone and the mesh network. Therefore it acts as a relay node, but with the exception of having multiple bearer protocols implemented.
2.3.8 Publish-subscribe
BLE mesh uses a publish and subscribe relationship. The nodes that have messages to submit are in the publish phase while nodes can subscribe to messages. The nodes can subscribe through their unicast address, a group address or a virtual address. The unicast address is the address for a specific node and used when the publisher is addressing a single node.
This unicast address is given to the node during the provisioning process.
The group addresses are divided in to two different types, Bluetooth SIG group addresses and user configured groups. The Bluetooth SIG group addresses includes groups such as all friends, all nodes etc while the user configure groups are application defined groups. Groups are used for addressing multiple nodes with the same message, such as reading the temperature of all temperature sensor in one room, where the rooms sensors are a user defined group. One node can subsribe to multiple groups, for example if a temperature sensor is in a door opening and is included in two room groups. Virtual addresses are less strict defined where it can include both a single node as well as a group of nodes.
2.4 BLE mesh operation
The BLE mesh operation always starts with the nodes being provisioned in to the network. This section will begin to describe how the provisioning occurs. Next it will go in to the timing schedule and congestion control, which is a important part in a mesh network to prevent packets from colliding. The chapter will go on to describe the mesh packet format and continue in to mesh models and elements. The latter are important to understand when developing applications since these determine how the nodes interpret the received data. The chapter will end with the mesh networks performance and network size.
2.4. BLE MESH OPERATION 19
2.4.1 Provisioning
Provisioning is the act of adding new devices to the mesh network. Each network need to include atleast one device implemented as a provisioner, but multiple devices can have the role as a provisioner. Two different types of provisioning exist, PB-ADV and PB-GATT. The former is the primary method used if supported, while PB-GATT is used for proxy nodes to provision external devices. The provisioning of a device is a five step process:
Beaconing
Beaconing stage is used for discovering non-provisioned devices. The PB-ADV transmits a beacon with a specific data format indicating its intention of being provisioned in the network. The provisioner scans the advertisement channels to locate the beacon from the non-provisioned devices.
Invitation
When a provisioner discovers a non-provisioned device beaconing the provisioner transmits a invitation PDU. The non-provisioned device re- sponds with its capabilites PDU. This PDU include number of supported elements, the security algorithm supported, the capabilities of inputting and outputting values between device and user, as well as the availability to exchange the devices public key via a Out Of Band (OOB) method.
OOB means a method not related to Bluetooth, these can include Near Field Communication (NFC), Quick Response (QR)-code or another ra- dio protocol.
Exchanging public keys
This step starts with the provisioner sends out an Start provisioning PDU. The PDU declares the method of exchanging the public keys, based on the information regarding OOB. If the non-provisioned device are missing a OOB method the public key are sent to the provisioner. If OOB method exists the provisioner read the public key through the OOB.
When both public keys are known the non-provisioned device and the provisioner calculates an key for encrypting and decryption the data.
This method is called asymmetric cryptography and is computationally expensive and therefore only used for exchanging a secret key. With the secret key a symmetric cryptography can be used, which is the AES-128
20 CHAPTER 2. BACKGROUND THEORY
algorithm. The later is used for the regular BLE mesh transmission after the devices are provisioned and the secret key have been exchanged [32].
Authentication
The authentication process can be done in three different ways depending on the features of the node, shown in Figure 2.8. Input OOB and output OOB is similar in that way that the user inputs a generated number in either the provisioner or the un provisioned device. With input OOB the un provisioned node generates and displays a number while the user inputs on the provisioner and vice versa for output OOB. The way that the generated number are displayed is different depending on capabilites of the node or provisioner. This could be a Light Emitting Diode (LED) blinking number of times, a sound played a number of times or a display showing the number. If the node does not have any OOB capabilities a static number could be used or no OOB where both node and provisioner generates a random number. Using these random number a confirmation number is calculated and sent between the devices. After this the ran- dom number is sent and the confirmation number is recalculated and the calculated value are compared with the previously received value. If the values match the provisioning process enters the next stage, otherwise it is canceled [33].
Figure 2.8: The three different authentication procedures [34, p.254-]
Distribution of Provisioning Data
The node and provisioner calculates a session key used to encrypt the distribution of provisioning data. With this encryption key the provision- ing data is sent which includes the network key and device key. Network
2.4. BLE MESH OPERATION 21
key is a global key used for the whole network and is what signals that a node belong to a network [33].
2.4.2 Timing schedule and congestion control
Since mesh is using managed flooding a lot of packets will travel within the network that is not related to the current nodes. These can both include networks where certain data only need to travel a short distance and should be limited in travel length, as well as nodes receiving pack- ets that the node already have relayed. To control these problems BLE mesh uses a few methods, a timing schedule to divide up transmit times, a decrementing hop count and a sequence number to keep track of seen messages.
Together with the payload the packet sent also includes a TTL. The TTL is a integer between 0 and 127 and indicates how many times the packet can be retransmitted by a relay node. A packet with a TTL set to 3 will be relayed 3 times before it is cancelled. By each hop the TTL is decreased by one. The TTL is implemented to limit the number of retransmission to decrease radio congestion and should be optimized in the application for the desired function. One extra functionality of TTL is the ability to determine if a node is a single radio link away. If the TTL is set to 1 it indicates that it may have been delayed but will not be relayed and therefore a node will never receive a relayed message with TTL of 0. A TTL set to 0 while transmitting have the same functionality that it will not be relayed, but it also indicates that the message have not been relayed before and have been set to 0 during the last transmis- sion, meaning that the transmitting node is within direct radio contact [34, p.44-]. If the packet with a unicast destination address reaches a node that contains the element with that address the message will not be relayed even if it has a TTL higher than 1. The TTL can either be specified while implementing the software and be optimized for the spe- cific application, but it can also be automatically decided by using the method described in section 2.4.6.
The network layer includes a SEQ field in the PDU, this is a 24-bit value.
For each transmit from the node it increases the SEQ number. When the SEQ-field is reaching the maximum value it increases the Initializa- tion Vector (IV) index, which is a 32-bit value shared across the whole network. Since the SEQ value is personal for each node it is enought that one node is closing in on the maximum SEQ value for the whole
22 CHAPTER 2. BACKGROUND THEORY
networks IV index to be updated. If a node received a packet with equal or lower number it discards the message and relays nodes will not relay those messages. This prevents messages from coming back to nodes that have already relayed the specific message. The recently seen messages are stored in a network message cache existing on each node. The size of the cache can vary depending on the requirement of the network as well as the memory size of the node and is a choice the software developer have to do during implementation. The only requirement of the cache is keeping track of already relayed message which means it can choose to only cache the certain values such as NetMIC, Source (SRC), SEQ or some other choice of data. The use of a network cache is implemented not only to limit congestion of excessive relaying but also to conserve energy when eliminating unnecessary processing of already seen packets since they can be discarded before they have reached the security and decryption steps [34, p.105-].
A delay is introduced between each packet to minimize congestion of messages in the network, this delay is minimum 20ms, but could be higher as well. These value have to be decided when implementing a ap- plication. All the relay nodes have a delay as well, this value is minimum 10ms. This results in a single packet with 3 hops would theoretical take a minimum of
3hops ∗ 10ms per hop = 30ms (2.3) to reach the receiver if the transmitting time is neglected. A packet segmented in to two messages transmitted over 3 hops would take a minimum of:
20ms transmitting delay + 3 ∗ 10ms per node = 50ms (2.4) to be received.
Since all wireless solutions have an inherent packet loss in the airtime each packet can be retransmitted in the relay nodes to ensure that the message reaches the intended receiver. This retransmission is done at a minimum of 10ms plus a random delay between 0 and 10ms and a usual number of retransmissions are 3 times but could be between 0 and 7 times. These values are chosen in the implementation step. One other important factor for congestion is the choice of number of relays. If the number of relays are to large the network will run in to congestion problems which increases the latency [31].
2.4. BLE MESH OPERATION 23
2.4.3 Mesh packet format
This section will describe the mesh packet. The packet at network layer is shown in Figure 2.9. Each segment in the packet will be described below.
Figure 2.9: NetworkPDU of BLE mesh
The SEQ number and IV index are described more in depth in section 2.4.2. Since the IV index in the data is a single bit while the complete IV index is a 32bit number the data packet IV field only indicate whether the full 32bit number should be incremented or not. The Network control message indication (CTL) field indicate whether the message is a control message, such as heartbeat or friend request, i.e. the message used for control of the network and not for sending data or a access message such as setting a state. This will result in different sizes of the NetMIC, 32bit for a access message and 64bit for a control message. The TTL is a value indicating the number of future relays a message should do, described in depth in section 2.4.2. The SRC adress is a unicast address from where the message originated. The Destination (DST) address is the intended receiver of the message and could either be a unicast address, a group address or a virtual address. The packet payload, or transportPDU contains all the message data, which is the opcode for the desired model, parameters and the transMIC. The NetMIC is a value similar to the MIC in regular 1:1 Bluetooth LE described in section 2.2.11 and used for authenticating that the received packet have not been changed in airtime [34, p.45- & p.94-].
2.4.4 Segmentation and Reassembly (SAR)
The largest message that can be delivered in a BLE mesh packet are 15 bytes in the upper transport layer including the transMIC, leaving 8-10 bytes to parameters after the opcode, but messages between nodes can still contain a message size of up to 384 bytes including the transMIC.
This is done by segmentation of the payload in the sending node and a reassembly in the receiving node. If the segmented message are sent to a unicast address the transmitter are waiting for a acknowledgment packet for each segment. If no acknowledgment have been received within the segment acknowledgment timer, shown in Equation (2.5) the packets are
24 CHAPTER 2. BACKGROUND THEORY
re-transmitted.
timeout = 200ms + 50ms ∗ T T L (2.5) When sending to a group address no acknowledgment are used and are therefore prone to dropped packets and it is recommended to resend all packets to ensure successful transmission. When the packets are seg- mented a sequence header are added to each packet to keep track of the order and used when reassembling the packet. The sequence header con- sist of 4 bytes which is the same size as the transMIC and therefore no extra overhead is used when segmenting messages since the transMIC is not added to every segmented message [34, p.21- & p.54-].
2.4.5 Mesh models & elements
One of the most important aspect of developing BLE mesh applications is the understanding of mesh models and elements. In Figure 2.10 a mesh device with three elements is shows. Each element includes either one or multiple models. One example of this could be a smart light bulb containing a light sensor as well as a temperature sensor,each of these being there own element. To refer to Figure 2.10 [35]. the heading mesh device could in this example be Smart light bulb, element 1 could be the light itself, element 2 could be the light sensor and element 3 could be a room sensor. Each model includes the functionality in the nodes, element 1 could include a model indicating the light OnOff state, one model indicating the lightness and one model could be an internal temperature sensor in the light. Element 2 is the light sensor and the states refers to the value of the light sensor. Element 3 is the room sensor and could include one model referring to the temperature and one model referring to the humidity. Each element have a unique address.
Since both element 1 and element 3 contains a temperature model the application need to address this unique element address which contains the desired temperature model.
2.4. BLE MESH OPERATION 25
Figure 2.10: Mesh device element and model description
When two mesh devices communicates with each other they are doing it via sending messages between models. The messages can be of two types, get, set or status. To understand when these are used the different model types that exist need to be introduced:
• Server model contains the states, behavior and messages that is implemented. Behavior explains what will happen when the node changes state, for example turn on the light bulb after the light bulb OnOff model have changed the state to On after receiving a SET message from the client.
• Client model does not implement any states but uses SET, GET and STATUS messages to communicate with the server model of another device.
• Control model contains both a server and a client.
In addition to independent states there also exist bound states and com- posite states. Bound states are states that depend on each other and
26 CHAPTER 2. BACKGROUND THEORY
when one states changes the other state changes as well. These can in- clude a power level and a on-off state where when the on-off state switches to off the power level should switch to 0. Composite state are similar to bounded state but are a group of states that together can make up an- other state, for example the Light Hue, Saturation, Lightness (HSL) state consist of the Light saturation, Light Hue and Light lightness states. In Figure 2.10 it can be seen that every model includes a subscriptions list.
This subscription list includes the addresses to the related other models, such as bounded models. If a model A subscribe to model B, another model C subscribing to model A it results in model C also subscribing to model C. When a state change message is sent to a server a state transition time is also used, indicating how fast the state should change after the message is received. This could be used to synchronize nodes or used for fade between two values, for example in a light bulb where a gradual change is more pleasant.
There are two subtypes of models, both Bluetooth SIG adopted mod- els, called SIG models as well as vendor specific models. The vendor specific models can be created for a specific application when none of the SIG models are suitable but they then need to be included in all the devices that are utilizing it. The SIG models on the other hand are imple- mented on all Bluetooth certified devices. Each model have a UUID, the Bluetooth SIG adopted models are 16bit and the vendor specific models are 32bit. These UUID is called the opcode, and is included in the mes- sage. This results in the vendor models additional byte in the opcode lowers the max message parameter by one byte. The opcodes for the Bluetooth SIG models are specified in the Model specification released by Bluetooth SIG. The vendor specific opcodes of are based on the com- pany Identifier (ID) aquired by Bluetooth SIG to each verified developer for Bluetooth equipment. The full opcode for a vendor-specific is 1 byte company identifier, 1 byte server ID and 1 byte client ID. The special opcodes with only 1 byte are for special messages, such as heartbeats described in section 2.4.6.
2.4.6 Heartbeat
Heartbeat are messages sent out periodically by the nodes and have two main objects, keeping the network active and analyzing the status of the network. Since a node need to be re provisioned after it have been offline from the network for more than 48hours. One of the reasons for heartbeats are to indicate to the network and provisioner that it is still
2.4. BLE MESH OPERATION 27
active. Another reason for the heartbeats mesages are to configure the network. In section 2.4.2 TTL are described as something that could be set up by the user, but the network could also dynamically set the TTL.
This would be done by setting a initial TTL in the heartbeat message and including this TTL as the parameter in the message. The node receiving the message could then calculate the difference between the current TTL and the initiall TTL included in the parameters. This difference refers to the number of hops between sender and receiver and the node could adjust their TTL in the next transfer to that node to limit the number of unnecessary relays. If the number of heartbeats the transmitting nodes are sending are known the health of the network can also be analyzed by counting the number of received heartbeats and comparing with the expected number to get a ratio of successful messages. The heartbeat message also includes a field indicating their node type, i.e. Low-Power, Friend etc.
2.4.7 Performance and network size
The performance of BLE mesh could be hard to evaluate since the number of hops are having a signiciant performance impact. Due to interferance and other external factors the number of hops in a network with station- ary nodes could still change without the change of nodes or transmitting power. One other important factor is the message size and whether SAR have to be used or not. Since the packets require a wait time between transfers the difference between having to send two or many could be significant. The minimum delay between packet transfers are 20 mil- liseconds. A example of a vendor-specific message with parameters of 256bytes would be segmented in to:
256bytes payload + 3bytes opcode + 4bytes transM IC
12bytes per packet ≈ 22messages
(2.6) 22 messages of maximum size would result in number of bytes required to be sent is:
22messages ∗ 32bytes per message = 704bytes (2.7) With a transfer speed of 1Mbps the transfer itself would take ≈ 5ms which can be neglected compared to the delay minimum delay between packets which would equal to 20ms ∗ 22 = 440ms. This is only the low- est theoretical transfer time between two neighboring nodes, in a real
28 CHAPTER 2. BACKGROUND THEORY
world application where interference and other factors present this num- ber would most likely increase. This also assumes that the message are sent to a group address without the need for acknowledgment or retrans- mits.
Since the TTL are a 7 bit number the maximum number of hops are 127, with a theoretical distance of 10m for transmission between nodes the maximum distance for a BLE mesh network is 1.27 km. The maxi- mum amount of unicast addresses are 32,767 and since these refer to each element this is also the maximum amount of nodes if each node includes one element.
2.5 DMX
2.5.1 DMX512 overview
DMX512 is based on EIA-485, which is a electrical standard utilized in many application but DMX adds some extra demands not specified in the EIA-485 standard, such as isolation and connector type [36]. DMX512 utilizes 512 channels where each channel is 8 bit and can represent a value from 0 to 255. In a dimmer 0 would translate to 0% and 255 to 100%. Later the same protocol was used all kinds of fixtures and not only dimmmers. This could mean that channels could be mapped to different colors or different effect, for example pan and tilt in a moving head [37]. Since the data is based on channels each fixture can interpret this data in different ways and to control a fixture the operator therefore need the information how which channels control which effects. Since the data could be utilized for different tasks this also means that fixture requiring higher resolution than 8 bit could use two channels to acquire a 16bit resolution. DMX devices are connected in a chain with a single cable going between devices. DMX connector consists of 5 pins, which are used as Data 1+, Data 1- and ground and is called XLR5. This connector is shown in Figure (2.11) [38]. The other two pins are often left unused while they could be used as a extra data link with Data 2+
and Data 2-. Using the extra datalink is uncommon and this leads to that the connector XLR3, with 3 pins is sometimes used. The use of XLR3 connector is prohibited in the DMX specification.
2.5. DMX 29
Figure 2.11: 5-pin DMX connector
2.5.2 DMX signal
DMX is sent balanced, asynchronous,half duplex serial over two wires.
Balanced means that the two pairs of data wires are reversed, meaning while one is outputting a high the other wire will output a low. This is done to limit the Electromagnetic interference (EMI) since the radiated EMI from each wire cancels out when they are opposite. Received EMI will also be reduces since both Data+ and Data- are affected equally and the difference between these remains the same and the signal maintained [39]. The data pins should be within +/-6 V but according to the EIA- 485 standard the transceiver should be able to interpret the data with a difference as low as 200mV [40]. Since no acknowledgment are returned to the sender the transmitter have no ability to know if the packets have been received and without no error-correction the data are prone to error.
Due to this the DMX standard warns about using DMX for controlling hazardous equipment such as pyrotechnic.
2.5.3 Data format
Figure 2.12: DMX data packet [41]
• Break 22-250 bits indicates the start of a DMX-packets and consists of Low bits.
• Mark After Break (MAB) 2-250 bits consists of High bits indicating to the receiver to start reading data, the mark can be of different length depending of the transceivers capabilities.
30 CHAPTER 2. BACKGROUND THEORY
• Start Code (SC) 11 bits have the same format as a regular channel data packet. The regular null SC with only Low bits is used in most cases but alternate SC exist for other purposes, for example sending text packets, some start codes are reserved as well for future propietary solutions [36].
• Mark Time Between Frames (MTBF) 0-250 bits consist of High bits to separate the channel data.
• Channel Data (CD) 11 bits consist of a start bit which can be Low or Space followed by the 8 bit DMX-value followed by 2 stop bits with High or Mark value.
• Mark Time Between Packets (MTBP) 0-250 bits consists of High bits to separate DMX-packets [41].
Figure 2.13: Oscilloscope measurement of a DMX-signal showing conti- nous transfer of DMX value 128 each starting with start bits and followed by stop bits. In this case MTBF is set to 0 bits
With 512 channels each consisting of 8 bits equals 4096 bits of channel data per packet. The total packet with overhead equals a minimum of 5678 bits [41]. With a data rate of 250 kbit/s approximately 44 DMX- packets can be sent each second.
Chapter 3
Implementation
This chapter will begin by describing the specification on the chose hard- ware. The chapter goes on to software, both the development tools as well as the implemented software on the nodes will be described. This will be described as an overview in section 3.2 as well as in section 3.1.2 and 3.4 related to how the DMX-conversion are implemented and how the software were implemented to perform continuous testing and acquire data. This chapter will end with a research methodology used for this report describing the measurements being conducted as well the param- eters for each of the test cases.
3.1 Hardware
This section will cover the chosen hardware, both regarding Bluetooth and DMX as well as show the routing for the hardware.
3.1.1 Bluetooth development kits
A few development kits(DKs) were considered in the beginning of the the implementation phase. These are shown in appendix A together with the decision matrix for choosing which hardware to use. The chosen hardware devices was in the Nordic Semiconductors line-up with nRF52840-DK, nRF52832-DK and nRF52840-dongle. These development kits are fully integrated with antenna, external connections, USB and other function- ality such as the DKs ability to connect to current measurements de- vices. The chip that these are based on are so called System on a chip (SoC), which means that they include multiple functional blocks such as a ARM microprocessor and a Bluetooth radio. The chip supports Bluetooth 5,Bluetooth mesh, Thread, ZigBee, ANT, 802.15.4, NFC and
31
32 CHAPTER 3. IMPLEMENTATION
proprietary 2.4GHz solutions. Some of the more relevant to this thesis specification for the DKs are:
Bluetooth develoment kit
Parameter nRF52840-dongle
nRF52840 PDK
nRF52-DK (nRF52832) Energy measurement
enabled No Yes Yes
Programmable via USB
Yes(with built
in bootloader) Yes Yes
IO 1 button, 4LEDs
GPIO-pins
4 buttons, 4LEDs GPIO-pins
4 buttons, 4LEDs GPIO-pins
MCU Arm Cortex M4
64MHz
Arm Cortex M4 64MHz
Arm Cortex M4 64MHz
Flash 1MB 1MB 512kB
RAM 256kB 256kB 64kB
Table 3.1: Decision table for hardware choice
The development kit are shown in Figure (3.1) and Figure (3.2) where the nRF chip is the smaller chip located in the bottom of the figures together with the antenna located at the Nordic logo. The larger chip on the development kit is used for interfacing with the extra functionality of the DKs such as power measurements, flashing etc. The connectors on the top of the DKs are used for connecting measurement device for measuring power consumption. In Figure (3.3) the dongle is shown, this only include the nRF chip itself.
3.1. HARDWARE 33
Figure 3.1: nRF52832 DK
Figure 3.2: nRF52840 DK
Figure 3.3: nRF52840 dongle
One other relevant factor for this thesis is the nRF-chips clocks. They include both a Low-Frequency Clock (LFCLK) running at 32kHz. The LFCLK is enabled during all times. It also supports a High-Frequency Clock (HFCLK) running at 16M Hz. Due to power constraints the HF- CLK is only enabled when required.
3.1.2 DMX-conversion
To output the DMX data a General-purpose input/output (GPIO) pin on the development kit can be used. Since DMX is differential the single wire GPIO needs to be converted to a two-wire differential bus. Suit- able hardware for this is the MAX485 transceiver which is a half-duplex transceiver taking input as Gnd, VCC and a single-wire serial port and outputs a two-wire differential bus. It handles up to 2.5Mbps, 12V and
34 CHAPTER 3. IMPLEMENTATION
with a typical rise/fall time of 15ns which is well within specification for DMX. The power consumption of the transceiver is between 120µA and 500µA unloaded versus fully loaded and also includes a low-power shut- down mode consuming 0.1µA [42]. A illustration of the MAX485 chip is shown in Figure (3.4)
Figure 3.4: Illustation of the MAX485 chip used.
The MAX485 routing schematic are shown in Figure 3.5. This will pro- vide a functional conversion from single wire GPIO pin to a differential bus but due to the lack of circuit protection, such as current limiting resistors this connections should be used in a real world application due to the risk of damage to the nRF device. Pin 1 on MAX485 is DMX input that are sent from the fixture. This can be used for warning if the fixture loses power since this return to 0 when the connected fixture loses power.
Figure 3.5: Wiring of MAX485 chip where the pin 7,8 and 9 of the MAX485 chip connects to the DMX connector. Pin 4 to a nRF GPIO output for DMX transmitting and pin 1 to a nRF GPIO input for de- tecting power losses.
