Much has already been said about the LoRa PHY, but perhaps less-so about the transceivers you must select if you wish to implement LoRa. All blog articles about LoRa tend to focus on the PHY and not the embedded systems perspective. I will evaluate both aspects.
Introduction to LoRa PHY
Almost four years ago I wrote a review of the ST SPIRIT1, which turned out to be quite popular. I was one of the first to implement anything on the SPIRIT1, although I’m not among the first to implement on the SX127x LoRa transceiver. 2016 was a good year for LoRa, and a lot of information exists about the LoRa PHY itself. I’ve referenced a few of my favorite articles below. You don’t actually need to understand everything described here, and in the next section I will describe succinctly what matters from the perspective of an embedded systems integrator. If you’re a wireless communications expert, though, you will want to read up.
- LoRa Modem with LimeSDR (PHY synopsis)
- LoRa Modulation Basics (Semtech Application Note)
- Reversing LoRa (reverse engineering LoRa encoding), plus … a video lecture
- Low Power Wide Area Networks (Something of a critique on the LoRaWAN MAC)
Everything You Need to Know about LoRa PHY in 5 Minutes
Semtech remains the single-source supplier of LoRa transceivers, despite rumors I’ve heard that ST is building one (I suspect it’s an SiP making use of the Semtech die, but I’m happy to be wrong). Today, at least, LoRa is synonymous with Semtech SX127x, and that leads to a bunch of pros and cons.
The Data Rate is Slow, but that’s Probably OK
Practically, the best you can get with LoRa is 15 kbps, and that’s in countries that accept FCC 15.247 (i.e. the Americas). In the rest of the world, you’ll max-out at around 4 kbps for long range apps, although in ISM 433MHz you can use 15 kbps at 1 mW power. This limits the types of applications you can use it for, but for LPWANs this doesn’t matter much. It does limit the utility of LoRa for LAN-type operations, though, outside the Americas.
CSS is Very Good, but It’s not Jesus
LoRa uses a type of chirp-spread-spectrum (CSS) modulation. This can also be thought-of as an M-FSK with large M and a particular type of symbol encoding. The company Nanotron has been using wideband CSS for indoor location, for at least a decade (Nanotron was bought by ST, so ST probably has the necessary IP to build LoRa without Semtech’s blessing, but I’m just guessing here). LoRa is effectively narrowband CSS (125-500kHz), but like all CSS it has high autocorrelation properties, so it is good as a spread spectrum modulation. According to theory, CSS is 1 dB better in correlation than the traditional DSSS modulation over QPSK/MSK, which is nice but not actually a great improvement — 1 dB is easily made-up-for by other optimizations, and I would bet that a fully digital modulation with a more sophisticated error correction scheme would make better use of silicon area and thus yield higher overall sensitivity. With that said…
LoRa’s Error Correction is Actually Counterproductive
This is the nasty part. Semtech writes that they use some type of “cyclic code” in the documentation. The cyclic code we all know and love is Reed Solomon (my RS implementation: marketing, Q&A). It turns out that Semtech just uses a Hamming Code instead. A convolutional code approach with soft-viterbi decoder (such as in TI, ST, and Axsem parts) or alternatively a clever approach using symbol SNR gating with a fast Walsh-Transform RS erasure implementation (excellent paper by F. Didier) would yield much superior performance. But they use what is essentially a glorified parity bit, instead, and parity bits can usually only identify errors, not correct them. In other words, the 4/5 and 4/6 codes will not provide any error correction per Hamming Code analysis (this is in-line with observations among the LoRa community), and the 4/8 code is redundant. The only one you should use is 4/7.
And here is where it gets embarrasing. LoRaWAN uses the 4/6 coding, which results in a 50% reduction of bit energy without providing coding gain. The net result is a -1.71 dB coding gain! Any advantage you got from the CSS modulation just got washed away. Perhaps they will fix this is the next version of LoRa. Semtech: if you’re reading this, my consulting rates are very reasonable, and you already have my contact info.Survey of some error correction schemes available to common IoT/LPWAN techs.
You’ll Want to Build Your Own Payload CRC
LoRa utilizes a dual CRC frame structure, with a CRC protecting the header and then a CRC at the end of the payload. This is very good as an architecture. However, they choose the CCITT CRC-16 polynomial, which is weak. You will want to implement your own CRC on the microcontroller. That’s not really a big deal, but it’s something to consider. My OpenTag implementation is open source.
The Semtech RF Front End is Excellent
Most of the true benefit you get from LoRa is simply that Semtech made a great, very sensitive front-end for the radio. Semtech has been making very good, very creative low power radios for years (SX121x, SX1282, SX123x), and their LoRa parts are the best ones they’ve designed yet.
Notes from Implementing DASH7 with SX127x
Now that the basics are done, let’s dive-in to the finer points of the SX127x itself. DASH7 is a sophisticated protocol, and it requires utilization of basically all the features the SX127x has to offer, and more that are implemented in firmware. I will highlight what I like about the SX127x, regarding the interface and programmability, and also what I don’t like so much.
Code Metrics: SPIRIT1 vs. SX127x
I’ve run sloccount on the SPIRIT1 and SX127x drivers for OpenTag (I used default settings on sloccount). Much of the pre-existing SPIRIT1 driver was rapidly portable to SX127x, as they use a virtually identical SPI bus interface and method for transferring interrupts across pins to the MCU — this helped cut-down the actual time spent in development, dramatically, because I could utilize my existing, bulletproof SPIRIT1 driver to a large extent. Nonetheless, the SX127x implementation is ~200 lines of C shorter than the SPIRIT1 implementation.
|Code||100% C||100% C|
Caveat: Rigid Packet Architecture Hurts Flexibility
The shorter code comes at a price, though, as the SX127x is not able by any means to support multiframe packets (i.e. packets with longer than 255 byte payloads). It’s also incapable of streaming via the FIFO, and there isn’t even a way to hack it. The bottom line is that if you want to use LoRa with DASH7 or even an IEEE 802.15.4 type of protocol, you will need to use Spreading-Factor 7 (or higher), which maxes-out at 15kbps (~4kbps in EMEA). You will also need to keep packets below 255 bytes. It is also possible to use MAC-layer Reed Solomon error coding with LoRa, but it’s not possible to do adaptive coding. The difference here is that the adaptive coding is specified in a header, and the LoRa header is impenetrable to the user. Semtech: in future LoRa, you should use a good CRC-8 polynomial on the header (like the Baicheva polynomial), which will outperform the lousy CCITT-16 polynomial anyway, and which will free-up 8 bits in the header for users to be creative with.
Win: Flexible State Model
A lot of parts have a rigid state model (like SPIRIT1), but the SX127x has a flexible state model by which any state can be entered from any other. For the firmware developer, a rigid state model vs. a flexible state model is the equivalent of driving a rally car vs. a highway cruiser with soft steering and automatic transmission. It required a lot less debug time to get the SX127x driver running well, but ultimately it’s not nearly as fast as the SPIRIT1 driver. At the low data rates LoRa uses, this hardly makes an impact, though, on power consumption. Moreover, the SX127x model is fast enough that it doesn’t really impact the RTOS, either.
Highlighting a Cool Feature: CAD
“CAD” means “Channel Activity Detection,” and it is the facility designed into the SX127x for doing carrier sense, clear channel assessment, and preamble sensing all in one. This makes it really, really handy for doing channel sampling for wake-on radio MACs like DASH7, as well as CSMA (i.e. listen before talk). The procedure of doing CSMA and wake-on detection on devices like SPIRIT1 and CC1200 is far more involved, from a firmware perspective, and takes longer. CAD will basically finish in less than 256 us, sometimes far less, while the CS/CCA+PQT model in a DSSS system tends to require a bit more time (about 400 us). This might seem small, but it results in a substantial energy savings because this process happens a lot.
Evaluating the Competition
Semtech has done a good job marketing that LoRa CSS is an absolute requirement for LPWAN. Of course, that can’t be true because SigFox uses a random-frequency-hopping ultra narrowband solution, but if you want to do any sort of 2-way communication, reliably, across an LPWAN I would highly suggest using a spread spectrum modulation. TI has DSSS-capable parts in the CC120x and CC13xx, which are superior to LoRa options if you need higher data rate (basically, their sweet-spot is between 10-100kbps, LoRa’s is 0.3-15kbps). If you’re deploying in the Americas, the DSSS approach probably makes more sense because you can transmit with up to 1W via FCC 15.247. In EMEA, the LoRa approach is basically the only approach so far. Here’s a table evaluating some popular LPWAN and SRD transceivers from the last few years.Feature survey of common LPWAN transceivers
Other Things to Note
- The SX1272 is for the 860 and 900 MHz bands only. If you are using 169, 433, 790, or some other frequency, you’ll need to use the SX1276, which is larger, more expensive, and has more external passives. That’s a shame, because 433 MHz is probably the best frequency for LoRa application in most of the world.
- For all SX127x devices, there are a lot of external passives and the chip packages themselves are quite big. For ultra miniature devices, TI’s CC13xx parts are the best bets. I know that integrated baluns exist for CC13xx, and I expect that one might exist for SX127x by now, but I’m not sure. If you need to miniaturize LoRa, look for an integrated balun.
- Good MCU firmware packages for SX127x seem to exist for STM32L0, STM32L1, and PIC18. Why you’d choose PIC18 is a giant fucking mystery to me, but it’s an option. By far the best LoRa dev kit seems to be the Nucleo LRWAN1 kit. It’s functional, cheap, the STM32L0 MCU is great, and the kit is widely distributed.
The one take-home message for embedded systems integrators looking at the SX127x parts is that you may not have the freedom to implement your protocol the way you want, so review the datasheet closely (feel free also to send me an email, I can help you with chip configuration, passing regulatory, etc.). Continuing with the car analogies from before, in my SPIRIT1 Review from 2013 I compare the SPIRIT1 to the Delta Integrale, which is still apt. The SX127x reminds me of an automatic VW Golf Diesel (including my opinion that the lousy error correction is a let-down equivalent to VW’s emissions debacle with the Golf). Nonetheless, I still love the Golf Diesel and I would covet one… in manual. That really sums it up. With only a couple small changes, the SX127x would be really great (namely, a streaming FIFO and a header design with a user-flags section). With those changes plus legitimate error correction, it would be an instant classic.
If this part were using something like QPSK rather than LoRa, it would rate at 3/5 stars in my book. In other words, nice, but unremarkable, and you might be wise to look at other parts that don’t cost so much. But I can’t ignore and respect the fact that it uses a novel modulation that took a decade to develop, and which works quite well, so I feel obligated to provide 4/5 stars. In any case, it’s the only game in town that supports LoRa, so even if it were an abysmal disaster of a part, you’d still need to use it. Hopefully 2017 will be the year where a company like ST, which should be in the clear from an IP perspective, releases it’s own LoRa part with better capabilities and price.