Hi, new user here with a couple of GTMs, primarily for post-emergency communications in New Zealand.
I’d like to request an easier way of testing connectivity, rather than having two units each hooked up to a phone and driving around the neighbourhood sending text messages. Firstly because it’s a lot of effort, and secondly because it doesn’t test the presence or extent of the wider mesh outside of my two units talking to each other.
Could there be some way that we can ping from the app, and that ping goes as far as it can and we get a report of which nodes and relays it managed to reach (without requiring another users intervention like a shout)? Having node IDs in the report would be ideal so that we can check if we’re reaching specific nodes that we might have setup, but at the very least just a report of how many units were reached at each hop level would be awesome. For example you might get a report that says:
Hop 1: 1 relay, 0 active nodes
Hop 2: 2 relays, 5 active nodes
Hop 3: 6 relays, 23 active nodes
This would be particularly useful where I am, as there’s not many GTMs shown on the nodemap in my area, so I have no way of knowing whether these things are actually going to be any use at all. But if I could just send out a ping and know that I’m consistently reaching at least a couple of other nodes or relays then I can be confident that if/when I need to use these in an emergency then there’s going to be a mesh in place.
I understand that pings like this will add traffic to the system, but there’s got to be ways to mitigate this - ie only allow one ping an hour for example.
An even better solution would be for the units to map out their network themselves. If they sent their own pings on set intervals then you could just connect to your own node and get a report of how many other nodes it has been in touch with in the last x number of hours/days.
Any thoughts on this would be appreciated!
Welcome to the Mesh Community!
This is an interesting request and could be useful. It would save me a lot of driving around, for instance.
There’s several things going on that make implementing it difficult. Which is not to say it can’t be done, at least for units that opt-in to participating. There are apps already out there that supply much of the functionality you seek. However, goTenna has been pretty consistent that users have to consent to providing info by opting in to data requests. I suspect it’s a hard sell to get to where every GTM in range is automatically mappable. A simple count of nodes in range might be possible.
I would also suggest that the node map seriously undercounts the number of GTMs out there. A comparison of total production (somewhere above 100,000 currently) with the nodes self-reported on the map (~12,500 currently) suggests only about 1 out of 9 has been marked up by their owners. To me this indicates a great deal of caution with regard to privacy among GTM owners, something which goTenna has to take into consideration. It’s a certain leap of faith that others are out there, I know, and not like the assurance you’re seeking with this functionality, but consider that you probably have more company than is immediately apparent from the map.
Another consideration is that a GTM is always relaying. Even paired units do this when not being used by the paired phone. Not sure if it would be possible to differentiate between pings from nodes in use that way vs in use as fixed relay nodes. I’m not sure whether you were aiming for that differentiation in uses, but it exists.
Finally, any such feature would need to work within the limited bandwidth available in the mesh.
So, possible, maybe, but probable would mean surmounting these issues.
Hi Mike, thanks for the detailed reply.
You mentioned other apps, could you please elaborate on that?
The privacy issues are a fair point, and I can understand why people might not want their node ID being transmitted. But yeah a simple count of nodes in range would be extremely useful, with or without the second or third hop node count.
As for the differentiation between relays and active nodes, perhaps I used the wrong terms, but what I’m interested in is knowing whether I’m seeing nodes which have been setup as relays which would suggest that they’re likely to be always on, and nodes that are in normal mode so they’re perhaps less reliable as they’re moving around etc.
I agree the node map is under-reported. There’s only 37 units mapped in NZ, so I’d be interested to hear how many have been shipped to NZ for comparison?
Overall I was hoping that the mesh aspect of these units would be slightly more ‘active’ for want of a better word. At the moment it just seems like we’re turning them on and shouting into the void, hoping for an elusive echo. Whereas with some seemingly simple software tweaks we could get a much richer picture of how the mesh is developing around us. Obviously in certain parts of the USA they’ve already got past the critical mass of nodes where this isn’t necessary, but in the developing markets (where the growth potential is) I’m sure this would be useful.
There have been specific apps developed for use by glider pilots and snowmobilers that integrate goTenna connectivity into what are essentially spatial awareness apps Then there is Mesh Developers Toolkit, which is iOS only and provides a number of features that can include mapping group movement. All of these presume that all users opt in to them in various ways.
A stationary relay is depicted as either a green or gold marker on the node map and is generally stationary. However, so long as it’s powered as always on, it can also be mobile, like the one on top of my Land Cruiser. Nodes that are are intermittently powered on and generally mobile are indicated by blue markers. Keep in mind that they relay also, but because of their mobile nature are generally not as well located for line of sight between nodes as stationary relays are. This status is self-reported like the other info on the node map.
I can’t help you with how many to NZ, but I suspect the ratio between reported vs unlisted is pretty similar. I would speculate this likely represents several hundred in use in NZ, but that’s just a guess.
The question of “Where’s the mesh?” is rather a chicken or egg thing. Remember that we’re just now coming up on the second anniversary of the public release of the GTM. The network development model for decentralized mesh is quite different from the centralized networks like wireless telephone and the internet.
People have to build mesh where they need it, but I’d say it’s really a remarkably simple exercise in terms of the physical part of it. It’s the social aspect of mesh that’s more a leap, because it assumes belief in the need for us all to participate in doing what we can if we’re interested in the really vast possibilities that exist when mesh is available. That also requires belief in how community cooperation can be a powerful force in societies that often pay more attention to individualism. People tend to expect to either pay for something or the government to make sure it happens, depending on one’s overall ideological preferences. Neither really applies well to explain all the motivations useful in building mesh, you have to think bigger than such artificially narrow points of view to appreciate what’s needed, IMO.
I don’t think this reflects so much a choice to put this POV in conflict with preexisting POV so much as it does the organic way mesh grows. Our system here started because I had some specific connectivity problems I needed to solve. Then I got the idea that this is a really great resource that can be shared, so we started UMESH. This doesn’t necessarily make UMESH into a dominant force, despite having a pretty good footprint already. There are others around here with mesh who set things up for their own reasons. The way mesh works though, means no one needs to coordinate they just put up what they need to solve their problem and go on. There are no central servers, configurations, or passwords needed, you just put yours up to suit and as the mesh grows, those who join in may still need to put something up to solve their specific need, but will increasingly find that they can depend on the mesh that others already have up for at least part of their requirements.
I agree with your point that the social aspect of the mesh depends a lot on relying on others, but I guess that’s my point. I’ve bought into the mesh idea but it’s very difficult for me to work out whether a mesh actually exists where I am, because I have to rely on someone seeing and responding to a Shout.
At the very least just a basic ping and a count of the automated responses would be all I’d need to confirm that these are potentially useful and not just a silly impulse buy. I’m surely not the only person in these less-saturated markets that feels this way.
In the absence of an automated solution here are a few tips that will allow you to size up your local situation with regard to the mesh that might already be out there.
First, check the node map to see if anyone else has posted up. If not, consider taking the plunge. If you want people to contact you, you can include your UID in the notes for your entry. Remember that addressing message directly to someone lets them be forwarded through the mesh, while a Shout only goes so far. You can register as either a stationary node (24/7 powered on) or a mobile node (carried on your person, so may not be in the same location 24/7.)
Second, keep your goTenna Mesh on the air by keeping it plugged into the charger or battery pack. Check your app sound/alert settings to make sure you’ll notice if someone is contacting you.
Consider mounting a GTM up high on your dwelling or other primary location to act as a relay. This acts much the same as an amplified antenna will, taking your ground level signal and relaying it at an altitude where it will reach others more easily. This also lets it act more effectively as a relay for others who may be nearby.
Locate local spots where you can post a notice with your UID. Consider making up business cards with your contact info, including the UID, as these are easy to post and hand out.
Evaluate your personal communication needs and build out your own mesh network. If a well-placed node could link you with friends or family, figure out a way to put up the minimum network you know you’ll need if things turn grim.
Test the network you do have by using your GTM to send messages back to your base as you move about to test the real coverage you have available. If there’s unexpected reach in one direction, check the node count of received messages, it may be an undocumented relay.