Industrial Internet of Things Design Master ready-to-use single-board design and develop IoT prototypes

fish001

Industrial Internet of Things Design Master ready-to-use single-board design and develop IoT prototypes [Copy link]

The Internet of Things, and in particular the Industrial Internet of Things (IIoT), is not only expected to have a transformative impact across many business sectors, but it is also expected to bring about a fundamental shift in the development of embedded IIoT solutions. Many engineers tasked with such projects choose a commercially available single-board computer (SBC) as the basis for their design. While this approach can produce results quickly, it can also make it difficult for developers to easily take the resulting design into high-volume production. When choosing a prototyping platform, be sure to carefully examine the MCU on which the design is based, as well as the various supporting components, to see if they can be purchased separately and integrated into a new design from scratch.

This article will focus on the design of a simple temperature sensor platform for IoT designs and will also highlight the individual components used. In addition, this platform is used not only to verify the design concept, but also to show how to fine-tune the development using power consumption investigations and how to optimize power consumption.

Figure 1: Basic functional requirements of an IIoT temperature sensor

Consider the simple temperature sensor design shown in Figure 1. This figure highlights the basic functional blocks that need to be designed for a battery-powered temperature sensor that stores its data on a cloud platform. The microcontroller (MCU) polls the temperature sensor at preset intervals and then uses wireless devices to establish a communication link and send data to the cloud application responsible for receiving the data. For the design engineer, there are many personal decisions to make when choosing the components to use, which affect the bill of materials cost. For example, the temperature sensor may include a dedicated temperature sensor such as the popular TMP36 series from Analog Devices, or a more comprehensive temperature, humidity and air pressure combination sensor such as the Bosch Sensortec BME280, or a common surface mount PTC thermistor from Epcos-TDK. Cost is only one consideration, and accuracy, tolerance and interface method must also be considered. The sensor selected will also determine the MCU specifications. If an inexpensive thermistor is used, it may not be linear with temperature over the required temperature range, so some degree of slope calculation will need to be performed in software. Although the number of MCU resources required to achieve this is minimal, it still needs to be considered. At the other extreme, the BME280 requires SPI or I2C communication with the host MCU, so a device that has these interface capabilities and can control the sensor and process more data is needed.

There are also many key decisions to make regarding the communication method. Perhaps the most important decision is the wireless protocol to use, with the most common protocols being Bluetooth and Wi-Fi. Bluetooth allows for short-range communications, which is suitable for relatively small amounts of data, and typically communicates with a gateway device, which may first aggregate the data before further transmission using a longer-range communication protocol such as Wi-Fi. When using sensors for Wi-Fi communications, there is no need for an intermediate gateway, so longer-range communications are possible and more data can be transmitted, but at the expense of higher power consumption.

Once you have decided to use wireless communications, you will also need to decide whether to go with a discrete approach or a pre-certified wireless module. Unless your company has its own RF expert design team and the expected production volumes are very high, you will most likely go with a module approach.

The final function of this design is power management. One way to power the sensor is from a replaceable coin cell battery, but it is also possible to use a rechargeable battery with wireless energy harvesting techniques or a small solar panel. In addition, being able to put the MCU and wireless module into a variety of different sleep modes can be very helpful in reducing power consumption to extend battery life. Software is often used to control the device in this way. Other considerations for this design include the expected volume and whether this sensor is likely to be one of many sensor products that the company hopes to develop and launch. If the latter is the case, there are more advantages to developing a platform-based approach, in which the MCU and wireless functionality are common across the family, with only the sensor-specific circuitry varying for each model.

When prototyping a sensor design such as the one highlighted earlier, there are many different ways that design engineers can build the design. In the past, manufacturers’ development kits and evaluation boards provided an ideal learning platform to build the foundation of a design, although in many cases some design work and embedded development was required to integrate the various functions. However, new, fully integrated, compact single-board computers (SBCs) are becoming increasingly popular with engineers who want to minimize prototyping time, and the designs are open source enough that they can be used as the basis for the final design. In this case, all the core components of the SBC must be available for purchase, and all device libraries must be covered by a Creative Commons license.

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

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

Weighing just 6.1 grams and measuring just 2.1 x 0.9 x 0.3 inches, the Adafruit Feather M0 Wi-Fi features a Microchip ATSAMD21G18 MCU in a QFN package running at 48 MHz, along with 256 kB flash and 32 kB SRAM. This Arm Cortex-M0-powered device provides 20 available GPIO pins, eight PWM ports, ten 12-bit analog inputs, and a DAC. Serial communication interfaces for peripherals include SPI, I2C, and UART. The onboard Diodes Inc. AP2112K-3.3 3.3 VDC regulator has a peak current capability of 600 mA, allowing the entire board to be powered via the micro USB connector. Logic levels are maintained at 3.3 VDC, so a level shifter is required if connecting to any 5 VDC devices. Alternatively, the board can be powered by a 3.7 VDC LiPo battery combined with a Microchip MCP7331T-2ACI/OT charger IC. The type-approved, FCC-certified Microchip ATWINC1500 module comes with an integrated antenna for 2.4 GHz, 802.11 b/g/n Wi-Fi communications. Under normal operating conditions, the board power consumption is approximately 10 mA for the MCU and 300 mA peak during wireless module transmission.

The Adafruit Feather M0 Wi-Fi schematic is shown in Figure 3.

Figure 3: Adafruit Feather M0 Wi-Fi schematic.

The board's BOM includes a 32.768 kHz crystal, four LEDs, and several resistors and capacitors.

The MCU with USB bootloader allows the use of the popular Arduino IDE, facilitating software development for Feather products. Using this approach, applications can be developed quickly, and the compact Feather board can be easily integrated into early low-volume production betas of new products. Rather than using the Arduino USB serial program and debug capabilities of the Feather, professional developers can choose to use the Atmel Software Framework (ASF), which uses the SWDIO/SWCLK pins located on the underside of the board.

As mentioned previously, the key to successfully prototyping your design with an SBC is to be able to build your own design around the core components of the SBC. The Adafruit Feather M0 certainly supports this approach. MCUs and wireless modules are readily available on the market with a wide range of development tools and resources. The Microchip SAMD21G18 microcontroller datasheet can be found here and details the available device options and package sizes. Hardware resources include the ATSAMD21 XPRO evaluation board, a comprehensive user guide, and an in-circuit emulator, programmer and debugger (Atmel-ICE), as well as a range of expansion boards such as the ATIO1-XPRO with a variety of sensors. The WINC1500 is also well supported by development resources, including the XPRO expansion board ATWINC1500-XPRO that can be used with the ATSAMD21 XPRO.

Feather provides an ideal development platform for validating design ideas and developing prototypes, and all the components it is based on are readily available, meaning you can move your prototype into production design with confidence.

To demonstrate the ease of prototyping IoT applications, this article references an example that connects a Feather M0 Wi-Fi to Azure, Microsoft's IoT service.

Microsoft Azure is a great example of an enterprise-grade, resilient IIoT platform that not only connects to sensor and actuator devices, but also provides a full suite of storage and analytics applications for the collected data. Using a free trial of this platform makes it easy to access all the functionality you need.

This application demonstrates the use of the Bosch BME280 temperature, humidity, and pressure sensor, but in this example you do not need to connect the sensor to the Feather in order to simulate the data being sent.

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

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

Figure 5: Setting up IoT Hub capabilities in Microsoft Azure.

The last stage in this setup process is to create a device in the IoT Hub. As shown in Figure 6, add a device with the Device ID of TempSensor1. Once you check the box and save, a device key will be automatically generated. You will need the master key for this device after running the Feather sketch. This can be confusing because the IoT Hub and each device has its own master key. The master key is the key you will need to enter when prompted for the connection string (Figure 8).

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

You can now run the provided demo sketch.

Assuming you already have the Arduino IDE, you just need to add the support files for the Feather M0 board. The Adafruit tutorial walks you through this process.

It's good practice to test your Feather M0 Wi-Fi board using the Blink example sketch. Before proceeding, make sure you are able to compile and upload the sketch, and that the onboard pin 13 LED (next to the micro USB connector) is blinking correctly.

To use the demo sketch, you must add the library list to your Arduino IDE environment. Note that for the Azure libraries AzureIoTHub, AzureIoTUTIlity, and AzureIoTProtocol_HTTP, you need to install version 1.0.21, otherwise the sketch will not run with compilation errors. Also, if you decide not to use the BME280 sensor but simulated data, you still need to include the library for that sensor. Not only that, but by default the sketch assumes that you are using a physical sensor. If you want simulated data, you need to change the header line in the config.h file to "#define SIMULATED_DATA true".

Figure 7 highlights the complete library listing, and the bottom portion of the screen indicates that the sketch was successfully compiled and uploaded to the target Feather M0 board.

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

Once the sketch has been uploaded, you will need to switch to the IDE's serial monitor. When writing the sketch, you will need to enter your Wi-Fi access details and the Azure connection string through the serial monitor (Figure 8).

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

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

Figure 9: The serial monitor showing messages being sent from the Feather M0 Wi-Fi.

Once Azure IoT Hub starts accepting messages, you can check to make sure that messages are being received. Figure 10 shows the IoT device summary, which shows the number of messages received.

Figure 10: Microsoft Azure IoT Hub showing a summary of messages.

Once the Azure platform starts receiving sensor data, you can investigate it using some of the data storage and analysis capabilities, details of which can be found on the Microsoft Azure website.

正如本文中的前文所述，当使用电池作为电源时，节省功耗至关重要。Wi-Fi 是一种特别耗能的协议，但正如人们已经认识到的那样，与其他方法相比，这种协议具有很多优势。因此，必须注意优化传感器设计的运行，以便在不影响传感器性能的情况下实现低功耗。MCU 和 Wi-Fi 模块都能够被置于休眠模式，这样可以显著延长电池寿命。

Details on the various MCU power saving modes and how the device's power management features control these modes can be found in the SAM-D21 datasheet. An application note that examines power saving methods that can be achieved from the MCU's peripheral interfaces and features can also be found here.

The ATWINC1500 offers nearly as many power-saving resources, including a section dedicated to them in this application note. In the Feather M0 Wi-Fi tutorial, Adafruit shows the use of a power monitor to illustrate differences in power consumption of Wi-Fi modules (Figure 11).

Figure 11: Feather M0 Wi-Fi board power consumption.

The orange line in Figure 11 represents the overall power consumption of the Feather M0 Wi-Fi board. The purple line represents the supply voltage of the LiPo battery. Note the spikes generated by the operation of the radio, with the first spike containing the link setup of the access point. Outside of the range of the communication taking place, the quiescent current is approximately 22 mA, indicating approximately 10 mA for the MCU and 12 mA for the Wi-Fi module. Understanding the potential use of the intended end product can help determine the level of power savings that can be achieved. For example, if the temperature needs to be measured only once a minute, and it takes 5 seconds to perform the temperature measurement and communicate with the cloud application, the device sleep duration can be set to at least 55 seconds, allowing the device to be in deep sleep mode 91% of the time. Other power saving methods may require performing multiple temperature measurements before sending the measurement results over Wi-Fi, or may only send the measurement results when the temperature reading is different from the previous measurement.

Summarize

Off-the-shelf SBCs provide an ideal platform for validating product concepts and building initial prototypes. Carefully selecting an SBC that uses popular, commercially available MCUs and wireless components ensures that once the prototype is validated, it can be quickly transformed into a final design by taking advantage of the time-to-market advantages, open source resources, and community support that such boards typically offer.