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

    SOLVED: LoPy, OTAA, Downlink message always repeated

    Scheduled Pinned Locked Moved LoPy
    downlinklopyacknowledgeconfirmationrepeating
    3 Posts 2 Posters 1.5k Views 2 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.
    • M Offline
      Meirssv
      last edited by Meirssv

      Hello,

      I am experiencing an issue with the online console "Downlink" payload in the TTN console. I have a LoPy connected to my application on TTN and it is sending uplink payloads correctly.

      I have setup a test payload (0xCAFEBABE) in the Downlink-section of the 'Overview'-section of my device. The Downlink message is received by the LoPy correctly, but now TTN always repeats the same downlink payload upon each received uplink message sent by the LoPy to the application. I am offending the fair use policy here obviously, and would like to get rid of the cafebabe now ;-) It looks like she's stalking me duh.

      I have been looking everywhere, but cannot seem to find a resolution. Do I need to ack the downlink payload manually in my micro pythons code on the LoPy? Do I need to register a lora callback function for this to work? I'm in the dark here.

      My code for the sending of the payload from LoPy to TTN and reverse:

      s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
      s.setsockopt(socket.SOL_LORA, socket.SO_DR, 5)
      # Tried both False and True for SO_CONFIRMED, same issue
      s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, False)
      s.setblocking(True)
      s.send(uplink_payload)
      s.setblocking(False)
      downlink_payload = s.recv(64)
      lora.nvram_save()
      #Tried a time.sleep(10) here, I was thinking 
      #       maybe the radio needs time to send the ack back to TTN for downlink,
      #       but it did not help
      machine.deepsleep(300*1000)
      
      1 Reply Last reply Reply Quote 0
      • M Offline
        Meirssv
        last edited by Meirssv

        I got rid of it by entering the downlink payload again on the TTN console, choosing 'last' and not selecting 'confirmed'. After this the downlink payload was sent for the last time...

        TTN Console documentation is not really clear on this topic... Anyhow, I got rid of the cafebabe. :-)

        1 Reply Last reply Reply Quote 0
        • P Offline
          PhatNerd
          last edited by

          Thanks Meirssv for posting a solution. Had the same problem. Funny thing is that TTN only repeats the downlink payload on my LoPy module and not on my Microchip RN2483 module. It's like a downlink handshake from LoPy is missing, so TTN repeats queueing the payload. Can't find any documentation on downlink acknowledgements though. Anyway it works now thanks to your reply.

          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