Fipy with OTAA node - Nano Gateway - TTN (not join)

  • Re: FiPy with LoRaWAN using AS923 channel plan

    I have 1 fipy with nano-gateway firmware (COM7) installed and 1 fipy with otaa firmware (COM6) installed.

    The forward end-to-end communication (i.e. OTAA node to Nano Gateway to TTN) seems ok, but the backward end-to-end communication (i.e. Nano Gateway to OTAA) not successful.


    1. OTAA node appears to be unable to join, therefore unable to received message back.

    2. Device Addr appears in TTN changes everytime I reset the OTAA Node, it is correct?

    Please advice. Thanks.


    OTAA Node and LoRa Nano Gateway


    1. Both Nano Gateway and OTAA node updated with latest firmware release 1.16.0.b1.


    1. The OTAA node unable to join (PROBLEM)

    Source Code (modified) (for both LoRa OTAA and Nano Gateway)
    Using AS923 Frequency,
    LORA_FREQUENCY = 923200000
    LORA_GW_DR = "SF10BW125"
    LORA_NODE_DR = 2 (OTTA node only)

    for i in range(3, 16):

    lora.add_channel(0, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)
    lora.add_channel(1, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)
    lora.add_channel(2, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)
    RX_PK = {
    'rxpk': [{
    'time': '',
    'tmst': 0,
    'chan': 0,
    'rfch': 0,
    'freq': 923.2,
    'stat': 1,
    'modu': 'LORA',
    'datr': 'SF10BW125',
    'codr': '4/5',
    'rssi': 0,
    'lsnr': 0,
    'size': 0,
    'data': ''


    1. Though I am using same fipy as my otta node, when I press reset button on the fipy, I received different device addr at TTN, it is correct? (PROBLEM)

  • @philip_teoph I made the same experience. It joined ONCE in four days od testing. Some of my observations are here:
    The title is a little bit misleading.
    The fact that I mentioned 1.15.0 is more a hint to Pycom, that it worked in earlier versions.

  • @robert-hh I would prefer to run on 1.16.0.b1 or above instead, since I needs to work on AS923 channel plan in my country as suggested by above by

    For your info, I just managed to get it join once. BUT, after I power off both Fipy (OTAA node and Nano Gateway) and try again, I CANNOT get it to join again (see INFORMATION).

    Are there anyone that found solution that fix the same stability problem?




    OTAA Node : FiPy
    Nano Gateway: FiPy
    Firmware : 1.16.0.b1 (OTAA only)

    '# remove all the non-default channels
    for i in range(3, 16):

    '# set the 3 default channels to the same frequency (must be before sending the OTAA join request)
    lora.add_channel(0, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)
    lora.add_channel(1, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)
    lora.add_channel(2, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)

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

    '# wait until the module has joined the network
    while not lora.has_joined():
    print('Not joined yet...')


  • @philip_teoph I have the same problem & fighting with it since days.
    Node: FiPy
    Gateway: Lopy
    Firmware 1.16.0.b1
    ABP mode works more or less. Uplink messages are delivered, dowlink messages rarely.
    However, downgrading the FiPy node to Firmware 1.15.0.b1 made the OTAA join succeed. Only then messages from the node to the gateway are not received in about every second case.
    So, there is much room for improvement.

    I think it is normal that device addresses are re-assigned, becase OTAA handles this dynamically.

Log in to reply

Pycom on Twitter

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.