Nano-gateway not receiving LoRaWAN packets



  • 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 ....?



  • @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.



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



Pycom on Twitter