Alex's Corner - Week 3 - LoPy LoRaWAN Nano-Gateway & TTN

[bucknall]

Hi Everyone,

I will be running the next webinar at 2pm (GMT) Thursday the 30th of March, around the topic of LoPy LoRaWAN Nano-Gateways! This will cover a look into Daniel's code, how it all works and how to get it set up for your own use.

The format will be as following:

• Introduction
• Tutorial/Demo
• Questions from Community

Please do ask any questions (either here or in the livestream chat) so I can help you out with any issues/problems you're facing!

Visit this link tomorrow on the 30th of March to join in!

https://www.youtube.com/watch?v=jL7hSx9qNjc

Cheers,

Alex

[rdixey]

Good Explanation of the code and Demo. Now I feel informed enough to migrate from LoRa Nano gateway to the LoRaWAN Nano-Gateway. In regard to future webinar topics I have two suggestions that I could use some expert guidance on.

• It looks like the LoRaWAN Nano-Gateway code will fail if transmit exceeding 256 bytes. Could you demo some strategies of Python code for keeping data within LoRa payload requirements? Currently I gather up sensor data on the node and store in a dict{}, then convert dict{} to byte(), then lora_sock.send(data). After adding sensors I quickly exceed the Lora max payload lora_sock.recv(256). I've been working on splitting the dict{} to keep under payload max, but wonder if there may be a more efficient way?

• Demo how to build firmware / frozen code based on capabilities of release 1.6.9.b1. I have been following the instructions here: https://github.com/pycom/pycom-micropython-sigfox/blob/master/esp32/README.md but have not yet succeed at creating a working build.

[bucknall]

Hi @rdixey,

That's definitely a good point! I shall draw up some clarity for best practices with LoraWAN packets - Not sure where I'll post it to but this could be useful both here on the forum and up on the documentation!

Regarding frozen code, I haven't tested it myself yet; I'll aim to try it out either tomorrow or early next week and look to do a livestream focused on the topic!

Cheers!

Alex

[PiAir]

I am afraid that I just don't get it to work as expected.

First of all: in de video Alex creates a gateway connector. Because that one doesn't connect, he goes back to one he has already setup, but that (judging by the ID) is a packet forwarder. So which one should we use?

I tried the setup for both options, same result.

My LoPy has the most recent firmware installed:
MicroPython v1.8.6-535-g84855b2b on 2017-03-24; LoPy with ESP32
(sysname='LoPy', nodename='LoPy', release='1.6.9.b1', version='v1.8.6-535-g84855b2b on 2017-03-24', machine='LoPy with ESP32', lorawan='1.0.0')

It connects to my WiFi network without a problem (I can check because I can connect both over serial and over Wifi).

The only messages I got are:

Pull ack
Pull ack
Pull ack
Pull ack
Pull ack
Pull ack
Push ack
Push ack
Pull ack
Pull ack
Pull ack
Push ack
Pull ack
Push ack
Pull ack
Push ack
Pull ack
Pull ack
Push ack
Push ack
Pull ack
Pull ack
Pull ack
Push ack

etc.

Sometimes it trowed an:
W (83966) wifi: post pm rx bcn failed

However, the console showed "not connected" consistently. It never succeeded to connect.
I created a LoPy node, had no result either. I had a Marvin based node close by, did not connect via the gateway either.

SUCCESS??
Then suddenly, after about 3 hours of testing without result, packets started arriving, but the gateway still showed as not connected (as never having connected yet). I gave up and called it a night.

NOPE
This morning when I got up, the TTN console showed the Gateway (I ended up with the Packet forwarder because Alex had two of those that appeared to be connected in his setup) very much online with signal coming in every 3 second.
The two nodes are also shown as online, but as in "6 hours ago". No data is coming in anymore, not visible in the console, but also not via the API, if I look a the application.

If I look at the LoPy gateway, it appears to still be receiving data from the LoPy node, but TTN is ignoring it?

In the end, the video did not really help, it did show that Alex had the same problems as the rest of us: he followed the steps that should lead to a working setup, failed.
But during the video, like magic, he had a previously prepared setup that worked without really explaining why that one worked and the other one didn't. I don't have that magic here.
Don't get me wrong, I really appreciate the effort, but either the LoPy is still not doing what it should do, or TTN is still to beta, but for someone that doesn't know the ins and outs of both, this still is impossible to get up and running reliably.

My question would be: can you make the gateway + node code more robust, or show us where to add debug information? So that I at least get a better idea of where to look for problems. Thanks!

[bucknall]

Hi @PiAir, I completely understand your frustration.

I was actually having concerns about calling off the demo as TTN was throwing some strange errors relating to viewing the gateway traffic. I believe they're making some changes as to how packet forwarding is working and that the gateway traffic feature is still under heavy development.

Looking back over the video, I see where the error was coming from; I'd accidentally selected Gateway Connector, under the protocol -

It should be Packet Forwarder and this was producing errors with the manner in which the nano-gateway connected to TTN.

--

What I will aim to do is to tidy up the example we have on the documentation and produce a step by step (with screenshots) as to how you can set up your nano-gateway.

I'll also modify Daniel's code to add a debug output that will hopefully make it easier to troubleshoot on the nano-gateway's side.

Apologies for the issues you've been running into, hopefully we can get them fixed shortly!

Cheers,

Alex

[PiAir]

@bucknall Hi Alex,

Thanks, that would be much appreciated. I understand that stuff related to the TTN backend is out of your control but anything that can make it more clear were the problem lies would be great!

Cheers,

Pierre

[gerkez]

@PiAir

@bucknall

Hi,
I'm in exactly the same situation, latest firmware and so on.
After watching the video, I set up my lopy to act as a nano gateway and thanks to your post, I created a packet forwarder gateway at TTN in stead of the gateway connector. I actually tried both of them.
No success.
At this moment I have a packet forwarder gateway, but I'm wondering whether I should choose a router.
In the video, Alex doesn't choose a router when he adds the gateway, but later on you see the "router.eu.thethings.network" on the pre configured gateway. I wonder where that one comes from.
I know it's the same one as in the config.py file, but should I enter this one while adding the gateway at TTN or not?
It looks like the script is running; I get the push ack's and pull ack's, but no connection with TTN
At the TTN console, I get messages like: "could not subscribe to gateway status. NOC connection timed out" and "Status not connected".

Is this going to work?
I really need a gateway, because there isn't one in my vicinity.

[PiAir]

@gerkez Currently my LoPy shows the same error without changing anything since this morning.
There are reports on the TTN network about the EU-router currently being down: https://www.thethingsnetwork.org/forum/t/lorawan-routers-down/6393
(or at least reports of people not being able to connect), so better wait until tomorrow.

You should go for
Protocol: packet forwarder
Gateway EUI: should be the same as in the config.py
Description: think of something
Frequency Plan: Europe (if you are in Europe)
Location: pick your own house on the map
Antenna placement: indoors

After you create the gateway, in Settings there is also the option "Router" where at first nothing is selected, you can specifically set that to ttn-router-eu but AFAIK that doesn't matter.

For now, nothing to play / experiment with as long as the gateways are (apparently) down.

[PiAir]

@gerkez It looks like the TTN backend is up again, so you should be able to get the LoPy Nano Gateway + the LoPy node working at the moment.

[PiAir]

BTW, I just noticed that the LoPy Nano Gateway and node support downlink information....nice. :)
(now I just have to add some code on the client to actually do something with it and a payload function to do the encoding on the TTN side, see if only the TTN backbone works then testing is much more interesting).

pfff....until I get another upvote I am only allowed one post per 600 seconds...

While I was waiting to post, I had another look at the abp_node.py code in the examples folder:

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

It might be worthwhile to explain somewhere that this node example script sends 200 packages and then stops.
Now, resetting will restart the node, but because the devices on TTN by default do "Frame Counter Checks", the backend will ignore the packages after the reset because the node will start at 1 again and the backend will see them as duplicates.
You can reset the frames counter for the device to fix this.

[gerkez]

@PiAir
Hi Pierre,
Thanks for your replies. I appreciate it a lot.
Who could have guessed that the ttn network / router was down?
Waited until today, have the same config as you described and guess what?
Today everything works. I'm happy, because now I have a gateway I can connect to without having to leave my house :-)
Thanks again.

[PiAir]

I combined a couple of my tests / results of this weekend in another blog post titled "LoRaWAN + The Things Network = Still some love left". Which shows that this weekend was better than last week when I wrote "LoRaWAN + The Things Network = Tough Love or No Love ?" ;-)

[rskoniec]

@daniel said in New firmware release 1.6.7.b1 (LoRaWAN Nano Gateway with TTN example!!):

@rskoniec I'm also seeing those and I'm investigating the cause together with Espressif.

@rskoniec said in New firmware release 1.6.7.b1 (LoRaWAN Nano Gateway with TTN example!!):

Sometimes I see series of W (xxxxxxxxx) wifi: post pm rx bcn failed messages on my LoRaWAN Nano Gateway:

Push ack
Push ack
Push ack
W (147750288) wifi: post pm rx bcn failed
W (147750288) wifi: post pm rx bcn failed
Pull ack
Pull ack
Pull ack

With the newest f/w 1.6.10.b1 I'm still seeing these messages. @daniel Any news from Espressif?

[Peter Lans]

Thank you Alex and all the people here on the forum.
Thanks to all the information provided here I managed to connect my Lopy as nano gateway to TTN. The frontpage detected it although my console tells me it is not connected. I guess that will be fixed at some point in time too.
But the data is coming through from de OTAA node, so I guess it works. It has to, because my Lopy is the only gateway around.

As I am completely new to lora, micropython and microprocessor programming, it is an exiting journey for me. But from here, I do have a great starting point to move on.

Kind regards,
Peter Lans

[jmarcelino]

@Peter-Lans
TTN is saying the gateway "not connected" and other issues should be fixed early next week.

https://www.thethingsnetwork.org/forum/t/known-issue-gateways-show-as-not-connected-in-the-console/6527

[bucknall]

I've gotten around to pushing up the LoPy LoRaWAN Nano-Gateway Tutorial!

Check it out here - https://docs.pycom.io/pycom_esp32/pycom_esp32/tutorial/includes/lorawan-nano-gateway.html

[palmy-nz]

Hi Alex, thanks for these videos.

I managed to get the nano-gateway working, using the Packet Forwarder protocol and finding out my Device EUI with these commands

import network
import binascii
binascii.hexlify(network.LoRa().mac())

However, I could not get the node working with the otaa_node.py example. I am getting this error:

ValueError: invalid argument(s) value

On this line

lora.add_channel(0, frequency=915100000, dr_min=0, dr_max=5)

Note I am on the 915 frequency (New Zealand). Has to be something to do with that aye?

Any advice appreciated.

Ps. I would love to see in an upcoming video how to pull data from sensors, and also push to nodes e.g. trigger led/servo.

[jmarcelino]

@palmy-nz
For the 915Mhz region the dr_max parameter (LoRa datarate setting) has to be 4 and not 5.

You'll also need to change the nano gateway script to match the frequencies and channel, please see this thread https://forum.pycom.io/topic/983/otaa_node-py-error/3

[bucknall]

Hi @palmy-nz please try the settings that @jmarcelino suggested and let me know how you get on. If this fails, I have another idea of what might have been the issue!

Data acquisition is definitely an interesting topic! I'll make sure it's on the list for Alex's Corner!

Cheers,

Alex

[palmy-nz]

Thanks @jmarcelino @bucknall

Changing the dr_max from 5 to 4 (for 915mhz) did fix this ValueError.

Now I am just getting Not joined yet

My gateway config.py looks like this

GATEWAY_ID = '70b3d54990c648be'

SERVER = 'router.au.thethings.network'
PORT = 1700

NTP = "pool.ntp.org"
NTP_PERIOD_S = 3600

WIFI_SSID = '***'
WIFI_PASS = '***'

LORA_FREQUENCY = 915100000
LORA_DR = "SF7BW125"   # DR_5

Anything glaringly obvious?