LoRa Gateway for Tests

I currently have a Kerlink LoRa IoT Station 868 for testing.

The Things Network supports this gateway, instructions how to update the gateway’s firmware to make it communicate with TTN can be found here.

Let me quote from TTN:

The Kerlink LoRa IoT Station is is an industrial solution suitable for people who want to mount the gateway outside and who have sufficient technical skills to connect, mount and maintain the device themselves.

We have tested the device and although we have remarks about the somewhat older software that is being used, this device will do the job. A trained software engineer will be able to update the device using the software from The Things Network.



LoRaWAN Single Channel Gateway

For first steps with The Things Network, you can build a LoRa Gateway. This gateway will have some restrictions:

  • Listens only on one single channel (one single frequency) for nodes
  • Listens only with one predefined spreading factor (SF)
  • Only listens, does not send back any kind of acknowledge messages

Okay. These are pretty hard restrictions, maybe we better should name it “Forwarder” instead of “Gateway”.





You need to define the IP address of the TTN server in the gateway software

  • In main.cpp, update the IP address of TTN server.
    You can find the current IP addresses to use here: For different countries there are different server addresses. Pick the appropriate one.
  • For europe (EU), I choose
    router.eu.thethings.network # EU 433 and EU 863-870

    Note that you can’t enter this server name directly, you need to lookup the IP address before:

    $ nslookup router.eu.thethings.network
    Non-authoritative answer:
    router.eu.thethings.network canonical name = bridge.eu.thethings.network.
    Name: bridge.eu.thethings.network

    The IP address to use in main.cpp is

  • In the code of main.cpp, it should look like this:
    // define servers
    // TODO: use host names and dns
    #define SERVER1 ""
    //#define SERVER1 ""    // The Things Network: croft.thethings.girovito.nl
  • Now compile the software and start it
    sudo ./single_chan_pkt_fwd
  • On start, it will output its Gateway ID, which is important for the next steps:
    pi@raspberrypi:~/single_chan_pkt_fwd $ sudo ./single_chan_pkt_fwd 
    SX1276 detected, starting.
    Gateway ID: aa:bb:cc:ee:ff:11:22:33
    Listening at SF7 on 868.100000 Mhz.

    This Gatway ID is unique for your gateway.

To create a gateway in TTN, you need to register at TTN and create an account. You then can register a gateway in the console.

  • Choose “bridge” as “Activation Method”
  • Cut and paste your Gateway ID as “Gateway EUI”
  • Choose the appropriate frequency plan
  • When you have filled out all fields, press button “Register Gateway” at the bottom of the page.


That’s it.

You now should have created you own experimental gateway in TTN and you should see that it has status “connected”.

Cross compiling to Raspberry Pi

Please don’t ask for the reasons, but the goal of today’s action was to get a cross compile environment running on Windows OS in order to compile to my RPi3 running Raspbian “jessie” (Raspbian GNU/Linux 8).

I write this blog post as a shortcut for people that like to do the same: Use the resources and comfortable IDE on a PC and do the code writing here, compile, link and finally transfer the executable binary to the Raspberry Pi and execute it there.


Downloaded Eclipse CDT as IDE for C/C++ programming.

Eclipse IDE for C/C++ Developers
Version: Neon.2 Release (4.6.2)

Precompiled GNU Toolchain for Windows32

Linaro provides several precompiled toolchains. It is up to you to select the right one.

It needs to fit the system architecture on the Raspberry Pi and the remote operating system you are running on (Raspian “jessie”).

There is a list of Linaro releases here:

For Windows32 as host/development system, I chose

Download it and extract it on your windows filesystem.


You additionally need build tools like “make”.

This can be downloaded from here:

Put the buildtool’s bin directory into your Windows PATH environment variable to make sure they are found by Eclipse. You possibly may need to restart Eclipse. If “make” ist not found when compiling some source files, then the reason is probably that the path to the buildtools is not configured properly.

Configuring Eclipse CDT

Create a new C project named “hello_world”, choose project type “Empty Project”. Toolchain “Cgross GCC” should be selected.

If you are ask for “Cross compiler prefix”, you enter


Note: Don’t forget the hyphen (“-“) at the end.

For “Cross compiler path”, navigate to the “bin” directory of your toolchain installation. In my case, it is


Note: There are two bin directories in the toolchain installation. Make sure to select the one that contains binary executables starting with the filename “prefix arm-linux-gnueabihf-“, e.g. “arm-linux-gnueabihf-gcc.exe”.

Hello World Application

Create a small hello_world.c file.

#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("Hello World.\n");

Compile it in Eclipse using Project -> Build All, and that’s it (almost).

00:40:57 **** Build of configuration Debug for project hello_world ****
make all 
Building file: ../hello_world.c
Invoking: Cross GCC Compiler
arm-linux-gnueabihf-gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"hello_world.d" -MT"hello_world.o" -o "hello_world.o" "../hello_world.c"
Finished building: ../hello_world.c
Building target: hello_world
Invoking: Cross GCC Linker
arm-linux-gnueabihf-gcc  -o "hello_world"  ./hello_world.o   
Finished building target: hello_world

00:40:59 Build Finished (took 1s.449ms)

Looks good. You can see that arm-linux-gnueabihf-gcc was both used for compiling and linking.

Transfer binary executable to Raspberry Pi

The binary is located in the project subfolder debug. Transfer it to the remote Raspberry Pi. Eclipse provides a way to build connections to remote systems using New -> Other -> Remote System Explorer. You can use this to transfer files without having to leave the IDE.

On Rasperry Pi, make the file “executable” and execute it:

pi@rpi3:~ $ chmod u+x hello_world
pi@rpi3:~ $ ./hello_world
Hello World.

Works. Fine. Go to bed now.

New project: LoRaWAN hacking

Inspired by the first meeting of the The Things Network Community Stuttgart this week I decided to make first steps with LoRaWAN communication. I was looking for a solution that works without soldering, and actually Dragino provides a extension module for Raspberry Pi, which is intended to build LoRaWAN solutions.

Dragino LoRA/GPS HAT

I ordered via Maker Shop EXP TECH, and actually the hardware arrived just one day after ordering. Great service.


Next to the Semtech LoRa transceiver there is also a GPS receiver on the extension board.

As I already have experience with FSK modulation in the 868MHz band, I think the first steps will be to check out how to use this kind of communication, before switching to LoRa and LoRaWAN.


Obviously my software works well to receive messages from the radiator controllers if they are just sent sporadically – every now and then.

But the software is unable to receive sequences of messages, in case they are sent directly one after the other, without temporal gap. In fact, the Room Unit sents sequences of messages in case the temperature of a zone has to change.

Why does the software fail?

Because it tries to read one message into the 64 byte FIFO receive buffer. As it is not possible to find out how long the message will be (without decoding it), the software just reads until the 64 bytes are read. And this is fatal, as in this case the software already reads the beginning (e.g. the RF preamble of alternating “1” and “0”) from the subsequent message.


66 55 56 55 2B 2B 52 B2 AD 53 4A CD 52 B5 55 55 55 55 55 55 55 4C B5 2C AB 4B 4A B5 2C AB 32 CA B2 B5 4B 2C D2 B4 CD 59 55

What now?

  • Alternative #1: Forget to read messages in the FIFO buffer and decode after that, instead do “direct stream processing”, bit by bit ?
  • Alternative #2: Fill the FIFO buffer byte by byte, and somehow try to find out when the complete message is read, then (very quickly) process the message and receive the next message using the RF receiver. The problem is that it takes some amount of time to decode the message and send the result to the client – probably too much time so we miss the RF preamble of the subsequent message.


Librato – Real-Time Monitoring of my room temperatures

The electronic radiator controllers in my house send out the current temperature every now and then. I receive this messages with my CC1101 based hardware solution and needed a solution how to graph diagrams that show the room temperature over time of day.

Librato is a cloud service provider that allows me to visualize this metrics in beautiful charts … in just a few minute’s time! It is really awesome how fast it was able to compose a dashboard using the charts I created for temperature values and the received signal strengh (RSSI) of the radiator controller as sender of the data.

I used python (librato-python) to send the metrics up to Librato:

api = librato.connect(“myemailaddress@gmx.de”, “some_api_key”, sanitizer=librato.sanitize_metric_name)
q = api.new_queue()
q.add(controller[deviceId], temperature)
q.add(“RSSI_” + controller[deviceId], convertRSSI(rssi))

Librato provides even more, check out their website at https://www.librato.com

Check out his picture of my dashboard

Librato Dashboard

What can you see? In some rooms, at night the temperature slightly goes down from 21°C   to approx. 19 °C. In the morning at 7am, the central heating controller puts it up to 21°C again, and 23°C in the bathroom.

SPI communication issues with Raspbian “Jessie”

Now that we are in the middle of autumn in Germany, and the daylight gets less and less, I decided to re-activate this little project of mine.

First thing was to update my Raspberry Pi (1) to Raspbian “Jessie”.

First check of my CC1101 Socket Driver Stack – and: Of course, it did not work.

Reason was that with Raspbian “Jessie” the way to enable the SPI kernel driver has changed. You can enable it using the “Advanced options” in the “raspi-config” configuration tool. Check out the description here: http://www.raspberrypi-spy.co.uk/2014/08/enabling-the-spi-interface-on-the-raspberry-pi/

Okay, after a reboot

  • lsmod shows the SPI kernel driver spi_bcm2835
  • The device files /dev/spidev0.0 and /dev/spidev0.1 exist

After that, the CC1101 Socket Driver Stack still did not work. Nothing was received over the air. Doing some analysis revealed that the ioctl calls responsible for the SPI data transfers between RPi and CC1101 failed.

Reason was that Raspbian “Jessie” uses a newer kernel than “Wheezy” and that the main ioctl message structure got a new field named “pad”

After I did take some more care to initialize this message structure in the code, everything worked will again.

And now the bad new: When analyzing the issue, I also killed my cross-compile installation  on Mac OS. It still does not work until now 😦