DesignSpark Electrical Logolinkedin

LoRaWAN Enable a Sensor



Adding low power, long distance wireless communications to an existing sensor platform.

Connecting devices has never been easier and thanks to LoRaWAN and The Things Network, it’s now incredibly straightforward to get data from sensors that are located a great distance from a gateway — a LoRaWAN base station — into an Internet-connected application.

In this example we’ll be using a SmartEverything LION (124-8830) Arduino-compatible board with LoRaWAN, GPS and more, together with an Ardubat shield for detecting bats via ultrasound. However, it should be possible to easily adapt this for use with other shields and attached sensors.


One of the really great things about LoRaWAN is that anyone can use it to build a network — the gateways are relatively inexpensive and simple enough to configure. There are various options for the LoRaWAN back-end, which can be thought of a “network core” which takes care of routing data to/from applications and device activation etc. These include The Things Network (global), Things Connected (UK-only) and standalone/self-hosted software solutions. 

The area where we are based is covered by a number of The Things Network (TTN) connected gateways, which means that we have zero infrastructure requirements and can just implement a node and use this publicly available network. If this was not the case, setting up a new gateway on TTN is easy and has the benefit that it can be shared with the community to extend coverage.

You may already have access to a gateway and to see if there is one nearby, you can check the map. If you have line-of-sight to a gateway, or perhaps only have a few structures in the way, there is a high likelihood that you can connect to it.

The wireless technology that these networks use (LoRa) is a modern marvel. Using the same radio spectrum that many wireless key fobs and doorbells use, 868MHz (in the EU and other parts of the world use other frequencies). A key fob can reach a distance of maybe 30m, whereas LoRa can easily reach 3,000 or even 15,000m — yes that’s not and typo 15km range is possible.

This extreme range is achieved by using some clever physics that have been known for a while but not implemented in commercial electronics until recently. Rather than using a single frequency like most radio communications, the LoRa waveforms are “spread” by modulating a FM modulated chirp onto a fixed signal. This technique is called chirp spread spectrum. By up-chirping a signal it becomes much easier to pick out from the background noise or even in/out-band interferers. 

The way the data is encoded is also aimed at eking out as much range as possible and it’s these two ingredients that makes the marvellous distances achievable.

What about the WAN part?

The wide area network (WAN) part of LoRaWAN is the clever IoT side of the puzzle. The node part is handled together with the LoRa protocol by the Microchip RN2483 module on the SmartEverything LION. The gateway forwards packets of data to/from TTN and we have little need to do anything other than connect our node to this network; it will take care of the rest — network de-duplication, gateway management, data forwarding, encryption and security, to name a few tasks.

Bat detection

Most bat detectors work by listening for the ultrasonic chirps the bats use for echolocation. From the length and frequency of these chirps we can decide which species of bat we have detected. While there are commercial bat detectors on the market, we couldn’t find a LoRaWAN enabled one so and we may have a first! 

The Ardubat detector has some limitations compared to a commercial offering. For example, it will get a little insensitive towards the high kHz range, meaning we may not detect the Greater/Lesser Horseshoe bat (80-100KHz). Additionally we are not recording the sound — just a pulse frequency and duration — so distinguishing some species may be difficult.

Given the nature of a bat detector we had to consider the following:

  • It needs to run on batteries for a long period of time
  • A static installation will be in a field or barn away from WiFi and power


Our device

The Arrow SmartEverything LION development platform is an Arduino- compatible LoRaWAN device / complete IoT development kit in one neat package.

The first thing to do with this device (as it would be with any LoRaWAN device) is to get the HWEUI from it. This is a unique identifier used for network access. The closest analogue that most would have dealt with before is a MAC address.

Getting this identifier varies from device to device and for the LION there are a few options, but the easiest is to load the code example “getChipInformation”, which puts this out on the serial port. Another option is to have the code below in your main application, which allows direct access to the RN2483 module and which we can query thought the command “sys get hweui”.

    if (Serial.available()) 
        c =;    
        buff[i++] = c;
        if (c == '\n') 
            i = 0;
            memset(buff, 0, sizeof(buff));

The Things Network setup

Setting up an account on The Things Network is simple, following a familiar account set-up will get you registered and allow network access within minutes. Next we have to enter the TTN Console and set-up our node.

Heading to the Applications tab we can first add a new application:

After this we need to register our device, leaving us with a device overview like this:


With this part complete our LoRaWAN device is configured and can connect to The Things Network once we have implemented our Arduino code.

Since we already have experience with the SmartEverything LION we skipped this step, but a good starting point here is to begin with the example “sendDataOTA_console”, to test your set-up and network connection. The only code that needs changing in this example are the lines below and the information can be found in the device overview tab on our TTN application.



err = lora.macSetAppEUICmd("0000000000000001");





Network limitations

A key point to be aware of when using LoRaWAN is that the data bandwidth is low — very low!

The allowed limits are around 1% per channel, but vary. This is likely a hard limit that your module — in our case the RN2483 — will enforce. This is also a limit the gateways must adhere to (more on this later).

In addition TTN have a fair access policy for nodes that limits air time to 30 seconds of uplink per 24 hour period, and 10 downlink messages per day. Since gateways have to adhere to these TX limits a reply from the gateway is not guaranteed, and especially if someone is breaking the fair use policy on your gateway.

There are two provisioning methods available with LoRaWAN, over-the-air activation (OTAA) and activation-by-personalisation (ABP). On a simplistic level, ABP uses a set key and this does not change ever. This can become a security issue as the encryption keys never change and may become easier to compromise over an extended period of time.

OTAA assigns a new encryption key on every connection and so this can be renewed by rebooting your device and forcing a re-connect. This second method is a little more tricky to get working and relies on a response from the gateway. This means if the gateway is busy or has used its allocation of TX, it may take some time to get a successful connection.

Adapting the example

Having previously adapted this example for other applications, we had found a few limitations:

  • The main loop has a poor control over timing and can spam the wireless module
  • Adding code can be a problem because of the point above adjusting this timing
  • This leads to connection issues by the RN2483 denying TX requests

The solution to this is to implement a more accurate timing loop and limit TX events to every so many minutes. We’ll end up using 60 minutes in our final application. At the minimum spreading factor (minimum range) of SF7BW125, a 2 byte payload will consume around 45 milliseconds of airtime per communication. Giving a total TX of 1 seconds airtime per day. If we went up to SF12 (longest range) we would have 27.6 seconds, which is pretty much the whole airtime available to our node without breaking the fair use policy.

It is very important in LoRaWAN to account for this difference in spreading factor and not to assume everything that will be at SF7, since SF12 may be just as likely. With this in mind we moved a lot of the code from the example into a function called “LoRa_TX”, replacing the sent data with our own string and adding a conditional check to the confirmed TX, so we can decide to use it periodically.

if (MAC_JOINED(state)) 
     if (!joined) 
          Serial.println("\nOTA Network JOINED! ");

          joined = true;

          Serial.println("Sending Confirmed String and clearing count...");
          returned = lora.macTxCmd(String(s), 1, TX_ACK);  // Confirmed tx check received ok so we can clear the count
          if(Serialdebuglevel <=1)
          if(returned == "RN_OK")
                BatsDetected =0;  // clear bat count
                Serial.println("Sending UnConfirmed String ...");
                lora.macTxCmd(String(s), 1);   // Unconfirmed tx buffer if required
     joined=false;// Network is not joined so try to join
     Serial.println("\nNot Joined Tying to Join");
     lora.macJoinCmd(OTAA); // wait a while after joining

We have a main loop that looks quite sparse:

void loop() 
    static bool joined = false;
    LoRa_management(); // in here we relay commands to the RN2483 and deal with RX.
    bat_detection_loop(); // bat related items get done here
    checktime();  // this keeps track of time (must be entered a few times per second to avoid loss of time)
    Time_to_tx(); // check the set the flag Go_Tx when we are ready to tx.
    if (Go_Tx) 
        Serial.println("\nTry to TX:\n");
        LoRa_TX(String(BatsDetected));  // this sends the Bat string

Adding the required liberal use of global variables and setup. Yes, bad practice, but justified here for the sake of expedience. The application is turned on and connects to The Things Network.



As of now the code is keeping a cumulative bat count and transmitting this unconfirmed every 60 minutes. Then every 12 hours this will be reset following a confirmed uplink (only if successful will the count be reset).

Potential improvements:

  • Ideally this should be network application controlled and a downlink could be sent to implement this count reset functionality.
  • The bat detection is not very smart and should be “binned” based on frequency and duration of the received pulses. This is just a matter of coding and experimentation.
  • Logging should be implemented to a SD Card
  • The system is using a fair bit of power and could do with a hardware timing and sleep routine, so that it is more practical for battery applications.
  • Finally and most importantly, our data is somewhat “bloated” since we are using ASCII encoded strings. Ideally we need a handler to compress and remove redundant data and send binary only.

Final words

Adding LoRaWAN functionality to any sensor is a relatively trivial matter. As with all things there will be room for improvement, but core functionality can be achieved with ease.

This technology allows extremely low power radio communication and is ideal for long-term logging applications. It has some limitations, but knowing these and implementing our code accordingly will allow us to create a reliable, low cost system for pretty much any sensor.

Karl Woodward

Karl is a design engineer with over a decade of experience in high speed digital design and technical project leadership in the commercial electronics sector.