-
Notifications
You must be signed in to change notification settings - Fork 906
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make mesh networking work nicely for unicast messages #3
Comments
Hi, I initially used the RadioHead mesh routing algorithm which worked but is pretty suboptimal because really almost all of my packets are better sent as broadcasts. So I have that commented out right now. See the second heading here for ideas I have been considering (also I've been trolling through a bunch of libs and papers): https://github.com/geeksville/Meshtastic-esp32/blob/master/docs/sw-design.md As a side effect of the hackaday post some kind person pointed me at this: sudomesh/LoRaLayer2#10 which looks super promising (and they are just across the bay from me ;-) ) I think the current broadcast solution will work fine for initial usage, but we'll want to have mesh turned back on sometime in the next couple of months. |
Mesh networking is now basically fixed, but keeping this open for a few enancements should do:
|
I did read the files. Nice job @geeksville! Unfortunately, I did not find information (most likely just didn't understand..) of what components the packet header is built of? Are the components, in the headers, kept same in every packet/message type? The mesh is intended to work, correct me if I'm wrong, by these steps:
|
This is all new to me, but this was a study done by Ram Ramanathan et al involved in the GoTenna device, "Long-Range Short-Burst Mobile Mesh Networking:Architecture and Evaluation" |
@ohcdh just because I'm scared about patents I don't think I'll read that one ;-) |
This issue has been mentioned on Meshtastic. There might be relevant details there: https://meshtastic.discourse.group/t/next-work-items-in-my-queue/153/1 |
Fix for T-echo to not have Critical Error #3 on startup
closing issues. this is a question rather than a bug of feature request. |
* INA3221 / Power Telemetry Variant Implementation modified: platformio.ini modified: src/configuration.h modified: src/detect/ScanI2C.h modified: src/detect/ScanI2CTwoWire.cpp modified: src/main.cpp modified: src/modules/Modules.cpp new file: src/modules/Telemetry/PowerTelemetry.cpp new file: src/modules/Telemetry/PowerTelemetry.h new file: src/modules/Telemetry/Sensor/INA3221Sensor.cpp new file: src/modules/Telemetry/Sensor/INA3221Sensor.h modified: src/mqtt/MQTT.cpp * ifdef for portduino / linux native modified: src/modules/Telemetry/PowerTelemetry.cpp * try #2 modified: src/modules/Modules.cpp modified: src/modules/Telemetry/PowerTelemetry.cpp deleted: variants/xiao_ble/1.0.0/libraries/SPI/SPI.cpp * try #3 modified: src/modules/Modules.cpp * try #4 modified: src/modules/Telemetry/PowerTelemetry.cpp * try #5? modified: src/modules/Telemetry/PowerTelemetry.cpp * try #6 modified: src/modules/Telemetry/PowerTelemetry.cpp --------- Co-authored-by: Ben Meadors <[email protected]>
I haven't read the source code, but I'm wondering if and how does the system works without a gateway, and in that case, how do you intend to do mesh networking ?
The text was updated successfully, but these errors were encountered: