I have scoured the community and if the answer is there I am just not smart enough to decipher the answer, so thank for your patience.
Is this correct?
The GTM only advertises its existence when it has a message to deliver. Be it the originator or one of the nodes in the mesh. The GTMs in general are listening most of the time, or at some short interval, but constantly. I would love to know the exact timing on this if anyone knows. Once a message is delivered, a confirmation is sent out and all the GTMs that have that message in their queue are happy and let it go to the netherworld.
So the GTMs are not advertising at regular intervals to build the mesh, so are they building a most efficient path, self-healing if a node goes down to reroute?
When not transmitting a message from the device they are paired with, the GTM does two things continuously.
It listens for message addressed to it. It relays any messages that haven’t yet reached the maximum increment for forwarding (either 3 hops with the standard firmware of 6 hops if enhanced with goTenna Plus.)
With the upgrade to the 5.0 firmware about six months back came improved message handling efficiency. In our local network, it may take 4 or 5 hops to get a message delivered the first time. That number then typically decreases by one or two hops when the message is answered with a return message. Somehow sensing the most efficient path happens, apparently via assessing the signal strength and number of alternatives paths available.
Thanks Mike. I am familiar with internet routing, and this sounds different. Of course computers do things at a speed level that us mere humans have a hard time relating too. I am sure we are talking nano seconds for all the comms going on.
I guess you could call it “RF routing.” The goTenna engineers may have a better name for it.
Interestingly, it can take a few seconds for messages to be relayed , so there is some latency going on here. I know the limit to accessing the mesh is set at 5/minute and the the GTM genenerally sends a message twice (but maybe the second time isn’t initiated if a response comes back on the first send?)
Depending on how many nodes a message is relayed through, it may take close to a minute for Confirmation to be returned. If it isn’t then the notification of possible lack of confirmation may take a little longer. At least that’s how thing work on our mesh. Be patient with it.
Another consideration is movement. We tend to have lower confirmation rates when moving here, but our mesh is pretty thin. Increased node density should help with this. I don’t run anymore , so can’t offer any insights to speak directly to your potential needs or findings.
I believe you are correct @MikeL. If the GTM on the initial message send gets a response directly from the recipient the message life cycle is over. If no response is received on the first message send then the 2nd message sent is an open to all GTMs to attempt to forward and relay the message to the recipient.