Say I have a Microcontroller device, with a Lora modem. RFM95W+RP2040
Ultimately want to be able to send (unencrypted) messages TO a mesh. But would also be happy to forward messages for others on the mesh. The device never needs to receive a message!
Ideally don’t want to use the full meshtastic firmware on the device, as already has stuff running in MicroPython. Nor do want to have two microcontrollers. (there is a ‘senselora_rp2040’ variant, which is close, but the RF modem is connected to different pins. But dont find a built in image in the flasher)
I’ve got the device listening with the right lora settings (syncword+frequency etc), such that can ‘hear’ the meshtastic messages, and can of course decode the Layer 1 header.
Without going into trying to decode the actual packet data (protocol buffers and encryption etc), would this be enough to play nicely with the rest of the mesh?
(ie just forward the payload as is)
In simplistic terms, if the HopLimit allows, just decrement it, and retransmit.
- Do leave the original Sender NodeID, or meant to put my id in it?
- Wouldn’t be sending ack directly, but they presumably need to be forwarded (as long as not broadcast message)
… would still need a way to identify acks, as would abandon forwarding, if ‘hear’ an ACK for the packet. - Assume still need to do Channel Activity Detection (CAD) to avoid flooding forwarded messages?
… seems like going to need to goto ‘Layer 2’ to really work with ACKs, which means decoding the packet (even if the payload is still encrypted)
I guess the question is there has done this? (a separate node capable of forwarding meshtastic messages ), have found MQTT bridges, but the basically receive message from the Mesh, and forward to MQTT, here wanting a device to ‘participate’ in the mesh.
If no reference implementation, guess will be looking into the meshtastic firmware source itself. But any tips on the specific points above appreciated!