LTE CAT M1 (sometimes called LTE-M) and NB-IoT are both exciting new cellular technologies targeting IoT applications. While there are many modems being built with this new technology, there are not many choices for hobbyists. There are a few Arduino shields and breakout boards based on the SIMCOM SIM7000 modem, and a few with u-blox SARA modems.

Nimbelink is a cellular technology provider that takes the unique approach of offering a variety of different modems as interchangeable modules. No matter what the actual cellular modem is, the 20-pin Nimbelink Skywire modules with the familiar “XBEE” footprint all have the same pinout and electrical characteristics. The interchangeable nature of these modem modules allows product designers to future-proof their products, allowing new modules to be plugged in later. Another huge benefit is that the Nimbelink modules are already certified on their respective cellular networks (Verizon, AT&T, etc.) so you don’t have to.

Nimbelink has a development kit for use by product developers, but it’s rather expensive. I wanted to try out a Nimbelink CAT M1 modem without the dev kit, and since there are so many hobbyists using Arduinos out there, I wanted to provide a nice Arduino library for the modem. I chose the Nimbelink module based on the Sequans Monarch CAT M1 modem and got to work designing an Arduino shield to hold it.

Skywire Shield with Nimbelink Skywire module with Sequans Monarch CAT M1 modem

Hardware Design

The shield is quite simple, and really just provides an appropriate switch-mode power supply for the modem. The input power for the shield can be 5-12V, and provides a stable 3.8V at up to 1.7A to the modem. I used a TI TPS5402 for this. Jumper settings allow you to connect the modem’s UART to the Arduino hardware UART on pins 0 and 1 or to software serial on digital pins 2 and 3. I typically use software serial at 19200 so that I can use the Arduino serial interface for debugging. The buttons labeled “Func 1” and “Func 2” are connected to digital pins 4 and 5.

Software Interface

What about actually using the modem in software? Every modem has its own AT command set, and although there are similarities, a developer must know the details of the modem they are using. Luckily, the excellent TinyGSM Arduino library provides an Arduino Client interface for a variety of underlying modems. The Arduino Client interface is widely used by networking libraries to abstract away the underlying hardware. That is, when you code to the Client API, it doesn’t matter if the hardware underneath is an Ethernet shield, an ESP8266, a cellular modem, or whatever. Examples of libraries that code to this interface and therefore work with many kinds of hardware are ArduinoHttpClient for web clients and PubSubClient for MQTT clients. Even HTTPS and MQTT over TLS work! Security is important.

TinyGSM did not have an implementation for the Sequans modem, so I wrote one. It’s in my forked repo of TinyGSM (it has not been merged into the parent yet). To use the TinyGSM examples with the Nimbelink module with a Sequans modem, simply add this to your source code:

#define TINY_GSM_MODEM_SEQUANS_MONARCH

I also bought a Nimbelink module with the Quectel BG96 CAT M1 and NB-IoT modem on it. Luckily, TinyGSM already has an Client interface implementation for this modem. After plugging it into my shield and simply changing my HTTP and MQTT test clients to use this modem, everything just worked! That is, I was able to change the modem to a different manufacturer (and completely different AT command set) and make my code work with a one line change:

#define TINY_GSM_MODEM_BG96

Skywire Shield with Nimbelink Skywire module with Quectel BG96 CAT M1/NB-IoT modem

So the lesson here is that with thoughtful design of software and hardware abstractions, one can achieve a lot of flexibility.

• the Arduino Client interface defines a standard software API for network clients so that an implementation for any hardware can be written and expose its functions through this same interface
• useful libraries like ArduinoHttpClient and PubSubClient code to this interface so that HTTP and MQTT are easily used with lots of hardware
• and finally, Nimbelink has defined a standard Skywire module pinout so that it’s easy to swap out the hardware

This is all getting pretty easy, right?! I hope you agree.

I haven’t decided if I’ll make this shield available as a product because there has to be some real demand for that to be worth it. Let me know if you are interested in an easy way to get started with modern cellular technology using Nimbelink modules.

Schematic and board design files at GitHub: skywire-cat-m1-modem-shield
Arduino library for controlling the Sequans Monarch and Quectel BG96 modems: TinyGSM

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.

Project source code at GitHub: samd21-lora-gps

I’ve been doing some LoRa projects lately in order to learn as much as I can about this exciting new radio technology (see this LoRa mesh networking project and this LoRa weather station). ATmega328-based Moteino modules work great for a lot of projects, but I wanted a LoRa node with more processing power, more memory, and an onboard GPS receiver. The ATmega328 is just too constrained with memory — I’ve outgrown it. I really wanted a LoRa board with an ARM Cortex microcontroller like the SAMD21. This is the microcontroller used on the Arduino Zero. So, my ideal board is a SAMD21 with LoRa radio module and GPS receiver, all programmable with the Arduino IDE.

But, where is such a board? I could not find one so I decided to design and make one myself.

Hardware Design

Microchip/Atmel makes a SAMD21 chip and there are several variants. Most designs use the ‘G’ variant, but I wanted to use the simpler ‘E’ variant because it comes in a TQFP-32 package that I can very easily solder in my reflow oven without any trouble, or even by hand if I have to.

The GPS module is a cheap Quectel L80 with a MTK3339 chipset. It is easy to use but the backup power circuit requires a charging circuit, so I don’t have battery backup for quick startup. I mainly chose this module because it has big soldering pads with 2.54mm spacing for easier prototyping.

The LoRa radio module is a HopeRF module soldered to the bottom of the board.

Here is the schematic and image of the board design. The Eagle files are in the hardware directory of the samd21-lora-gps GitHub repo.

Burning a Bootloader

To make this board work with Arduino, I had to burn the Arduino bootloader onto the chip using an Atmel-ICE programmer. My board has 5 test points on the bottom for this purpose. The Atmel-ICE needs connections for VTG (3.3V), SWDIO, SWCLK, RESET, and GND. The board has to be powered over USB during the programming procedure. In the Arduino IDE, I selected Tools->Board = Arduino/Genuino Zero (Programming Port), Tools->Programmer = Atmel-ICE, and then just clicked Tools->Burn Bootloader. In a few seconds, my board had a bootloader and is now programmable as an Arduino Zero!

Programming the Board

I was careful in my design to allow this board to be used as an ordinary Arduino Zero even though it uses a different variant of the SAMD21 chip. The downside of this is that the default SPI pins defined for the Arduino Zero board use pins that are not present in the ‘E’ variant of the SAMD21. Luckily the design of the Arduino system is flexible enough that we can define a different SPI interface on different pins. There is a great article by Adafruit on this topic but it may be pretty hard to understand. The bottom line is that by using these lines in your Arduino sketch:

SPIClass SPI1(&sercom1, 12, 13, 11, SPI_PAD_0_SCK_1, SERCOM_RX_PAD_3);
pinPeripheral(11, PIO_SERCOM);
pinPeripheral(12, PIO_SERCOM);
pinPeripheral(13, PIO_SERCOM);

You can now use interface SPI1 to communicate with the LoRa module. I wrote a simple test sketch that reads the GPS module and broadcasts the GPS coordinates on the radio every 15 seconds. See the samd21-lora-gps GitHub repo.

This test code uses the RadioHead library to control the LoRa radio. The RadioHead library is flexible so I was able to use the SPI1 interface by defining a couple of new files, RHHardwareSPI1.[cpp,h].