First step in LoRa land – microchip RN2483 test

Microchip RN2483 Lora
Microchip RN2483 Lora

After spending some time reading and writing about LoRa it was a good time to make some real test of this technology.

As actually there is no network for LoRa, as much as I know, in my town, I expected to start a simple LoRa test (point to point and not as part of a WAN). I just bought some RN2483 LoRa module from Microchip online and also get some from Avnet (thank you Guillaume)

 

The module is easy to solder on a prototype board and get its command over a serial port. I choose to make two modules :

  • The first one is connected to a FTDI cable and will stay at home as a basestation
  • The second one is connected to an Arduino and will be a mobile device for my test

Create the test board

The RN2483 module have a lot of pins but most of them are GPIOs and power supply. To make my board simple, I decide to not connect all the GND and it sounds to work as expected, so at the end my schema looked like this.

RN2483 Lora simple circuit
RN2483 Lora simple circuit

The FTDI cable provides 5V so you have to add an LDO regulator to get 3,3V as module power supply. I just plug RX/TX from FTDI to the module and that is all what you need. The RF antenna I use is a half wave antenna centered on 868 Mhz. Once soldered, the test board are looking like :

LoRa on FTDI
LoRa on FTDI
LoRa on Arduino
LoRa on Arduino

Make the first communication ready for LoRa

For communicating with the module, the default serial port setting is 57600 bps. Once set on your terminal, you can communicate with the module. The list of available command can be retrieved here.

There are 3 level of commands :

  • sys for system command
  • mac for LoRaWan protocol related command
  • radio for low level radio transmission

The command sys get ver returns the firmware version, it is a good way to ensure the circuit works.

sys get ver
RN2483 0.9.5 Mar 24 2015 14:15:33

Then to get a communication between the two device, based on a point to point LoRa link, you must start pausing the mac level. The mac level is managing the LoRaWAN protocol we do not want to use at that point.

So you have to run on each of the board: It returns a long pause duration when you do not specify your expected duration.

mac pause
4294967245

Now we are ready for communicating, we can check the default configuration : this document from Semtech is a great help to understand these parameters.

radio get mod
lora
radio get freq
868100000

These 2 first command indicates that the module is configured as LoRa device by default with a rx/tx frequency of 868.1Mhz

radio get sf
sf12

The spread factor parameters defines the sensitivity of the reception, with a such value (sf12 is the more sensitive) the SNR can be up to -20dB. This also impacts the duration of the transmission that becomes longer.

radio get bw
125

The used bandwidth determine time on air and sensitivity. With 125KHz the sensitivity is better but time on air is longer. Chip is capable from 125KHz to 500KHz. The time on air is doubled from 125KHz to 250KHz.

With a 125kHz bandwidth and a spread factor of 12, the time on air duration is about 1 second

radio get cr
4/5

The CR (Coding rate) parameter determines an error correction mechanism by adding some information to the message. 4/5 is the best correction mechanism especially when the signal is low.

radio get prlen
8

The prlen gives the preamble length in symbol.

radio get pwr
1

Power level gives the power in dB of the transmitter ; values are from -3db to 15dB

With these setting, you can get the all the information about sensitivity and bitrate from the LoRaCalculator. With the default configuration we have the following configuration:

  • bitrate : 292 bps
  • time on air for 12 byte : 991ms
  • link budget : 138dB
  • power consumption : 23mA/h

Now we can change the power to 14dB to get more power and better link budget (this will consume 44mA/h and get 151dB as link budget)

radio set pwr 14
ok
radio get pwr
14

Any change to the radio level can’t be saved, so you have to reconfigure it on every reboot.

Let’s send the first message over LoRa

Now we can send a message over the air. The first thing to do is to configure one of the device for reception : the parameter 0 indicates that reception is blocking until getting a message.

mac pause
4294967245
radio rx 0
ok

On the second device we can now sent a message :

mac pause
4294967245
radio set pwr 14
ok
radio tx 123456789012
ok
radio_tx_ok

On the receiver we get :

radio rx 0
ok
radio_rx  123456789012

Now let’s make a keyapp testing device

The next step will be to test LoRa performance in real environment (even if my RF design is not really nice regarding my soldering stuff !! By the way, let’s make something. The system will be based on a transmitter always sending a message every 30 seconds and a receiver making a led blinking every time the message is received. (Ok this is not respectful of the duty cycle … so let’s say 100 seconds instead of 30)

#!/bin/bash
# LoRa loop send a message in loop over LoRa medium 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

Now, on receiver, we simply want to wait for a message, check if the message is the expected one, then blink a led a couple of time to indicate a message has been received. This is based on Arduino.

String str;
void setup() {
  Serial1.begin(57600);
  while (!Serial1);

  pinMode(3,OUTPUT);
  digitalWrite(3,HIGH);

  // reset the module
  pinMode(2,OUTPUT);
  digitalWrite(2,LOW);
  delay(500);
  digitalWrite(2,HIGH);
  delay(2000);

  Serial1.setTimeout(2000); 
  str = Serial1.readStringUntil('\n');
  Serial1.println("radio set wdt 105000");
  str = Serial1.readStringUntil('\n');  
  Serial1.println("mac pause");
  str = Serial1.readStringUntil('\n');  
  digitalWrite(3,LOW);
}
void loop() {
  // switch recieve mode
  Serial1.println("radio rx 0");
  str = Serial1.readStringUntil('\n');
  if ( str.indexOf("ok") == 0 ) {
    int ok=0;
    while ( ok == 0 ) {
       str = Serial1.readStringUntil('\n');
       if ( str.length() > 1 ) {
          if ( str.indexOf("radio_rx") >= 0 ) {
            if ( str.indexOf("0123456789AB") >= 0 ) {
              int j;
              for ( j = 0 ; j < 10 ; j++) {
                 digitalWrite(3,HIGH);
                 delay(100);
                 digitalWrite(3,LOW);
                 delay(100);
              }
            }
            ok = 1;
         }
      }
  } 
}

Some little modification compared to initial schema :

Pin2 is connected to RN2483 reset PIN and Pin3 is connected to a LED for showing result : blinking 10 times when the message is received.

The command radio set wdt 105000 set a reception timeout to 105s to ensure being in the expected transmission windows.

Make the test, get the map

With this solution done, I did some tests driving in my city. The result is not a really good benchmark for many reason, the first one is that the emitter was on my roof but not on top of it, so part of my roof was hiding the western part of the city what can can easily see on the graph below. The blue point from where the arrow are starting is the emitter position.

LoRa coverage zone
LoRa coverage zone

The emitter was in the city downtown and the 1,3Km is really going on a city environment with a lot of building. The longest distance have about 2km of city and 2km of country side. The part on the top left of the map is a mountain that is limiting the coverage in this area.

On the map, the red part are location where I did a test and get nothing. The blue one the location where I did the test and it was working well, the uncolored parts are where I did no tests.

By the way, I’m very impressed by these results as my emitter is really not optimized for transmission : standard internal antenna, connected as you can see on the photo… The transmitter was limited to 14dB on the 15dB available to keep an acceptable power consumption.

Next step will be to put an emitter on top of our mountains to make a better test !

This entry was posted in IoT, Networks and tagged , , . Bookmark the permalink.

71 Responses to First step in LoRa land – microchip RN2483 test

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.