LoRaWAN with LoPy and KPN + Loggly

 Gepubliceerd door om 15:49  Hardware, LoRaWAN
mei 202017

In the Netherlands, KPN was the first to offer nationwide coverage of a IoT network based on LoRaWAN. You can read about my first tests using their Network in combination with the Marvin node in this post. Unlike with the IoT network that for example is currently being rolled out by T-Mobile, which uses NB-IoT and different hardware than The Things Network (TTN), switching a device from the TTN network to the KPN network is simple: just change the DEV_ADDR, NWK_SWKEY, APP_SWKEY values in the config.py of you Pycom LoPy to the values that are provided in the management environment of KPN (see image left). No changes in the microPython code needed. You could even have a device connect to both networks and switch between them (although you probably don’t want to do that when you’ve got a battery powered node).

KPN offers a free test period where you can test your nodes on their infrastructure without having to pay. It is what I used for my train trip last month where I used both the Marvin node (connected to KPN) and the LoPy (connected to TTN) as a way to get a feel for coverage while moving in the Netherlands.

Besides the fact that KPN offers a commercial solution, the free test version (don’t know about the paid version) has a number of differences: unlike TTN where they provide a number of integration options (Cayenne, Data Storage provided by TTN, HTTP integration, IFTTT Maker), KPN only offers HTTP integration. This means you have to provide a destination URL for an HTTPS endpoint where the data is stored. In the Marvin workshop they use Hookbin.com as a free and easy to setup endpoint. But endpoints created there only store data for a limited time. That is why I now use the free version of Loggly.com to collect the data. But of course, the data is only useful if I manage to get it from Loggly to my own local system.

A second difference is a bit of a mystery. If I used the Marvin to send data over the KPN network, the data gets encrypted by the Marvin, but automatically is being decrypted again on the KPN server. But if I use the LoPy to send data over the KPN network, the data shown in the debug console at KPN and the data received by Loggly is still encrypted.

I managed to get both challenges resolved and in this post I’ll do a write-up not of the (lengthy) process of getting to the working code, but of the end result. All code is available on Github.

Lees verder….

Deel dit bericht:
mei 142017

At AliExpress they sell a number of cheap GPS modules that you can use for Arduino. I ordered one (this one) GY-NEO6MV2 for €6,82 incl. free shipping (the seller doesn’t offer free shipping anymore so you might want to shop around a bit) and wanted to try it out on the LoPy. Now, I wanted to say that using it is really easy, it is, but then again there were more than enough bumps in the road to get it to work the way I wanted it. But hey, what is life without some challenges?

First things first: the GPS module is easy to use. It use UART to connect to it. As soon as you have got something that is willing to listen to it, power it (it worked using 3.3V), it start sending you GPS data that you only need to interpret. I soldered 4 header pins to the module, connected the VCC to the 3.3V, GND to GND on the Pyboard, the TX line to “P11” and the RX line to “P12”.

As soon as you connect power to the LoPy, the GPS unit is powered. The red light blinking means that the unit is working and sending data. You just need to listen to it.  The code to do that is available here on GitHub.

To start listening:  com = UART(1,pins=(config.TX, config.RX), baudrate=9600)

To interpret the data coming from the module, I use the MicropyGPS module. It is initialized using my_gps = MicropyGPS().

After that it is a matter of checking if there is any data available, and then feed it character by character to the module:

if com.any():
    my_sentence = com.readline()
    for x in my_sentence:


Lees verder….

Deel dit bericht:
apr 152017

Now that Alex explained everyone how to use MQTT in combination with the LoPy, I thought it was time to show some more advanced uses of MQTT in case you still had no idea why you would bother learning to understand it.
The nice thing about MQTT (MQ Telemetry Transport or Message Queue Telemetry Transport) as a protocol, is that it is not tied to the LoPy or WiPy that Alex used in his example. You can use it in combination with many different devices, tools and applications. For example, in our house, I use a Mosquitto MQTT broker as the central backbone for the home automation. For those that can understand Dutch, see this blogpost I did in 2014, or the one about the lights in my Christmas tree.

MQTT is also supported by The Things Network (TTN) meaning that you can retrieve all the data that your nodes send to TTN using MQTT. This also means you can use MQTT as a way to create a local backup of the data that your nodes send this way.
You can also use it in combination with the KPN LoRaWAN network, but the setup is slightly different. So in this post I am going to focus on TTN, although like before I will be using both the Marvin board and the LoPy board (in combination with Puck.js although that is completely optional of course).

I will be using Node-RED installed on one of my Raspberry Pi devices and I will be using MySQL as the database backend. I will be posting about MySQL versus MongoDB versus InfluxDB one of these days, but on a Raspberry Pi for now this was the quickest and easiest solution.

Let’s dive in:

Lees verder….

Deel dit bericht:
apr 092017

I still wasn’t out of “what if…” scenario’s for the devices I had been playing with in relation to The Things Network / LoRaWAN. Because, although I had used the WiFi (and of course LoRA) capabilities of the LoPy a lot, I had not yet played with its BLE (Bluetooth Low Energy) capabilities. For that I needed something else that could use BLE to connect to it. My iPad Mini, the micro:bit, my desktop machine (thanks to the BLE USB adapter), they all could do that. But I wanted to use the Puck-js buttons that I had for that.

The use-case:  If I press the button on the Puck.js (I have two of them, I can press either of them), then the Puck.js connects over bluetooth to the LoPy. After the connection has been made, the Puck.js sends 1) its device-id 2) the measurement of the light sensor of the Puck.js 3) the measurement of the temperature sensor of the Puck.js and 4) the battery voltage of the Puck-js. Once the LoPy has received those 4 values (encoded as a single HEX-string), it sends it to The Things Network (TTN) via LoRaWAN.

Like with the Adafruit Circuit Playground, one of the challenges was that both devices (the LoPy and the Puck.js) use different programming languages and there were no existing examples that handles the cross platform connection.

I uploaded all code to github.com

Programming the Puck.js

To program the Puck.js, you need the Espruino IDE. I have had my fair share of problems connecting to the Puck.js from within that IDE. It is probably one of the challenges of using BLE as a connection to program. But in the end it got the job done. I wasted most time trying to understand how I can send data from the Puck.js to the LoPy after connecting to it. There was an example using 2 Puck.js to send data, but I could not figure out what the UUID of the PrimaryService and the UUID of the Characteristic for the LoPy that allowed me to write data to it where.

I tried to figure that out using code on the Puck.js, but that didn’t work. In the LoPy code that I found, the service and characteristic were defined like this:

srv1 = bluetooth.service(uuid=b'1234567890123456', isprimary=True)

chr1 = srv1.characteristic(uuid=b'ab34567890123456', value=5)

I finally discovered how these needed to be added in the Puck.js code by using nRF Connect, a free tool for iOS. After setting up the LoPy so that it broadcasts using BLE (see the code below), I connected to the LoPy using the nRF Connect app. It then shows you the correct UUID’s that are in the Send_BT_to_LoPy.js script:

return d.getPrimaryService("36353433-3231-3039-3837-363534333231");

return s.getCharacteristic("36353433-3231-3039-3837-363534336261");

Easy, once you know it.

Note #1:  The Puck.js connects to a device named “LoPy01” so if you change the name of the device in main.py for the LoPy, you also have to change it in the code for the Puck.js
Note #2:  I added the id for the Puck.js in the code, first line. You need to change that to the code for your Puck.js if you have more than 1 Puck.js and want to be able to keep the transmitted values apart afterwards.

Let’s continue with the LoPy.

Lees verder….

Deel dit bericht:
apr 072017

What happens if you take a LoRaWAN node with you in a train while you travel across the Netherlands for about 2,5 hours? I did not know and wanted to find out today because I had to be in Zwolle for a meeting.

So I charged a big external battery (with 2 USB ports), drilled a couple of holes in a plastic container to guide through the micro-USB connectors, and put in some bubble foil inside for safe transport. I drilled another hole to connect the external antenna for the LoPy node. Besides the LoPy, I put the Marvin in the box, with the temperature/humidity sensor on the outside of it. Not that it really mattered, today was going to be about finding gateways while I was on the road.

Things did not look good for the experiment though in the morning. The Things Network (TTN) backbone was acting up again. That was a bummer, because I still had to change the code on the LoPy. It had the code installed for the Circuit Playground and I wasn’t planning on bringing that also. So I changed the code to a simple “send a number every 30 seconds” but was not able to test it before leaving for the train.

To make matters more balanced: I decided to have the Marvin connect to the KPN network (still got 60 days left on my free trial), but the Hookbin.com server decided that today was a good day to refuse to work. And I needed a place to store the data sent by the Marvin. Luckily I found loggly.com another site that you can use as a destination for KPN nodes. I think it is better than Hookbin btw because it keeps more records and even the free plan should be enough for most people. Another nice thing was that Loggly also can act as an HTTP-integration for TTN, so I could collect both the data sent via KPN and the data sent via TTN in one single place. Quick tip: Loggly provides you with an http:// url for the endpoint, KPN doesn’t accept http:// but you can simply change the provided url to https:// and then it works.

OK, into the train. I wasn’t really sure what to expect. A train means lots of metal and a fast moving object (and nodes).

Lees verder….

Deel dit bericht:
apr 052017

One of the challenges left with regards to the LoPy was to find a way to actually connect sensors to the node. I had little luck with the DHT11 temperature/moisture sensor (one of the drawbacks of MicroPython over regular Arduino code is the lack of libraries) and didn’t have any I2C sensors lying around. But I did of course still had the Circuit Playground by Adafruit and I knew how to talk to that one from another device using the hardware serial RX/TX connection because I had already connected it to a micro:bit that way (the posts are here, but in Dutch).

So surely it should be possible to connect it to a LoPy and send the sensor data to The Things Network (TTN) that way? Is was. Not as easy and simple as I had hoped, but in the end it worked. Since it is rather a complex structure, I made a small graphic to explain how all the parts go together.

Let’s start with the easy parts: I have got a LoPy Nano Gateway up and running. That is not a full compliant LoRaWAN gateway, but it takes care of receiving messages send via LoRa / 868 Mhz and relaying them, via WiFi, via my WiFi Router, the internet, to the The Things Network (TTN) backend. That is the regular part.

On the right end lower corner, the action starts with the LoPy Node. It is connected via two cables to the Circuit Playground (CPG). One cable goes from the TX port of the LoPy Node to the RX port of the CPG. The other one goes from the TX port of the CPG to the RX port of the LoPy Node. The LoPy Node sends a signal (a digit ranging from 1 to 10) over the serial connection to the CPG. After the CPG receives the signal, it reads the three build in sensors for light, noise and temperature. It then converts the values to a 12 byte HEX string value and sends that back over the serial connection toe the LoPy Node. After sending the signal, the LoPy node waits a bit, giving the CPG time to return the value, then it reads the values and sends that via LoRa to the first available gateway, in this case the LoPy Nano Gateway on my desk.

After the gateway has delivered the messages to TTN, a Payload function translates the received value back into three individual values. It then send them, via the Integrations option, to the Swagger server where it the is available in JSON format. See, easy peasy. 🙂

I uploaded all the code to Github. You can find it here. The code in the LoPy-flash folder is (of course) intended for the LoPy Node, the code in the Circuit Playground folder needs to be uploaded to the CPG via the regular Arduino IDE. I made some changes to the LoPy node code provided by Pycom: I added the option to have the LoPy Node also connect to your local WiFi. Not necessary, but it makes it easier to debug/connect. If you leave that info blank, it will just ignore. Also, if you take the node outside of the range of you WiFi network, it will just ignore it. Another thing that I changed, is the use of config.py for the Node, so that you only need 1 place to change all the info. Finally I choose OTAA instead of ABP as the authentication for the node.

Lees verder….

Deel dit bericht:
apr 022017

If there is a thing that is dislike most, than it is giving up on a technical problem before it is solved. So, although this weekend a late cold finally managed to make me sleep more than usual, I did manage to spend some time with The Things Network, the LoPy Nano Gateway and the Marvin Node.

So, one thing that really can kill your debugging efforts is the fact that the backbone for The Things Network is rock solid stable. I don’t know whether that just is the case during the weekend, but like last week, this weekend there were some outages. There is no single status page that you can check, so that makes it a bit hard. But I’m starting to learn that if the console page act oddly, like failure to show the gateways that I defined, or if suddenly everything is displayed is disconnected, it might just be that they are having problems on their end.
Who am I to complain about a free service? I know, still, an automated page that tells me if I need to just wait and do other stuff, would be nice.

But during the uptime, I was able to get some more stuff working.

First of all: the code that Alex used in the video does work, just make sure you select “Packet forwarder”.

Another thing to know is that the default abp_node.py script has this code:

for i in range (200):
s.send(b'PKT #' + bytes([i]))
rx = s.recv(256)
if rx:

Basically it just sends 200 packages within a short time and then stops. So if you don’t know that, you’ll think the node stopped working. It does, but on purpose. Now if you reset the LoPy, it will start again, but the TTN backbone will ignore that data because the LoPy will start again with package #0, and the backbone will already have a package #0. The quick solution during testing is to reset the frames counter for the device.

Also, the test script is nice for testing, but LoRaWAN was not build for a rapid stream of data, so make sure you read the post about the TTN Fair Access Policy, even with small messages at close range, the 500 messages (of 10 bytes each) per day at SF7 means max. 1 message per (about) 3 minutes, the script sends one every 10 seconds. Granted, it stops after 200 messages, but if you repeat that 2-3 times during testing, you go above that.
For me, testing it on my own Nano Gateway, the chances that I “steal” airtime from other nodes is small, but if you’re using someone else’s gateway, you could be causing problems for other nodes being unable to get their messages through.

But like I said in the title, the weekend showed there is still some love left. I managed to get a few more things working with my two nodes.

Lees verder….

Deel dit bericht:
mrt 312017

If your are used to learning stuff without there being a clear manual available, without a teacher that gives you a step by step breakdown of what to do, like when you like to experiment and play with electronics or ict, then you know how frustrating the process of trial and error can be to get something to work. And how rewording it is when it does work in the end.

There are limits however. And LoRaWan in combination with The Things Network (TTN) is really testing my limits with this regard. Because it turns out it is really tough to get it to sort of work, even though it looked easy at first, and I am not sure anymore whether this is good and a way to learn all the ins and outs of LoRaWAN and TTN or whether it just is not worth it (yet).

So, what is the current situation?

  1. On Monday I wrote about connecting the Marvin node to KPN, that worked surprisingly good and was easy to do. Connecting the LoPy as a node to KPN was just as easy. But since KPN is a paid solution and I don’t have a use-case that warrants that amount of money, I kept on looking.
  2. On Tuesday I wrote about setting up a single channel gateway for TTN. That worked also, but only for half a day. At the moment, I understand it sort of was surprising that it worked at all, though online information isn’t always very clear whether failure is by design or by accident, in particular because that info was from before I got the gateway online. Currently, that gateway shows as connected in the TTN console, but no data has been transferred by it since it disconnected Tuesday evening.
  3. Yesterday, there was a live broadcast by Alex from Pycom where he was going to explain how you can use the LoPy as a “Nano Gateway” for TTN. If you watch it, you’ll see that even for Alex, getting the LoPy acting as a gateway is not easy and not something that he could totally do from start to finish during a livestream. I tried to follow the steps that Alex outlines, wasted a couple of hours last night and by the looks of it by accident, the gateway started to accept broadcasts by both the second LoPy and the Marvin node. However…
  4. The LoPy Nano Gateway still is online, data from both of the nodes is being displayed in the console page for the gateway (see image), but not always and none of that data (except for the first few hours) is displayed at the data page for the nodes. So basically I now have a functioning gateway and still no data from the nodes.

Give up or go on?

Personally I don’t have any use-case for nodes that need to be in a location where there is no WiFi. Yes, WiFi uses a lot of battery power, but for the more battery sensitive stuff, 433Mhz transmission also works, and I have got plenty of those lying around.
Yes, I know that Single Channel Gateways or Nano Gateways are not LoRaWAN compliant. So, I cannot blame TTN if they don’t (fully) support them. And nobody is forcing me to use their free infrastructure.
But I am someone that would be willing to spend the couple of hundred euros needed to put a gateway on my house, either by building one for 200 euros or buying one for 400 euros, but with this little succes (and love) in a test setup, that is not going to happen. Because I really don’t know if spending that money would fix all the current problems.

So for now, my home village will have to do without TTN capabilities. I did post a question on the Pycom forum, maybe Alex can shed some light on the problems, maybe he has suggestions, other than that, I don’t know what to test for now.
If someone has a spare gateway lying around that he wants to borrow or donate to get Deurne (NL) on the TTN map, let me know!

Deel dit bericht:
nov 122016

Na de LoPy loopt er op het moment weer een LoRa Kickstarter campagne: de Marvin, een project van RDM Makerspace uit Rotterdam.

De Marvin verschilt op een aantal punten van de LoPy.

Zo beschikt hij niet over WiFi of BLE (Bluetooth Low Energy), is er geen sprake van een externe antenne (zat blijkbaar wel bij de prototypes) en is er geen ondersteuning voor microPython ingebakken.
Daar staat tegenover dat hij een USB-aansluiting heeft zodat je hem eenvoudig (zonder extra uitbreiding) via de USB-poort van de computer aan kunt sluiten en kunt programmeren én je hem eenvoudig op een powerbank kunt steken om hem te laten functioneren. Ook zitten er vijf “Grove” aansluitingen op waarmee je eenvoudig sensoren aan kunt sluiten (mits die ook een Grove aansluiting hebben).

Ook de chip is anders, de LoPy gebruikt de gloednieuwe ESP32 terwijl de Marving gebruik maakt van de toch al wat oudere Atmel 32u4. Tot slot is hij net wat duurder. Een LoPy kun je al kopen voor €29,95. Koop je het ontwikkelbord erbij (wel zo handig) dan komt daar nog eens €16,- bovenop, een antenne set nog eens €9,-
Dan nog, bij die complete set, zit je lager dan de €70,- die de kale Marvin moet gaan kosten. Het zal dus van het gebruiksscenario’s af gaan hangen wat je voorkeur heeft.


Deel dit bericht: