Shouts do not relay. They only go directly to another GTM device that is within range of yours without aid of a relay.
MikeL is correct - shouts do not relay, they simply transmit out from the goTenna unit paired to your Android or iOS device. So if you have your stationary relay node operating in “relay mode”, it will not retransmit any shouts it receives. On the other hand, if you pair your Android or iOS device to your stationary relay node, and remain in Bluetooth range without setting it into “relay mode”, it will be the goTenna that originates your shouts. (But your shouts will not get retransmitted by any other goTenna’s in-range that receive the shout.) Make sense?
In one of MikeL’s latest posts [Here] he mentions his concern about whether the battery capacity in his solar powered relay node will be sufficient to keep the node up and running until the snow and ice clear from his solar panel to restore normal power output to recharge his external battery pack.
It’s a concern I have as well, since I have to deal with snow and ice accumulation during the winter months – and I know that during some periods of severe winter weather, it can take weeks before the temperatures rise sufficiently (and for a long enough duration) for the snow and ice to melt away and clear the solar panel and the dry box that contains the goTenna Mesh relay node.
Early in the linked post, Mike notes, “When the snow first came down, it’s effects were very minor, mostly involving needing to resend a message where it was typical to get a confirmation returned after a several hop connection. Things aren’t so good two days later. Apparently, the melting of the snow compacted it, which had a bigger effect on RF signals getting out consistently.”
Mike’s experience is that once the snow partially melts and refreezes, the operational effectiveness of the relay node is compromised – or fully defeated – because the layer of dense snow pack and ice hampers the radio signal.
So the rest of this post contemplates options to consider that will help stationary relay node owners keep their nodes powered and operational under winter conditions, while avoiding the need to visit the setup to restore power or operational performance.
Keep the dry box containing the goTenna Mesh elevated off the surface where snowfall will accumulate. Do the same for the solar panel too. If the historical extreme for snow accumulation in your area is 4 feet, then make sure you mount the solar panel and the dry box containing the goTenna Mesh at least 4 feet above the surface of the roof or platform. This is necessary to keep them from getting buried in snow pack. Make sure you consider the worst-case extreme total accumulation from multiple consecutive snowstorms in your area.
Install a small angled wooden “roof” over your goTenna Mesh’s dry box. If you’re mounting your setup to a pole that’s on top of your building’s roof, put the angled wooden goTenna “roof” highest on the pole, with the goTenna’s dry box underneath. Below that, mount the external battery’s dry box (assuming it’s separate), and underneath the battery dry box, mount the solar panel.
Make sure you mount the solar panel at a steep enough angle to facilitate rapid clearing of snow and ice when temperatures get above freezing. As noted in a previous post in this topic, mounting the solar panel at a tilt angle of 70 degrees up from horizontal is optimal for power output in New York City during December when the periods of daylight are the shortest. This mount angle will also nicely facilitate rapid clearing of ice and snow from the panel when temperatures rise above freezing.
Install a higher capacity external battery to keep the relay node powered longer - ideally until the solar panel is operating at full power output again.
Use a larger solar panel with higher output power. Even when not operating at full output power, it will sustain power to the relay node longer than if you choose the bare minimum panel wattage needed in good weather conditions.
These are all options to consider. They involve classic design tradeoffs between cost, setup complexity, and system reliability. Some people have tighter financial constraints than others, and will decide that they are willing to trade away higher system reliability to have lower setup complexity and lower cost, even if it means they’ll need to perform more work to maintain the uptime of their stationary relay nodes. Each stationary relay node owner will have to make a personal decision on the optimal compromise of complexity, cost, reliability, and maintenance obligations. I’ll leave you with the following questions to contemplate as you seek to make the optimal decision for yourself:
a) What’s my primary purpose for setting up stationary relay node(s)? (Experimentation? Expanding the local mesh presence for everyday use under routine circumstances? Establishing an off-grid emergency communication system for disaster preparedness?)
b) Depending on my answer to a), what is my tolerance for dealing with lower reliability and/or system outages of my stationary relay node(s)? Can I live with periods of lower reliability, or will it be inconsistent with my primary purpose for establishing the stationary relay node(s)?
c) If I have decided that I want to maximize uptime but minimize setup cost and complexity, how do I feel about tending to my stationary relay node(s) if they experience reduced operational performance or lose power due to severe winter weather? Are they placed in locations that are safe for me to access when there is ice and/or snow present?
d) How much can I afford to spend to set up my stationary relay node(s)?
When you answer these questions, you’ll have a clearer concept of the tradeoffs that are optimal for you.
That’s a great summary of issues in snow country. Depending on where you’re at, this may be less of a factor with climate change, but keep in mind that one result of that is a greater intensity of precipitation. If you’re in snow country, it might even get deeper than is now typical in many places. Here in the Midwest, the trend has been toward higher temps through winter, so I am hoping that this winter’s experience is unlikely to be repeated in the future.
It’s also important to keep in mind that gloom can be almost as bad an enemy as snow. Between November and February, overcast days often far outnumber sunny ones. I tend to have a chuckle over people getting their calculators out to see just how small a panel they can get away with. That works fine in the summer, but estimating what is needed to get through winter is much trickier, when panel output is most likely a small fraction of what is available on a bright sunny day. Best to go big as seems reasonable, as you’'ll need it all on the darkest days of the year.
The pole mount idea is one that makes a lot of sense, but also requires more material, a more complex set-up, more potential points of failure, and is less likely to be found visually acceptable by node hosts. In fact, that’s what I have here at home, because one more antenna at my place won’t stick out…
In this pic, it’s the small box on the mast in the middle, before solar power was added. Looking the other direction…
For long periods of snow blockage of solar panels, only a really large battery will work for weeks at a time. Seems economically unfeasible for most installs, but if it’s where comms are needed it is possible.
This makes me wonder about whether panel heaters are available? How would they be controlled, etc? There’s some possibilities there, but seem costly and would require their own dedicated batteries.
You got that right. Lots of us want this.
I don’t get it. Why doesn’t someone just change the firmware to do this? I’d do it like this:
- On mode change to relay, push some bits into EEPROM storage that says “we are in relay”. (And on going back into non-relay, push bits in that say “we aren’t in relay,”)
- When you power up initially from battery power loss, read the location above to determine if we should go straight into relay.
This is really straightforward. Simple enough that it likely can just be tacked onto the existing firmware. (Don’t get me wrong, this is “really really hard” without the source, but not impossible. It’s just ARMv7 opcodes. Especially if it’s a feature that nearly everyone wants and for some reason goTenna doesn’t provide or doesn’t know how to provide.)