The internet of things (IoT) has become unquestionably the next biggest thing and already has blown up faster then most people could have imagined. As the IoT gains traction more companies will be seeking to to provide IoT components. This market includes everything from ICs and modules to fully connected hardware platforms and all the software in between, as well as the cloud platforms to which remote sensor data is uploaded to and analyzed.
With so many options in the hardware, software and cloud platforms it can often be confusing to decide on one option or even to know why to choose an option. Since this is only becoming an increasingly bigger issue I decided to try and do a comparison between two setups that would accomplish the same task. The task to be implemented would be to monitor power consumption in semi-real time. The data sampled would then be uploaded to the cloud to provide information such as power consumed, line voltage, power factor etc. The success of each system would be judged by the simplicity of getting a prototype running and the possibility to move that into a final product.
Measuring Power Consumption
The MCP39F511 from Microchip was selected to do the power measurements due to its ease of use and availability. Specifically the ADM00667 demonstration board was used since it provides everything needed to use the MCP39F511 without needing to design and build a board. The MCP39F511 can output 11 commonly used values that are tracked and can be easily exported. These values include line voltage, current, power factor, and energy counters among others. For this project the calibration and tuning variables were left unchanged as they provided relatively good values.
ADM00667 Power Demonstration Kit for the MCP39F511
The two hardware platforms selected were the MSP430 Launchpad series from Texas Instruments and the mangOH Green from Sierra Wireless. The MSP430 was selected for its ease of programming (Energia is used in this project) as well as its ability to be upgraded to a full production product with code written in C.
The project was first implemented using the MSP430 Launchpad ecosystem. The platforms looked at here included the MSP430FR5969 and the MSP430F5529. The project initially started with the MSP430FR5969 because of the simpler chip design and lower power consumption in sleep time. Unfortunately the WiFi stack or another portion of the provided connectivity libraries appears to have a bug that causes the system to disconnect after a few transmissions.
MSP430FR5969 With and Without the CC3100 Mounted
This portion of the project was therefore moved to the MSP430F5529. This is a board that has been used before in other Wi-Fi and IoT projects with some success. It was hoped that the current iteration of the libraries would fare better, which thankfully they have.
MSP430F5529 With CC3100 Mounted and UART Connections to MCP39F511
The Wi-Fi connection is provided by the CC3100 BoosterPack. This is an easy to connect board that uses SPI to communicate with the host processor. The board follows TI’s boosterpack standard and therefore easily allows other boards or devices to connect without interference.
The second implementation of the project will use the mangOH Green board from Sierra Wireless. The mangOH board offers a lot of functionality that enables it to easily and reliably talk to various sensors. This includes mangOH IoT connectors, an Arduino compatible connector, USB and RS323 and RJ45 among others. The mangOH also has the ability to communicate over cellular networks removing the need to have a WiFi or ethernet connection. The operating system running on the mangOH is Linux based Legato. This provides the ability to prototype with the mangOH in various software languages.
mangOH Green Development Kit with WiFi and Breakout Expansion Cards Installed
Other hardware platforms were considered but for various reasons were not selected. The ST Discovery platforms were considered but were rejected due to a lack of programming resources available to easily and quickly produce a functional prototype. While mbed does allow for quick prototyping the steps involved in doing so and the need to be online at all times were seen as drawbacks for quick prototyping. Arduino was also an option but, due to the ability to produce the same prototype using Energia and the ability to move past a prototype if needed made the MSP340 series superior for this comparison.
The cloud platforms looked at include a long list of which only one has been selected for use at this point and one has been tentatively selected by default. Others may be explored in later blogs. The first cloud platform selected is M2X from AT&T. This platform was selected because of it very broad range of supported languages and operating systems. M2X can be used, to name a just a few, on Arduino, mbed, BeagleBone, Raspberry Pi and Energia. M2X also supports languages that include but are not limited to C, Java, Node.js, Python and Ruby. With this wide range of options it allows for a project to be easily implemented on a large range of platforms and software formats. The second cloud platform being considered for review is AirVantage from Sierra Wireless. This was given higher priority due to one of the platforms being used in this review was designed by Sierra Wireless and uses their processor.
In selecting M2X and AirVantage other cloud platforms were looked at but, like in most projects a quick and justifiable decision needed to be made. Below is a list of the platforms looked at and a brief explanation why they weren't used. Since the goal of the project was to produce a prototype in a short period, it should be noted the main reason for rejecting a platform was due the inability to get the correct information quickly and easily.
This platform is currently under review due to one of the selected platforms having been produced by Sierra Wireless and the hope that the two should be easily connected reducing prototyping time.
A brief look showed all supported devices need an OS. This was a big negative considering that most nodes do not need to contain heavy computing power but rather a simple Wi-Fi connection to upload data.
This was an option but could not quickly find how to use WiFi with my device and their service. Good tutorials to get started but in the end the steps needed to get moving were longer than the final choice. This may be looked at again in a later version.
This was also an option but with no easily visible where the data would appear. It also appeared that the data would appear on other platforms that could be easily uploaded to directly. If multiple platforms were going to be used (pull from one and push to another) this would be a great option.
Tago does not provide a way to implement their solution using the desired hardware platforms.
This looked like a great option but again complexity of the website made this a choice to come back to if something simpler could not be found. This may be an option for a later implementation of this project.
This platform provides a REST API that would have been useful but curl is needed. From all the looking around cul needs some form of OS to run correctly. Either way this wasn't a quick prototype option.
Convoluted website, finding something to get started easily and quickly was not possible.
Another convoluted site with a lot of information but nothing to get me to what I needed in a short time or with any reasonable guidance or explanation.
This was by far the most convoluted website. Trying to find just a service that may work for my application was a task. Once this was found, if you do find it, getting any information on how to get up and running quickly is even harder to find if it at all possible. Definitely a platform I would avoid for now.
Original post on Element14 can be found here