IoT Prototype Development Using Readily Available Single Board Designs

By European Editors

Contributed By Digi-Key's European Editors

The Internet of Things, and specifically the Industrial Internet of Things (IIoT), is responsible for not only creating a transformative effect across many business sectors, but also for bringing about a fundamental shift in the way embedded IIoT solution development is approached. Many engineers faced with such projects have opted to select a commercially available single board computer (SBC) as the basis of the design. While this method can yield fast results, it can also take the developer down a path that makes it difficult to easily take the resulting design into high volume production. When selecting a prototyping platform it is important to carefully review the MCU that a design is based around, and the plethora of support components to see if they can be purchased separately and incorporated into a new design from scratch.

This article will highlight the design of a simple temperature sensor platform for an IoT design and will also focus on the individual components used. In addition, the platform will be used to not only prove the concept of the design, but will also show how it can be used to fine-tune the development using an investigation of the power consumption profile and how to optimize it.

Diagram of basic functional requirement for an IIoT temperature sensor

Figure 1: Basic functional requirement for an IIoT temperature sensor.

Consider the simple temperature sensor design illustrated in Figure 1. This highlights the basic functional blocks that need to be engineered for a battery-powered temperature sensor that stores its data on a cloud platform. The microcontroller (MCU) polls the temperature sensor at a preset interval, and then using a wireless device establishes a communication link and sends data to the receiving cloud application. For the design engineer, there are many individual decisions to be made that will dictate the choice of the components used, and in turn influence the bill of material cost. For example, the temperature sensor could comprise a dedicated temperature sensor such as the popular TMP36 series from Analog Devices, or a more comprehensive combined temperature, humidity, and air pressure such as a Bosch Sensortec BME280, or a humble surface mount PTC thermistor from Epcos-TDK. Cost is only one consideration, with accuracy, tolerance, and interfacing method being others. The choice of the sensor will also shape the MCU specification. If you used an inexpensive thermistor, it would probably not have a linear relationship with temperature across the desired temperature range, so some degree of software-based slope calculation would be needed. The amount of MCU resource to achieve this is minimal, but it is still a consideration. At the other extreme, the BME280 needs SPI or I2C communication to the host MCU, so a device with these interface capabilities and the ability to control the sensor and process more data would be needed.

There are equally a number of key decisions for the method of communication. Probably the most vital one is the wireless protocol to be used, of which Bluetooth and Wi-Fi are the most popular. Bluetooth offers a short communication range, is suitable for relatively small amounts of data transfer, and typically communicates to a gateway device that might aggregate data prior to onward transmission using longer range communication such as Wi-Fi. Provisioning Wi-Fi communication at the sensor cuts out the need for an intermediate gateway, permits longer range communication and suits higher data volumes, but at the cost of a higher power consumption profile.

Once the wireless communication has been decided, there is the additional decision of opting for a discrete approach or using a pre-certified wireless module. Unless your organization has its own specialist radio frequency engineering team and the intended production volumes are very high, then it is most likely the module approach will be used.

The final function of this design is that of power management. Operating from a replaceable coin cell might be one approach for powering the sensor, but using a rechargeable battery with wireless energy harvesting techniques or a small solar panel is an alternative approach. In addition, the capability to place both the MCU and the wireless module into a number of different sleep modes can greatly assist in conserving power in order to prolong battery life. Typically, control of the devices in this way is achieved through software. Other considerations for this design will involve the intended production volumes, and if this sensor is potentially one of a number of different sensor products that the company wishes to develop and launch. Should the latter be the case, there is much merit in developing a platform-based approach where the MCU and wireless functions are common across the range, with only sensor specific circuitry being different for each model.

When contemplating the prototyping of a sensor design such as highlighted above, the design engineer has a number of different ways to architect the design. In the past, manufacturer development kits and evaluation boards have provided an ideal learning platform on which to base a design, although in many cases integrating the various functions required some engineering work and embedded development. However, a new breed of fully integrated and compact single board computers (SBCs) are becoming popular with engineers who are looking for minimal prototype development time, and that the design is sufficiently open source so they can base their final design around the SBC. In that context, it is imperative that all core components of the SBC are available to purchase, and that a Creative Commons license covers any device libraries.

A good example of a compact fully integrated SBC is the Adafruit Feather M0 Wi-Fi (Figure 2).

Image of Adafruit Feather M0 Wi-Fi single board computer

Figure 2: Adafruit Feather M0 Wi-Fi single board computer.

Weighing in at just 6.1 grams and measuring only 2.1 x 0.9 x 0.3 inches, the Adafruit Feather M0 Wi-Fi comprises a Microchip ATSAMD21G18 MCU in a QFN package running at 48 MHz complete with 256 kB flash and 32 kB SRAM. This Arm® Cortex®-M0-based device offers 20 accessible GPIO pins, 8 PWM ports, 10 12-bit analog inputs, and one DAC. Peripheral serial communication interfaces include SPI, I2C and UART. An on-board Diodes Inc. AP2112K-3.3 3.3 VDC voltage regulator with a peak current capability of 600 mA allows the whole board to be powered via a micro USB connector. Logic levels are kept at 3.3 VDC throughout so level shifters will be required if interfacing to any 5 VDC devices. In addition, the board can be supplied from a 3.7 VDC LiPo battery in conjunction with a Microchip MCP7331T-2ACI/OT charger IC. A type approved FCC certified Microchip ATWINC1500 module complete with an integrated antenna provides the 2.4 GHz, 802.11 b/g/n Wi-Fi communication. Under normal operation, the power consumption of the board can be about 10 mA for the MCU and a peak of up to 300 mA for the wireless module during transmit.

A schematic of the Adafruit Feather M0 Wi-Fi is shown in Figure 3.

Schematic diagram of Adafruit Feather M0 Wi-Fi (click to enlarge)

Figure 3: Schematic diagram of Adafruit Feather M0 Wi-Fi.

A 32.768 kHz crystal, four LEDs, and a handful of resistors and capacitors complete the BOM for the board.

Software development on the Feather is aided by the MCU having a USB bootloader, which allows the use of the popular Arduino IDE. Using this approach allows the rapid development of applications, while the compact nature of the Feather board allows it to be easily integrated into low volume early stage beta versions of a new product. In place of using the Feather’s Arduino USB to serial program and debug features, professional developers can opt to use the Atmel Software Framework (ASF) using the SWDIO/SWCLK pins located on the underside of the board.

As mentioned earlier, the key to successfully using an SBC to prototype your design lies in being able to architect your own design based on the core components of the SBC. This is certainly the case with the Adafruit Feather M0. The MCU and wireless module are commercially readily available and come with a host of development tools and resources. The Microchip SAMD21G18 microcontroller datasheet can be found here and gives an in-depth explanation of the device options and package sizes available. Hardware resources include an ATSAMD21 XPRO evaluation board along with a comprehensive user guide, an in-circuit emulator, programmer and debugger (Atmel-ICE), and a series of expansion boards such as the ATIO1-XPRO that hosts a variety of different sensors. The WINC1500 is also well supported with development resources including an XPRO extension board for use with the ATSAMD21 XPRO, the ATWINC1500-XPRO.

The Feather provides not only an ideal development platform from which to prove a design concept and then prototype it, but since all the components on which it is based are all readily available, it means that the prototype design can also be taken into a production design phase with confidence.

In order to demonstrate the ease with which an IoT application can be prototyped, reference is made to an example that connects the Feather M0 Wi-Fi to Microsoft’s IoT service, Azure. A comprehensive detailed explanation can be found here, which guides the engineer through the steps of preparing the Feather board to connect to Azure, the required libraries for use with the Arduino IDE and the Azure set-up instructions.

Microsoft Azure is a good example of a resilient, enterprise class IIoT platform that not only provisions the connectivity with sensor and actuator devices, but also delivers a comprehensive suite of storage and analysis applications for the collected data. A free trial version of the platform is available that provides easy access to all the required features.

This application illustrates the use of a Bosch BME280 temperature, humidity and pressure sensor, although for this example you can stimulate the data being sent without the need to connect the sensor to the Feather.

The first step is to register for a free Microsoft Azure account here. Once that has been completed, log in and access the Microsoft Azure Dashboard illustrated in Figure 4.

Image of setting up your new Azure IoT Hub instance

Figure 4: Setting up your new Azure IoT Hub instance.

Click the + New button at the top of the dashboard page and select Internet of Things followed by IoT Hub. You can then name your IoT Hub parameters (name and resource group) as highlighted in Figure 5.

Image of setting up the IoT Hub function in Microsoft Azure

Figure 5: Setting up the IoT Hub function in Microsoft Azure.

The final stage in the setup process is to create a device within the IoT Hub. This is illustrated in Figure 6, where a device is added with the Device ID of TempSensor1. Tick the box to auto-generate device keys, which will occur when it is saved. You will need the primary key for this device once you get the Feather sketch running. It can be confusing, as both the IoT Hub and each device have their own primary keys. The primary key will be the one to use when prompted to enter the connection string (Figure 8).

Image of adding the Feather temperature sensor as a device to the IoT Hub (click to enlarge)

Figure 6: Adding the Feather temperature sensor as a device to the IoT Hub.

You are now ready to work on the supplied demonstration sketch, which can be downloaded here.

Assuming you already have your Arduino IDE available, you just need to add the support files for the Feather M0 board. An Adafruit tutorial walks you through this process which can be found here.

It is good practice to test your Feather M0 Wi-Fi board using the Blink example sketch. Ensure you can compile and upload the sketch, and that the on-board pin 13 LED (situated next to the micro USB connector) blinks correctly before continuing.

In order to use the demo sketch you have to add the list of libraries into your Arduino IDE environment. Note that for the Azure libraries AzureIoTHub, AzureIoTUtility and AzureIoTProtocol_HTTP you need to install the 1.0.21 versions, otherwise the sketch will fail with compile errors. Also, if you decide not to use a BME280 sensor but use simulated data, you will still need to include its library. Also, by default, the sketch assumes you will be using a physical sensor. If you wish to simulate data, you need to change the header line in the config.h file to read ‘#define SIMULATED_DATA true’.

Figure 7 highlights the complete list of the libraries, and at the bottom of the screen, the successful compilation and upload of the sketch to the target Feather M0 board.

Image of Arduino IDE showing list of libraries and a successful upload

Figure 7: Arduino IDE showing list of libraries and a successful upload.

As soon as the sketch has been uploaded you need to switch to the IDE’s serial monitor. The sketch is written in such a way that the Wi-Fi access details and the Azure connection string are inputted via the serial monitor (Figure 8).

Image of entering Wi-Fi and device connection information

Figure 8: Entering Wi-Fi and device connection information.

Shortly after the above details have been entered you should see confirmation on the serial monitor that the Wi-Fi connection has been made. Then the Feather should start sending data to the Azure IoT Hub, as shown in Figure 9. In this example we have been using simulated data.

Image of serial monitor showing messages being sent from Feather M0 Wi-Fi

Figure 9: Serial monitor showing messages being sent from Feather M0 Wi-Fi.

Once messages have started to be accepted by the Azure IoT Hub you can check to see that they are being received. Figure 10 illustrates the IoT device summary showing the number of received messages.

Image of Microsoft Azure IoT Hub showing message summary (click to enlarge)

Figure 10: Microsoft Azure IoT Hub showing message summary.

Once the sensor data has started to be received by the Azure platform you can then investigate using some of the data storage and analysis functions, further details of which can be found on the Microsoft Azure website.

As mentioned earlier in this article, the need to conserve power consumption is paramount when using a battery as a power source. Wi-Fi is a particularly power-hungry protocol, but as already identified, has many advantages over other methods. For this reason, attention must be paid to optimizing the operation of the sensor design so that a low power consumption profile can be achieved without impacting the performance of the sensor. Both the MCU and the Wi-Fi module are capable of being put into sleep modes that together can significantly extend battery life.

In-depth information on the various MCU power saving modes, and the way the device’s power management feature controls these, can be found in the SAM-D21 datasheet. An application note that investigates the power consumption savings possible from the MCU’s peripheral interfaces and functions can also be found here.

The ATWINC1500 also has a similar number of power saving resources available, including a section dedicated to this in this application note. In its Feather M0 Wi-Fi tutorial, Adafruit showcases the use of a power monitor to illustrate the variation in consumption by the Wi-Fi module (Figure 11).

Image of power consumption of Feather M0 Wi-Fi board

Figure 11: Power consumption of Feather M0 Wi-Fi board.

The orange line of Figure 11 is the overall power consumption of the Feather M0 Wi-Fi board. The purple line indicates the supply voltage of a LiPo battery. Note the spikes caused by the radio’s operation with the first one including the link set up with the access point. Outside of communications being made, the quiescent current is approximately 22 mA, indicating roughly 10 mA for the MCU and 12 mA for the Wi-Fi module. An understanding of the potential use cases for the intended end product will assist in determining the degree of power savings possible. For example, if it is only required to measure the temperature once per minute, the device could be kept in sleep for at least 55 seconds based on the temperature measurement and communication to the cloud application taking 5 seconds, allowing the device to be in its deepest sleep mode for 91% of the time. Other power saving methods could involve taking several temperature measurements before sending them over Wi-Fi, or perhaps only sending if the temperature read is different from the previous measurement made.

Conclusion

Readily available SBCs make an ideal platform on which to prove product concepts and create initial prototype designs. Carefully selecting an SBC that uses commercially available and popular MCU and wireless components ensures that once proven, the prototype can be rapidly transformed into a final design, making full use of the time-to-market advantages, open-source resources, and community support that using such boards typically provides.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

European Editors

About this publisher

Digi-Key's European Editors