For the past three months I have been working on a school project. It is called an Asset Monitor. The Asset Monitor allows you to monitor your assets remotely through a smart phone.
The Asset Monitor consists of a network of Asset sensors that monitor the status of assets for motion and temperature. A central controller records all the data sent by all the Asset sensors, and forwards critical messages to the user’s mobile phone. Figure 1 shows an overview of the Asset Monitor.
The Asset Monitor has four major components:
- Asset sensors
- Google Cloud Messaging server
- Asset mobile app
An Asset sensor is a small battery powered device that is attached to the asset to be monitored. It monitors the asset for motion and temperature, and reports data to the controller periodically and in case of an event. The communication between the Asset sensor and controller is done using Bluetooth Low Energy (BLE).
BLE is a low power version of classic Bluetooth that is designed for low power applications such as battery powered sensors. The Asset sensors for our project are developed using the BLE121LR modules from Bluegiga. The BLE121LR module is built around the TI CC2541 microcontroller. The BLE functionality for the BLE121LR is already implemented by the BLuegiga software stack, and Bluegiga has also developed a scripting language called BGScript to program the modules. The main components of an Asset sensor are:
- BLE121LR Bluetooth Low Energy module
- MMA8452Q accelerometer
- CR2032 coin cell battery
- Push button
Figure 2 shows the prototype of an Asset sensor I have created.
The motion detection is done using the MMA8452Q accelerometer. This accelerometer has a built-in motion detection capability, which can generate an interrupt signal when the acceleration exceeds a given threshold. This relieves the host processor from having to constantly poll the accelerometer for acceleration. The BLE121LR interfaces to the accelerometer using the IIC interface. Figure 3 shows a schematic of the Asset sensor prototype.
The BLE121LR module has a built-in analog temperature sensor that can be used for temperature sensing. BLE121LR has a dedicated ADC channel to read the output of the temperature sensor. BLE121LR also has the capability to monitor its battery voltage. This is also done using the internal ADC.
Asset sensor firmware
The Asset sensor firmware is designed as a state machine. It can be in any one of five states at any given time as shown in Figure 4.
Asset sensor spends much of its time in the Idle state; the state that consumes the least amount of energy. To join a sensor to the Asset sensor network, it must be put on the Network Join state. This can be achieved by doing a two-button press (pressing the button twice within one second). Once joined to the network the sensor will wake up every second and increments a counter. If the counter matches the reporting interval (15 minutes), the device will read the temperature and battery voltage and enters the Report state, where it reports the data to the controller.
The Asset sensor firmware also supports message routing, which allows a sensor to act as a relay between another sensor and the controller. To join a sensor to the network through a relaying-sensor (parent device), first the joining-sensor (child device) must be put on the Network Join state. Then the parent device must be put on the Add child state by issuing a four-button press command. During the Add child state the parent device will automatically find and add the child device to the network.
Each sensor can support up to seven child devices. When one or more child devices are added to a sensor, it switches between the Scan and Idle states every second with a 10% duty cycle. During the Scan state, the parent device is able to accept messages from a child device.
Figure 5 shows the packet structure used by an Asset sensor to report data to the controller or a parent device.
The type of packet used is a BLE broadcast packet, which is also called an advertisement packet. The firmware modifies the payload section of the advertisement packet to include battery voltage, motion status and temperature data. The device address helps the controller distinguish the data belonging to a child device from that of a parent device. A message id is added to help the controller eliminate duplicate messages. The advertisement packet can contain up to 37 bytes of data and can be easily extended to add additional parameters if necessary.
The flow chart in Figure 6 shows the steps used to configure the MMA8452Q accelerometer for motion detection.
Motion detection is configured on all three axes (x, y & z) of the accelerometer. The threshold is set to be just above ±1 g such that motion will not be triggered simply due to gravitational acceleration. The interrupt functionality of MMA8452Q is used to avoid the need for excessive polling by the CC2541 to check if motion is detected. In the interrupt mode, the accelerometer will generate an interrupt signal whenever the acceleration exceeds the set threshold value. The interrupt signal wakes up the CC2541 microcontroller so that it can report the motion detected event to the controller.
The motion de-bounce interval of 50 ms eliminates spurious detections due to noise. Once the CC2541 receives an interrupt signal from the accelerometer, it reads the motion threshold register of the accelerometer to clear the interrupt status. Three seconds after reporting the motion detected status to the controller, and if no other motion interrupts are received by the CC2541, then a no motion status is reported to the controller.
The temperature sensing ability of the Asset sensor is utilized from the built-in temperature sensor of the CC2541 microcontroller. The analog temperature sensor of the CC2541 is capable of monitoring temperature across the full operating range of the BLE121LR module (-40ºC to +85ºC). The temperature sensor outputs a voltage proportional to the temperature, which is read by the internal ADC of the CC2541. The sensor does not calculate the temperature with the ADC value, rather it sends the ADC result to the controller, and the controller performs the conversion from the voltage to the temperature in Celsius.
Battery voltage detection
In addition to motion status and temperature, the sensor also monitors its battery voltage level and reports to the controller. This allows the user to know when the battery needs to be replaced. Battery voltage detection is performed similar to the temperature detection. The CC2541 internal ADC has a dedicated channel for reading the battery voltage.
The Asset sensor is powered by a CR2032 coin cell battery. This battery has a capacity of 240 mAh and is rated for +3 V. However, when the battery is loaded with a circuit, the maximum voltage output of a new battery drops to around 2.65 V. When the battery is near the end of its life the output voltage drops to 2 V. The sensor reads and reports its battery voltage to the controller every 15 minutes.
The controller is the most critical component of the Asset Monitoring system since all messages from the Asset sensors must pass through the controller. This section provides an overview of the controller, its functionality and implementation. The main roles of the controller are to
- Create and manage a network of Asset sensors
- Record messages sent by all Asset sensors
- Promptly alert the user of all critical messages
In order to carry out its duties the controller must have the following three key requirements:
- Must support Bluetooth Low Energy
- Must be connected to the internet
- Must have a display for user interaction
For our project we used an old cell phone as a controller since it supports all three requirements above and can be easily programmed. A laptop, a desktop PC or a Raspberry Pi are all suitable choices for a controller. Figure 7 shows the cell phone that is used as the controller for the Asset Monitor.
The controller application is simply an Android mobile phone application developed using Android Studio development environment. The controller must be connected to a Wi-Fi network with internet access. The controller application keeps the CPU of the phone awake at all times. Therefore, the controller must be connected to a power outlet through an adapter to provide a constant source of power.
Figure 8 shows the controller application window with two sensors connected to the network.
The controller application allows the user to add sensors to the Asset Monitor network. When a sensor is successfully added to the network, it will appears as an item in the sensor list as shown in Figure 8. For each sensor, the controller displays the most recent data received from the sensor including temperature, motion status, battery status and the time of last report.
The controller application must continuously listen for messages from child devices, since a sensor may report a critical message at any time. Before the controller is able to join devices to its network it must configure the Bluetooth LE adapter and register itself with the Google Cloud Messaging server. Figure 9 shows the initial configuration steps carried out by the controller application.
After the Bluetooth LE adapter is configured, the controller app connects to the BLE service, a process that runs in the background, which provides BLE functionality to the app. Then the app registers itself with the Google Cloud Messaging (GCM) server and obtains a registration token. This step allows the controller to receive status update requests from the Asset mobile app. More information about GCM will be covered in the Google Cloud Messaging section.
The final configuration step is to start a repeating timer that periodically checks to see if the connected sensors are sending reports at regular intervals. If the controller has not received a message from a sensor within 17 minutes from the last report, an alert message is sent to the Asset mobile app. Once the initial configuration is complete the app simply waits for user to add sensors to the network.
User can add sensors to the network by clicking the Add Device button in the controller app. Figure 10 shows a flow chart of the process of joining a sensor to the network.
When the Add Device button is pressed, the controller app scans for network joinable Asset sensors and creates a list, which is presented to the user after the scan timeout occurs. The user selects a device for joining from the scan results list. Then the controller temporarily establishes a connection with the device, which indicates to the device that it has been added to the controller’s network. The sensor records the Bluetooth MAC address of the controller as the address of its parent. Afterwards the controller disconnects from the device and starts scanning for data reporting messages from the sensors.
When one or more sensors are joined to the controller, the controller begins to scan for messages from the sensors. Figure 11 shows the flow chart for scanning messages from connected sensors.
The controller only responds to messages from Asset sensors connected to its network. This allows two separate Asset Monitor systems to coexist at the same location. When a message is received from a child device, the controller responds with a scan request message. This message acts as an acknowledgment for the child device that the controller has received its message. If the message reported by child device is critical, such as a motion detected event, then the controller immediately sends a message to the Asset mobile app on the user’s cell phone via GCM server.
Sensor network topology
Figure 12 shows the topology of the Asset sensor network and two methods for joining sensors to the network.
Asset sensors can be joined directly to the controller or they may be joined to another sensor that is already joined to the network. This feature allows the range of the Asset Monitoring system to be extended beyond the maximum range of BLE. Each sensor has a parent device and may support up to seven child devices.
The direction of data flow is from a child device to its parent with the final destination being the controller. The child device does not receive data from its parent or the controller except for an acknowledgement that the data has been received.
There is no limit to the number of hierarchical levels that can exist in the network. However, adding more levels increases the network delay. Unlike the controller, a parent device cannot be listening to messages from child devices continuously as it significantly increases the energy consumption of the device. To conserve energy, a parent device scans for messages for only 100 ms and sleeps for 1 s before scanning again. Furthermore, a parent device only accepts a single message during scanning. So each level may increase the network delay by up to 7 seconds.
GCM connection server
This section explains how messages are exchanged between the controller and the Asset mobile app on the user’s mobile phone using Google Cloud Messaging (GCM). GCM is a third party service that is provided free of charge by Google Inc. to send messages between an application server and mobile devices. In our project, the controller or the Asset mobile app becomes the application server when one needs to send a message to the other. Some of the features provided by GCM include
- Downstream and/or upstream messaging using HTTP or XMPP protocols
- Group messaging for up to 20 devices
- Maximum 4 kB of data per message
- Store and deliver messages when devices are available
For our project we are using HTTP protocol since it provides the simplest implementation and does not require maintaining an active connection with the GCM server as in XMPP.
GCM service setup
Before using the GCM service both the controller and the Asset mobile app must register with the GCM servers. To register with the GCM service, a Google API project must be created in the Google Developers Console. The Google API project provides a project id and an API key. The project id is used during the registration process to identify a particular GCM enabled project. The API key gives access to the GCM service when a message needs to be sent.
After successfully registering with the GCM servers, the Asset mobile app subscribes to receive group messages. In GCM group messages (or multicast messages) are called topics. By subscribing to a certain topic, the mobile app receives all messages sent to that topic. Topics allow the controller to send only a single message rather than sending messages individually to all registered mobile devices.
The Asset mobile app subscribes to three topics: status, alarm and warning. The controller sends status updates of all Asset sensors to the status topic. Critical messages such as motion detection are sent to the alarm topic. Non critical alerts such as “sensor battery low” are sent to the warning topic. When a message from a certain topic is received the Asset mobile app executes the appropriate course of action for that topic.
Similar to the Asset mobile app, the controller also registers with the GCM server, but subscribes to only a single topic: controller. When the user requests a status update from the mobile app, it sends a status request message to the controller topic. When the controller receives a status request message, it assembles the latest information from all the sensors and sends the data to the status topic.
GCM message format
When using the HTTP protocol a GCM message is sent as an HTTP post request to the GCM server. Figure 13 shows the structure of the message sent to the GCM server.
The optional attribute “priority” is used to indicate the urgency of the message. The GCM servers will attempt to deliver a message immediately if the priority is set to “high”. The “data” attribute is another JSON object that contains the message delivered to the recipient. The “data” attribute can contain up to 4 kB of data.
Asset mobile app
The Asset mobile app is the interface that allows the user to monitor his/her assets from any location. The only requirement is that the user’s mobile phone must be connected to the internet either through Wi-Fi or a mobile network. The Asset mobile app has two tasks:
- Receive and display messages sent by the controller
- Send status request messages to the controller and retrieve the latest sensor status
For our project we implemented the Asset mobile app for the Android operating system. A similar application can also be created for other mobile phone operating systems such as iOS. Figure 14 shows how notifications and sensor status are displayed to the user by the Asset mobile app.
The very first time the user executes the Asset mobile app, it registers itself with the GCM server to receive messages from the controller. The app initiates a process called GCM listener service that runs in the background, which periodically checks in with the GCM servers for any pending messages. If the GCM server sends a message, the GCM listener service receives the message and hands it over to the Asset mobile app. If the message is from the alarm or warning topics, the app assembles a notification message and displays it to the user. If enabled by the operating system the notification message will also generate an audible sound.
The user can request a status update by clicking the Refresh button (see Figure 14). When the refresh button is clicked, the app sends a status request message to the topic controller. Upon receiving the status request message the controller will send a message that includes an updated list of all sensors to the status topic. When the Asset mobile app receives a message from the status topic the app updates its sensor list with the latest information and displays it to the user.
And this is not so quick introduction to my latest project. If you are interested to learn more about the project and to see some of the results we achieved you can access the full report here.
Special thanks goes to my Local/Wide Area Networks instructor at BCIT, John Dian, for providing us with the Bluegiga development boards for this project.