Bob continues his article series on LoRa. Previously in the series, he described the details of The Things Network (TTN). In Part 4, he explores one way to put a LoRa device on TTN.
Quite often clients come to our company and ask us to create a production version of their prototype. Oftentimes they’ve used off-the-shelf hardware and mostly off-the-shelf software. For example, a short while ago a customer came to us with a device that used the Beagle XM board, Linux, u-boot, a small LCD display and a proprietary camera. They wanted us to help them “productionize” the unit. As we put together the quote, I was amazed at how much more work was needed to get them ready for production. Even once the customer has the prototype up and running, there is usually a lot of work to be done.
— ADVERTISMENT—
—Advertise Here—
Some of the simple sounding, yet time consuming changes were things like getting u-boot to talk to the display and the USB drive at power up. And there were many more development costs, not to mention certification costs—FCC emissions certification, safety and wireless network certification, for example. So, if the scope of the amount of work to bring a prototype to production still surprises me after 40 years in the industry, you can imagine how often it surprises our budding entrepreneurs.
This month I’m going to look at building a prototype LoRa device and a prototype LoRaWAN gateway out of off-the-shelf hardware and off-the-shelf software. Using these parts, it took me less than 4 hours to get the prototype and the network up and running. I emphasize prototype 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-anddeploy product. We will look at the hardware and the software I used to put together one LoRa node and one LoRaWAN gateway. If you are not familiar with LoRa, check out Part 1 of this article series in Circuit Cellar 351, October 2019.
THE HARDWARE
The LoRa Device: For the LoRa device we used the ExpLoRer board by SODAQ (Figure 1) [1]. We are using the 915MHz version for the US. In general, we would love to have one chip/module that controls the radio in which we can also put our application software. There are several LoRa modules out there that operate stand-alone—in other words, not requiring an external processor. For example, the Laird RM186 and RM191 [2] allow you to write your application using their smartBASIC software and use the on-board GPIO, ADC, SPI, I2C and UART interfaces to talk to your sensors. The Multi-Tech xDot [3] allows you to program the chip directly in C/C++. Murata also sells a stand-alone unit [4].
I am convinced that someday our company will have an application that can use these stand-alone devices—LoRa, Bluetooth and cell. For now, our experience is that the development software is too immature, the learning curve on yet another SDK is too high and the module costs too high to develop the more sophisticated and low recurring cost applications that we are asked to quote using these modules. But we are a small fish in the big embedded pond. There are many applications that can use these types of modules.
— ADVERTISMENT—
—Advertise Here—
All of that is to say we chose a radio that requires an external MPU because it is most like what is required for the kind of projects we work on. And the development environment is standard. The board that we picked has a Microchip/Atmel SAMD21 (used in the Arduino Zero) for the external processor, a Microchip RN2903 LoRa radio, a Microchip RN4871 Bluetooth radio and ceramic antenna (which we are not evaluating at this time), an embedded antenna for the LoRa radio (PCB antenna), a Microchip crypto chip for storing the LoRa keys, 4Mb of flash and a rechargeable coin-cell battery. The battery was charged with a USB connector. That same connector was used for programming the SAMD21 and for the serial debug port. There is a jumper to allow you to power the board externally so that you don’t drain the coin cell when you are unplugged from the USB power source conveniently marked Int and Ext.
The LoRa Gateway Hardware: Since we were evaluating The Things Network (TTN), we went with a Raspberry Pi 3 model B+ [5] and RAKWireless RAK831 LoRa Gateway (the 915MHz version for the US) [6] which included a stubby antenna. We required some generic jumpers to connect the Pi to the radio and a power supply that would support the power draw of the two modules. You need a USB power supply that can supply 2A through a micro USB connector, so I used a Canakit power supply [7].
Unfortunately, the radio does not just plug into the Pi, so jumpers are needed. The Pi talks to the radio over the SPI bus with the Pi as master. The radio needs: power, ground, a reset and the SPI bus connections (MISO, MOSI, SCLK and Chip Select). Table 1 shows the connections. Figure 2 shows a block diagram of this setup with a photo of it shown in Figure 3.
THE SOFTWARE
LoRa Device Software: Because the device that we chose is based on the Arduino Zero hardware, the vast array of Arduino development software is available to you. I downloaded the SDK version 1.8.10 from Arduino.org. With the ExpLoRer board, I received some documentation and a number of example sketches. The LoRaWAN101 [8] sketch provided everything I needed to send temperature up to TTN since the board had a built-in temperature sensor. This is a standard Arduino sketch, which was easily compiled and uploaded to the ExpLoRer board using the Arduino SDK.
The only necessary changes that needed to be made were to add the user ID and keys provided when you created the TTN gateway interface:
// LoRa Definitions and constants
// For OTAA. Set your AppEUI and AppKey. DevEUI will be serialized by using HwEUI (in the RN module)
const char *appEui = “FILL in the EUI”;
const char *appKey = “FILL in the Key”;
Additional changes were made during testing to evaluate the effect of changing the transmit power, the Spread Factor, the time delays between sending messages, enabling more status for Serial Debug and the way the LEDs were displayed. These were done with simple constant changes in the code and in the h files. I was not previously familiar with the Arduino SDK, but found it very simple to use.
LoRa Gateway Software: The gateway we created uses Linux and a packet forwarder called poly_pkt_fwd. A packet forwarder talks to the RAK 831 over SPI and then sends the data up to the host over Ethernet or Wi-Fi (we used Wi-Fi) using a non-authenticated and non-encrypted UDP protocol. I followed the instructions on Hackster.io [9] to configure and set up the Gateway. It does assume that you are familiar with Linux. I won’t repeat the instructions here because they were very straightforward and well written. I used my local Wi-Fi network for connecting the Pi to the Internet. I used PuTTY [10] to connect to the Pi to configure and verify operation.
The basic steps for configuring the Pi to become a LoRa gateway are outlined in detail at Hackster.io. They are as follows: 1) Enable the SPI bus; 2) Configure the Wi-Fi with your SSID and password (unless you use Ethernet); 3) Download and install the gateway software from github; 4) Register yourself and your gateway at the TTN site (Note: You do have to wait overnight for it to register your gateway). Once this is complete, Viola! Your gateway should show up on the world wide map of TTN gateways. Figure 4 shows my gateway in Avon, Connecticut. Notice the lack of TTN gateways in my area!
If you log into the Pi (with PuTTY for example) and run “top,” you should see poly_pkt_fwd running as in Figure 5. The installation process automatically puts poly_pkt_fwd into the Linux startup, so it will run every time the Pi starts up.
We need to mention that there are a wide variety of packet forwarders available. Semtech created a prototype UDP protocol to which others have added enhancements. This is what’s called the legacy packet forwarder. But all of the packet forwarders using the UDP suffer from the following problems: 1) No authentication; 2) No encryption; and 3) Unreliable communications. To solve this, TTN defined its own protocol called the Gateway Connector Protocol which has authentication, has encryption and is reliable.
Unfortunately, the project has been put on hold because of the complexity and lack of resources. Every project has its own unique security risks and security requirements. Because the data is encrypted at the device and decrypted on TTN backend, this may be sufficient for some systems. But if you want a production quality secure gateway that talks to TTN that you build yourself, you will need to find a packet forwarder that includes authentication. I haven’t found one. If any of you know of one, please pass it on to me.
PUTTING IT TOGETHER
While connected to the ExpLoRer board via USB, you could run the Serial Monitor that comes with the Arduino SDK to monitor traffic, assuming that you compile it with the following line in the main loop uncommented:
ExpLoRer.showStatus(); // Un-comment during LoRa debugging to see status in Serial Monitor
In addition, I printed some additional items. Figure 5 is an example of what shows on my Serial Monitor. You can see in the printout when a transmission is successful and the Power Index as well as the Spread Factor. These are things I varied in my testing.
On the Console for the Gateway on TTN you can also see the traffic. This is necessary to verify transmission once you disconnect from the Arduino Serial Monitor. Figure 6 shows you the data that this provides on a series of transmissions from the gateway. Figure 7 shows the TTN console.
Finally, using PuTTY, you can view the SPI and the socket traffic on the Raspberry Pi or you can be more sophisticated and use either a hardware tool like an Aardvark to read the SPI traffic, and a software tool like socat (socket output cat). You can install socat with the command line:
sudo apt-get update && sudo apt-get install socat
If you kill the poly_pkt_fwd started at startup, you can restart it with strace capabilities and get a significant amount of data on your Linux console:
strace -s9999 -o poly_pkt_fwd.strace -eread,write,ioctl ./poly_pkt_fwd
PERFORMANCE TESTING
Finally, I took my LoRa device off its power umbilical and carried it around the neighborhood, which is completely filled with trees and hills. Overall, I was impressed given my tiny PCB antenna. My initial tests showed that I could only get about 100 meters distance. I found that the software that came with the node had not set the RF power to the maximum allowed. I found that the default transmission power was set to 6, while the maximum was 10. After modifying the software, I set the RF power to 10 and the Spread Factor to 10 (which takes more air time). I got a little over 623 meters (Figure 8). The satellite view in Figure 8 shows the kind of houses, water and trees over which it was successful. At 600 meters it was successful about 1 in 30 tries. At 643 meters it never connected in over 300 tries.
Another thing I discovered is that the antenna orientation is critical. At 623 meters, it was very sensitive to orientation. LoRa relies a lot on reflected RF signals. Therefore, if possible, you may need to make the mounting angle of your sensor flexible and provide an RF indication of maximum signal strength when your device is mounted if you are pushing the range envelope. Taking an extra 30 seconds on installation to adjust the orientation could save a lot of grief.
Certainly, the off-shelf software on GitHub that I evaluated was far from production ready. A properly designed gateway would need to be more robust and more secure for most of the applications that we usually are involved with. The software in the ExpLoRer board seemed more robust during my testing. I did not see automatic power reduction algorithms to extend battery life as I saw in the gateway software, but other than that it looked pretty far along toward a production release. As always, I have only looked at this in thin slices. 
RESOURCES
References:
[1] SODAQ Explorer Board[2] Laird Stand-alone LoRa Module
[3] Multitech Stand-alone LoRa Module
[4] Murata Stand-alone LoRa Module
[5] Raspberry Pi 3 Model B+
[6] LoRa Gateway RAK831
[7] Gateway Power Supply
[8] Source Code for LoRaWAN101
[9] Instructions for bringing up the Pi gateway
[10] Putty
Arduino.org | www.arduino.cc
CanaKit | www.canakit.com
Laird Connectivity | www.lairdconnect.com
Microchip Technology | www.microchip.com
Multi-Tech Systems | www.multitech.com
Murata | www.murata.com
RAKwireless | www.rakwireless.com
Raspberry Pi Foundation | www.raspberrypi.org
Semtech | www.semtech.com
SODAQ | www.sodaq.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • APRIL 2020 #357 – Get a PDF of the issue
Sponsor this Article
Bob Japenga has been designing embedded systems since 1973. From 1988 - 2020, Bob led a small engineering firm specializing in creating a variety of real-time embedded systems. Bob has been awarded 11 patents in many areas of embedded systems and motion control. Now retired, he enjoys building electronic projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org
