Hi B,
As an experiment, could a string of repeater nodes, between A and B, that are already set to a particular frequency, could be switched on a a particular time, just to pass a message between them. Would this work? (I know others may be on that frequency etc)
C.
Well they dont need to specifically ‘synchronize’ being switched on. They just need to be turned on (ie so they are ‘listening’)
If a repeater hears the message, it will then rebroadcast it, which allows the it to be received by the next in the chain. And ‘hop’ down the chain/string, until hopefully reaches the other end.
One of the points about meshtestic, is it has ‘predefined’ frequencies (within each region), and Lora ‘presets’ to make it much easier to establish communication with other nodes. So users with no prior contact, have a good chance of using the same settings.
Once a lora chipset has been set to specific settings, it will ignore other signals/ messages on the same frequency (because it can’t decode them)
Hi B,
My understanding is that there are hop limits with meshtastic, what I’m suggesting is for longer distances. Does what your suggesting send messages long distances? (I don’t mean mountain to mountain distances)
Why I suggest all route nodes are switched on at the same time, or at least synchonised by time, is so the others aren’t listening.
C
The point to point record is several hundred miles.
So your in Glasgow and want to send a message to someone in London, its 550km.
How would all the (many) nodes on the route know;
That a message was about to be sent ?
Which nodes are on the route ?
Exactly when to turn on ?
Remember that the turn on times would need to vary, be staggered, down the route because of the air time of the packets.
What you suggesting sounds like your trying to replicate IP type network routing and discovery protocols, but on an extremely low bandwidth network using very simple microcontrollers with limited storage.
Hi S,
Firstly I don’t think the existing meshtastic system will take off in a big way, because of it’s limitations, including crowding, so I am exploring a different system that may be an upward step to success.
Yes, I’m trying to replicate system similar to the IP system, which may be impossible with the existing limitations, but as a thought process, let’s carry on, and see what microcontroller size we can get away with, for the simplest system.
A satnav for example uses theis equasion: https://en.wikipedia.org/wiki/Dijkstra’s
In the example is a matrics of dots to join, which I doubt needs a lot of computaion size, as long as it know where the dots are.
If we start as simple as I can follow (I’m not that clever).
Say there a matrix of 144 dots where Glasgow was top left (dot 1) and london was bottom right (dot 144) The system would know the sequence: 1-14-27-40-53-66-79-105-118-131-144.
Allowing for process time 1-14 switch on and send, then 14-27 switch on and send and so on till 131-144.
What would it take for this simple example?
C.
The bit I am strugging most with this this concept of all the nodes needing to ‘turn on’ at sepecific times?
… it implies some sort of ‘overruling entity’ that can control and orchestrate the little nodes.
It would need some way to communicate with all nodes, but if such a comunnication path existed, just use that for the messages, the lora part is redundant.
Also the point about other times ‘not listening’? What does that solve?
Meshtastic certainly could evolve some sort of “Decentralized Routing”. Decentralized Routing
The way Meshtastic is developed, slowly and iteratively, means it could come up a working structure.
Rather than a ‘top down’ developed system, thats great on paper, but falls down in practice.
… ultimately it might end being some sort of two tier system, the original ‘flood fill’ broadcast agorithm for communication within the local mesh. But ‘edge nodes’ could be identified that can communicate with multiple meshes, and perform a bridging function, and so able to be used for long distance routing. Might even be that these ‘routing’ nodes, need to be more powerful processors, than the local nodes. More Raspberry PI scale, than a MCU 
Somewhat analogous, to the concept of ‘home routers’, and carrier grade routers used by ISP for internet routing.
Work it out.
Assume a reasonable number of achievable hops from Glasgow to London.
Work out the air time for an average length packet and add maybe 10mS for the TX\RX switching at each hop, multiply this time by the number of hops.
Hi S,
I’m not good at calculations, but let’s say 1000Km and the average hop distance, may be 1Km if we count some high ones, and room to roof ones, so there may be 1000 hops. I don’t know how long a hop is, but I can see there will be quite a delay.
C
Hi B,
If we use a GPS module only ** for timing (they need 1x satellite for this) and ‘say’ the long route nodes are programmed in. If each node switched on at it’s specific time: ‘say’ node 1= 1st sec, node 2=2nd sec 3= 3rdsec and so on, in this case for a 1000 secs from A to B.
The ‘not listening’ bit, is so that when a message goes by ‘your’ node it is switched off, so doesn’t block the network. If you are expecting a message from east to west, then your long route nodes would switch on at alternate times to the north south ones. These times would be programmed into the sytem.
To me this doesn’t sound great on paper as I’m making it up as I go along, but does seem to be an idea for what would be an overloaded system, for meshtastic as it is, and extends it’s range.
Yes, the ‘routing nodes’ could have more powerful processing than the home nodes. (good idea)
C.
A node that is turned and ‘listening’ does not in anyway ‘block’ or interfere with the mesh. Would be passive.
… its only if it retransmits (or transmits its own message) - that it could potentially interfere. If lots are talking at once, they could interfere, and prevent reception.
Or a message bounces around a small area, decrementing its hop count, without moving any closer to its destination.
So its transmission that needs synchronizing. For long distance connections, would need somewhat ‘strategic’ transmissions, to maximise chance of reaching destination.
The hard bit is identifying the key ‘retransmission’ or router nodes. At the moment, it is still done by manually setting a devices role to ‘router’. In practice it that doesnt always work, because it might not actually make a good router. And/or normal clients might happen to actually be in a better position to retransmit.
but also it might vary from message to message, so would need to be dynamic. So couldnt be ‘programmed in’, partly because as noted, there isn’t a ‘overlord’ to do the programming. But the mesh itself is ever changing, so needs to respond to current situation.
Hi B,
Ok, when switched off this is only for transmissions.
I imagine that if a message ‘bounces around’ then it isn’t being directed, in the way I indicated with the matrix.
I would think the trasnmission direction and synchonising, could be programmed, but this is beyond my level.
As previously mentioned, I thought it a good idea that the ‘router nodes’ would be known and set up with more powerful computing power.
I don’t know about who actually programs and develops the meshtastic system. Do you think they are likely to read this forum?
C
Hi,
Just remembered!
I think my idea of switching off all other nodes apart from the ‘router nodes’ was to let messages go by on the long distance connections.
I’m sure this is difficult, but it may give ideas.
C
Yes we read the forums, the project is 5 years old and has a number of Lora routing experts, in general ideas from TCP are just not that helpful on a flooded Lora mesh, and there is not available bandwidth to do extensive control messages or routing.
1 Like
I suspect the people who understand LoRa, Meshtastic and legal restrictions are not short of ideas.
Hi G and S,
It’s good to know that the developers read these forums, but it’s not good to know, that I’ve wasted my time.
I don’t hink meshtasic will thrive, with the hop limits and crowding, so let’s hope they figure something out.
C.
Meshtastic is growing like a weed, no need for concern.
1 Like
Meshtastic seems to be thriving well enough as it is, for its intended purpose it works well and stays within legal limits.
Just because it might not be possible or practical to turn it into a into a World wide messaging app, does not stop it being used as is.
Hi G and S,
I’m expecting 2x more any time soon, that I intend to use as relays, and some interesting ideas for getting these high enough for low hop distances.
C
Some ideas here;
https://stuartsprojects.github.io/2015/08/01/in-the-footsteps-of-marconi.html
That was written in 2015, the closing para is interesting;
“Using a LoRa tracker\repeater on a foil party balloon (or long distance model plane) has potential for collecting data from widely spaced ground based transmitters where there is no possibility of telephone or Internet based connectivity back to base.”