In Part 1 of this two part series I laid out the case that low-band HF communications fills a critical EMCOMM shortfall that exists in most local EMAs. It's a largely unacknowledged requirement but one, I'm sure, that will become blindingly obvious to every EMA director faced with a Hurricane Maria-level communications outage.
I believe it's important that ARES groups prepare to fill this requirement and build HF comms expertise - make it an organic part of their services delivery package.
But what to deliver? It's not enough to just show up at the EOC with an HF radio and a bundle of wire and exclaim "I'm with ARES and I'm here to help!" In fact, that's the worst thing you can do. Instead we have to deliver a communications service, one that demonstrates the ability to seamlessly and effectively communicate with adjacent, higher and lower EMA organizations. The EMA director won't care that this service is based on HF, on NVIS, uses Winlink or JS8CALL. All he or she will care about is that the service works, is responsive, fills a real-world need and is professionally managed by skilled ARES personnel.
What kind of traffic will an EMA need to have moved? Most of it will likely be ICS formatted messages and free text communications between agencies. Winlink excels at this task. It has ICS message tools built into the desktop application and can transition seamlessly between transmission modes; internet-based (telnet), VHF/UHF packet-based, and HF based. This means Winlink in the hands of a skilled, experienced and properly equipped ARES member can effectively work under a wide variety of changing EMCOMM conditions. If the internet is up, use Telnet. If the internet is down (or over-burdened), switch to VHF or UHF to hit a local Winlink node. If there's no local VHF/UHF nodes switch to HF to hit a node outside of the impacted area. If nodes are unreachable try peer-to-peer to a station that can reach a Winlink node. Because of this incredible flexibility and robustness, Winlink-based communications should be the foundational service that ARES groups offer to their EMAs.
If Winlink has a shortcoming it's the system's node-to-node, or one-to-one architecture. It's one Winlink operator connecting to one Winlink node to pass traffic to a specific set of email addresses. But what if traffic needs to be sent to, or received from, an agency that for some reason doesn't have email capability? In a Hurricane Maria-like scenario this is not an inconceivable situation. This is where we need an ICS-compliant one-to-many or many-to-one capability. In this situation a soundcard-based digital application like Fldigi running either PSK-31 or the faster PSK-125 mode is called for. Actually, the software is less important than the ability to operate in the PSK mode and pass ICS traffic, and there are several software packages that could be used. However, Fldigi is the ideal candidate because it's robust, has built-in ICS message functionality, has become an unofficial ARES standard so there's a large pool of embedded experience in the ARES community, runs well on a variety of platforms (Linux, Raspbian, Windows XP/7/10), and it's free.
In this we see the development of what I term the 'layer cake' concept of EMCOMM support. Think of this paradigm:
Note the bottom layer in the software stack - coordination & last option comms. Winlink and Fldigi are very good at what they do, but there are weaknesses in both of these platforms that were revealed during Hurricane Maria. First, neither of these modes do particularly well in poor band conditions. Winlink performance can be improved using tools such as a Pactor 3/4 hardware modem or the VARA software modem, but we simply can't expect average ARES members to bear the cost of additional hardware or software. Second, neither of these operate particularly well in crowded band conditions. Third, PSK-31 and PSK-125 offer no forward error correction and only limited error detection, meaning Fldigi often delivers as much garbled text as it delivers clear copy.
This bottom of the software layer stack is reserved for an application that can serve as a dedicated ARES coordination channel and as a last-ditch weak signal communications tool. When all else fails, what can the ARES operator fall back on to get basic, short and unformatted emergency traffic out?
Today, the best option to fill that bottom layer role seems to be JS8CALL. JS8CALL is currently under evaluation by our local ARES group, but so far its performance is impressive. Its weak signal capabilities are very robust, successfully decoding message strings that are heard at SNR levels well below -18 dB (that's way more noise than signal). Yes, the JS8 mode is slow - we'll never be able to pass ICS formatted message traffic using JS8CALL. But... slow-go is better than no-go.
I'll be doing a blog post specifically on JS8CALL in the near future, but let me list a few of the other key JS8CALL capabilities that I feel make it the ideal candidate to fill that bottom software layer:
- the ability to establish call groups (ex: @GAARES), which greatly eases the job of sending traffic to multiple recipients (one-to-many relationship) and to help establish a mission-specific network topology
- the ability to direct third party stations to either directly forward message traffic to the intended recipient, or to store the traffic for later retrieval by the recipient station
- robust checksum-based error detection - no garbage
- auto-acknowledgement of received messages
- JS8CALL is professionally developed - it's robust and stable and the learning curve is relatively flat
- it runs on a wide variety of platforms - Windows, Linux, Raspbian, OSx
- it's free
So if we accept JS8CALL as that bottom level of the software stack the 'layer cake' looks like this:
So what? Just why, and how, is this 'layer cake' important? Remember, we're selling a capability to EMA directors and personnel that they don't even realize they need. It's important to focus on requirements and show that we can meet those requirements with an easily understood support concept. Nothing pie-in-the-sky, nothing that requires new technology or infrastructure, and one that is as close to zero cost to the served agency and ARES members as you can get. By focusing on just the elements in this 'layer cake', ARES groups can build effective training and exercise scenarios that emphasize skills development and quickly build organizational expertise.
There's more to this discussion that will be covered in future blog posts. For example, what should the hardware layer look like? Here's a cue for the upcoming post on that topic - you can't run any of these modes simultaneously on the same radio/computer/antenna setup. We'll talk about ideas for addressing that later. But for now I'd love to have your feedback! You can comment directly to this post, or contact me at email@example.com.
Hi Brian, W8BYH,ReplyDelete
This is Mike (AB6EW) from Yuba City, Northern California. I like your post and completely agree about what an Operator could bring to the table especially to the EMA director.
My question to you if you could "Afford" that just one piece of HF Radio, which one would suggest even light of current and Bad Solar Sunspot cycle that we're in, a HF QRP Yaesu FT-818ND or Yaesu FT-891?
I like the Yaesu FT-818ND due to the fact on how small it is and very light weight and easy to transport.
The current Solar Sunspot does scare me to pull the trigger for the HF QRP Radio, but at the same time to have a HF QRO Radio seems to be a bit heavy to carry in a Bug Out situation.
What are thoughts on this?
Mike, thanks for your input. In my perfect world the EMAs would fund the equipment purchases, or we'd go after a state or federal grant for the money. Looking at what we've got in-place for comms protocols in Georgia and looking at what's available on the market today I'd likely recommend the Icom IC-7100. It's very good on HF digital modes plus it offers the UHF/VHF side with DSTAR, which is an adopted standard with ARES here in Georgia.Delete