Element14 decided to conduct a RoadTest of some of their most comprehensive Internet of Things (IoT) kits. The exercise in total included a dozen bits of hardware including the most popular single board computers (SBCs) various microcontroller boards and sensor boards. Wireless technologies included 3G mobile, 802.11 Wi-Fi and Bluetooth Smart (Bluetooth Low Energy). IoT platforms from three service providers were used. A free 4-week training course from IBM was examined. Multiple development environments, platform middleware and programming languages were used to explore some end-to-end solutions. This blog post examines all these and summarizes the findings.
The full RoadTest reviews are here:
The hardware included:
with , with , , , , , , .
Looking at an early diagram from IBM’s website that was captured two years ago (the original link has disappeared) it was clear that IoT needed to provide connections to many systems for the full expectation of it to be achieved. Early IoT was criticized for providing a web interface to devices that did not need to be connected to the Internet to perform their existing tasks effectively. IoT was missing important bits. Better IoT solutions pulled out useful data that could be combined along with data from other non-IoT sources to create valuable information that allow existing solutions to be improved and leap-frog the competition or to create whole new solutions.
One example would be Uber which combines data from many drivers in order to provide fast service and a simple, efficient user experience. That alone is highly useful but Uber went that step further and offered something that many taxi companies were unable to do; Uber provided an application programming interface (API) to build machine-to-machine communication (M2M) between Uber services and third party services. It allows for logistics services such as the ability to provide ultra-fast deliveries using Uber drivers and have this completely integrated into the product ordering systems.
The key to this is that ideas don’t come all at once overnight; there is a need for middleware and APIs that will allow the flexibility to rapidly develop solutions repeatedly to continuously innovate.
A number of things have happened over the past decade and without them IoT couldn’t work. Possibly the most important is cloud computing; without cloud services it is extremely hard to rapidly scale as new ideas come forth. Cloud service providers now offer a very rich set of building blocks for applications and for connections to IoT devices. As part of this the cloud services from IBM, Amazon and Sierra Wireless were examined.
This blog post only briefly explores the highlights from some of the many diverse features that go toward making up an IoT solution and how these features were supported with the supplied RoadTest hardware and software. Please also see the individual RoadTest reviews for further information.
One major advance that helps in the rise of IoT is better Internet connections capability brought about through the rapid adoption of 3G/4G/LTE mobile. The hardware for these technologies has shrunk in size. Cost was reduced too but interfacing to the devices could still be difficult depending on what hardware is chosen. A serial interface using the AT command set is not ideal because it requires a software framework to handle the out-of-band control communication and the data communication over the same path and code to parse the serial flow into meaningful content for control and data. Internal microcontrollers tended to be limited to the end user for running interpreted scripts. The modern Sierra Wireless CF3 format Embedded Modules are different; they have a built-in ARM applications processor that can run Linux and they come with APIs to perform mobile operations. The mobile interface appears just like any other network interface in Linux so adoption is familiar and easy for developers.
Wired Ethernet connection options have improved too; some of the NXP/Freescale microcontrollers have in-built handling of the lower protocol layers for Ethernet meaning that a low-cost physical layer (PHY) chip and magnetic components is all that is needed. There are built-in features for TCP/IP handling such as multiple packet buffers, TCP offload engine functions, automatic IP header checksum calculation, automatic VLAN tag handling, and protocol error statistics reporting. Uniquely there is also the capability of handling industrial IoT use-cases due to built-in IEEE 1588 capability which many single board computers do not support. To make life simpler for developers there is an API for TCP and UDP traffic that looks very similar to the POSIX socket API. The learning curve is therefore low.
The learning curve is of course also low on the Pi and BeagleBone Black Industrial since they support Linux and the normal socket API. However they have full applications processors whereas the NXP/Freescale FRDM board has a Cortex-M4 core and is designed for a different use-case (IoT device or sensor nodes). The learning curve is low on the Sierra Wireless modules as well because they support Linux.
Most of the platforms tested have sleep capabilities to allow operation for long periods For the platforms most likely to be used for battery-powered nodes the Cortex-M4 microcontroller on the board operates at 1.71 to 3.6V and current consumption can approach 35mA at 120MHz depending on what integrated peripherals are being used At very low clock rates the current consumption drops to a few milliamps In very low power run(VLPR mode the microcontroller current consumption drops to close to 400-500uA depending on the integrated peripherals again and a slow clock rate In static shutdown modes the current consumption is down to 5.8uA with wake-up within 5us which is great for(say wake-up on wireless activity
The Sierra Wireless module operates at 3.4-4.3V (it is ideal for powering with a LiPo cell) and has an operating current consumption of about 42mA although of course that shoots up when the mobile interface is in use, to around 500-650mA when performing sustained data transfer. It’s ultra-low power mode (ULPM) consumes 6-50uA depending on which triggers are activated for waking up.
The CC2650 wireless microcontroller from Texas Instruments operates at 1.8-3.8V and consumes around 2.9mA at 48MHz, or down to 1uA with memory and some register retention and wake-up in 150us.
It is important to consider what data resides where in a solution and who needs access to it and the risks if the data was not secured. To help develop secure solutions all the devices tested have various security features. With Linux there are also popular software features for securing connections. It was great to see that low-cost microcontroller such as the NXP/Freescale part have hardware acceleration for ciphers and hashes and that the operating system (OS) that was used with it, mbed OS, has transport layer security (TLS) useful for secure HTTP.
The TI CC2650 also has a crypto processor and a high quality random number generator that relies on ‘shot noise’ to produce a jittery signal that is then sampled by the system clock and the result is combined with a linear-feedback shift register.
All of the processors/microcontrollers in the RoadTest support the industrial temperature range of -40 to +85 degrees C; the exception being the Pi 3. The BeagleBone Black Industrial is uniquely one of the lowest cost, full Linux platforms for outdoor and industrial use (with appropriate enclosures and temperature and environment considerations). It also has a built-in LiPo charging capability. The BeagleBone Black Industrial also has a coating for long life in harsh conditions.
Sensors and Bluetooth Smart
Around a dozen sensors are present on the TI SensorTag; this is absolutely great for exploring the world and obtaining real-world data to begin developing data processing strategies. The SensorTag is the kind of tool that will get anyone interested in at least one technology or more related to IoT, such as measurement, data processing, device firmware, radio communication, applications design and so on. It is also great for school kids and their science experiments!
I was impressed that Bluetooth Smart at last appears to work reliably and consistently with the recent versions of the Linux Bluez software stack (this wasn't always the case with earlier Bluez releases!). However, the stack is still supplied with poorly documented API and little example source code. The Bluez ‘gatttool’ is not fit for sensor support without working at a very low level. Anyway there are higher-level Linux libraries created by others that will allow people to easily construct applications for Bluetooth Smart devices. See the BeagleBone Black Industrial Kit review for more information on Bluetooth Smart and the SensorTag.
Integrated Development Environments (IDEs)
All of the platforms have excellent development environments. The Sierra Wireless board comes with a virtual machine with pre-installed development environment for a very smooth experience for developers.
The Pi and BeagleBone Black are both supported by rich IDEs; a full desktop Linux can run on them so the IDEs can even run on the same hardware. There is no issue to compile applications directly on them since the CPUs are of good performance. A file system can be mounted for this purpose.
The BeagleBone Black offers a programming environment built-in as supplied; as soon as the BBB is plugged in and Linux powers up there is access to it from a browser.
The CC2650 has fantastic support; code can be developed with TI’s Code Composer Studio (CCS) which is great to see; no need to invest in expensive toolchains. There is also CCS cloud which eliminates the need for installing CCS locally.
The FRDM board is exceptional however; it too has a cloud-based development environment called mbed and it is extremely easy to use; easier than an Arduino! There is also a local option called mbed-cli.
Device OS and Application Frameworks / Middleware
The devices suitable for wireless sensor nodes all had great OS and support libraries. The CC2650 has very rich support with TI’s OS called TI-RTOS and there is also support with other OS’s such as Contiki.
The FRDM board has very rich libraries and an OS in the form of mbed-OS. It proved to be very easy to make use of basic task management and inter-process communication features with mbed-OS. Protocols for IoT communications such as MQTT and connector support for IBM’s IoT platform was straightforward to use.
The Sierra Wireless module had the excellent Legato framework. This framework provides virtually everything a solution could require for developing, deploying and managing IoT applications either locally or from a portal.
IoT Platform-as-a-Service (Paas) Review
IBM’s IoT platform and Watson IoT services running on top of Bluemix (IBM’s cloud platform) proved to be very feature rich and currently I believe easier than AWS IoT to get into. IBM’s course helped a lot but even without it it was possible to begin developing applications. But the course is highly advised (see further below).
The Sierra Wireless platform was exceptionally nice to use. Everything was smooth. The beautiful dashboards were easy to use and one never felt lost. In terms of functionality it proved possible to easily remotely manage endpoints and perform over-the-air (OTA) application installs and upgrades. Although the northbound interface was not explored I have high hopes for it based on everything else I’ve seen with the Sirerra Wireless platform. Unlike AWS and IBM, it is expected to host your own applications with your own resources (say using IBM or Amazon cloud resources) since there is no IaaS and limited PaaS functionality in the Sierra Wireless platform for developer applications.
IoT Training Course
After having sat through the 4-week training course (in an accelerated form; I didn’t do all exercises or watch all videos in their entirety but I did watch each video sufficiently to work with IBM IoT) I think it is a very valuable course. It takes a user from no IoT knowledge all the way to controlling and receiving data from the Pi 3 and Sense HAT. The user needs just limited, basic programming knowledge and be willing to occasionally google if additional information is needed. There is also a forum for asking questions or helping others through the course too.
I was impressed how useful modern hardware and software has become to support creating IoT solutions. To be honest all of the RoadTested hardware and software was useful, no time is wasted with any of it if the goal is to explore IoT and to experience what can be done with it.
If anyone wanted a recommendation on how to get going with IoT I’d suggest doing the IBM course and exploring Linux on any of the platforms as well as on a PC. The course does not involve any cost.
If one wanted to do the exercises, then the Pi 3 kit is helpful because it comes with the Sense HAT too which is used in the course. For real gateways the BeagleBone Industrial is worth examining because there are known commercial deployments of it. It has a rich feature set and well-suited for industrial applications particularly with the built-in high speed processors that allow for time-sensitive protocols to be tightly integrated with Linux kernel drivers or applications running on Linux.
Some other major technology highlights for me are mbed which is a real pleasure to use, the SensorTag and the Sierra Wireless platform. All of these things are worth exploring.