In part 1 of this series I showed how to set up a simple LoRaWAN gateway, and in a previous article described a simple but powerful LoRaWAN-capable end device that I designed. Now I’ll show how these devices can be used in a real LoRaWAN application.

LoRaWAN Application on The Things Network

The Things Network (TTN) is the Internet infrastructure that allows us to use end devices to do something useful on the Internet. End devices (sometimes called nodes) talk to a nearby gateway, which is connected to the Things Network infrastructure. An application is anything you can imagine on the Internet that does something with the data provided by the end devices. The Things Network bridges the radio technology to Internet technology. The communication does not need to be one-way; applications can downlink data to end devices, too. A common example of an application is a Cayenne dashboard which is an easy way to visualize data from your devices. You can also read data from TTN using Node-RED, a common tool for building IoT solutions.

In part 1 I showed how a gateway is registered to TTN. To connect end device nodes, we also have to define an application in TTN, even if the real functionality of our application is implemented elsewhere on the Internet. An application has a name and a unique ID called an Application EUI. It also creates an Application Access Key that you use to integrate other services like Cayenne or Node-RED to your application. I won’t go into the integration details because there is plenty of info available about that.

After creating a TTN application, you need to add devices to the application so that your code on the devices can talk to TTN. There are 2 ways for a device to authenticate with TTN. The recommended and more secure way is called over-the-air-activation, or OTAA. This is the default mechanism when you create a device in TTN. With OTAA, a device negotiates with the network to establish a network session key and an application session key. The other mechanism is activation-by-personalization, or ABP. With ABP, the keys needed to communicate with the network are hard-coded in the device ahead of time. This makes it much easier and quick to connect, but is less secure.

Before we go any further with details about OTAA and ABP, let’s define the many types of IDs and keys associated with LoRaWAN applications and devices. It can be very confusing, because some of them have very similar names!

Gateway ID: A unique identifier for your gateway. You specify this when you register a gateway with TTN.

Application EUI: A unique identifier for an application. It is provided by TTN when you create an application.

Device ID: A name that you assign to a device when you register it in TTN.

Device EUI: A unique identifier for an end device. This may be provided by your hardware so that you can specify it when registering a device in TTN. OR, you can have TTN generate one for you.

Device Address: An identifier for an end device that is used during communication between device and TTN. This is assigned dynamically when using OTAA, but is hard-coded when using ABP.

Application Key: A value that is used for secure communication between device and TTN. This is generated when a device is registered with a TTN application. Each device has a different Application Key.

Network Session Key: A value that is used for secure communication between device and TTN. This is assigned dynamically for a session when using OTAA, but is hard-coded when using ABP.

Application Session Key: A value that is used for secure communication between device and TTN. This is assigned dynamically for a session when using OTAA, but is hard-coded when using ABP.

Is everything clear now? I didn’t think so. Let’s break it down in terms of what information you need for the two approaches, OTAA and ABP.

Over-the-Air Activation (OTAA)

After defining an application in TTN and registering a device, the device code needs some of important information in order to connect to the network successfully via a gateway. OTAA requires 3 pieces of information: Application EUI, Device EUI, and Application Key. The other information — Device Address, Network Session Key, and Application Session Key — will be determined dynamically during the activation process.

See the OTAA example on GitHub. Note the library dependencies required for the examples to work.

Although this method is secure and recommended, connecting to the network can take several minutes or more. The negotiation of session keys requires that the network communicate back down to to the end device during precisely timed receive windows, which can be tricky.

Activation-by-Personalization (ABP)

Using the ABP approach, the device code needs different information in order to connect to the network. ABP requires 3 pieces of information: Device Address, Network Session Key, and Application Session Key. This method of connecting is much faster and reliable, but for a number of reasons is less secure.

See the ABP example on GitHub. Note the library dependencies required for the examples to work.

When using an ABP device, it’s important to disable the frame counter checks in the device settings on TTN. This is one of the things making it less secure.

Range Testing

By driving around with an end device node in my car, I’ve tried to determine my communication range with my gateway. I’ve been a bit disappointed, but there are many things that affect signal propagation. First, despite having an 10-foot antenna mast, my antenna is still not even close to being higher than my house. And I’m hardly an RF engineer when it comes to designing my custom end devices.

They have a simple wire antenna, but my prior experimentation led me to think that this was just as good as any other LoRa antenna I’ve tried. In one test, my son and I each strapped a LiPo battery powered end device to our bikes and went for a long ride, having each node send GPS data every minute to my gateway (I realize that this test used far more duty cycle than one should in a real application). A Cayenne dashboard mapped the received data from each device. The smooth path on the map is the actual path as measured by GPS in my son’s phone. Superimposed on this are two non-smooth paths defined by blue points at which the gateway “heard” the GPS data reported from the end-device. The gateway is in the southwest are of the map, and you can clearly see that it did not receive much data when we are on the northernmost part of our bike ride. The maximum distance for a received signal was about 1.2 miles.

I also experimented between using confirmed vs. unconfirmed messages. Confirmed message get an acknowledgement from the gateway, whereas unconfirmed are more like “fire and forget”. Counterintuitively, it seemed like confirmed messages were more reliable and had better range. Nonetheless, I will continue to do more range testing to try to improve the situation.

Node-RED Integration

An online service like Cayenne makes it super easy to integrate with TTN, but you can also integrate with your own software via MQTT. Data uplinked from your devices to your TTN application are published to MQTT topics that you can connect to in your own application. I love using Node-RED for all sorts of IoT fun. You can use MQTT nodes (here “nodes” refers to Node-RED components, not end devices) to receive the data published by TTN. To make it even easier, TTN has even written custom nodes for TTN integration. If you are a Node-RED junkie like me, I strongly recommend you look into this type of integration so that you can build just about anything based on data from LoRaWAN end devices.

I hope you found these posts about LoRaWAN useful. The learning curve is significant but it’s exciting when a technology is so new.

I have been playing with LoRa modules a lot recently (see projects LoRa Weather Station and LoRa Mesh Networking) and even designed my own LoRa development boards. LoRa is an easy way to achieve low-power, long range radio communication with small payloads. To get even more capability out of this radio technology, you can set up a LoRaWAN network that is connected to the Internet and allows mobile nodes to hop between gateways, just like your mobile phone connects to different cell towers as you move around. So this summer I was determined to set up a low-cost LoRaWAN gateway and get it up and running on The Things Network. It was easier than I thought.

Gateway Hardware

A gateway is an Internet-connected LoRa device that listens to multiple LoRa channels and forwards packets between the network backhaul (e.g. The Things Network) and the end device nodes it hears. Think of it like a cell tower for lower-power, mobile end device nodes. There are several gateways to choose from and I decided to try the RAK831 gateway from RAK Wireless, a Chinese company. The RAK831 is a LoRaWAN concentrator board that connects to a Raspberry Pi. I bought their LoRaWAN starter kit because it seemed to have everything you need.

In fact, it had more than I really needed. Here are the components that were essential to me:

• RAK831 LoRaWAN concentrator board
• Raspberry Pi 3 with SD card preloaded with all the drivers and setup for The Things Network
• Converter board to attach the RAK831 to the Raspberry Pi. This board also has a GPS receiver on it.
• GPS antenna
• Glass fiber antenna with 6dBm gain, so I could set up a tall antenna mast
• a 5 meter RG-58 tie line for the antenna
• heat sink for the concentrator board. I’m not sure it’s necessary.

The kit also came with a WisNode board which is like an Arduino + LoRa end device. It also came with a board called a LoRa Tracker, which I found useless because it requires some strange programming environment to use. Besides I had already designed my own end devices with GPS.

Configuration

I got a lot of information from this article on hackster.io about how to configure the Raspberry Pi to connect to The Things Network. Many of the steps are not necessary because the required software was preloaded. I did not have to enable SPI on the Raspberry Pi, or download the iC880a-based gateway software from GitHub. This had already been done.

I did set my WiFi credentials in /etc/wpa_supplicant/wpa_supplicant.conf as instructed.

Then the main task is to set up the configuration file for the gateway. First, you need to determine the gateway ID. It is unique to the hardware because it is based on the MAC address of the network interface. Here’s a handy script to get it:

GATEWAY_ID=$(ip link show eth0 | awk '/ether/ {print $2}' | awk -F\: '{print $1$2$3"FFFE"$4$5$6}'); echo ${GATEWAY_ID^^}

Configuring the gateway is a little confusing. First, there’s a global configuration file that is not specific to your gateway but is specific to the region you are operating in (EU, US, Australia, etc.). I’m in the US, so I used the US global configuration file from the Things Network’s gateway-conf project on GitHub.

The gateway_conf section near the end is the important part. This has the correct router information for your region. This file goes in /opt/ttn-gateway/bin. IMPORTANT: in order for my gateway to work, I had to enable GPS in the global_config.json file by adding this to the gateway_conf section:

{
  "gateway_conf": {
  	...

    "gps": true,
    "gps_tty_path": "/dev/ttyAMA0",
    "fake_gps": false,

  	...
  }
}

Information specific to your gateway goes in a file /opt/ttn-gateway/bin/local_config.json. Here you use the key information from the global_config.json plus your gateway_ID, location information about where your gateway is, and contact info. Here’s mine:

{
  "gateway_conf": {
    "gateway_ID": "B827EBFFFEF11045",
    "servers": [
      {
        "server_address": "router.us.thethings.network",
        "serv_port_up": 1700,
        "serv_port_down": 1700,
        "serv_enabled": true
      }
    ],
    "ref_latitude": 45.0466,
    "ref_longitude": -93.4747,
    "ref_altitude": 277,
    "contact_email": "michael@nootropicdesign.com",
    "description": "nootropic design RAK831 LoRa gateway"
  }
}

When the gateway starts, the local_config.json info is merged with the global_config.json information.

The tricky thing is that your gateway configuration can be controlled by a remote file in GitHub. The gateway-remote-config GitHub repo is a collection of many local config files for TTN Gateways. When your gateway starts up, it actually pulls the latest content from GitHub. If it finds a file for your gateway, it removes the local_config.json file and creates a symbolic link from bin/local_config.json to the file in the cloned repo on your Raspberry Pi!

If you want to do this, fork the gateway-remote-config repo on GitHub, commit your own local config file to your forked repo named for your GatewayID (e.g. B827EBFFFEF11045.json), and then submit a pull request to the master repo. In a few days, your local configuration file will be merged and when your gateway starts, it will use it.

My final configuration is the /opt/ttn-gateway/bin/local_config.json which is a link to the
my config file in GitHub. The gateway_conf section in global_config.json simply contains this:

{
  "gateway_conf": {
    "gps": true,
    "gps_tty_path": "/dev/ttyAMA0",
    "fake_gps": false
  }
}

The Things Network

You’ll need to register your gateway on The Things Network using their registration instructions. This is easy.

Enclosure and Antenna

I mounted my gateway in a waterproof enclosure with wires going in for the 5V power, LoRa antenna, and GPS antenna. It did not get too hot in the summer, and I will soon see how well it fares in a Minnesota winter. I am hoping that the heat generated by the enclosed Raspberry Pi will keep the hardware from freezing, but I have no idea! UPDATE: the Raspberry Pi had no problems even when it was -28F (-33C) !!!

The antenna mast is PVC pipe and I used a 5 meter RG-58 cable to connect the concentrator board to the glass fiber antenna. There is power loss in 5 meters of cable, but the antenna still provides a net gain after accounting for this. I think it looks great and I hope my neighbors don’t think it is an eyesore.

In Part 2 of this article I’ll get into the details of using LoRaWAN nodes with the gateway. Stay tuned.

Difficulty Level = 7 [What’s this?]

Several people in the FPV RC world (that’s First Person View Remote Control for the uninitiated) have contacted me about the possibility of using a Video Experimenter shield as an OSD solution (on screen display). People who fly RC planes and helicopters are increasingly using on-board video cameras to provide a first-person view of the flight, and they like to overlay GPS data onto the video image. Flying radio controlled drones has become a huge hobby (just look how big the DIYDrones and RCGroups communities are!).

I don’t have any RC vehicles, so I’m really on the outside looking in, but I thought I’d experiment to see how useful a Video Experimenter might be in overlaying data onto a video feed. I wrote a simple Arduino program that reads GPS data from the Arduino’s serial RX pin and overlays a heads-up display onto the video input. I think it turned out pretty nice:

Using a Video Experimenter as an OSD

All relevant info is displayed: current latitude/longitude, compass heading, speed (left), altitude (right), and distance home (meters) in the lower right. There’s also a home arrow in the center of the screen pointing toward the hard-coded home location. Note that the ground elevation is also hard coded in the Arduino program so we can calculate altitude.

Circuit Setup

I think there are two ways that a FPV solution could use this approach. If the vehicle is transmitting video and also transmitting GPS telemetry via an XBee radio, then the GPS data can be overlayed onto the video at the ground station. I had to configure the XBee radios to use the same baud rate as my GPS (4800bps).

Circuit for GPS overlay ground station

OR the Arduino and Video Experimenter shield could be onboard the vehicle itself. This way the GPS data is overlayed onto the video before the video is transmitted. In this case, the GPS module is connected directly to the Arduino RX pin, and there’s no XBee radios involved. An Arduino+Video Experimenter shield weigh 2 ounces or 57 grams (I knew you were going to ask that).

I need to be clear that this overlay software can’t run on your ArduPilot hardware. Processing video in an Arduino environment requires nearly all of the ATmega’s SRAM, so there’s no way that this is going to run on the same hardware as your autopilot code.

Again, I’m not in the FPV RC community and don’t have a plane, so I’m not entirely sure how feasible all this is. But a number of RC hobbyists have asked about the Video Experimenter and were enthusiastic about the possibilities. Comments are very welcome!

GPS Configuration

My EM-406 GPS module is configured to only output RMC and GGA sentences, and they are output once per second, so the display only updates at that frequency. It was important to limit the output to only the RMC and GGA sentences, because when using the Arduino video library (TVout), serial communication is accomplished by polling, and it can’t handle data too quickly. To limit the output to RMC and GGA sentences, I wrote these commands to the GPS RX line, with each line followed by a CR and LF character. The Arduino serial terminal works fine for this. Don’t write the comments, of course.

# enable RMC, output 1Hz:
$PSRF103,04,00,01,01*21

# enable GGA, output 1Hz:
$PSRF103,00,00,01,01*25

#disable GLL
$PSRF103,01,00,00,01*25

#disable GSA
$PSRF103,02,00,00,01*26

#disable GSV
$PSRF103,03,00,00,01*27

#desiable VTG
$PSRF103,05,00,00,01*21

If you have a MediaTek GPS module, I believe the correct command to disable all sentences except for RMC and GGA would be this:

$PGCMD,16,1,0,0,0,1*6A

I don’t know how fast of a data feed that the Arduino overlay code can handle, so some experimentation would be in order.

Download

Download the Arduino code OverlayGPS.zip. The awesome TinyGPS library is also required, so install it in your Arduino libraries folder. You also must use the TVout library for Video Experimenter that is required for Video Experimenter projects.

Difficulty Level = 9 [What’s this?]

This was a fun project I built using a perf-board Arduino with GPS receiver, some LEDs, some long wire, some clever code, and a car!

I have this friend that has a speeding problem. So I built this device for my friend so he’ll know when he’s speeding. How will he know? Because when the small perf-board Arduino device with a GPS module detects that his vehicle’s speed is over the speed limit, it turns on a police lights display that is mounted on the inside of his car’s rear windshield. When he sees those flashing police lights in the rear-view mirror, he’ll know he needs to slow down!

Police in the rear view mirror!

OK, it’s me, but you already figured that out. If you weren’t smart, you wouldn’t be here. Here’s a rundown of this project’s features:

• A simple perf-board Arduino circuit with an EM-406a GPS Receiver connected to the microcontroller
• A pair of CAT-5 cables running from the circuit to the back of my Honda Civic
• A small perf-board with red and blue LEDs and two white LEDs representing the headlights of a police car. This small board is mounted on the inside of the rear windshield using suction cups.
• The software running on the microcontroller is programmed to know the speed limit in different locations near where I live and drive. I did this by specifying “speed zones” which are polygons and a speed limit. The polygons are defined as a list of latitude/longitude vertices.
• Whenever the GPS module reports the current position and speed (every second) the code determines which bounding polygon or “speed zone” the car is located in. If the GPS receiver reports that the current speed is greater than the speed zone’s limit, the police lights are activated. If below the speed limit, the lights will be turned off.

The Hardware

Look at this nice clean circuit…

OMG don’t look at the bottom!

Read more…