Make mesh networking work nicely for unicast messages

[X-Ryl669]

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 ?

[geeksville]

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.

[geeksville]

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

[cyclomies]

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)

[ohcdh]

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

[geeksville]

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

[geeksville]

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

[mc-hamster]

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