New firmware release 1.6.7.b1 (LoRaWAN Nano Gateway with TTN example!!)

[Clemens]

@ThatStudentGuy The public parameter is for talking from LoPy to RFMs necessary. Your problem is related to theat but not the public variable. Unfortunately there was a major change in the LoRa specification section, you have to set parameter expicitly now, see
https://forum.pycom.io/topic/770/lora-receiving-only-b

It's a bit annoying that now all defailt examples here in the forum and also on git no more working, from y perspectiv a no go and very frustrating for new users. You are tolde that you have to update your board but the "simplest code you can get" is not working, see my comments about that under:
https://forum.pycom.io/topic/770/lora-receiving-only-b/4

In case there is a need for this heavily change it must be documented on a prominent location or the next release must have a kind of change or fix. Just my 2 cents! ;-)

[ThatStudentGuy]

@Clemens
Thanks for your answer. That was indeed the problem.

[Movsun]

Hello,
I have successfully connect the LoPy to TTN. But when I try the ABP and OTAA code on other LoPy I don't see data in TTN device. and device status is never connect. I use "binascii.hexlify(lora.mac()).upper().decode('utf-8')" to get my device EUI to register my device in TTN. and use the key they generate to put in the example code.
I have already update the to device to 1.6.7.b1. What should I try to find the problem?

[daniel]

@Movsun if you look at the OTAA example, you'll see that we are hardcoding the DEV_EUI:

# join a network using OTAA
lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0)

Do the join like this in order to use the MAC address of the LoPy as EUI:

lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0)

[livius]

@daniel
It looks like STA_AP mode work ok
and there is some issue with Windows10 system not Wipy itself
fixed by tip from @Colateral
https://forum.pycom.io/topic/679/ap-sta-mode/5

And another +
on 1.6.7 i do not see corruption of files compared to 1.6.3 version :)

[rskoniec]

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

and Downlink timestamp error!, t_us: xxxxxxxxxx messages:

Push ack
Downlink timestamp error!, t_us: 4295216794
Pull rsp
Push ack
Downlink timestamp error!, t_us: 4295288926
Pull rsp
Pull ack
Push ack
Downlink timestamp error!, t_us: 4295280463
Pull rsp
Push ack
Pull ack

I would like to know a little bit more about these.
Thank you in advance.

[daniel]

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

[Movsun]

@daniel Thank you, And if I want to use 250 khz bandwidth. which code should I modify in both the gateway and node?

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

OK, thank you @daniel I hope you'll find the cause of those.

[daniel]

@Movsun just change the bandwidth (to make it 250 KHz) argument in the LoRa constructor for both LoPy's.

[jomifo]

@daniel +1 to see code adapted for US frequencies.

[Colateral]

Hello Daniel,

You promised weeks ago (around build 1.3.0) that you will enable frozen bytecode. When this will happen?

[johncaipa]

Is there anyone who has tested how many nodes could be received in practice with the nano-gateway?

[Colateral]

@johncaipa So far we tested with 7 nodes .... but not with pycom nano-gw example.

[gerkez]

Hello Daniel,

The scripts look great, but I don't seem to get them working.
I have created a gateway in the TTN console, but the gateway doesn't connect.
I have a WiFi connection to my router, so that is not the problem.

In your config.py:
the GATEWAY_ID = '11aa334455bb7788'. Where did you get this ID?
I created my own ID when I registered a gateway at TTN console.
Can I leave the LORA_DR = "SF7BW125" # DR_5 unchanged?

In the nanogateway.py:
def stop(self):
# TODO: Check how to stop the NTP sync
# TODO: Create a cancel method for the alarm
# TODO: kill the UDP thread
self.sock.close()
I have no idea how to handle those TODO's.
Can you give some examples?

Hopefully you can help a newbee to get this working.
Thanks

GerkeZ

[daniel]

@gerkez you can put there in the Gateway ID that you created when registering it to TTN.

Can I leave the LORA_DR = "SF7BW125" # DR_5 unchanged?

Yes.

Don't worry about those TODO's, those will be taken care of on a future update of the nanogateway scripts.

Cheers,
Daniel

[jmarcelino]

@gerkez
also make sure you have selected the "packet forwarder" protocol when registering the gateway in TTN. I think your ID question may relate to this.

[gerkez]

@daniel
Thanks. I'll try it and let you know

[gerkez]

@jmarcelino
Hi. Thanks.
I deleted my gateway and registered a new one with the "packet forwarder" protocol.
It generates a Gateway ID based on the EUI (eui-70b3d54991ae49e8).
I tried both ID's in the config.py.
eui-70b3d54991ae49e8: script runs but the console displays "not connected".
70b3d54991ae49e8 (without prefix eui-): script runs but restarts all the time.

Here is my config.py:

GATEWAY_ID = 'eui-70b3d54991ae49e8' (not working)

GATEWAY_ID = '70b3d54991ae49e8' (infinite loop, restart)

SERVER = 'bridge.eu.thethings.network'
PORT = 1883

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

WIFI_SSID = 'my ssid'
WIFI_PASS = 'my passwd'

LORA_FREQUENCY = 868100000
LORA_DR = "SF7BW125" # DR_5

[daniel]

The correct gateway ID to use is: 70b3d54991ae49e8

These 2 parameters are incorrect:

SERVER = 'bridge.eu.thethings.network'
PORT = 1883

Please use the same as in the example, which are:

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

Cheers,
Daniel