Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    LoPy4 LoRaWAN Nano Gateway and Node - ABP and OTAA issues

    Scheduled Pinned Locked Moved Discussion
    lopy4lorawan nano gwabpotaattn
    19 Posts 4 Posters 4.2k Views 4 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D Offline
      DillanG @robert-hh
      last edited by DillanG

      @robert-hh
      I tested the LoPy4 units with code for Raw LoRa and I was able to transmit and receive messages between the two units so I don't think there is a problem with the antennae I'm using.

      Carrying on using ABP to join, the program definitely gets stuck with the s.send() function. I tried this by setting up the socket with the main program and then typing s.send('Hi') into the REPL. This returned a value of 2 (for the number of bytes I'm guessing??) and then became unresponsive.

      If the settings between gateway and node are different, am I correct in thinking that the node should still be able to send messages? Just the gateway I'm using won't be able to detect them?

      Are there any reasons why the send function might make the LoPy4 unresponsive? Are there some socket parameters that I may have not set?

      1 Reply Last reply Reply Quote 0
      • D Offline
        DillanG
        last edited by DillanG

        Solved by downgrading the firmware on the LoPy4 running as the node to version 1.13.0.b1.

        OTAA join requests work and messages can be sent from the node and appear on the TTN console.

        robert-hhR 1 Reply Last reply Reply Quote 0
        • robert-hhR Offline
          robert-hh @DillanG
          last edited by robert-hh

          @dillang It depends on the combinations of versions. With 1.17.3.b1, you have to use the most recent copy of the nanogateway example from the github repository of the library. The difference: it must use ticks_cpu() instead of ticks_us() for time taking.
          This new version of the nanogateweay example does not work with older versions of the firmware. Uplinks work, but no downlinks, including teh one sent during OTAA join.

          1 Reply Last reply Reply Quote 0
          • B Offline
            bed @DillanG
            last edited by

            Hi @dillang

            I'm also using the AU915 plan and have had a similar problem. Looking at another issue in this forum: fipy_lorawan-otaa-join-freezing-after-subband-selection I think that it's the same issue.

            @jmarcelino has put in a patch which may fix this, though it isn't in a release yet.

            Good luck,
            Brian

            1 Reply Last reply Reply Quote 0
            • R Offline
              RG_ELECT
              last edited by

              Hi,
              I am also having the same issues with my lopy4 node not joining. Issue is the same as @DillanG was there any resolution to this? my gateway is a lopy and is connected to TTN my node is a lopy4 and have the OTAA copied into the main.py file.

              from network import LoRa
              import socket
              import binascii
              import struct
              import time
              import config

              lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.AU915, adr=False, tx_retries=0, device_class=LoRa.CLASS_A)

              dev_eui = binascii.unhexlify('AABBCCDDEEFF7778')

              app_eui = binascii.unhexlify('****D57ED000C4EF')

              app_key = binascii.unhexlify('*****6CAC02F5742C41EE594460FDF87')

              for i in range(16, 65):
              lora.remove_channel(i)
              for i in range(66, 72):
              lora.remove_channel(i)

              print("ADD CHANNELS")

              for i in range(8, 15):
              lora.add_channel(i, frequency=915200000 + i * 200000, dr_min=0, dr_max=3)
              lora.add_channel(65, frequency=917500000, dr_min=4, dr_max=4)

              for i in range(0, 7):
              lora.add_channel(i, frequency=923300000 + i * 600000, dr_min=0, dr_max=3)

              print("JOINING")

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

              while not lora.has_joined():

              time.sleep(2.5)
              
              print('Not joined yet...')
              

              s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

              s.setsockopt(socket.SOL_LORA, socket.SO_DR, config.LORA_NODE_DR)

              s.setblocking(False)
              time.sleep(5.0)
              for i in range (200):

              pkt = b'PKT #' + bytes([i])
              
              print('Sending:', pkt)
              
              s.send(pkt)
              
              time.sleep(4)
              
              rx, port = s.recvfrom(256)
              
              if rx:
              
                  print('Received: {}, on port: {}'.format(rx, port))
              
              time.sleep(6)
              
              D 1 Reply Last reply Reply Quote 0
              • D Offline
                DillanG @RG_ELECT
                last edited by

                @rg_elect Do you ever see the "Not joined yet..." message? I semi-solved this by downgrading the firmware version on the node to 1.13.0.b1, before they implemented the ability to select the LoRa region when the LoRa object is initialised. This solved the issues I had with joining and sending messages.

                R 1 Reply Last reply Reply Quote 0
                • robert-hhR Offline
                  robert-hh @DillanG
                  last edited by robert-hh

                  @dillang The gateway should print a message when it received a packet from the node, even when the TTN parameters do not match. If not, the may work at different frequencies. The nanogateway listens only at a single frequency. So better sort that out first, and then carry on. You may also use the simple examples (e.g. https://github.com/pycom/pycom-libraries/tree/master/examples/lopy-lopy or https://github.com/pycom/pycom-libraries/tree/master/examples/loraNanoGateway) to verify, that the RF set-up works.
                  And yes, if you use revision 1.17.3.b1 of the firmware, you have to use also the most recent copy of the nano-gateway code from the library.

                  1 Reply Last reply Reply Quote 0
                  • R Offline
                    RG_ELECT @DillanG
                    last edited by

                    @dillang Yes that's as far as it gets. I have a feeling it is in the RF connection between the node and the gateway. The gateway doesn't seem to hear it. I have tried all sorts of node codes but it think theres and issue in the gateway RF settings? My gateway shows push and pull ACK from TTN but nothing from the node.

                    1 Reply Last reply Reply Quote 0
                    • B Offline
                      bed
                      last edited by

                      There are a couple of problems with the 0.17.3b1 release around AU915 -- if there are no channels to transmit on, the code will keep looping looking for a channel. Like forever! If you aren't seeing 'Not joined yet....' then I suspect the sends for the OTAA join are stuck in that loop. In 0.17.3b1, the add_channel() command has a problem (fixed on github) which will make your add_channels silently fail. I don't know if the add_channel() when it fails removes the channel. If so then there would be no channels, so the OTAA join sends would loop forever.

                      If you comment out the section of code which removes channels and add channels, then if I'm right, the 'Not joined yet...' messages should start coming out, as the standard channels are setup when in the LoRa() call. I would try that first.

                      I haven't used a nano-gateway, but as has been said, it will only listen on a single frequency, so you need to make sure that your LoPy4 is using the same frequency. If it is on a standard frequency, then I would just use lora.remove_channel() to get rid if all other channels (until a new release is created). Then all LoPy4 transmissions should be transmitted on the channel that the nano gateway is listening on.

                      Good luck!

                      R 1 Reply Last reply Reply Quote 0
                      • R Offline
                        RG_ELECT @bed
                        last edited by

                        @bed Hi.
                        I am getting the “not connected yet” in terminal from the lopy4node. I have removed all channels except 0,1,2 and all on 915200000 freq and data rate 3. I am not sure how to check the freq the nanogateway is listening on? I have setup the gateway config.py file for
                        LORA_FREQUENCY = 915200000
                        LORA_GW_DR = "SF7BW125"
                        LORA_NODE_DR = 3

                        This should setup the freq it is listening on but I need to query the process on what it is actually on?

                        B 1 Reply Last reply Reply Quote 0
                        • B Offline
                          bed @RG_ELECT
                          last edited by

                          @rg_elect Glad that the OTAA is progressing.

                          As the nano-gateway is listening on Channel 0, I would remove 1 and 2 as well. That will force the sends to be on exactly 915.2. With the GW using SF7BW125, that looks like it's DR 5 not 3. So I would try LORA_NODE_DR = 5.

                          I don't know much about the mechanism of the OTAA or the nano gateway so I could be off base here. But it would be neat if the nano-gateway received a message -- does it print out to the console when it does?

                          Anyway, I would suggest removing 1 and 2, and using DR 5 instead of 3.

                          robert-hhR 1 Reply Last reply Reply Quote 0
                          • robert-hhR Offline
                            robert-hh @bed
                            last edited by

                            @bed Yes, approach it step by step. First check the RF connection witrh the simple examples, which are tricky too. Then try ABP join, since that does not need downlink messages. After that go for OTAA join. There is indeed a problem with DRl 0 in the official 1.17.3.b1 revision, see https://github.com/pycom/pycom-micropython-sigfox/commit/ae3a294c40026433dbdac3e08da788b2b4c4dfdb, but that should not affect here.

                            1 Reply Last reply Reply Quote 0

                            Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                            Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                            With your input, this post could be even better 💗

                            Register Login
                            • 1 / 1
                            • First post
                              Last post

                            Pycom on Twitter

                            Pycom