Hi,
I’ve been racking my brain on how Meshtastic could be used for long distances!
Much of this is guesswork when it comes to the workings of Meshtastic, but it would be good to air them here anyway.
If a net of nodes was in existence around the country (I’m in uk) all within a node to node range, so all the dots could be connected/routed, and each of these has a known location.
Say a node in the north wanted to connect to a node in the south many miles away. A route could be made, in the same way as a satnav.
If each pair of connecting nodes TXed and RXed on the same frequency at a precise time, and so on till the message reached it’s farthest node would this kind of thing work.
Each node could be synchronised to it’s neighbour by the accurate timing of it’s GPS module.
I’m sure there are lots of things to consider, and I’d be interested to hear what others have to say.
C
Some nodes could end up handling a great deal of traffic, and with medium to long range settings in use, there could be significant breaches of legal duty cycle limits.
In theory nodes are always ‘listening’ (as long as not currently transmitting!) - so they when one node transmits a packet, all surrounding nodes can receive it. And most of the time, will be rebroadcast. So ‘hops’ around the network.
… but in practice, real meshes are somewhat messy, as often messages can’t fully treverse a mesh. Gets lost in loops, or drowned out before gets very far.
So ‘building’ a route alone a linear line is quite trickly, although possible.
Did also built this:
which attempts to simulate (a somewhat idealized) senario.
Its not very easy to see this routing in the App, but in general can see it happening, most recent apps, include a ‘Hops’ metric that show how many hopes are used to connect to a remote node.
Hi S,
I suppose there would be bottle necks, so I assume it depends on how much this gets adopted, but if it catches on there would be more nodes that could divert round bottle necks.
C
HI B,
As it is there is a limit to the hops, so ot so distant.
I’m suggesting that there’s not always listening, and only listen at set times, so long links can be made. This would mean that for an A to B message surrouinding nodes wouldn’t be listening at that time. (Note I’m not that clever to have thought it fully through, so this is an idea)
I’m glad you’re experimenting, it is an interesting subject, which I’m sure wouln’t make paid phone services happy, if it ever succeeds.
C
If a route between A and B was calculated at the start
I don’t think ‘listening’ at set times would particularly help, wouldn’t be able to synchronize that. As the nodes are decentralized anyway, would be hard.
But they definitely COULD be more ‘intelligent’ routing through the mesh, to encourage more successful long distance links.
For example, only a node (ideally a router in a prominent location) will rebroadcast a message when it ‘knows’ it part of the route between sender and receiver.
Keep down the noise, but more selective rebroadcasts, so there aren’t lots of nodes ‘talking over each other’. Nodes that not needed for routing would be silent.
But how would simple Meshtastic nodes know that the ‘route’ they had planned was a bottle neck, as in that the intended destination node had not received a message and a new alternative route was needed ?
Hi B,
I’m not talking about how Meshatastic is set up at the moment, but an alternative system.
E,G, If there was a previously set up route from ‘say’ a large city in the south to a large city in the north, all switching on at the same precise time, all set to the same frequency, these should pass a message from north to south. (I fully understand, that this is glybly suggested, and difficult to carry out, and I repeat, it’s only an idea)
C.
Hi G,
I don’t understand your sentence, I’m using Meshtastic.
I also don’t understand how the whole system works, but if I’m correct, LORA is the radio frequency hopping technology, but I’m thinking about the module control.
A LoRa device needs to receive a packet in full before it can re-transmit it. Thus the air time of the packet, which could be 500mS or more gets added to each hop.
So with a lot of hops the network could be out of action for quite a while whilst one message is routed over the many hops.
What if when you wanted to send a message the system did a traceroute first and then only the nodes in the path would rebroadcast the message?
No traceroute = no send…
Could that cut down traffic? Cheers
Hi G,
It was my quick way of saying:
CSS (Chirp Spread Spectrum) is a technique used for transmitting digital data over a wide range of frequencies. It is a form of spread spectrum modulation that involves the use of a modulated signal called a chirp. In this article, we will explain CSS in detail, including its history, working principle, advantages, and applications.
C.
Hi S,
Firstly, thanks for a constructive question.
What you suggest is the kind of thing, I’m talking about, so other nodes nearby would be out of action, while the message went past…
I think it would cut down the traffic.
C
system did a traceroute first … Could that cut down traffic?
In concept yes.
In practice, well the traceroute itself uses traffic, it can be pretty inefficient. Would need effectively ‘flood broadcasts’ to find the node.
But suspect the biggest issue, the mesh is going to be always influx, many ‘links’ are not reliable, even if they work most of the time. A contrived example could a passing van is needed to be the exact right location to reflect the signal, or trees blowing in he wind.
… but also many nodes are mobile, and move around, not usable for long term links.
A a traceroute, that works now, not might not even seconds/minutes later.
Plus the kinda irony that the traceroute would need to be able to reach end to end anyway, so the ‘flood’ algorithm needs to ‘work’ before you could use ‘tunneled’ routing.
Finally in real meshes, many messages are ‘broadcast’ anyway, not addessed to a specific receiver.
