Have you ever done communications where some aspect of either your equipment, the control/remote connectivity or the actual mode of connectivity depends on anything outside your shack and the other person’s shack?
Did you ever try EchoLink, Fusion, D-Star or any similar modes?
Did you ever VPN, RemoteHam or SmartLink to a remote station?
Does any of your gear or methods require precision time references from outside your shack?
REPOST from Oct. 28th, 2011
—
What is the Radio Amateur’s responsibility for Personal Emergency Communication Preparedness?
Yeah, let’s get that answered and out of the way.
In absolutes their responsibility is “none” – zero, nada, zilch – none.
Personal Emergency Communications Preparedness, even for those of us who are ARRL members, is not a requirement.
[ Wipe Brow and Sigh here ]
REPOST from Nov 28th 2011
—-
I’ve been asked why I limit my Emergency Communications involvement to little more than Personal Preparedness?
There are a whole raft of reasons:
REPOST from Feb. 2nd, 2009
—
When the chips are down, and full Emcomm is running, how will “we, the people” maintain communications?
Whether Emcomm, Freecomm, or just for personal use, can a radio amateur depend on a remote station when the “chips are down?”
There are some compelling reasons that a remote station would be a useful tool in an emergency. Whether it is to access a station unaffected by a localized emergency event, whether it is to gain a high performance remote station’s capabilities while being relatively mobile, through concepts like minimizing personal risk through DF (direction finding) & retaliation in a confrontational emergency – there are dozens of rationales making access to a remote station a consideration. Personally I find the idea a single operator might be able to access any one of several remote stations compelling.
By definition remoting a station requires the operator to establish a link from their location to the remote station. While there are several types of connections available the contemporary remote station depends largely on internet connectivity to create the “bridge” between the operator and the remote station.
I’d like to talk about this ‘internet bridge’ in general reliability terms.
Robustness, Reliability and Latency are the keywords to define what works best. Most Robust, Most Reliable and Lowest Stable Latency are the goals we need for an effective remote operation.
All current solutions depend on our operator to remote station bridge traversing multiple internet connections.
Often the most Robust, Reliable and Lowest Latency is technically complex and involved.
Largely solutions fall into a couple classes:
Some solutions require the remote station to have a computer interfacing towards the wider internet, others allow station components to interface directly to the internet.
The remote station interface computer can range from a separate PC class machine to a dedicated processor integral in perhaps a router (thinking VPN here folks) or even a board-type computer like a dedicated Raspberry-Pi acting as the interface.
If you visualize this remote station to operator ‘bridge’ from end to end, many components are single, dedicated, unique to that ‘bridge.’ These are often called “single points of failure,” meaning that if they fail the entire system will fail. You can do a lot of research on “single points of failure” and suggest searching on it (you might want to use the “SPOF” shorthand and “single point of failure mitigation” to get a start on analysis/solutions.)
There is another consideration concerning the Robustness of parts of the ‘bridge.’ While we try to build our remote station ‘bridge’ using the most robust components we normally frame the expected reliability under the concept that whole system is only as good as it’s weakest link.
Actually the whole system – that ‘bridge’ – isn’t even as good as the weakest link. Reliability Engineers multiply each uptime percentage with all the other SPOF reliability factors to get an overall system reliability prediction (see Lusser’s Law.) This means we shouldn’t consider a ‘bridge’ 95% reliable that crosses say seven different 95% reliable SPOFs, rather we should consider that ‘bridge’ only roughly 70% reliable (the product of the seven 95% rounded off).
Actually this sort of math is fairly tedious and may only offer a reliability indicator in the end for our purposes, as we seldom have actual measured individual reliability factors. One certainly wouldn’t want to build a reliability prediction based on marketing claims – that is why we intuitively put more stock into the real world experiences we can get information on.
A lot of Emcomm/Freecom station address the know SPOFs that face an emergency station – redundant gear, radios, power, manual paperwork/procedures to replace the automated ones, repair supplies & tools, and maybe even a cached complete redundant station in a different location in case the main station was damaged.
Things quickly get complicated when we remote though. It is a lot harder to say swap in a good antenna switch when lightening damaged our usual switch when we are operating remote. Like it isn’t likely to happen without feet on the ground at the station itself.
Then can we depend on traversing the WWW Internet to complete our ‘bridge?’
The impetuous to write this article has been a rare outage in Microsoft’s Azure, the backend product behind FlexRadio’s SmartLink. SmartLink became unusable for part of day when lightening created a power surge that damaged the cooling in a major Microsoft Azure datacenter. The loss of cooling led to the servers protecting themselves and going offline. While established SmartLink ‘bridges’ appeared unaffected, there was a loss in SmartLink’s brokering new connections. Establishing new remote connections via SmartLink wasn’t possible.
That brief outage led to a lot of thinking about whether a remote station is a good Emcomm/Freecom solution?
In my case I do keep a SoftEther VPN backup in the ready.
That is a Parallel alternative to the brokered SmartLink connection.
Parallel systems improve overall reliability with every completely separate parallel system available.
Mathematically say we have three 95% options we can calculate the overall reliability using the formula
Overall Reliability = 1-(first system’s failure rate x next system’s failure rate….)
That would give us in our example
Overall Reliability = 1-(5% x 5% x 5%) which equals 99.9875% calculated Overall Reliability
(If you think you’d like to get into more on this subject, including guidelines on how to calculate combined series/parallel system reliabilities I can suggest http://reliawiki.org/index.php/RBDs_and_Analytical_System_Reliability for a starting point.)
The math should guide us – if we have truly parallel redundancy we minimize the SPOFs we can control.
The remaining wildcard is how reliable we can consider the WWW Internet in an Emcomm/Freecom situation?
Whether the internet is interrupted by the emergency event or is disrupted separately, can we depend it to allow our proposed Emcomm/Freecom remote operations?
Recently in the amateur radio news the MARS folks have announced they want their people to both have the capabilities to operate and drill without internet connectivity. As a great many MARS stations use a computer, they have asked that this computer be ‘air gapped’ – meaning physically disconnected from the internet.
I’m thinking it would be best practice that any Emcomm/Freecom remote station also have a parallel system to ‘bridge’ between operator and the remote station that is also fully ‘air gapped.’
Otherwise my take is we are just fooling ourselves as the greatest part of the ‘bridge’ is across systems & hardware we neither control or can access. In most cases we may note be able to even figure out exactly what the ‘bridge’ topography actually is.
If that ‘bridge’ topography is altered to bypass damaged components (or for other reasons) it may pick up an unacceptable latency compromising our ability to operate remote.
In a future post I’ll cover ideas on possibilities for an “air gapped bridge.”
73
Steve
K9ZW
Just ordered a new handheld: AnyTone Tech TERMN-8R Dual Band Radio.
The TERMN-8R includes built-in GMRS and MURS modes with 23 GMRS channels and 5 MURS Channels. The TERMN-8R is FCC Certified for Part 90 and Part 95 usage. The TERMN-8R is able to Transmit and Receive fully on Narrowband (12.5kHz).
The TERMN-8R is one of the most flexible radios available, it can receive transmissions on 6 Different Bands. It can receive on UHF (400-520MHz), VHF (136-174MHz), Aircraft AM (108-136MHz), FM Broadcasts (64-108MHz), Short-Wave AM (2.3-30MHz), and AM Broadcasts (520-1710kHz). Plus NOAA
The TERMN-8R has two built-in receivers (full duplex). You can receive two signals at the same time; you can even transmit and scan (or receive) at the same time! The TERMN-8R also allows you to use your radio as a cross band repeater (VHF/UHF or UHF/VHF).
and much more. Arrives to the K9ZW Shack Wednesday.
73
Steve
K9ZW
EDIT March 29th 2015
Got busy and the radio sat unopened. To my disappointment the radio is unusable, having been produced with a faulty antenna socket (lacks the required threads). Very suspect, as how could the raid have passed Quality Control? And how could it have even been tested once assembled?
Anytone Termn-8R missing threads
The radio has gone back for a refund. I cannot afford to depend on gear that hasn’t even had basic QC performed.
73
Steve
K9ZW
