LoRa (Part 7) – Building a Prototype LoRa Device

Bob wraps up his article series on LoRa. In the previous two articles, Bob examined MachineQ resources for LoRa development. Here, in Part 7, Bob explores creating a prototype sensor for the MachineQ network.

That’s what we’ve been discussing in the past six articles. This month we wrap up our not-so-deep-dive into LoRa. We are going to look at building a prototype LoRa device for the MachineQ network using a development kit and the example software. For testing, we will be using the off-the-shelf MachineQ LoRaWAN gateway. As I did with building a device and gateway for The Things Network (TTN), I want to emphasize the prototype nature of what I did. That’s because I don’t want to mislead you into thinking: “Wow! That part is all done and all I need to do is concentrate on my specific application.”

Au contraire. Using this hardware and software will get you going for a proof-of-concept prototype, but it is a long way from a certified, ready-to-build-and-deploy product—especially in terms of the software. We all have used example software that was little more than 10% of the finished product—all-the-while hoping that we could use that example software and be done with it.

In addition, I am a little concerned about the robustness of the off-the-shelf gateway I was using from MachineQ. Two days ago, I disconnected the Ethernet cable from the gateway at my router and put the cable into a different port. The gateway stopped connecting for 36 hours until I powered it down. I was already told there were problems with Wi-Fi in this area. This does not bode well for 24/7 unattended operation.

REMOTE RESET WOES

As a side note, we experienced this several years ago with an off-the-shelf cellular modem. We were in the midst of a feeding frenzy in Ontario when solar energy suppliers were knocking on doors asking homeowners if they could rent their roofs to install solar panels. Canada was recognizing that it needed to supply more electrical energy than its infrastructure could provide, but did not want to invest in the fossil fuel infrastructure [1]. The provincial government was paying an outrageous amount for homeowners to put electricity onto the grid using photovoltaics ($0.802/kW-hour! [2]). I pay just over $0.09/kW-hour for fossil fuel generated electricity.

Many companies were tripping over each other to get solar panels on every possible roof as fast as possible. We rushed out a modification of a design of a solar power energy monitor for one of our clients that used an off-the-shelf cellular modem powered by USB. Once a few were in the field, we found that some modems would stop communicating and require a reset. We quickly installed a fix to allow us to remotely power-cycle the modem. Ever since then something equivalent to this has been part of virtually all of our designs that incorporate complex (software) off-the-shelf systems. Basically, we don’t trust suppliers to create robust devices. You just cannot send technicians to the field to reset thousands of devices. So, if you are using anyone’s off-the-shelf gateway in a place that cannot be easily reset, consider providing the ability to remotely reset it or power cycle it.

Getting back on track, this month we will look at the hardware and the software I used to put together one LoRa node on an off-the-shelf LoRaWAN gateway on the MachineQ network.

THE HARDWARE

The LoRa device: For the LoRa device, MachineQ offers two development kits: The MQSpark is the simplest and comes with four Grove sensors for measuring temperature, sound, distance/speed and orientation (Figure 1). There are literally hundreds of Grove sensors [3] for you to experiment with. Robotics, motion, environmental and proximity sensors are available to rapidly prototype your new design. The device plugs into a USB port for power and communications. It uses the Arduino IDE for development.

All that said, I chose to use the other offering: the STMicroelectronics (ST) LoRa Development kit, which is for those who want to design their own sensor and require more advanced software and hardware. This kit consists of two boards. The main board (B-L072Z-LRWAN1) and the X-NUCLEO-IKS01A2 daughterboard (Figure 2).

Main board: Also known as the Discovery kit for LoRaWAN, Sigfox and LPWAN protocols, this main board contains a Murata CMWX1ZZABZ-091 module (Figure 3). This module contains an ST Arm Cortex M0+ Core with 192KB of flash, 20KB of RAM and 20KB of Serial EEPROM; a Semtech SX1276 LoRa radio; and variety of I/O (ADCs, DACs, USB, serial ports, discrete I/O, 7 LEDs, two pushbuttons and more). There is a battery holder on board for 3 AAA batteries. However, as shipped, the battery is not connected. You have to cut a jumper to connect the battery. Unfortunately, you then forfeit the ability to use the USB for loading, debugging and monitoring the software. Ouch! Very unfriendly for real development. I decided to buy a USB battery charger for a phone and use that for my range testing. I was impressed by the supported development toolchains: Keil, IAR Embedded Workbench for Arm, GCC-based IDE’s like Eclipse, and Arm embed. I used the Keil IDE, which was provided free with the purchase.

Daughterboard: The daughterboard provides the sensors for initial testing and reference designs. The board contains accelerometers, gyroscopes, a magnetometer, humidity, pressure and temperature sensors all on one board.

I have to digress a minute. A gyroscope? An accelerometer? That rings a bell. I worked on the Apollo program (Figure 4) and the Viking Mars lander’s inertial measurement systems. We had gyroscopes and accelerometers. The gyroscopes were large electro-mechanical devices. These were 2″ in diameter and about 3.5″ high—you can see the top of one in the upper right of Figure 4 and the side of another on the top left. The accelerometers were fragile pendulums suspended in a can (see one in the bottom right of Figure 4). But how can you have three dimensions of gyroscopes and accelerometers all in one little chip? Are there really little spinning gyroscopes in there?

The technology used on the daughterboard is called a MEMS or a Micro-Electro-Mechanical System. These are used in hard drives in laptops to detect when it is dropped to protect the head from crashing and in air-bag deployment systems. I can only point you to a few articles [4] [5] to describe how they work, but, let me assure you, they are really cool!

The LoRa gateway hardware: For the LoRa gateway, I used the Area 8C gateway from MachineQ. It is capable of connecting to eight devices. I connected it to the Internet via both Wi-Fi and Ethernet. Check out the MachineQ website for more details about this gateway [6].

THE SOFTWARE

As I mentioned earlier, I chose to use the Keil tool chain and was very pleased with it. The documentation was good and the tools were easy to use. Using a Windows 10 development platform, I was able to connect a USB cable to the Discovery kit, which provided both power and (because I didn’t cut the trace!) communications to the IDE for loading new software.

I made a few changes to the software to both brand it with a moving version number (so I always knew that I was making the changes I thought I was making) and to add control of an LED to indicate successful transfer communications to the gateway. The sample project was called “End node.”

I made most of my changes to main (main_machineq_v121_rev1.c). PRINTF statements (macro for a special printf) were used to provide debug statements to a USB serial port which I connected to via puTTY. Figure 5 shows a typical output during debugging. You could also set breakpoints and step through the code as needed. Overall, development was more seamless than I often experience.

PERFORMANCE TESTING

As with The Things Network device, I took my Discovery board device off its power umbilical and moved it and the MQFlex around the neighborhood. This time I had my grandchildren do the walking. All the while they were asking: “Can you hear me now?” The gateway was placed in the same spot on my roof for both tests. It turned out that I didn’t need my modifications to use the green LED on the Discovery board to determine when it was communicating because I was able to watch the results from the gateway.

MQFlex: As you may remember from my previous articles, the MQFlex is a self-contained set of sensors with an embedded antenna. It actually performed almost as well as the TTN ExpLoRer board. One thing I noticed was that the Spread Factor (SF) stayed at 7 even as the device was beginning to drop packets. Apparently, the software (by design or by bug) did not change the SF to increase the range (at the cost of increased radio time and increased power usage).

With the TTN and the ExpLoRer board, the range was 623 meters. The MQFlex achieved almost the same at 616 meters (Figure 6) before it completely dropped out. At that distance, my grandkids climbed a hill to a water tower and it recovered communications with the gateway.

Discovery board: This device had a stubby antenna on it (Figure 2) so I expected better performance. As the grandchildren started complaining about all the walking, it kept working. So, I sent them to a road that started down a hill because I knew the line-of-sight would be lost. Sure enough, as we started down the hill, within 50 yards it started dropping packets and eventually would not connect. Even so, I was impressed how much below the top of the hill we were when it stopped working. Overall, the maximum range I got was 816 meters. (Figure 7)

I noticed that the example software started adjusting the SF as it started dropping packets. I expected this software, which was put together as an example, would be like that from Microchip on the ExpLoRer board: using static transmit power and a static Spread Factor! But the algorithm looked quite sophisticated. The software has the allowable ranges of SF across regions as well as increasing it only when needed.

The code sets transmit power only once upon initialization, so that would be another thing that you would want to change if you were trying to minimize power. Here is where the prototype’s sample code becomes a project: creating a robust and sophisticated algorithm to minimize power while maintaining reliable throughput.

SUMMARY

Overall, I was very impressed with ST’s Discovery board and the sample software. It was reasonably well documented and I was able to find my way around the code quite quickly. The Keil tool chain worked flawlessly. You are now fully empowered to develop a sophisticated LoRa sensor. Of course, only in thin slices. Next time I am going to start a new article series on FreeRTOS. Stay tuned and stay safe. 

Read “LoRa (Part 1)” Here

RESOURCES
[1] See this 2011 report on their $293 billion dollar need https://www.cbc.ca/news/canada/canada-s-power-grid-needs-293b-infusion-report-1.1002711
[2] See this article about the government of Ontario lowering the rate from $.802/kWh to $.549/kWh in 2012. They lowered it again later. https://www.cbc.ca/news/canada/toronto/ontario-to-cut-rates-paid-for-wind-solar-power-1.1157717
[3] https://www.seeedstudio.com/category/Sensor-for-Grove-c-24.html
[4] For a very simple but clear introduction to MEMS gyroscopes, check out this article:
https://learn.sparkfun.com/tutorials/gyroscope
The video below from STMicro provides both an introduction (the first 4 minutes) and starting at 10 minutes, the technical background as to how gyroscopes actually measure the Coriolis effect.

[5] For a simple introduction to a MEMS accelerometer, check out this article by Sparkfun
https://learn.sparkfun.com/tutorials/accelerometer-basics/all
And this video by Bosch:

[6] https://store.machineq.com/store/products/area-8c

Arm Keil | www.keil.com
MachineQ | www.machineq.com
Murata | https://wireless.murata.com
STMicroelectronics | www.st.com
Semtech | www.semtech.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • OCTOBER 2020 #363 – Get a PDF of the issue

Sponsor this Article