Messing About with LoRa

At RK, we count ourselves among the pioneers in the use of low-power radio for AM&T (Automatic Meter & Telemetry), so we keep an eye on emerging technologies. One of these is LoRa, aimed at a range of IoT applications. LoRa can operate in two modes: peer-to-peer and LoRaWAN. LoRaWAN is ultimately the way to scale this technology — we’ll have a future entry on deploying a LoRaWAN basestation at our offices. In the meantime, let’s look at what it takes to do some peer-to-peer testing. (Credit to Paul, who wrote the original disk91 article — refined here to use the equipment we had.)

The motes

We ordered two Microchip LoRa motes. These operate on 868MHz (the legal frequency in Ireland and many other parts of the world). They’re nice little gadgets with an OLED screen for reporting status, and an onboard PIC MCU — so you can write little programs that let the gadget act untethered.

Communicating with the motes

The motes are based on the Microchip RN2483 LoRa modem, which can be configured and operated with simple console commands at three levels. The command sys get ver returns the firmware version — a good way to ensure the mote works:

sys get ver
 RN2483 1.0.1 Dec 15 2015 09:38:09

Plugging in the transmitter

I plugged one mote into a SolidRun CuBox-i we had lying about, running the standard Debian distro. Any Linux/ARM setup — BeagleBone Black, Raspberry Pi — would work just as well.

Plugging in the receiver

I plugged the other mote into my Mac — this would be the receiver.

Transmitter software

On the SolidRun, take Paul’s script and run it. The serial port may need changing from /dev/ttyUSB0; the mote pretends to be a modem, so it called itself /dev/ttyACM0 in my case:

bash loratx.sh /dev/ttyACM0

Here is Paul’s script:

#!/bin/bash
# LoRa loop: send a message in a loop at default frequency
# module is connected to /dev/ttyUSB0 device
dev=$1

startRet() {
   (if read -t 3 ret < $dev; then echo $ret ; return 0 ; else return 1 ; fi) &
   wf=$!
}
checkRet() {
   wait $wf
   return $?
}

stty -F ${dev} 57600 cs8 -cstopb -parenb -echo

startRet ; echo "sys get ver" > $dev
if checkRet ; then
  startRet ; echo "mac pause" > $dev
  if checkRet ; then
     startRet; echo "radio set pwr 14" > $dev
     if checkRet ; then
        i=0
        while true ; do
           echo emiting $i
           startRet ; echo "radio tx 123456789AB" > $dev
           sleep 100
           i=$(( $i + 1 ))
        done
     else echo "error setting power"
     fi
  else echo "error setting mac in pause"
  fi
else echo "cant establish communication"
fi

Setting up the receiver side

On the Mac, I coded up the following dirty little thing in Python (it prints an ASCII BELL character so you can hear each ping arrive):

import serial, time, datetime, sys

echo=False

def readlineCR(port):
    rv = ""
    while True:
        ch = port.read()
        rv += ch
        if ch=='\r' or ch=='':
            return rv

def sendcmd(cmd):
    if echo: print (">>"+cmd)
    port.write(cmd+"\r\n")

def sendcmdprintresp(cmd):
    sendcmd(cmd)
    rcv = readlineCR(port)
    print "<<"+rcv

port = serial.Serial("/dev/tty.usbmodem1421", baudrate=57600, timeout=3.0)
sendcmdprintresp("sys get ver")
sendcmdprintresp("mac pause")

while True:
    sendcmd("radio rx 0")
    resp=readlineCR(port).strip()
    if (resp == "ok"):
        while True:
           resp=readlineCR(port).strip()
           if (resp.startswith("radio_rx")):
               print "\aRECEIVED at "+str(datetime.datetime.now().time())+": "+resp.split("  ")[1]
               break
           elif (resp.startswith("radio_err")):
               print "RECEIVED error"; break
           time.sleep(1)
    else:
        print "ERROR: "+resp
        time.sleep(10)

Running the tests

I set everything up in the lab with the Mac pinging nicely. (To increase the ping frequency from every 100 seconds, change sleep 100 to something like sleep 30.)

I left the transmitter in our lab — on the top floor of a four-storey building in Limerick city centre, a mostly low-rise town, so relatively high up. However, our building has a lot of metal along with a metal roof, so I expected significant attenuation. In other words, the transmitter was in a rather sub-optimal location.

I then took the receiver to the basement car park and received every ping. This is impressive — you certainly wouldn’t see this with something like Zigbee unless you installed a bunch of repeaters. Then I went driving to see where the range faltered. Performance to the West was very good — unsurprising, as there are far fewer buildings that way and the transmitter sits above the low-lying region. Performance to the East was less impressive, which I associate with greater building density, the urban-canyon effect, and Limerick’s gentle rolling hills.

Overall, this technology looks very promising even when deployed in absolutely lousy conditions, like I just did.

Very shortly we’ll be deploying a LoRaWAN base station for Limerick on The Things Network — and doing it in a much more professional way.

Where Full Stack Energy fits

Hands-on radio and IoT experience like this is the foundation of the connected hardware we build — the same depth behind our bespoke board design and device-to-database pipelines. If you’re deploying low-power radio for telemetry, we can help.