Nano-gateway not receiving LoRaWAN packets

[jand]

I am trying to set up a LoraWAN node and a nano-gateway connected to TTN with two lopy4 boards (firmware 1.18.2.r1) each plugged into an expansion board V.31. I used the latest scripts from Github for both the node (ABP) and the nano-gateway. The gateway is registered on TTN and shows with status 'connected' on the TTN website. The node is sending packets, but the log of the nano-gateway does not show the packets are received (and they obviously don't reach TTN):

Autoconnect: Connecting on COM5...
[     2.437] Starting LoRaWAN nano gateway with id: b'30AEA4FFFEEC9B90'
[     7.259] WiFi connected to: TalkingD
[     7.264] Syncing time with pool.ntp.org ...
[     7.319] RTC NTP sync complete
[     7.343] Opening UDP socket to router.eu.thethings.network (52.169.76.203) port 1700...
[     7.355] Setting up the LoRa radio at 868.1 Mhz using SF7BW125
Traceback (most recent call last):
  File "main.py", line 19, in <module>
  File "nanogateway.py", line 167, in start
ValueError: no region specified and no default found in config block
[     7.413] Push ack
Pycom MicroPython 1.18.2.r1 [v1.8.6-849-e0fb68e] on 2018-11-26; LoPy4 with ESP32
Type "help()" for more information.
>>> [    32.426] Pull ack
[    57.415] Pull ack
[    67.404] Push ack

>>> [    82.408] Pull ack
[   107.404] Pull ack
[   157.406] Pull ack

As the log shows, when starting the nanogateway, an error occurs. But it does not stop the nano-gateway to communicate with TTN (push ack and pull ack):

I know the node is correctly transmitting packets and is properly registered on TTN, because it was able to send messages from that node to TTN through another nanogateway set up with an older lopy running firmware 1.8.6 The same nanogateway script runs on the lopy without any error:

Upload done, resetting board...
OKets Jun  8 2016 00:22:57

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff9010,len:12
ho 0 tail 12 room 4
load:0x3fff9020,len:388
load:0x40078000,len:11584
load:0x4009fb00,len:848
entry 0x4009fc9c
[    52.875] Starting LoRaWAN nano gateway with id: b'240AC4FFFE0272F4'
[    55.812] WiFi connected to: TalkingD
[    55.815] Syncing time with pool.ntp.org ...
[    55.867] RTC NTP sync complete
[    55.888] Opening UDP socket to router.eu.thethings.network (52.169.76.203) port 1700...
[    55.896] Setting up the LoRa radio at 868.1 Mhz using SF7BW125
[    55.908] LoRaWAN nano gateway online
[    55.910] You may now press ENTER to enter the REPL
[    55.933] Push ack
[    80.957] Pull ack

MicroPython v1.8.6-760-g90b72952 on 2017-09-01; LoPy with ESP32
Type "help()" for more information.
>>> [   105.939] Pull ack
[   115.940] Push ack

And it receives the packages from the lopy4 node.

The lopy still runs firmware 1.8.6. I know that I should update the firmware because the function ticks_cpu has been changed from firmware 1.17 onwards and it now returns a value in microseconds, and the nano-gateway example has been updated to use this function instead (see https://forum.pycom.io/topic/2875/new-firmware-release-v1-17-3-b1). With the lopy as nano-gateway the downlink messages did not get to the node ('downlink timestamp error' in the log of the nano-gateway), and I guess that was because of the old function ticks_cpu in firmware 1 1.8.6 being different from what it is supposed to be in the new nano-gateway scripts. So that is why I decided to use the lopy4 as nano-gateway (and ran in the new problem).

What exactly is the error I get on the lopy4 nano-gateway, and why does it not show up on the lopy nano-gateway (although I am using exactly the same scripts)? That is probably where the solution starts ....?

[jand]

@paul-thornton
Thanks, this worked! I figured out that the same addition 'region=LoRa.EU868' is needed at 4 locations in nanogateway.py: around line 169, 263, 355, and 378.

I still have a problem with the downlink not getting to the node (without giving any error message). This may be a timing problem: Only in one instance, the TTN website indicated that the node confirmed receipt of the downlink. In all other cases, no such confirmation was received. Let me investigate that further first.

[Paul Thornton]

Took a quick look at the code. at around line 167~ (its a multiline function call) in nanogateway.py
is a call to the LoRa() constructor. could you try adding a region=LoRa.EU868 parameter to it. (with your required region constant which looks like it might actually be EU868 anyway)

so it becomes

  self.lora = LoRa(
            mode=LoRa.LORA,
            frequency=self.frequency,
            bandwidth=self.bw,
            sf=self.sf,
            preamble=8,
            coding_rate=LoRa.CODING_4_5,
            tx_iq=True,
            region=LoRa.EU868 # inserted region.
   )

and seeing if that fixes your issue.