Okay, so from my understanding the limit on 6 “hops” is a firmware problem, in that it becomes unstable going much further due to congestion and the way in which the network decides how to route messages from one device to another to reach a final destination. So, would it be frowned upon to utilize a separate device to relay messages from one GTM to another GTM to bridge from one max set of 6 hops to another set of 6 hops, thus enabling a hypothetical 12 (or 11 I suppose since 2 units are basically 1 unit in the setup)? Obviously in order to use this with the built in messaging system rather than a custom application that merely uses the same network to relay messages, we’d need to direct messages to the bridge device so that that receives it, rather than the linked receiving GTM just trying to relay it along, so basically I’m proposing (early concept)…
Android device, 2 GTMs. 2 instances of the app. 2 remote users out of range of each other. In range with the bridge.
User A sends messages formatted something like “TARGET:USER_B\Hello from afar!” With BRIDGE as the recipient. Upon receipt, BRIDGE reads, parses the message, and sends a new message “ORIGIN:USER_A\Hello from afar!” With User B as the recipient. User B gets the message “Hello from afar!” from User A in the custom interface.
Personally, I think it’s a great idea. In order to circumvent the instability issues, and to extend relay range, only potential issue is the fact that bridge units would be able to see anything that passes through them and potentially alter it. However I’m not entirely convinced that it’s impossible for any existing relay in a chain to see the contents of a message. I’m not familiar with what sort of encryption the system uses though. Anyone have knowledge of that?
Anyone with objections to my idea or other thoughts or anything? My android device relay is just a first idea because I think it would be easiest to implement, long term a setup would probably be better suited with a traditional desktop Linux or (maybe) Windows setup.
Combined with directional antennas, this could be useful.
On the other hand, the real answer to taking too many hops and lacking the “reach” needed to get to someone on the other side of of a growing mesh is one simple but often hard to acquire - height.
Most of our nodes here, for instance, also are “down in the weeds” during the warm months because of leaf growth. So things imrpove in the fall through early to spring period.
The biggest game changer is getting a spot on a tower or building that is up above all the clutter. You can cover the distance in one hop what might have taken 3, 4, or 5 down close to the earth. It’s just as or more effective than other solutions and is almost always the first, best alternative to more complex solutions.
I don’t say that to discourage your approach, but to help you keep perspective about the amount of time and energy you might consider investing in it vs other potential solutions. In some case it difficult or impossible to gain height and that’s where the alternative solution come in handiest.
I have considered this points before, but my hypothetical idea here I think would be more suitable for repetition. Basically I’m looking for a solution that would allow relaying across vast distances, across the country perhaps one day. Obviously that would require significant infrastructure in place and would also benefit from well placed transmitters, but no amount of range from one unit would go far enough without significant modification, so…
Basically I’m looking for the solution that’s more plug and play, if I get time over the next few weeks I’d like to see if I can do up a proof of concept setup, what I want is something that allows anyone with no experience to get a device, pair it wirelessly (wired perhaps, but that requires certain host devices with appropriate ports) with two GTMs, install the application, run it, and forget it. Eventually my thought was a semi-centralized list of bridges stored online that could be added manually or retrieved automatically by the bridge device and messages could potentially be related indefinitely by being directed across the appropriate bridges to get to their destination. This would require that users who want to receive a message outside of standard range would need to share not just their GoTenna ID (or phone number), but also an in-range bridge ID.
Again it’s just an idea right now, but I totally think it’s doable with little to no hardware modification, which means it can be distributed with just software and “off the shelf” devices. The end goal being to enable consumer-level communication across vast distances without the requirement of centrally managed networks (the internet).
Ah, I see what you are at. That would be useful, but lots of problems to solve to make it work. It’s the barebones of a solution from the sounds of it, though.