2 LoRaWAN Nodes went for a train ride through the Netherlands….

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).

Tracking the Marvin on KPN

KPN has got a debugger tab on its LoRaDeveloper site where you can see the 10 most recent received messages. You can’t see any real metadata like gps coordinates of the gateway there, but it helps to see if the node is successfully sending messages (actually: if it send messages that are successfully being received).

But on the Loggly dashboard, the messages and all the metadata was displayed as soon as they arrived, so that was reassuring. The Marvin, despite it not having an external antenna, it being in a plastic container in a fast moving train delivered a lot of messages during the day.

Tracking the LoPy on TTN

The LoPy did nothing at first. No messages were being received due to the network being down. But even while the network was up during the trip back, still nothing. When I connected the node directly to my laptop so I could see the messages, I realized what was a  possible problem: I was using OTAA (over the air authentication) and that requires 2 way communication between node and gateway. Not that the LoPy can’t do that, but it means more time needed to register. So, I switched to ABP (authentication by personalization) and finally messages arrived. Not as often as with the Marvin, but it worked.

BTW, TTN has a really cool mapping tool for situations like this: ttnmapper. I installed the app on my Android LG G4 and it then uses the GPS of the phone to determine where you (and the node) are. Keep in mind that it totally drains the battery of your phone, so bring a backup/spare battery.

Analyzing the logs

So, who did a better job at receiving the messages from my two nodes? Was it KPN or TTN? I didn’t need much analyzing to conclude that, despite the really cool TTN map, and despite that my train trip went through areas like Eindhoven, Den Bosch, Utrecht, Amersfoort, KPN has much better coverage in between those cities. I did notice that sometimes there were a couple of minutes between messages, so data probably got lost also (note to self: use a counter a message contents so that it is possible to see how many packages did not make it!), but overall the coverage, in particular with this speed was impressive.

Loggly.com uses JSON to store, export the data. I wanted to extract just the coordinates of the gateways. That sounded easy enough. I exported the data to csv. However, in case of TTN, the message can be received and relayed by multiple gateways which all get listed in the data. If I export that to csv, straight from Loggly, the conversion doesn’t work. You get a csv, but for stuff like the coordinates, gets buried in a single word “array”.

So I exported the whole dataset to JSON and then used this online tool to convert it into a flat XLS file. After exporting it to CSV, I could use this online tool to convert the CSV to GPX. Then I used this online tool to put the GPX on a Google map. That looks like this:

Can you tell which one is which?

I should be relatively easy to see that the left map (TTN/LoPy) contains much less gateways than the one on the right (KPN/Marvin).

Conclusion

KPN can be considered the current champion as far as the comparison “LoRaWAN messages from within a moving train” goes. Most impressive is one gateway, that according to its coordinates is over 16 km from the train tracks. I know LoRaWAN was meant for much larger distances, but considering that the Marvin has no external antenna, just the one on the motherboard and was located in a fast moving metal object, I had not expect to reach those distances.

Does that mean that TTN is bad or useless? No, not automatically, but it does mean that if you take a node, connect it to TTN and travel across the country, there will be a lot of areas where the node won’t be able to connect. Unlike with KPN, where a scenario of a container on a freight train sending temperature data (and preferably of course GPS for the node) via LoRaWAN looks like a totally feasible scenario already. Even if some packages get lost, the coverage is good enough.

Then again, at Utrecht CS for example, the TTN connection was great. The mapping tool showed that, even while I was walking around the train station because I had to change trains, the messages were being delivered. And so was the situation in some other areas like Eindhoven, Apeldoorn, even passing through Helmond resulted in a number of close-enough-by gateways.

Also, the TTN node (the LoPy) reported all transmissions being done using SPF7 while the Marvin on KPN used SPF12 a lot (for most of the messages). I do not know what makes the node decide to switch the spreading factor and thus the possible range of the transmission. For either nodes, the code itself doesn’t contain anything that looks like something that changes this.

One option of course would be to repeat a test like this with both nodes on KPN or both nodes on TTN to rule out differences caused by the node, their firmware and the programming used. I don’t have to be in Zwolle for a while, but given that KPN has full coverage of the Netherlands, other routes are a possibility there also. For another TTN test, my usual route to work isn’t that optimal since even ttnmapper doesn’t show any gateways even remotely near that route.

To be continued.