Raw LoRa

[Michael Brogan]

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.

[Michael Brogan]

@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.

[g0hww]

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.

[g0hww]

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.