What, How and Why?
The aim of this project was to create the system facilitating the management of big conferences. The first step was to think what a potential end user would like to achieve by using this kind of system. As the result of this process, we prepared a short list of features, that are crucial to satisfy user expectations:
- distribution of the Wi-Fi password
- messaging system, which can be used for example to send notifications.
- identification of participants, which are currently inside particular conference room,
- providing proceedings adjusted to the user location and profile,
- choosing speaker during Q&A.
The next step was to define the set of devices essential to implement those features. In the spirit of Internet of Things philosophy, we decide to create intelligent identity cards called „Enhanced Beacons” and devices, which allow us to detect and configure them - „Base Stations”. The configuration process was accomplished by the COAP protocol. Global access was achieved by using Bluetooth 6LoWPAN technology. Another requirement was energy consumption – IDs should work for at least two weeks without battery replacement, so nRF51 microcontrollers were pretty obvious choice. In addition we had them provided by Nordic Semiconductor for the contest.
This picture shows the idea of the whole system and also explains where all the devices should reside.
„Enhanced Beacon”
As the part of the system, which will be handed to all participants, our intelligent identification cards have to be small, so it will be possible to produce them in a form of pendants, wristbands etc. That's the reason why we chose to build first prototypes using the “Smart Beacon Kit” manufactured by Nordic Semiconductor company. The first step was to implement functionalities on the GATT protocol layer from the BLE standard – user attributes like ID number, first name, last name, the Wi-Fi password and another one attribute for short text messages. All of those attributes were assigned to our own bluetooth service. If you have ever tried to do that, you probably know that it requires setting a unique UUID for each attribute and service, what we actually accomplished by using the first, not yet assigned numbers, larger that IDs specified by the Bluetooth standard. What's more, each device advertises its unique 16-byte long ID and bitwise flags, which inform about the configuration status of the beacon and the button state. From the “software” point of view we have used softdevice S110 and nRF51 SDK.
The first problem that we have to cope with was a very limited set of controls available on Nordic Beacons – they have just two buttons and one RGB diode. To solve that fundamental problem we decide to attach widely available 0.96'' OLED display. Currently we use it for displaying Wi-Fi password and messages. We had to develop our own library to use those displays. Unfortunately during first tests made on a regular breadboard and “nRF51 DK” board we found out that, that in contrary to information published on the seller's page, they are configured to be driven by SPI interface, not the I2C bus.
To navigate between the sequence of screens we decided to use one button, originally attached to the Nordic Beacon. On the picture below you can see the preprogrammed sequence.
After a while we realized, that it will be useful to notice the owner of a beacon when any part of the displayed information changes, so we attached a little vibrating motor detached from a mobile phone. All those external parts were connected on the little extension board. In that form we prepare two prototypes, which were presented during the Nordic IOT Contest finale.
„Base Stations”
Thinking about minimalistic power consumption and considering required separation of BLE devices for Central and Peripheral role, we decided to use two “nRF51 Dongle Kits” connected on a PCB. Hardware limits of applied chips forced us to use SPI bus to connect Dongles (the only UART interface was used to create very simple console interface for debugging purposes). Those two components of Base Stations were called according to their functional role - “Server” (BLE peripheral role) and “Scanner” (BLE central role). From the “software” point of view, in the server we applied softdevice S110, and in the scanner – softdevice S120 with patched mix of nRF51SDK and IoT SDK.
The main task of “Scanner” is to collect packets advertised by beacons, filter them according to the database and keep list of known beacons synchronized with “Server”. By doing that, “Server” just changes its own list entries, and that action propagates by synchronization process to the scanner and configures designated beacon.
The “Server” is responsible for generating dynamic list of CoAP resources according to its beacon list. The second task was to handle requests from CoAP layer and modify beacon list, so on the client side all beacons and the configuration process could be represented by list of resources.
The major problem while implementing server application was the memory limit and management of the dynamically allocated buffers during requests. Unfortunately, despite the fact that we slightly optimized CoAP implementation for memory usage and created new, “Huge” iot buffers, the maximum number of known beacons is 35. The working prototype is presented on the picture below:
Attached battery case allows you to put „Base Station” at any place, where it can connect to a gateway.
Key components and standards implemented in our system
Server Applications
All informations used by the system are stored inside database. As the database storage engine we chose MySQL. To allow administrative and user access for the database and management of “Base Stations”, we needed to create an application, that will be run on a public server. To acomplish that we have created two components in Python – Base Stations Management Deamon (BSMD) and a web application. Surprisingly, we haven't found user friendly, working CoAP client package, so we had to create our own library. Due to limited amount of time, we weren’t able to support any advanced features of protocol like for example message confirmation. The web application was built with technologies like Tornado server, microframework Bottle, Bootstrap and Jinja2 template engine. Currently this interface is working only in read-only mode.
Plans for the future
The first step will be developing server applications, so they will be more useful and user friendly. The next thing will be redesigning “Base Stations” by using more powerful microcontroller for handling “Enhanced Beacons” and (probably) use nRF51 chips just to provide physical layer of communication between parts of the system. We also consider replacing them with a nRF52 chip, that might be enough to solve problems with memory. Additionally it could be possible to create services to control projector from 6LoWPAN gateway, so it will be possible to manipulate it by “Enhanced Beacons”. The final task will be reducing beacon size and designing it in other forms (cards, watches, little torches etc).
The picture above presents three situations in which using Enhanced Beacons will significantly facilitate resolving problems. From left: changing conference room caused by additional speaker requirements, improving Q&A sessions and automatic generation of participants list, WiFi password update during event or while moving to another building.
Tomasz Chyrowicz & Łukasz Jarosz
The official website of the Iot Contest: www.nordicsemi.eestec.pl