Wireless Sensor Project (WiSP) at Potomac Photonics

WiSP is a collaboration between Potomac Photonics, Potomac Mesosystems, and Gray Technologies.

Potomac Mesosystems and Gray Technologies, under direction and co-funding from Potomac Photonics, are collaborating on a project they are calling the Wireless Sensor Project (WiSP). The goal of this work is to create a network of wireless sensor nodes that communicate with mobile devices (smartphones and tablets) to send and receive sensor data. Dr. Paul Christensen, founder of Potomac Mesosystems, is leading the project and upon completion will miniaturize the electronic components of the sensor node. Mark Gray, founder of Gray Technologies, and myself, Aidan Gray, are handling the software components including writing the sensor node code and developing an iOS app. I am an undergraduate student majoring in Physics at the University of Maryland Baltimore County (UMBC). This was an internship position for me during the summer of 2013.

The project was organized into phases. Phases 1 and 2 were completed during my internship. The objectives of Phase 1 were to define the requirements of the components comprising a wireless sensor node and to perform a comparative analysis of existing wireless sensor development platforms focusing specifically on the software development tools and the ease of use of the tools. The objectives of Phase 2 were to use and compare the different platforms identified in Phase 1 and to choose one and develop a demonstration on that platform.

In Phase 1 we identified four functional components comprising a wireless sensor node: a wireless communication module, a microcontroller module, a sensor module, and a power module as shown in Figure 1. For power, ideally the power source for a deployed sensor node is a 3 volt lithium coin-sized battery; however, for development on a microcontroller development board, power over a USB connection is common. The requirement for low power is the biggest factor driving wireless sensor node design and the largest consumer of power in the node is the communication module. Bluetooth Low Energy (BLE), marketed as “Bluetooth Smart”, is rapidly being adopted in mobile devices including the latest iOS and Android smartphones and tablets. The second most important factor driving our design is the ease of developing software for the sensor node and the mobile devices that it will communicate with. The third most important factor is the size of the electronics and the ability to repackage them in the smallest form factor possible and therefore highly integrated system-on-chip components are preferred for the microcontroller and sensor modules.

 

After identifying these three fundamental requirements, we then looked at existing wireless sensor development platforms and decided to focus on three platforms: (1) the Arduino platform with an 8-bit ATMega328 microcontroller and a separate BLE shield (daughtercard); (2) the Texas Instruments SensorTag with an 8-bit 8051 microcontroller and BLE radio integrated into a single chip with six sensors all integrated on one board; and (3) the Texas Instruments LaunchPad with a 16-bit MSP430 microcontroller with on-chip temperature sensor and a separate Anaren A2541 BLE daughtercard. All three platforms meet the first and third requirements for BLE communications and highly integrated electronic components (the SensorTag having the highest level of integration).

I first compared the SensorTag IDE with the Arduino IDE combined with RedBearLab’s BLE Shield. I analyzed the capabilities of both platforms and came to the conclusion that the SensorTag has more computing power, more memory, and takes up less space and power than the Arduino platform. With this knowledge, we moved on to start a mockup of an iOS app that would work with the SensorTag and to learn the inner workings of the 8051 program that runs the BLE software stack. Both proved difficult and Emmoco’s solution promised to remove those difficulties so we turned our focus to the third platform, the MSP430 LaunchPad and Anaren A2541 BoosterPack. The Emmoco software for this platform allows one to bypass all of the underlying Bluetooth processes, making the entire project significantly easier and allowing the system to be replicated and altered much more easily. Emmoco’s IDE, Em-Builder, even helps create the code needed for the iOS app creation in Xcode.

The deciding factor between the platforms came down to the ease of use of the software development environment and specifically the ability to easily create BLE communications between the sensor node and the mobile devices that will connect to them. Phase 2 was primarily centered on contacting and engaging the vendors of the three platforms and comparing, through use, the software development tools. Although the Arduino platform is a common development environment for hobbyist and academic research, the TI platforms are commonly employed in commercial and industrial applications and specifically the MSP430 is mature and well supported. Topping that is the BLE development environment that Emmoco has developed for the Anaren A2541. Emmoco has abstracted the BLE software stack into a simple set of “resources” that one defines for their application. These resources are defined in a data “schema” and associated schema code that are shared between the sensor node’s microcontroller program and the mobile device’s app. The microcontroller periodically updates and inspects the resource values and the mobile app periodically reads and writes these values. Discovery and connection are handled automatically.

 

Figure 2: Wireless Sensor Node Demonstration

At this point we have ended Phase 2 and have an operational demonstration as illustrated in Figure 2. The demonstration consists of an iPhone app running a schema that we developed using Emmoco’s Em-Builder IDE. The schema executes on Emmoco’s Em-Browser app. The app connects to our wireless sensor node consisting of an MSP430 LaunchPad and Anaren A2541 BoosterPack which plugs into the LaunchPad. Running on the MSP430 is a temperature sensor program that we developed which has the same schema compiled into it for communicating with the Em-Broswer app. On startup, the MSP430 operates as a BLE peripheral device advertising to BLE centrals that may want to connect to it. The Em-Browser app running on the iPhone operates as a BLE central device. It discovers and lists the MSP430 peripheral devices where the user selects one from a list and the app connects to it. After connection, the resources are presented to the user. We have a timetick resource that counts up and the user can reset it 0 and we have a temperature sensor resource that the user can read at any time and the value is displayed on the iPhone.

I developed an initial mockup Potomac Temperature Sensor Demo iOS app using Apple’s Xcode IDE.  Figure 3 shows the title screen for the app. This app will replace the Emmoco Em-Browser app on the iPhone. The Em-Builder development environment did not fully support the integration of the schema and related code into my iOS app at the time that I completed my internship. Once the iOS app is completed, together, the Potomac iOS app and the Potomac sensor app will form an end-to-end example that Potomac customers can use and modify for their sensor applications running on Potomac miniaturized wireless sensor nodes.

Currently, Emmoco is working on releasing their latest update, version 13, to their development platform. Once they have released this update we can complete the Wireless Sensor Project by demonstrating an iOS device connecting wirelessly through Bluetooth Low Energy to a set of sensor nodes comprised of the MSP430 LaunchPad and Anaren A2541 BoosterPack to display temperature readings sent from the nodes. From here, Potomac Mesosystems will add sensors options and miniaturize the hardware on a customer-driven basis.