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 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:
mrt 282017

My apologies to my regular Dutch readers, given the nature of the topic I am going to do this post in English also. I promise to return to the regular Dutch posts.

When I wrote about connecting the Marvin board to the LoRaWAN network in the previous post, my conclusion was: wow, great, KPN truly does offer easy access to LoRaWAN and it even has coverage in my hometown whereas The Things Network (TTN) has a far from complete coverage in the Netherlands. (Yes, I know, I can add my own gateway, but before I’m going to spend a lot of money on something like this, I would like to play with it first).

Downside of KPN was/is the costs involved in using it beyond the 71 (72?) day trial period. So I wanted to try to connect the Marvin to The Things Network. For that I first needed something that could act as a gateway. I do have a LoPy, but had been unable to get that setup as a gateway. Luckily I also had a Dragino Lora Shield that I had ordered via AliExpress for $19.- a while back. I hadn’t had the time to try and get it to work as a single channel gateway, but now I did. I used the easy to follow instructions available on mobilefish.com. In my case I used an old Raspberry Pi 1 since it does not have to do too much anyway and I am only going to use it for testing purposes.

Within 10 minutes I had my first gateway online. Thanks Robert!

Next step was getting the Marvin to connect to TTN. I am really new to everything LoRaWAN related, but have some Arduino experience, so a .ino file does not scare me. I took a look at the Arduino script that I used for the temperature / humidity measurements (side note: a working version of the script for KPN is available on github). I could not find too much that looked KPN specific.

The only thing that I had to set for KPN were the set_nwkskey,  set_appskey and set_devaddr variables. So next I had a look around in the devices section of the console at TTN. And what do you know? If you select Activation by Personalisation (ABP) as the authentication method, then TTN provides you with just those three keys. Would it really be that easy? Yes! 🙂

Lees verder….

Deel dit bericht:
mrt 272017

I will do this post in English because the number of potential readers will increase, and because I do have some additional questions that are more likely to be answered this way.

So, last weekend I played around with my Pycom LoPy boards. A while back they announced that it would finally be possible to setup a LoRaWAN Nano Gateway with TTN (The Things Network) using the board. Now, I know there are fierce discussions about this, yes, I do realize that “There are no true or half true LoRaWAN (or even π % true) devices. There are LoRaWAN devices and non LoRaWAN devices“. In my case I simply want to be able to experiment with LoRaWAN and get some nodes connected for testing. Without TTN coverage in my home village that is not going to happen. Now, I might pay for the 300-400 euro for a simple “true” gateway, but it means I will have to have a working setup first. Otherwise I am not sure that it will ever work. But this post is not about The Things Network, nor about Pycom and the Lopy boards. There is a webinar scheduled this week, hopefully after that I will be able to set things up.

It is just an introduction as to why, when I unboxed the Marvin board that got delivered earlier this week, I was not that hopeful about actually getting it to work. And I was wrong. 🙂

Lees verder….

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: