Hands on with LoRa in North America. #3

HopeRF RFM95, Teensy and Multitech LoRa Conduit working together.

<-PART 2

In order to test HopeRF radio, I decided to use the existing code running on Teensy MCU (v: 3.2) in public LoRa mode.
You will need the following:

Keep in mind that my goal here is to focus on HopeRF’s radio testing as Teensy MCU is way too expensive and consumes too much power to even be consider it for production usage.

To start, you will need to solder few wires together:

Teensy LC/3.1/3.2 — RFM92/95


3.3V — 3.3V

RFM95 & Teensy LoRa Solution

RFM95 & Teensy

2 — DIO0

5 — DIO1

6 — DIO2


10 — NSS

11 — MOSI

12 — MISO

13 — SCK

Since Teensy is basically yet another Arduino Development Platform, we will use Arduino SDK with Teensyduino add-on to program Teensy with IBM’s LoraMac.

You can just follow this set of instructions to get Teensyduino running on your platform.

Once installed, try compiling one of the demo programs for Teensy, just to make sure that everything went ok.

Now, we are ready to proceed with actual LoRaMac code. First, Clone the whole package to your system, then add it as new library to your Arduino SDK.

LoRa LoRaMac Installation

You are almost done ;), just few modifications left…

I will be using defaults with the exception of the DevAddr below.

In the main file, we need to change DevAddr to something unique globally.

static const u4_t DEVADDR = 0x03FF0001 ;

//In this example I used 0x03FFEBB2, you will see it below in the section when we define node manually in gateway's db. 

This is equivalent of MAC address associated with your Ethernet port. In production, you will have your own prefix, obtained from IEEE, but for now we can just use anything, as long as it’s not duplicated on your network.

Then, we will adjust Spreading Factor from 11 to 9 to match gateway configuration (as per FCC in North America, Spreading Factor could be between 7 and 10).
// Set data rate and transmit power (note: txpow seems to be ignored by the library)

Now, you need to use your favoured editor to change the config.h located under arduino libraries (in case of MacOS: /Users/<Your User Name>/Documents/Arduino/libraries/arduino-lmic-v1.5-master/src/lmic to support 915MHz as North American ISM frequency and SX1276 chip for RFM95 HopeRF radio module.
#ifndef _lmic_config_h_
#define _lmic_config_h_

// In the original LMIC code, these config values were defined on the
// gcc commandline. Since Arduino does not allow easily modifying the
// compiler commandline, use this file instead. (MK)

//#define CFG_eu868 1
#define CFG_us915 1
//#define CFG_sx1272_radio 1
#define CFG_sx1276_radio 1

// 50 μs per tick
#define US_PER_OSTICK 50
#define OSTICKS_PER_SEC (1000000 / US_PER_OSTICK)

#endif // _lmic_config_h_

You can connect your Teensy, compile your code and program your board.

Go back to your gateway and manually add the node:
# nc -u localhost 6677
node add 03FFEBB2 0200000000EEFFC0 4242456789ABCDEF 2B7E151628AED2A6ABF7158809CF4F3C 2B7E151628AED2A6ABF7158809CF4F3C

Using the following syntax: node add [DevAddr] [APPEUI] [DEVEUI] [NwkSKey] [AppSKey]

Depending if you run gateway or packet forwarder, go to you logs or run mosquitto_sub -t lora/+/up to see incoming packets.

As soon as you run your demo code, you should see something like that:

where “d29ybGQ=” is base64 representation of the word “hi”.

Almost forgot about last cosmetic modification… in order to avoid an extra character at the end of the string, modify
// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, mydata, sizeof(mydata), 0);

to // Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, mydata, sizeof(my data)-1, 0);

Enjoy and stay tuned…

Soon, I will share my experience with modules from one of the new LoRa node makers from China.

I will also experiment with LoRa range, explaining ways to get the most from your node…

Stay tuned…

LoRa Hybrid Mode and FCC regulations

As indicated in my previous post, LoRa implementation in North America presents itself with several challenges imposed by FCC regulations. However, hybrid mode deployed by Multitech and Kerlink and probably also by Link Labs provide clever solution to this problem:
As per Semtech: There is an FCC OET publication [5] that details a possible hybrid mode scenario:

It is possible for a device to be designed to operate as a DTS, as a FHSS system, or using a combination of these two modulation types.
A hybrid system uses both digital modulation and frequency hopping techniques at the same time on the same carrier. As shown in Section 15.247(f), a hybrid system must comply with the power density standard of 8 dBm in any 3 kHz band when the frequency hopping function is turned off. The transmission also must comply with a 0.4 second / channel maximum dwell time when the hopping function is turned on. There is no requirement for this type of hybrid system to comply with the 500 kHz minimum bandwidth normally associated with a DTS transmission; and, there is no minimum number of hopping channels associated with this type of hybrid system.
As a possible application scenario, consider a system operating with eight 200 kHz channels.
To comply with the requirements for hybrid operation the channel dwell time in frequency hopping mode must not exceed 400 ms in any (400 ms * 8 channels) 3.2 seconds. In addition, the power spectral density shall not exceed +8 dBm in any 3 kHz bandwidth.

It is a good alternative and perhaps, soon we will see plenty of choices for LoRa gateways operating within North American spectrum. The power needs to be limited and capacity is also limited, but still it is an inexpensive way to deploy LoRa network in North America.

Hands on with LoRa in North America. #2

Public LoRa Configuration

In the previous post, I have explained how to configure Multitech Conduit and mDot module to communicate with each other, using private LoRa network mode. Today, we will change it to use public LoRa mode, however we still use just one device to observe incoming packets. We will be running Network Server together with a Gateway on our Conduit.

Let’s change configuration of the LoRa-network-server by editing /var/config/lora/lora-network-server.conf like below:

"lora": {
"netID": "010203", /* netID for beacon packets */
"frequencyBand": "915", /* US="915", EU="868" */
"frequencySubBand": 7, /* Sub-band for US operation, 1-8 */
"rx1DatarateOffset": 0, /* Datarate offset for mote rx window 1 sent in join response (0-3) */
"rx2Datarate": 12, /* Datarate for mote rx window 2 sent in join response (7-12) */
"maxTxPower": 14, /* Max Tx power (dBm), -6 to 26 default 14 */
"frequencyEU": 867500000 /* center freq for extra EU channels (Hz) */
"udp": {
"appPortUp": 1784, /* port for user-developed application use */
"appPortDown": 1786 /* port for user-developed application use */
"addressRange": {
"start": "00:00:00:01", /* address range used for mDots */
"end": "FF:FF:FF:FE"
"network": {
"public": true, /* set to false for private LoRa network with mDots + Conduit */
"leasetime": 1440, /* time until mDot join expires (minutes) */
"eui": "02:00:00:00:00:ee:ff:c0", /* configure network security */
"key": "2b:7e:15:16:28:ae:d2:a6:ab:f7:15:88:09:cf:4f:3c"
"log" : {
"console" : true,
"syslog" : false,
"level" : 30, /* error=10, warn=20, info=30, debug=50, trace=60, max=100 */
"path": "/var/log/lora-network-server.log"
"mqtt": {
"enabled": true

We can then restart the server by executing the following command:

/etc/init.d/lora-network-server restart

Now, we will connect to our mDot module, and using AT commands we will change it’s network mode to be a public mode plus we will provide network related information to match our Conduit system. Actually, we will be using the same network information which one would use to connect to The Things Network, in a future post we will show how to use the Packet Forwarder and connect to their Network Server.

Lets execute the following:

AT+PN=1      //set the public network mode

AT+NI=0,0200000000eeffc0     //set network id
AT+NK=0,2b7e151628aed2a6abf7158809cf4f3c //set network key

Run AT&V, and you should see something like that:

Device ID: 00:80:00:00:00:00:9e:be
Frequency Band: FB_915
Frequency Sub Band: 7
Public Network: on
Start Up Mode: COMMAND
Network Address: 00000001
Network ID: 02:00:00:00:00:ee:ff:c0
Network ID Passphrase:
Network Key: 2b.7e.15.16.28.ae.d2.a6.ab.f7.15.88.09.cf.4f.3c
Network Key Passphrase:
Network Session Key: cb.75.96.1a.ae.fa.d1.23.ca.86.f1.dc.97.6f.28.10
Data Session Key: 0c.5c.3c.ff.d9.16.9b.fe.a6.0c.6c.29.b8.b6.34.59
Network Join Mode: OTA
Network Join Retries: 2
Join Byte Order: LSB
Link Check Threshold: off
Link Check Count: off
Error Correction: 1 bytes
ACK Retries: off
Encryption: on
CRC: on
Adaptive Data Rate: off
Command Echo: on
Verbose Response: off
Tx Frequency: 0
Tx Data Rate: SF_9
Tx Power: 11
Tx Wait: on
Tx Inverted Signal: off
Rx Frequency: 903700000
Rx Data Rate: SF_9
Rx Inverted Signal: on
Rx Output Style: HEXADECIMAL
Debug Baud Rate: 115200
Serial Baud Rate: 115200

Wake Interval: 10 s
Wake Delay: 100 ms
Wake Timeout: 20 ms
Log Level: 0

Public LoRa
At this point you are ready to go, connect to your mDot and send something to your conduit looking either at logs or subscribing to mqtt topic as per instructions from the previous post


AT+SEND=hello world

In the next post, we will connect 3rd party, HopeRF LoRa radio with Teensy 3.2 MCU and then test it with our Conduit Public LoRa gateway


PART 3->