Make mesh networking work nicely for unicast messages about firmware HOT 7 CLOSED

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.

from firmware.

Mesh networking is now basically fixed, but keeping this open for a few enancements should do:

• When doing mesh flooding we should include a random delay before each rebroadcast.
• Implement DSR for unicast messages (currently we are just flooding broadcasts)
• See remaining work items listed in comment at top of Router.cpp

from firmware.

Mesh networking is now basically fixed, but keeping this open for a few enancements should do:

• When doing mesh flooding we should include a random delay before each rebroadcast.
• Implement DSR for unicast messages (currently we are just flooding broadcasts)
• See remaining work items listed in comment at top of Router.cpp

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:

• set channel settings from the app
• send user information to the mesh by flooding
• receive answers from the mesh of other nodes (change our node ID if necessary)
• update our node database of other nodes (of all messages "heard")
• send location update to the mesh (periodically or by request)
• flood all messages to the mesh (in future, flood only messages with not only one recipient?)
• switch to DSR to unicast messages (not yet in use), using the node database information
• if a node is not in our node database, send a DSR route request (not yet in use)
• update our node database per answers (not yet in use)
• continue unicast messages per DSR and our node databases (not yet in use)

from firmware.

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"
https://cdn.shopify.com/s/files/1/0046/7524/0005/files/goTenna_Long-Range_Short-Burst_SECON.pdf?8213

from firmware.

@ohcdh just because I'm scared about patents I don't think I'll read that one ;-)

from firmware.

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

from firmware.

closing issues. this is a question rather than a bug of feature request.

from firmware.