Connecting MCUs to the Cloud in Industrial Sensor Applications

A fast-growing element of the Internet of Things (IoT) is the wireless sensor. These devices are the eyes and ears of the IoT and provide the massive amounts of data that analytics and big data applications require to make intelligent decisions. In industrial applications sensors can supply accurate data for optimizing chemical processing and material transfer, supporting higher levels of automation, improving energy-grid efficiency and enabling a host of other applications yet to be delivered.

MCUs will be at the heart of wireless-sensor applications. New devices that simplify the implementation of wireless-sensor connectivity make it easier than ever to add these capabilities to even the most modestly priced systems. This article will look at some implementation options these new devices provide to illustrate just how easy it is to move data from the MCU to the cloud.

Wireless MCUs come online

Recently introduced MCUs are adding integrated wireless communications functions that can connect to a wide variety of wireless standards. These new devices take one of two common approaches to implementing wireless communications. Some devices use a flexible wireless subsystem that can implement a variety of standards. Other devices focus on one or two common and similar standards to optimize their solution for specific applications.

Flexible implementation often provides a programmable radio “front end” that manages all of the generic wireless “building blocks,” such as modulation options, that include Gaussian frequency-shift keying (GFSK), frequency-shift keying (FSK), four-level GFSK (4GFSK), four-level FSK (4FSK), and on-off keying (OOK). Other common hardware blocks include low-noise amplifiers, mixers, programmable gain amplifiers, an analog-to-digital converter, a digital signal processor and packet-handling logic, and FIFO storage. These wireless building blocks can be used, via MCU software, to implement a variety of radio-based standards. Often the MCU manufacturer provides high-level applications programming interfaces (APIs) that implement common standards to simplify development.

An example of the flexible approach is the Silicon Labs EZR32LG 32-bit wireless MCU, whose block diagram is shown in Figure 1, below. The flexible wireless transceiver is treated as a peripheral and uses the SPI interface to communicate with the MCU. The EZR32LG uses a variety of advanced energy-saving modes, which are particularly useful in low-power wireless-sensing applications, and the modes available to each module are color coded on the block diagram with the darker blue color indicating the modules that operate in the lowest-energy mode, and the lightest green color indicating operation in the higher-energy modes. Higher-energy modules can be turned off when not needed to save energy while the lower-energy modules continue operation. 

Figure 1: Silicon Labs EZR32LG wireless MCU block diagram. (Courtesy of Silicon Labs)

Another approach to implementing MCUs with wireless connectivity is to focus on a few common standards and implement them in a more dedicated fashion. This typically reduces cost and overall power but does not cover the wide range of standards that more flexible implementation can.

The more flexible implementations may find homes in applications that require an element of wireless bridging. In bridging applications a wide range of legacy, custom, and new sensors coexist, so a flexible implementation can communicate with every sensor and translate between different standards to extend system lifetimes and reduce replacement costs. Low-cost sensors can implement a fixed wireless standard and then count on the more flexible bridging devices to connect them to the rest of the system.

As an example of a wireless MCU with a more targeted set of standards, let’s consider the Texas Instruments CC2640 Wireless MCU with support for Bluetooth Low Energy (LE). Using a flexible on-chip wireless sub-system the CC2640 implements the Bluetooth LE (BLE) protocol on the Cortex-M0 control MCU within the wireless module. As seen in Figure 2 below, the BLE radio firmware is provided in ROM for the radio-control MCU, simplifying development dramatically. The Cortex-M3 is used to run the higher level functions such as the BLE stack, RTOS, BLE profiles and services, and finally, the user application. MCU peripherals are available to implement any other timing and communications functions required by the user’s application.

Figure 2: Texas Instruments CC2640 BLE wireless MCU block diagram. (Courtesy of Texas Instruments)

Wireless MCUs often include other specialized functions to simplify design and, in particular, to manage power. The CC2640, for example, has an autonomous sensor interface that can wake up independently of the MCU and perform sensor readings, collect data, and determine if the main CPU must be brought out of a low-power mode. Additionally, the CC2640 can be powered down and a low-power RTC used to periodically bring the device out of the low-power mode while a special SRAM block can be used to retain data during the low-power state. A wide voltage operating range also simplifies the design of battery-based applications.

Kits and reference designs accelerate development

MCU manufacturers are making it easy to develop wireless sensors in record time by providing complete development environments. Texas Instruments, for example, provides its Sensor Tag reference design (CC2650STK) that includes over 10 sensors and interfaces; and can, right out of the box, transfer data and commands between an iPad or smartphone and cloud storage. You can access cloud-based sensor readings using a web browser and issue simple commands to the sensor tag via the web interface as well. This level of functionality makes implementing your own wireless sensor a snap.

Silicon Labs also has a sensor-reference design for a Weather Station (designated part number SLSTK3201A) that can be used as a starting point for a variety of wireless-sensor designs. This reference design includes sensors for humidity, temperature, ultraviolet, infrared, and proximity. The proximity detector supports common gestures like hover and swipe to illustrate how simple commands can be captured via hand movement.

Example wireless sensor solutions

We can now look at an example implementation of a low-power wireless sensor that illustrates how easy it is to add wireless capability to simple sensors. One very common sensor application captures temperature and humidity readings for produce transported via truck or rail. These readings are reviewed after shipment to make sure the produce stays fresh. Figure 3 below shows the block diagram of a very-low-power implementation that uses a CR2032 coin cell battery to power the sensor for up to 10 years. The nano-power system timer periodically wakes the system from a completely off state by activating the ultra-low leakage switch to supply power to the system. The MCU (in this case the TI CC2650) wakes up and captures a set of readings from the humidity and temperature sensor. When enough data has been captured, the MCU logs the data and identifies cases where the temperature or humidity levels violated any maximum or minimum alarm levels. Alarm levels can be customized for the type of produce delivered and the associated optimal conditions. Tomatoes, for example, have a different optimal temperature and humidity profile than lettuce. In fact, tomatoes have a time-varying profile since some ripening is desirable initially, and then freshness must be retained once ripeness has been achieved. The MCU can take all these factors into account when creating and sending the report via the wireless link.

Figure 3: Wireless Sensor Implementation Block Diagram. (Courtesy of Texas Instruments)

Once a standard such as Bluetooth LE is implemented it is easy to connect it to a Bluetooth LE-enabled smartphone or tablet. In the above example design, a tablet-based interface could monitor the sensors within the truck or rail car and would move the data periodically from the sensors to cloud storage (perhaps using the Texas Instruments sensor-tag reference design as a starting point). Remote traffic managers could use this data, and similar data from all their other product transport systems to dynamically route shipments to the optimal location based on real-time freshness and ripeness parameters. 

Conclusion

With the growing demand for wireless sensors as an element of IoT, MCUs – the main controllers for IoT sensors – need to connect to the cloud. As we have demonstrated, recent innovations in on-chip wireless MCU peripherals, stand-alone wireless modules, software tools, and hardware kits make it easy to connect an MCU to the cloud.

For more information about the parts mentioned in this article, use the links provided to access product pages on the DigiKey website.