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

[Colateral]

@robert-hh I believe I know what was happening. If you jump from Wipy default AP to the new AP (as STA_AP) having the same MAC and you try to connect Wipy to the wifi router where computer is plugged with the Lan cable... . Windows 10 is going to be confused. After I restarted windows and unplugged the cable everything is working fine.

[gas]

@gas said:

router.eu.thethings.network:1700

we are talking at the TTN side right

Description            lopyNanoGW
Status                      not connected
Frequency Plan      Europe868MHz
Router      router.eu.thethings.network:1700

[jmarcelino]

@gas
On TTN have you registered the gateway as "gateway connector" or "packet forwarder" under Protocol?

You have to register as "packet forwarder"

TTN will also automatically add a 'eui-' prefix to your gateway ID if you chose the correct one.

[rskoniec]

@gas Here is my TTN config:

Gateway should be packet forwarder type.

[gas]

@jmarcelino
your right i was using the Gateway not the packet forwarder

now it is connected cool
but the exampe of otaa is wrong
lora.join don't se deveui
my node is connected over my Lopy LoRaWAN nanaGW OTAA

github should be updated

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

[daniel]

@gas, yes, the example force the deveui to some value, I'll update the code on githb to clarify that. Thanks!

[gas]

@daniel

Thanks
Great Job any and impressive both micropython and Pycom
now let me try the range with my sample code of GPS ...

[daniel]

@thanks! keep us posted about your results :-)

[Colateral]

@robert-hh I tried Windows10 ftp in browser as ftp://micro:python@192.168.4.1

[ThatStudentGuy]

After upgrading to the latest firmware i'm no longer able to send using raw Lora mode. I'm running the same code as i did before the weekend and it worked then. The code is basically the LoPy to LoPy code for sending and receiving. I did the firmware update. I tried to play around with the public parameter as told earlier but with no result.
Anyone else experiencing the same problem?

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