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

    Raw LoRa

    Scheduled Pinned Locked Moved LoPy
    lopy4raw lora
    4 Posts 2 Posters 36 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
      Michael Brogan
      last edited by

      Hello,
      I'm starting my journey with LoPy4.
      I want to be able to press buttons on one LoPy4 to turn on a LED on another LoPy4.
      So button A LoPy4(1) will turn on LED A LoPy4(2) and button B LoPy4(1) will turn on LED B LoPy4(2) and button C LoPy4(1) will turn on LED C LoPy4(2).
      And depressing each button a second time will turn each respective LED off.

      Is this at all possible?

      Mike.

      1 Reply Last reply Reply Quote 0
      • G Offline
        g0hww
        last edited by

        I would say yes, but with some complexity if you need comms robustness.

        I don't know anything about buttons, but I have been using SOCK_RAW for a while to send encrypted and authenticated location data, This is stateless, and a corrupted or missed message is of no specific relevance.

        You would probably need some kind of ACK/NAK mechanism above the socket that solicits retransmissions of messages, in order to preserve distributed state.

        Even with no specific link challenges, i.e. close proximity and no known interferers, I would receive spurious messages. So I bolted on an HMAC-MD5 mechanism to filter out the cruft.

        1 Reply Last reply Reply Quote 1
        • G Offline
          g0hww
          last edited by

          I have been thinking about this a bit more over the course of the day, and seeing as my last post got an upvote, I decided to offer my latest thoughts.
          My lopy4 based GPS tracker and the LoRa/MQTT gateways (which used to beacon over LoRa too, but that is temporarily inhibited) make their LEDs blink red when they transmit and green when they receive over LoRa.
          Given that your stated requirements don't specify any required level of reliability, I would be tempted to adopt a similar approach. Perhaps blink blue to acknowledge the button press, then red to indicate that the command is being sent, and then green if you get an ack.
          Then it is up to the user to keep pressing the button until he gets a full cycle or blue->red->green, then they should expect the LED state at the far end to match their expectations. If it only does blue->red then they need to have another go.
          This will then only need the receiving end to acknowledge commands, and there is no need for any kind of retransmission in protocol or code. Just make the red blinks long enough to cover up the command/ack exchange time and ignore further input from the buttons until there is an ack timeout.

          M 1 Reply Last reply Reply Quote 0
          • M Offline
            Michael Brogan @g0hww
            last edited by

            @g0hww thanks for taking the time to respond. Have you any code examples? Very basic push button on one LoPy4 turns on a LED at the other.

            Mike.

            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