Long Range Embedded Systems — Part 2
I’m prepared and now it’s time to test the embedded systems. The challengers are:
Semtech SX1276 Modules
I’ve rounded up 4 representative Semtech SX1276-based modules.
The Pycom LoPy is an embedded module that is based on an ESP32 chipset. It includes Bluetooth (3.0), Wi-Fi, and LoRa. The fully-shielded module comes with a very good custom version of MicroPython preinstalled. The 1.0 LoPy is too memory-constrained although newer Pycom modules (some of which have the same LoRa hardware) are not. It uses an SX1276 chipset internally and a U.Fl antenna connector. They support the +20dBm high power port only. Software is open-source. Hardware is closed-source.
The inAir9B is a Semtech SX1276-based module with shielding. Modtronix (based in Australia) claims excellent RF performance and high-quality components for their open-source module. MicrocontrollerShop is a U.S. distributor. Note that the U.Fl version is only available from Australia, and oddly MicrocontrollerShop solder their pins in upside-down (but you can get it unsoldered). The inAir9B supports the +20dBm high power port only.
I also have some inAir9 modules (lower power) with SMA connectors in the same configuration.
The Heltec LoRa is available very inexpensively via Aliexpress and Amazon. It’s an ESP32-based design with a 0.96" OLED display, a LoRa interface, and WiFi/Bluetooth. All packed into a chip-module. Looking at the implementation it’s hard to imagine RF performance is any good. There’s no shielding, the chip is under the display, and there are very few passive filtering components. One might speculate the SX1276 is a clone, but that’s just speculation.
Hope RFM95-based Modules
I have two distinct RFM95 implementations. The modules are the same so I’d expect similar characteristics. I also have two modules I bought via Digi-Key and sold by RF Solutions that will go into boards soon. We’ll see if they’re all the same.
HopeRF licenses the technology from Semtech and do not use an SX1276. The unshielded close-source RFM95W module is virtually identical to some of the SX127x modules and it is pin- and software-compatible.
I have three RFM95W-based modules to test.
Adafruit Feather M0-LoRa
Two are Adafruit Feather M0-Loras — an M0 with an RFM95W module. One has a wire antenna and one has a U.Fl (with an SMA adapter).
This Feather is a very simple design and the RMF95 output is wire or U.Fl.
Adafruit LoRa RF Featherwing
The Adafruit LoRa Featherwing is an add-on wing for Feathers with an RFM95W module and a switch on it. I’ve soldered on an SMA adapter.
Frequency Accuracy Test
Accurate frequency calibration is critical for reliable LoRa communications. Semtech suggests a misalignment error ≥25% of the LoRa bandwidth will cause total packet failure. In my testing the 25% seems optimistic. Let’s assume 15%.
If you want to really stretch your range and run at (not-recommended) 32.5KHz that’s a maximum misalignment between the two systems of about 5KHz (5PPM at 915MHz)!
When you add in temperature drift issues… factory calibration is important.
Although the inAir9x modules are not precise on frequency, their error is consistent on the low side and so they’ll work ok together (each generation in particular is well-matched with the other) — not so well with other folks. The Heltecs are hit and miss. The RFM95W modules do well here.
[Update]: I have purchased a GPSDO (a very high resolution clock) to calibrate the LimeSDR mini frequency. According to the GPSDO (which is accurate to about 1Hz) the mini error at 915MHz is about 5Hz. So, the values printed above are very accurate.
More interestingly, what we see here I think are production runs of components (with the exception of Heltec and I don’t remember their provenance). Proving that if you want two to talk to each other buy them at the same time.
The Pycom wasn’t usable in this test because it only supports a bandwidth of ≥125KHz — way too high to be useful for this deviation testing in my system.