Modules in Action
In Part 1 of this article series, Brian examined some of the technologies and services available today, enabling you to ease into the IoT cloud. Now, in Part 2, he discusses the hardware features of the Particle IoT modules, as well as the circuitry and program code for the project. He also explores the integration of a Raspberry Pi solution with the Particle cloud infrastructure.
After looking at broader aspects of easing into the IoT Cloud in Part 1, now it’s time to get into the hardware and software details. Let’s take a look at three of the Particle modules, shown in Figure 1. The P0 module contains the Cypress Semiconductor BCM43362 Wi-Fi chip and STMicroelectronics STM32F205RGY6 120 MHz Arm Cortex M3 microcontroller (MCU), in a small surface mount package. The Photon module contains this P0 module, plus a 3.3 V switch-mode power supply regulator, USB socket, mode switches and an RGB LED—all mounted on a 24-pin DIP package. The Electron module contains the U-blox SARA-U260/U270 3G cellular modem, the STM32F205RGT6 120 MHz Arm Cortex M3 MCU, a BQ24195 power management unit/battery charger, a Maxim Integrated battery gauge IC, plus the same mode switches and RGB LED contained on the Photon. It is mounted on a larger, 36-pin DIP module.
The Photon and Electron share a common set of peripheral ports. These include 1x 12- bit ADC with up to 8 inputs, 2x 12-bit DACs, 2x SPI, 1x I2C, 1x I2S, 1x CAN, 1x USB, 9x PWM, 1x UART and 18x GPIO.
The Electron module, having 12 more pins, has more of some of the above peripheral ports. Because the peripheral ports of both modules occupy many of the available pins, there will be fewer GPIO pins available if you use some the peripheral ports.
Particle provides libraries or high-level APIs for just about all the peripheral ports I’ve listed. The only peripheral port that I found was not supported was the I2S block. I2S is basically a high-speed bus dedicated to audio DACs/ADCs/Codecs. Due to the high speed, synchronous data transfers that I2S devices demand, such devices are generally not compatible with the real-time operating system (FreeRTOS) that the Particle device runs under (unless you use DMA-based I2S).
Particle’s GPIO, I2C and SPI API’s are written to be compatible with their counterparts in Arduino. Because of that, third-party Arduino libraries that are available for many common peripheral chips/breakout modules will work with the Particle modules without further tweaking.
— ADVERTISMENT—
—Advertise Here—
Both the Proton and Electron come with a tiny U.FL socket for an external antenna. In the Electron, a Taoglas external antenna is required and is provided. The Photon has a small PCB-mounted Wi-Fi chip antenna, but you can also use an external antenna if you are mounting the Photon in a case that doesn’t allow RF to penetrate. There is an Automatic RF mode, where the best signal from either the chip or external antenna is used.
The Electron module can draw around 2 A or more when communicating with a cell tower. This is more current than can be supplied if you were to plug the Electron into a PC’s USB port. Although you can get USB adapters that supply greater than 2 A, you wouldn’t be able to communicate with the Electron via USB, which would be handy during debugging. Particle wisely decided to include a Li-Po battery charger on-board and included a 2,000 mA-hours Li-Po battery with JST plug in the Electron kit. This assures the user that there will be enough power available to operate the cellular modem’s RF circuitry at full power.
As of this writing, the Particle 3G Electron (in the DIP package) is only available in an educational “kit” format, which includes the Electron module, antenna, LiPo battery, USB cable and a small protoboard. With all those support components included, it’s a good deal at $69. The E-Series SMT module, meant to be integrated into a commercial product, is more expensive ($79 in unit quantities), and doesn’t include any of the support components in the Electron kit.
PROJECT CIRCUIT DETAILS
The first Particle-based project I built was the over-temperature alarm that I described in Part 1 of this series. It also sends out an alert if the power fails. Figure 2 is a schematic of the circuit. I decided to use the Dallas Semiconductor (now Maxim Integrated) DS18S20 1-wire temperature measurement device. It is more expensive than a thermistor, but is accurate to within ± 0.5°C and doesn’t need any calibration procedure. The Particle library contains a “ds18x20” library that handles both the DS18B20 and the DS18S20 devices. These two devices differ in that each one outputs temperature at a different resolution, and the library handles this transparently. The DS18x20 can be operated in a 2-wire mode—signal and parasitic power on one wire, and ground on the other. However, timing constraints are less onerous if you use separate wires for the signal and power lines, and that is how I wired mine.
I chose a small Nokia 5110 LCD display for the user interface. These are inexpensive, as they are pulled from or are surplus units from popular older Nokia cell phones. An Arduino-based Nokia 5110 library works with Particle devices. This can be found in the “Library” section of the Particle Web-based IDE. The 5110 LCD has a separate backlight pin, which can be driven by a PWM signal, to control the backlight LED’s brightness. I run the backlight with a PWM duty cycle of 25%, which is plenty bright and uses less power.
The user controls are as follows:
1) An SPDT switch acts as the Setpoint UP/DOWN adjustment.
2) A TEST pushbutton, when pressed, simulates an over-temperature condition and sends out the same message for test purposes.
3) A RESET pushbutton is connected to the Electron module’s *RST pin.
4) While not shown in my diagram, I later added a switch in series with the Li-Po battery’s positive wire, to disconnect the Li-Po completely. This allows the unit to be turned off when the USB power adapter is unplugged and this switch is shut off.
The LCD displays the current time, which is synchronized with the Particle cloud server, so it’s very accurate. It also displays the measured temperature and the Setpoint temperature. The fourth line of the display indicates the AC power status. Because the power status is only monitored once per minute, it will not report a momentary power-loss.
Figure 3 shows the finished unit. The DS18S20 temperature sensor is externally mounted using a 3-conductor ribbon cable, to capture the actual room temperature—not the internal case temperature. Note that the LCD displays AC power fail. I took this photo outdoors for better lighting, so the power adapter was not plugged in.
PROJECT CODE
Particle devices run FreeRTOS as the underlying operating system. Your code runs in conjunction with it. Several System Modes are available. There isn’t room to cover them in detail here, but I’ll mention the following, based on the Electron module I used in the project.
— ADVERTISMENT—
—Advertise Here—
By default, the compiler will generate code, which places the module in Automatic Mode. In this mode, the module will first connect to a local cell-phone tower, and then make a data connection to the Particle’s Device Cloud. If it has problems, it will re-try either or both phases of this operation until it is successful. Your program code will not run until this 2-phase process has completed. So, if you have a display attached, and plan on having it show a “splash screen” or some other status indication during boot-up, it doesn’t work this way in Automatic Mode. That’s the downside. The upside is that your program doesn’t have to initiate the cell-phone/cloud connection, nor do you have to worry about re-connecting if the connection is lost.
Various other system modes are available, which give your program more control over the cloud connection, but your code will have to be a bit more complex to handle these issues. See the System Modes chapter of the documentation for more detail.
In my program, the Setup function basically configures the various GPIO pins that I use, sets up the SPI port for the Nokia 5110 LCD display and clears the display.
The Loop function does the following tasks:
1) Monitors the Setpoint and Test pushbuttons and reacts accordingly.
2) Measures the temperature by calling the DS18S20 Read routine at a program-specified interval in seconds (I use 60 seconds).
3) If the temperature exceeds the setpoint, the current temperature is “published” to the cloud using:Particle.publish(“temp”, msg);
where “temp” is the variable’s name, and msg is the temperature.
If the temperature remains above the setpoint, this event will be published every 15 minutes for a maximum of four times. After this, the program will not send any reports until the unit is reset.
4) Using the pmic.getSystemStatus() function, if the voltage coming from the USB adapter disappears, a power fail message will be sent out (also using the Particle.publish function.)
5) All the relevant parameters are sent to the Nokia LCD display.
Publishing these event “alarms” to the Particle cloud is only the first step. We still must turn these alarms into SMS/email messages notifying the user what went wrong. This is where the cloud server “IF This Then That” (IFTTT) comes into play.
IFTTT CLOUD SERVICE
IFTTT is a free cloud service. It is designed to allow people to associate the occurrence of some Internet-based event (the “trigger”) with the generation of one or more Internet-based actions (“services”). The combination of a trigger and a service is called an “applet.” You can either write your own applet, or just use one of thousands of applets that others have written and posted on the IFTTT website.
When you visit the IFTTT website, it is immediately obvious that most of the applets are centered around social media such as Facebook, Instagram and Twitter. Social media are popular these days, so the IFTTT service is similarly popular and well-utilized.
To use IFTTT, you must first register at the ifttt.com website. Registration is simple—you can register using your Google or Facebook account ID. The IFTTT registration procedure has security features built-in to ensure that random people can’t set up IFTTT apps in your name. During registration, they will send you an email message to which you must respond, to verify that you are actually the person that is attempting to set up the account. Like most modern websites, the IFTTT website uses cookies, so when you visit this website later, it will recognize you and automatically log you in.
I am going to briefly cover the procedure needed to set up your IFTTT applet for this project. However, I didn’t “invent this wheel” myself. I found a good online tutorial that explained it in detail. See the Circuit Cellar article materials webpage for step-by-step instructions.
Once registered, search for the “SMS” service, or follow the link provided in the tutorial. You will have to enter your cell phone number, preceded by your country code (001 here in North America). Once again, there is security to ensure that some rogue individual doesn’t write an applet that floods you with SMS messages. After you enter your cell phone number, click “send PIN”. It will send you an SMS message containing a PIN number that you must re-enter on the webpage on which you registered the cell phone number.
To send an email, you must use the “Email” service. This works much like the SMS service. You enter your email address, and go through a verification procedure.
After setting up the two actions or services that you want performed, you must set up a “trigger” to initiate them. Fortunately, Particle has collaborated with the IFTTT people and written custom services/applets that interact with their cloud server. So, when you are selecting the “trigger” for your own custom applet, you would search for Particle, then pick the “New Event Published” trigger that is displayed. You must press the “Settings” icon (a gear) and enter your Particle account information, to link this service to your specific Particle account.
You configure this Particle trigger by entering the following:
1) Event name—for this project it is “temp”.
2) Is (Event Contents)—leave blank for this project because the module only sends an event if the temperature is above the setpoint.
3) Device Name—this is the device name you gave your Electron module.
You have now created custom action services and one custom trigger service. You must next link the trigger and action services together in your own custom applet. To do this, navigate to My Applets -> New Applet. You will see a screen, as shown in Figure 4. Here it’s a bit confusing. To choose the trigger event, click on the blue “+” icon and select the Particle service you just defined. You must name this trigger with an event name. Use something that is be meaningful to you.
— ADVERTISMENT—
—Advertise Here—
Next, you must add the service that you want to have performed. This time click on the blue “+” icon to the left of “that.” Search for the SMS icon and fill out the “message box” the way that you would like your SMS message to read, then click “Create Action.”
If you also want to get email notifications, you can repeat the above procedure to make a second custom applet. This time just replace the SMS applet with the Email applet, and fill it out accordingly. There are opportunities to check out the actual operation of these functions as you set them up. You can send a test SMS message to your phone to ensure that everything is working properly.
At this point you have basically finished setting up your IFTTT applet. Make sure that you have toggled the applet(s) ON or they will not function.
If you also want to receive an SMS message if the power fails, you will have to repeat the above procedure. In this event, use “power” for the trigger “event name,” and leave the “Is (Event Contents)” section either blank or “0”.
RASPBERRY PI AND PARTICLE
I have used Raspberry Pi SBCs for several projects, and have several of the older, less capable boards sitting around doing nothing. So, I was interested in using them with Particle’s cloud infrastructure.
I found Particle’s support of the Raspberry Pi somewhat surprising. The Raspberry Pi is an SBC running under Linux, and the Particle IoT modules use a much less powerful MCU, running under FreeRTOS. It would not be unusual for the Particle cloud functions, themselves, to work with the Raspberry Pi. But I found it remarkable that you can write the same Arduino-based C/C++ code that you would use on the Particle modules, and have that work on a Raspberry Pi.
How, exactly, is this accomplished? The firmware that the compiler generates for a Particle module contains all the code that needs to run on the Particle module to perform your task. However, in the case of the Raspberry Pi, the firmware generated by the compiler is in the form of a daemon. That is, it is a task, running continuously in the background, under the Linux operating system. The fact that this daemon is always running does not prevent other programs from running concurrently on the Raspberry Pi.
How does the code generated by the Particle compiler get downloaded to the Raspberry Pi? As with the Particle devices, the firmware is downloaded over the air (OTA). To allow this to work, the Raspberry Pi module must be registered on the Particle cloud, to inform the compiler which Raspberry Pi board to send the code to.
To make this “magic” work, you must first load what is called the Raspberry Pi “Particle-Agent” software on your Raspberry Pi. This is done in much the same way as you would install any other Raspberry Pi software. First, you make sure your Pi OS is up-to-date by issuing from a terminal window:
sudo apt-get update
sudo apt-get upgrade
This will take some time. When finished, install the Raspberry Pi Particle Agent as follows:
bash <( curl -sL https://particle.io/install-pi )
This script will install the relevant files, and at the end of the process, will prompt you for your Particle account name and password. This will register this Raspberry Pi board with the Particle cloud, using a device name that it also prompts you for.
You can start/stop this daemon using the commands:
sudo service particle-agent start
or
sudo service particle-agent stop
I am fairly certain that the Particle-Agent daemon runs automatically at boot-up. I don’t recall that I had to place the agent-start command in the etc/rc.local file.
To compile/download your code to the Raspberry Pi, you must first select the Raspberry Pi by name, using the Devices icon in the Web-IDE. As with Particle modules, the download status will be displayed on the status line at the very bottom of the Web-IDE page. This happens quickly. Occasionally it will notify you that the process is taking too long, in which case it usually fails subsequently. This can happen if your Raspberry Pi doesn’t have a good Wi-Fi connection, or isn’t powered up, of course. But I have also encountered this message when the Raspberry Pi is powered up and Wi-Fi-connected. Generally, re-trying the download will be successful.
RASPBERRY PI FUNCTIONALITY
Particle provides the Raspberry Pi Particle Agent as a “perk” for its customers, because they don’t sell Raspberry Pi SBCs. I’m not sure who did all the work, but it’s available to the public on their Github repository (see Circuit Cellar article materials webpage).
When I started writing this article, the Raspberry Pi Particle-Agent was defined in Particle’s documentation as being an on-going project, separate from the main Particle device development process. As I finish writing this Part 2 article, I have discovered that the Particle Raspberry Pi project has been discontinued. You can still configure, connect, and flash firmware to your Pi, but new releases of the Particle Agent software are unlikely to occur in the future.
I found this discouraging. The Agent likely will not incorporate any new features in the future, unless Particle users, themselves, come up with new features or bug fixes. Whether or not the Raspberry Pi Particle-Agent will continue to work when future updates to the compiler/build process/libraries occur is anyone’s guess. Currently, the Github page for the Particle-Agent doesn’t mention this news. Some of Particle’s Raspberry Pi documentation is now harder to find, though it is still on the website if you search for it by topic. Despite this news, I would like to cover some of the capabilities that the Particle Agent provides for the Raspberry Pi.
At a basic level, the GPIO capabilities of Particle devices extend to the Raspberry Pi GPIO pins. The mapping of Particle module’s GPIO lines to the GPIO pins on the Raspberry Pi is shown in Figure 5.
I tested the 1-wire and I2C functions on a Raspberry Pi, and they worked fine. The SPI function works at 4 MHz, but the Particle SPI documentation is incorrect. If you refer to Issue #12 “SPI Port Issues” for the issue report that I made to Github, you’ll see the details.
If you want to run other Raspberry Pi programs from the Particle Agent, and/or monitor output from that program, you can use the “Process” command. The links to this have been removed from Particle’s web-based documentation, but the document’s webpage is still up. The Particle Device Cloud functions that are available on the Particle modules, are also available on the Raspberry Pi. Links to all of these are on the article materials webpage.
CONCLUSIONS
From a hardware standpoint, I found both the Photon and the Electron modules to be very versatile. The office where I do electronics development is a long distance from my Wi-Fi router in the basement. I noticed that the Photon module often had trouble connecting to my Wi-Fi access point, whereas the Espressif ESP8266/32 modules that I use have never had this problem. I think the Cypress Wi-Fi IC on the Photon board might have a less sensitive receiver, or a less powerful transmitter than that of the ESP8266/32. But, to be fair, the ESP8266/32 modules have a much larger antenna than the chip antenna found on the Photon module.
The Particle documentation is excellent. Because it is an HTML document, it’s easy to navigate to the information you’re looking for. You should heed my advice in Part 1 of this article about selecting the device and document category—such as Guide, FAQ, datasheet and so on—from the drop-down menus at the top of the documentation homepage.
Particle provides several useful utility programs—both PC- and smartphone-based—to assist you in the “cloud” aspect of your project. My only criticism is that the web-based editor is not nearly as sophisticated as what I, and most software developers, would be accustomed to when using PC-based IDEs. Particle provides a desktop version of their IDE, in addition to the web-based version. However, it still sends your source code to the Particle cloud server for the build process. I have not been interested enough to try it, because it is still not a completely “off-line” product.
I am hoping that the Raspberry Pi will continue to be useable with the Particle cloud infrastructure, and that the web-IDE will continue to allow you to build code that runs under the Particle-Agent daemon. Only time will tell.
I have one final observation. While I have referred to a Particle cloud server throughout the article, I am reasonably certain that their “cloud” service—which the company calls Device Cloud—is actually spread out among several different cloud servers. In fact, if you watch the status line at the bottom of your browser window, while you are loading the Web-IDE, the last thing you will see is that it is transferring data from www.facebook.com. Since I don’t have a Facebook account, this data transfer can’t have anything to do with my own personal data.
For detailed article references and additional resources go to:
www.circuitcellar.com/article-materials
RESOURCES
Cypress Semiconductor | www.cypress.com
Espressif | www.espressif.com
Maxim Integrated | www.maximintegrated.com
STMicroelectronics | www.st.com
Particle | www.particle.io
U-blox | www.u-blox.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2019 #342 – Get a PDF of the issue
Sponsor this Article
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.
