meshtastic
RS485 Serial Packet Module
This PR adds a module named SerialPacket based on RAK WisBlock 4631+RS485 interface that provides an alternate path for Meshtastic packets.
The RS485 serial link is used as an alternative path for packets (similar to mqtt) 1. Any packet that comes in via wireless is sent out via RS485 (if the packet is rebroadcast) 2. Any packet that comes in via RS485 serial link is sent out wireless 3. Any packet that came in via RS485 serial link is never rebroadcast back to the serial link
This capability is currently used by Huntsville Cave Rescue (http://www.hcru.org/) for underground comms, the serial link allows a mesh deployment that has mixed wired/wireless links (the wired links are used in tight passages). A packet can travel wirelessly, hop on a wired link, hop off and continue wirelessly. Complete documentation on testing is at (https://github.com/rbreesems/flamingo).
This PR only implements the RS485 serialpacket module changes from the flamingo repo and has been tested on firmware 2.6.11 with two (19007 board+ RAK4630) + RS485 (RAK5802 WisBlock RS485 interface) systems.
This PR is woefully incomplete as it does not implement module-specific config (requires protobuf modifications and iPhone/Andoid app, python Meshtastic module changes - the PR author is not familiar enough with the complete Meshtastic ecosystem to be able to implement these changes).
The PR 'as is' will compile, and a hardcoded DEFINE in the SerialPacket.cpp file is used to enable/disable the module - the module is DISABLED by default.
The firmware footprint is approximately 0.5% on a RAK4631 (82.8% before, 83.1% afterwards).
If you need me to work on this PR more in terms of adding serial module config data, protobuf generation, etc, I would need some pointers on how to proceed. I am 'Dawgi' on Discord, email is [email protected].
🤝 Attestations
- [x] I have tested that my proposed changes behave as described.
- [ ] I have tested that my proposed changes do not cause any obvious regressions on the following devices:
- [ ] Heltec (Lora32) V3
- [ ] LilyGo T-Deck
- [ ] LilyGo T-Beam
- [x] RAK WisBlock 4631
- [ ] Seeed Studio T-1000E tracker card
- [ ] Other (please specify below)
Hello! Can you immediately add control over the RS-485 transmission direction, since not all bus driver chips support the auto mode?
Hello! Can you immediately add control over the RS-485 transmission direction, since not all bus driver chips support the auto mode?
I believe this would be easy to add if you knew the IO pin/polarity needed to enable/disable driver TX. It would only take a small change to the SerialPacketModule::onSend method, where the driver would be enabled prior to the Serial1.write call and disabled immediately only return. The IO pin, default output value would need to be configured in the SerialPacketModule::runOnce() method. This code changes would need to protected by an #ifdef RS485_ENABLE or something similar. However, I don't have a board that works this way, and I do not like adding code that I can't personally test. But someone else with a need could easily do this.
