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

[gas]

@jmarcelino
doesn't this in lower case
I tried the lorwan nano but no luck i don't see it connected
I changed the WiFi parameters and the use the code snippet to generate the gateway_id (i added .lower())
added the gateway on TTN using the same Id
but no lock i don't see pull/push arriving to TTN

do we need to change the router address too ?

Thanks

[livius]

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

I tried your setting and it worked fine for both addresses (STA and AP)

Did you tried WLAN.STA_AP? or separately? WLAN.STA and another try WLAN.AP. Separately it work but not as WLAN.STA_AP.
I have tested this and i can not connect to AP in that mode.
But i have while True: loop.
Inside loop i have machine.idle but this do not help.
I see Wipy on the list of networks but can't connect.

[rskoniec]

@gas On the TTN gateway configuration you should use router.eu.thethings.network:1700 from config.py @jmarcelino addons generating GATEWAY_ID are OK.

[robert-hh]

@livius Yes, I used STA_AP mode, and connected without rebooting the LoPy to the STA and AP, one after the other. At the same time it's not possible since only one connection at a time is allowed. But the behaviour was a little bit inconsistent. In active mode, trying the ls command, I got two different error messages, when it should be the same all the time.

[Colateral]

@livius I tried and STA_AP is working. I am connected with my laptop on AP (ftp getting files) and the WiPy is connected to local server sending data. I replied to your topic ... seems that is missing connect

[gas]

@rskoniec
Thanks itis exactly what i have
I see push pull but nothing on the TTN
I'm missing something .. not sure where (wifi is connected )

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