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

    Packet loss in Lorawan

    Scheduled Pinned Locked Moved LoPy
    nano gatewaypacket loss
    13 Posts 7 Posters 3.2k Views 7 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.
    • J Offline
      jcaron @rpct
      last edited by

      @rpct Have you correctly configured the sending node to only use the single frequency the nano-gateway is listening on?

      R C 2 Replies Last reply Reply Quote 1
      • R Offline
        rpct @jcaron
        last edited by

        @jcaron

        Here is node code :

        """ Node example compatible with the LoPy Nano Gateway """
        
        from network import LoRa
        import socket
        import binascii
        import struct
        import time
        import config
        import pycom
        
        print("Single channel node")
        
        # initialize LoRa in LORAWAN mode.
        lora = LoRa(mode=LoRa.LORAWAN)
        
        dev_eui = binascii.hexlify(lora.mac()).decode('utf-8').upper()
        if dev_eui in config.NODES_AUTH :
            print('Got auth parameters for {} TTN node'.format(config.NODES_AUTH[dev_eui].ttn_name))
        else :
            raise Exception('Cannot get OTA auth parameters for node with DEV_EUI {}'.format(dev_eui))
        
        # 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)
        
        # remove all the non-default channels
        for i in range(3, 16):
            lora.remove_channel(i)
        
        # join a network using OTAA
        if(config.NODES_AUTH[dev_eui].auth_type == LoRa.ABP) :
            print('doing ABP activation')
            if(config.NODES_AUTH[dev_eui].abp_auth == None) :
                raise Exception('No abp params for node {}'.format(config.NODES_AUTH[dev_eui].ttn_name))
            else :
                lora.join(activation=LoRa.ABP, auth=(struct.unpack(">l", binascii.unhexlify(config.NODES_AUTH[dev_eui].abp_auth.dev_add))[0],
                                                     binascii.unhexlify(config.NODES_AUTH[dev_eui].abp_auth.nw_sess_key),
                                                     binascii.unhexlify(config.NODES_AUTH[dev_eui].abp_auth.app_sess_key)),
                                               timeout=0, dr=config.LORA_NODE_DR)
        elif(config.NODES_AUTH[dev_eui].auth_type == LoRa.OTAA) :
            print('doing OTAA activation')
            if(config.NODES_AUTH[dev_eui].otaa_auth == None) :
                raise Exception('No otaa params for node {}'.format(config.NODES_AUTH[dev_eui].ttn_name))
            else :
                lora.join(activation=LoRa.OTAA, auth=(binascii.unhexlify(config.NODES_AUTH[dev_eui].otaa_auth.app_eui),
                                                      binascii.unhexlify(config.NODES_AUTH[dev_eui].otaa_auth.app_key)),
                                                timeout=0, dr=config.LORA_NODE_DR)
                                                # wait until the module has joined the network
                while not lora.has_joined():
                    time.sleep(2.5)
                    print('Not joined yet...')
                print('Joined')
        else :
            raise Exception("Authentification type : {} not handled".format(config.NODES_AUTH[dev_eui].auth_type))
        
        pycom.heartbeat(False)
        pycom.rgbled(0x00ff00)
        
        # create a LoRa socket
        s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
        
        # set the LoRaWAN data rate
        s.setsockopt(socket.SOL_LORA, socket.SO_DR, config.LORA_NODE_DR)
        
        # make the socket blocking
        s.setblocking(False)
        
        time.sleep(1.0)
        
        i = 0
        while True :
            pkt = b'PKT #' + bytes([i])
            print('Sending:', pkt)
            s.send(pkt)
            i += 1
            #time.sleep(4)
            rx, port = s.recvfrom(256)
            if rx:
                print('Received: {}, on port: {}'.format(rx, port))
            time.sleep(4)
        time.sleep(6)
        

        I observed that moving code that removes all default channel

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

        AFTER join gives better results. I cannot explain it. In my case, I'm only using 1 channel, Join request / Accept will be done using 3 first channels all configured as same channels. Deleting other channels before or after join success should be the same? In all cases, when node sends a packet it only sends it on 3 first channels.

        J H 2 Replies Last reply Reply Quote 0
        • J Offline
          jcaron @rpct
          last edited by

          @rpct In the general case, changing the frequencies after the join (and a few packet exchanges) could be different as the gateway can give instructions to the node about which channels to use.

          Not sure if the nano-gateway code does anything like that...

          bmarkusB 1 Reply Last reply Reply Quote 0
          • bmarkusB Offline
            bmarkus @jcaron
            last edited by

            @jcaron said in Packet loss in Lorawan:

            @rpct In the general case, changing the frequencies after the join (and a few packet exchanges) could be different as the gateway can give instructions to the node about which channels to use.

            Not sure if the nano-gateway code does anything like that...

            Gateways never give instructions (more precisely MAC commands) to devices, it is up to the Network Server. Gateways do not have encryption keys nor any knowledge on devices.

            1 Reply Last reply Reply Quote 0
            • C Offline
              chumelnicu @jcaron
              last edited by

              @jcaron The node is to close to gateway ...

              1 Reply Last reply Reply Quote 0
              • H Offline
                hajermet @rpct
                last edited by

                @rpct how did you import the network module please? I'm new to pycom and I'm having problems with that . Can you help?

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

                  @chumelnicu could you be more precise about mechanisms causing packet loss when gw is too close from node? How can we calculate minimum distance? How can we check a node is too close?

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

                    @rpct try to delete all channels but one after joining. That solved it for me

                    J 1 Reply Last reply Reply Quote 0
                    • C Offline
                      chumelnicu @rpct
                      last edited by

                      @rpct To much power could bring lora module in supra-saturation ...For that is important to have a minimum distance between node and gateway .... Just try to put the gateway in other room

                      1 Reply Last reply Reply Quote 0
                      • J Offline
                        jmarcelino @robert-hh
                        last edited by jmarcelino

                        @robert-hh

                        That’s only true for single channel gateways (using a Lopy as a nano-gateway). When using a real, full, LoRaWAN gateway you should keep all the channels.

                        Real gateways also have more sensitivity it’s recommended that nodes are least 2 meters away to avoid overloading the RX amplifiers.

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

                          @jmarcelino as far as OI read it, that's the case here.

                          J 1 Reply Last reply Reply Quote 0
                          • J Offline
                            jmarcelino @robert-hh
                            last edited by

                            Yes thanks @robert-hh,

                            Just wanted to make it clear to anyone looking this answer up for the more generic node - gateway separation concern that was being discussed

                            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