Easing into the IoT Cloud (Part 1)

Web Connecting MCUs

There are many advantages to having the control/monitoring of devices communicate indirectly with the user interface for those devices—using some form of “always-on” server. When this server is something beyond one in your home, it’s called the “cloud.” Today, it’s not that difficult to use an external cloud service to act as the “middleman” in your system design. Here, Brian looks at the technologies and services currently available for enabling you to ease into the IoT cloud.

Long before the term “Internet of Things” (IoT) was coined, many electronics enthusiasts were designing and building RF remote-control devices for their home or property. The choice of available modules was limited back then to mostly small ISM band (433 MHz) transmitters and receivers. These were usually OOK (on-off keyed) or occasionally FM (frequency modulated), and often used Holtek encoder/decoder chips to distinguish legitimate command signals from random RF noise. Security and hacking were seldom an issue. That’s because such projects were custom-built, and the range of the signals was limited. Therefore, any reasonable 8-bit microcontroller could act as the device’s controller.

After the Internet arrived, not much changed until Wi-Fi became prevalent in the home. Even then, until the Espressif ESP8266/32 arrived, it was still costly to add Wi-Fi capability to an MCU-based project. I’ve used half a dozen of these Espressif System modules around the house for control/monitoring. I generally communicate using simple ASCII commands under the UDP (User Datagram Protocol) transmission protocol. The user controller is generally one of my iOS devices (iPhone or iPad). In some cases, I’ve embedded a web-server in the project’s MCU code, so that I can control/monitor the device from a webpage, using the Safari browser. Because, in most cases, the data communication is directly between the Controller/Sensor device and the iPhone/iPad, there was no need for an intermediate server acting as the “middleman”.

What is becoming common in projects today is the use of control/monitoring device(s) to communicate with the user interface device indirectly, with some form of “always-on” server. This may be a server in your home—such as an always-on PC computer—or maybe a Network Attached Storage (NAS) device. This works fine inside your own home, or within your own yard, though you may not want to have a computer running constantly because electricity is expensive.

Now, many people opt to use an external “cloud” service to act as the “middleman.” This provides some combination of the following advantages, depending on the project:

• 1) No ongoing electricity costs to run a PC-based server.
• 2) The ability, in some cases, for the IoT device to be in a “sleep” mode most of the time, and wake up only occasionally to communicate with the server. This allows the IoT device to be powered by a small battery.
• 3) The ability to control/monitor the IoT device from outside of the home—that is, anywhere that Wi-Fi or cellular service is available.
• 4) The ability to have the IoT device directly send SMS messages or emails to the user—usually in an alarm-monitoring situation.

Numerous large-scale cloud services are available for business and industry on a monthly lease basis (Amazon AWS, Microsoft Azure and so one). It’s unlikely an individual with a home-based custom IoT product would want to make use of such a service. Many “free” cloud services are available to individuals, and some services fall somewhere between the two extremes.

A “CLOUD” FOR THE INDIVIDUAL
I don’t have a comprehensive knowledge of all the “free” cloud services available. The ones I’ve heard about were mentioned in the forums that I follow. I am a believer in the old saying that nothing in life is free. So, I see the “free” cloud services as falling into three broad categories:

• 1) The service is associated with social media firms. The services provided can involve data that can be analyzed, bundled and sold as “big data” to advertisers. These are not really free. You are the “product” that they sell to some other entity.
• 2) The service is provided by a hardware company free or at low cost, to enable their hardware products to perform the functions that they claim. They make their money on the hardware they sell. A variation on this would be Adafruit, which sells many different electronic products, including some IoT modules, and provides basic cloud services as a “perk” to its customers.
• 3) The company provides paid cloud services for large-scale customers, and offers stripped-down versions of the service at no charge to individuals or students.

In addition to those categories, I’ve seen “free” cloud services for which there doesn’t seem to be any way for the hosting company to make money. Having worked at a university throughout the early days of the Internet, I know that some online services were hosted by universities’ mainframe computers. Beyond that, however, I would be careful about using a free cloud service if it didn’t appear to have a way of sustaining itself financially.

When you choose a cloud service, you should give some consideration to the MCU hardware that you are going use for the IoT device. It’s true that cloud services operate using various standardized protocols. One example is the MQTT protocol, which is supported by APIs on many common MCUs. However, if you can buy an MCU module whose development IDE provides built-in cloud functionality, all the better. In Part 1 of this article, I’ll discuss the software development features of a family of IoT devices that I started using recently. In Part 2, which will appear in my January 2019 column (Circuit Cellar 342), I’ll discuss the hardware features of these modules and describe a project I built using one such module.

PARTICLE
I became interested in the cloud when a colleague asked if I could build him an over-temperature alarm for his lab. The lab contained several large instruments that generated enough heat to be damaged if the air-conditioning failed. The instruments ran continuously and were unattended during nights and weekends. The best notification method was an SMS message to his cell phone and/or an email message. Previously, I had built something similar for home use—a water leakage alarm—but he wanted it to work even if the electrical power feeding the lab failed. This ruled out both Wi-Fi and 10-BaseT network connections in the lab, because they both stop working when the power fails. Cellular communication seemed the ideal solution, but I hadn’t yet tried using cellular modems.

A search of IoT modules featuring cellular capability led me to the line of IoT modules from Particle. They currently sell both Wi-Fi and 2G or 3G modules, with LTE modules due out this fall. Because 2G won’t be supported much longer, and I didn’t want to wait for LTE, I picked a 3G module. Cellular service operates on different bands in different regions of the world, and Particle sells two different 3G cellular options: the N.A./Australia version, which I chose, and another for Europe/Asia/Africa.

I don’t have the capability to mount small, fine-pitch ICs/modules on PCBs, so I was happy to see that the 3G Electron module comes in a 36-pin DIP module. They also sell the functionally-equivalent E-Series module in a surface mount package. There was another important consideration. The Particle family also includes the Photon Wi-Fi module, also available in DIP and SMT packages. All Particle modules have a basic level of software compatibility. This means that you can do much of your software development on the low-cost Photon module, needing only Wi-Fi access. You only have to switch over to the cellular (Electron) module when you’re almost finished. As a result, you don’t have to worry about activating the Electron’s SIM card or having to start paying for a data plan until your firmware is ready to go.

The available cellular data plan is an important consideration in terms of monthly cost and the amount of data covered. I found Particle’s $2.99 US/month plan—which includes 3 MB of data—reasonable, and the Electron kit came with a SIM card. This data plan is free for the first 3 months. I was impressed with the hardware, which I’ll discuss in more detail in Part 2 of this article series. But I suspect that readers are equally concerned about the software development environment required to program a given MCU/module. Personally, I examine this very closely before deciding to use any new MCU device.

The Particle devices use a STMicroelectronics (ST) STM32F205 Arm MCU for both the Electron and Photon. The Photon uses a Cypress Semiconductor BCM43362 Wi-Fi chip and the Electron uses a U-blox SARA U-series cellular modem module. Despite the hardware differences, the software stack needed to run either the Wi-Fi or cellular functions is basically transparent to the user, being handled by a high-level API.

ST’s Arm MCU family seems to have hundreds of device variations. Until one gets familiar with such a large MCU family, it’s often daunting to set up and use the compiler toolchain and device programmer. Particle has chosen a unique way of handling code development, which differs from what I’m accustomed to. Next, I’ll describe their development system, and add some personal observations that I made as I proceeded from “square one.”

THE DEVELOPMENT SYSTEM
The most salient feature of the software development suite is that its editor and build process is a Web-based application. This application runs the compiler on a Particle server. Libraries, your source code and the final executable binary file also are stored on this cloud server. You don’t have to download and install a large tool-chain on your own PC. That said, you must sign up for a free Particle user account, which is needed to access the Web-based IDE and to register your devices. Web-based IDEs are not new. The web-based Arm “mbed” IDE platform has been around for several years. Microchip and Arduino have introduced Web-based versions of their development IDEs more recently.

I routinely use Microsoft’s Visual Studio with the Visual Micro plug-in for code development. This combination provides a very capable IDE with many features such as Intellisense code completion, context help and deep searches into dependency/library files. Because it is basically a “wrapper” around the Arduino IDE, it can be used with all the MCU development boards that Arduino supports. I currently use it for AVR, Teensy and the ESP8266/32 MCU/modules.

I expected that Particle’s Web-based IDE would be much slower than what I was used to. With my fast Internet connection, I have found the Particle IDE to be very responsive during operation. The processor-intensive build process is done on the Particle cloud server. During all my sessions, I found the time that it takes to build code was reasonable—about equally as fast as with Visual Studio/VM running on my Intel i7 computer with an SSD drive. My other concern was the actual development language. While there are now many languages available for MCU development, I prefer C and C++. The Particle IDE uses the simplified Arduino implementation of C++.

Although Arduino boards and their development IDE were initially dismissed as being too simplistic to be useful for serious developers, their overwhelming number of users has resulted in an unmatched number of libraries and peripheral drivers, along with arguably the most active user forums. It’s encouraging that many third-party Arduino libraries can be used directly, or with reasonable modifications, with the Particle modules.

Particle’s Web-based editor is similar to Arduino’s–definitely bare-bones. I would find it challenging to write complex programs with it, particularly if the program had many dependencies from external libraries. It’s definitely not as capable as the Visual Studio/VM IDE that I am familiar with using. Program code can be downloaded to a Particle module in several ways. By default, Particle expects you to perform over-the-air (OTA) downloading. However, before anything can be done with these modules, they must be registered on the Particle cloud. This registration process has two requirements:

• 1) The device must contain a bootloader, pre-loaded from the factory. This bootloader will communicate over either a Wi-Fi or a cellular network, depending on the model.
• 2) You must have a Particle user account, so that each module can be registered on the Particle server and associated with your account.

For both cellular or Wi-Fi modules, this registration process is technically somewhat complicated, but Particle has implemented a step-by-step process for it. You must go to their website at setup.particle.io, select your module as shown in Figure 1 and then follow the instructions. For Wi-Fi modules, you are instructed to download a ”photonsetup.html” file. You must next open this file, but only in the Chrome, Firefox or Opera browsers.

This will bring up a control panel (Figure 2), which instructs you place the Photon module in a known initialization mode by pressing the setup button. You then change your computer’s current Wi-Fi network to one labeled “Photon.” This allows your PC to communicate with the Photon module through its on-board Wi-Fi access point. You will be prompted for the SSID and password of your home Wi-Fi access point and asked to select a name for your module. This rather involved process is needed for security purposes, to ensure that your SSID and password can be stored in the Particle module’s flash memory, without it having to be sent over the Internet to Particle. A long security “key” that associates your module with your Particle account, (embedded in that photonsetup.html file) is also stored in the Photon’s flash memory.

ELECTRON REGISTRATION
The registration process for the Electron module (cellular) is necessarily different. You must activate the supplied micro SIM card via the Particle website. This requires you to supply your credit card information to pay for the cellular data plan after the free 3-month interval has elapsed. You must enter the SIM card’s ICCID number, which allows Particle to associate this specific Electron module with your user account (as long as you don’t swap out the SIM card later). As with Photon modules, you go through a Web-based, step-by-step installation process to register your Electron on Particle’s cloud server.

A part of the registration process is the “Claim Device” function, which establishes the “ownership” of a particular module to your Particle user account. There is also an “Unclaim Device” function, which you could use, for example, to transfer that module to another person (such as one of your customers). This would be necessary in most cases, because the customers would want to maintain their own cloud accounts, and not use those belonging to the project/software developers.

Once the device(s) are registered, you can write and modify programs using Particle’s Web-based IDE, and download them “over the air” to your module. How does the Web IDE know where to send your firmware, using OTA, if you have more than one module powered up? You must first specify which device is the target by selecting it using the name you gave it during registration. Click on the Devices Icon, as illustrated in Figure 3a and select the proper device. Figure 3b shows that I have one Photon, one Electron, and numerous Raspberry Pi boards. When this screen shot was captured, the targeted device was a Raspberry Pi Model 3, and it has a yellow star to indicate that. I’ll discuss Particle’s compatibility with the Raspberry Pi in Part 2 of this article. If you click on the “>” to the right of the device, it will give you information on the device, such as its ID #, or allow you to “signal” the device.

Tiny RGB LEDs are mounted on all Particle modules. The module’s firmware indicates the module’s MODE and various other states, by flashing various color combinations, or by letting the LED “breathe” one color—slow fading/brightening of the LED’s intensity. If you press the “Signal” icon, it will flash this RGB LED in a what is called a rainbow pattern, identifying the target module and indicating that it is “on-line”.

So far, all the program development and firmware downloading that I’ve discussed is done on-line. All applicable project files reside on the Particle cloud. However, there are provisions to allow you to download any or all these files to your local PC’s hard drive. Within the code window, there is a “black cloud” icon that will download a project’s binary code (.bin file), and an “↓” icon that will download your source code file(s) in .zip format. Apart from just saving local copies of your files, it is good to have a local copy of the binary file. This file is needed if you want to download firmware to your Particle modules using a USB cable, instead of the default OTA download method. We’ll look at this in the next section.

COMMAND LINE INTERFACE
Once you step away from the Web-based development IDE, you abandon Windows entirely and make use of a multi-purpose Command Line Interface (CLI), with the actual program name of “particle”. The CLI is a Node.js application that runs on Windows, Mac and Linux operating systems and handles utility functions too numerous to list here. Type “particle help” from the command prompt to see them all. Some of the more common ones are discussed here.

Particle flash. This can be used to flash firmware to a Particle module via USB. There are two modes: USB, which uses the DFU mode of the Particle module; and Serial, which uses the module’s on-board serial bootloader mode (which also uses the USB port). Read the documentation, as each method requires the MCU to be booted up in a specific way.

Particle serial. This opens up a terminal window on the PC. Any serial.println() statements in your firmware will cause that data to be sent out by the Particle module’s USB-emulated serial port. Note that this serial terminal will auto-identify which of the PC’s COM ports the Particle module has been assigned to. If you were to choose a different terminal program, you would need to run the PC’s Device Manager to determine the module’s assigned COM port, which will be labeled either “photon” or “electron.”

Particle setup. This allows you to create an account, set up Wi-Fi and claim a device to your Particle account. I haven’t used it, but assume it is a command-line version of the Web-based setup program mentioned earlier.

Particle device doctor. As its name suggests, this is a “last-resort” utility that allows you to wipe your device clean and re-install the various parts of the firmware needed to bring the device back to life in a “factory-fresh” state. Besides your own program’s firmware, there is also the freeRTOS firmware, and a section of the flash dedicated to the I.D. code and security key linking the physical device with your Particle account. All these components are re-loaded by the device doctor.

Particle subscribe and particle publish. When you use either particle.publish or particle.subscribe in your code, these functions allow the PC to perform the same functions as those performed by the Particle module itself. They are analogous to MQTT publish and subscribe functions, and will be discussed in Part 2.

I was initially successful getting my Photon module up and running with my own simple application firmware, using the Web IDE. Next, I registered my Electron module and loaded it up with the same firmware. Everything was fine for a day or so, then the Electron module lost its cloud connection and became invisible to the Web-IDE. I then had to resort to using the CLI to proceed. The Particle CLI must be installed separately on your computer. If you choose to do all your software development/OTA downloading from the Web IDE, you won’t necessarily need to install it—assuming you don’t run into any problems. I installed it on my Windows 10 64-bit PC, and the installation program didn’t throw any warning or error messages.

Re-flashing my own firmware to the Electron by USB using the CLI didn’t help solve my “dead” Electron module issue. Also, I was unable to get the device doctor utility to run. An “elite” forum member assisted with solving this problem. (Particle has a fairly active user forum). You might run into the same issue as I experienced. During the CLI installation, an SSL library is installed in your hard drive’s root directory (C:\), in a folder called “OpenSSL-Win32” (if that SSL folder was not already present). The CLI installer should have added a path to this folder in the Windows Environment. It didn’t in my case, and the device doctor function was unable to run without knowing the path to this SSL library. After I created this path, Windows 10 performed an update on my computer, removed the path that I had added from the Environment, and then solved this issue by adding the following line to my System variables list:

OpenSSL_CONF C:\OpenSSL-Win32\bin\openssl.cfg

Once I got the device doctor function working, I was able to restore the Electron to factory condition and then re-load my own firmware. I still don’t know why this problem initially occurred with my Electron module, but it hasn’t happened again. Beginner’s bad luck, I guess!

CONSOLE UTILITY
The Particle devices are supported by two forms of utility programs: PC-based and smartphone-based. For the PC, there is the Web-based Particle Console Utility. You can access this console on the Icon bar in the Web IDE (Figure 3a), which opens it up in a separate tab in your browser. You can also access the console from Particle’s website home page, using the “For Developers“ tab and selecting Console. You will have to login using your Particle account credentials.

The Console program has an icon for Devices, where it lists all the devices you’ve registered, along with the last time that each device “checked in” with the Particle cloud server. Regardless of whether your application sends data to the Particle cloud regularly, the RTOS firmware periodically communicates with the Particle cloud server as a background task. In the Device view, you can “unclaim” any device by clicking on the button labeled “…” (Figure 4). If you click on a device, you can view the events that the device is generating—basically in real time. All the identification numbers associated with the device are also shown—serial number, IMEI/ ICCID (cellular only) and the version of the OS that the device is running.

In addition to published events, the Particle devices can be programmed to make specific program variables and functions visible to the cloud server. If you choose to do this, these values will be visible in the Variable and Function Windows, respectively. I did not use this capability, because I didn’t know how much data would be transferred to implement this or how often it would be sent, and I didn’t want to needlessly exceed my 3 MB/month data plan allocation.

If you are using a cellular module, pressing the SIM card icon will reveal your data limits and a usage graph. If you press the Credit Card Icon, you will see the cost of your current data plan. The console program is a great way to determine if your firmware is generating the proper events, when triggered by hardware and so forth. And if your firmware subscribes to events, you can generate these manually from the View Device section of the program.

SMARTPHONE UTILITY
There is a Particle utility program for both iOS and Android smartphones. I have used only the iOS version, which works equally well on both my iPad and iPhone. This utility offers a subset of the Console functions mentioned above. Figure 5 shows the Device Screen, listing all the modules I have registered on my Particle account. The ones with the “?” are the various Raspberry Pi boards that I connected to the Particle cloud for testing. On the smartphone screen, the blue dot to the right of the Electron module is actually “breathing.” This is a “heart-beat” to indicate that my Electron module is currently online, though the screen capture doesn’t show that. If you select a device, you will see an Info Screen containing the same information shown on your computer’s Console section. There are also Data and Event tabs, which show the Variables and Functions that have been programmed into the device’s firmware, together with any events that are occurring—assuming the device is online.

The neatest feature of this utility is the screen that displays the Tinker application (Figure 6), which is installed by default on all new modules. The basic I/O pins (those present on all Particle modules) are labeled like an Arduino: 8 Digital pins, 6 Analog pins and 1 DAC output pin. In the Tinker app, clicking on a Digital pin icon will allow you to set its input/output direction, and if output is selected, you can then toggle the level by repeated presses. If you set a Digital pin as an input, its current logic state will be shown. The Analog pins can be set for analog input or output by pressing the pin icon.

When set as an input, it will display the 12-bit ADC value measured on that pin. If set for output, you can enter an 8-bit value, which will result in the pin producing a PWM waveform output with that duty cycle of value/256. Alternately, the six Analog pins can be used for Digital inputs/outputs. Finally, you can set the DAC pin to a specific voltage (from 0 to 3.3 V) by entering a 12-bit value. Particle Electron devices have almost twice as many I/O pins as those displayed, but they cannot be accessed by the Tinker application. This app will also allow you to rename the device or re-flash the Tinker program on any Particle device that shows up in the program and is “on-line.”.

DOCUMENTATION
Particle provides good documentation on their modules. This is accessed by selecting the “For Developers” tab on the home page and selecting Documentation. All the documents are HTML-based. To navigate the documentation (Figure 7). You can click on “Electron” and select the module that you are interested in. Similarly, if you click on “Guide,” you can select Guide, Tutorials, FAQ, Datasheets or Support. You must be careful to select your target device first. That’s because the information in the various sections—Guide, Datasheets and so on—doesn’t usually state that it pertains to a specific device.

An active user Particle user’s forum can be accessed from the “Community” section of the “For Developers” tab on the home page.

In Part 2, I’ll discuss the hardware features of the Particle IoT modules, as well as the circuitry and program code for the project that I mentioned early in this article. I’ll also discuss the integration of the Raspberry Pi with the Particle cloud infrastructure. 

Additional materials from the author are available at:
www.circuitcellar.com/article-materials

RESOURCES
Cypress Semiconductor | www.cypress.com
Espressif | www.espressif.com
Microchip Technology | www.microchip.com
Microsoft | www.microsoft.com
STMicroelectronics | www.st.com
Particle | www.particle.io
U-blox | www.u-blox.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • NOVEMBER 2018 #340 – Get a PDF of the issue

Brian Millier

+ posts

Brian Millier runs Computer Interface Consultants. He was an instrumentation engineer in the Department of Chemistry at Dalhousie University (Halifax, NS, Canada) for 29 years.

• Brian Millier

  https://circuitcellar.com/author/brian-millier/

  The Teensy Audio Station (Part 2)
• Brian Millier

  https://circuitcellar.com/author/brian-millier/

  Repurposing Old Disk Drives For Rotary Encoders
• Brian Millier

  https://circuitcellar.com/author/brian-millier/

  The Teensy Audio Station (Part 1)
• Brian Millier

  https://circuitcellar.com/author/brian-millier/

  Building a Touchscreen Display (Part 2)