top | item 46642997

(no title)

gh02t | 1 month ago

Meshtastic also struggles with high density and high traffic networks. Some modifications can be made to work better, but with the default settings it really grinds to a halt, and modifying the settings to be better suited requires some expertise and foresight. It works amazingly in off grid, relatively sparse networks, but it's got some major limitations.

discuss

order

wolvoleo|1 month ago

Yeah I always wonder with these mobile ever changing mesh networks: how do they prevent messages from aimlessly looping around the network? With all the mobile devices they're too dynamic to make routing tables and broadcasting everything leads to network saturation really quickly. You could give them a very short TTL but then the reliability will suffer a lot.

linsomniac|1 month ago

Meshtastic has a TTL of up to 7 and (from what I've been able to understand) uses flood routing largely. In Northern Colorado (where I'm at) we don't have a particularly dense mesh, but are turning down from 7 because of congestion.

Meshcore seems to (I'm still learning on this) use a TTL of 64 and flood to find a route to a destination, then uses source routing for future packets, reverting to flooding again if that path fails (say a mobile repeater moves out of range).

zoobab|1 month ago

You need 2 kind of networks: one stable with fixed nodes, with very low refresh rates of the routes, and another one for mobile nodes.

NoiseBert69|1 month ago

The decision that every station is always a (delayed) router was a bad one. Also the old firmware was super chatty eating a lot of valuable ISM TX time.

They must clean up their role mess and switch to a "all clients are totally quiet - until they are set to a different mode for a reason"-strategy.

gh02t|1 month ago

Eh, Meshtastic was originally for sparse off grid comms less than big public networks. In that role (which is still what I mostly use Meshtastic for) every client repeating messages makes more sense.