Computers and Operating Systems - A Reality Check (Part 2)

In Part 1 of this two part series I briefly covered how the current versions of Windows (Windows 10) and a current version of Linux - Raspbian - got to where they are today. Both are good operating systems, and each has something to offer the Amateur Radio community.

But when we look at operating systems from the perspective of what's best for ARES-based EMCOMM work, is there a winner? Are there reasons to pick one over the other?

Yes.

Just what are the ARES-based EMCOMM computer requirements? Keep in mind, this is my list and I take full ownership of it. The focus is not on hardware or software, but on capabilities. What does the computer & operating system need to deliver to make it a useful tool when supporting an emergency management agency like your local EOC?

First, let's set the scenario. For planning purposes we have to assume the worst. Think a Hurricane Maria-type situation. Austere, no Internet, intermittent power. The computer needs to be used not just for ARES EMCOMM tasks but also general purpose tasks like managing email, preparing documents, presentations and analyzing spreadsheet data, etc. The computer will be used by multiple ARES operators over the course of the event, so the interface needs to be easily understood by the average appliance operator (see Part 1).

We can also assume that at some point the computer will be added to a local area network, so the OS and its networking functionality needs to be well understood - and trusted - by the IT support staff. Since the computer will be used by multiple ARES operators the OS needs to be able to support multiple user accounts, and those accounts may need to be managed by an external Active Directory server or similar authentication service. In short, the computer you bring to the disaster needs to 'play well with others'. In addition the computer must:

• natively run Winlink, Fldigi and JS8CALL and any other critical Amateur Radio software (no emulators)
• run a locally installed office automation suite like Microsoft Office, Open Office or Libra Office (remember, no Internet = no Google Docs or Office Online)
• be compatible with the supported agency's computer and network security software
• be supportable by the supported agency's IT staff

ARES EMCOMM support staff needs to fall-in on standardized equipment that has a flat learning curve and minimal support requirements, so they can focus on providing effective support, and not on futzing with a new and different computer equipment and interfaces. Remember, very few ARES members who show up to support a disaster will be computer superstars. Most fit the appliance operator mold - their experience is limited to the desktops or laptops they use at home, and those computers overwhelmingly run... Windows. While it's OK to pray for a never ending supply of superstars, we have to plan for the appliance operators, and the appliance operators run Windows.

What do all these requirements point to? Clearly, Microsoft Windows.

Next, let's talk about hardware. In Part 1 I reviewed the Raspberry Pi - a truly groundbreaking bit of hardware that attracts a huge variety development and integration effort within the Amateur Radio community. There's a lot of effort going on today to try to turn Raspberry Pi's into general use ARES EMCOMM computers. But in this specific use case, as an EMCOMM common computing platform, it falls short. 

While the basic Pi is quite a good little computer, it lacks important features such as a real-time clock, a battery-based power supply, a case, a keyboard, a mouse, and a monitor. Yes, all of these can be easily added - and most users certainly plug in a keyboard, mouse and HDMI monitor to get up and running. But when you start adding in all the necessary components to make a Pi a truly useful general purpose ARES EMCOMM computer, well, you are schlepping around more than you can carry in one hand. Which begs the question - how is this better than a regular laptop? C'mon folks, every laptop built in the last 20 years comes with a real time clock, a battery capable of powering the system for several hours, a full keyboard, a touchpad for cursor control, and a screen. All in one handy, easy to carry package. Again, appliance operator vs. superstar.  Imagine an appliance operator-level ARES member sitting down at a Raspberry Pi for the first time and trying to find the on/off switch (hint - Rapberry Pi's don't have on/off switches).

Score one for the standard laptop configuration. It simply makes more sense. Flattens the learning curve. Gives the operator a form factor they are already familiar with.

So, Windows + Laptop = the ideal ARES EMCOMM common use computing platform. This is what we should be focusing on as we put together equipment support packages for our local EMAs. Forget the exotic gear or the cool maker stuff. Plan against the common denominator, and in this scenario that's the appliance operator. 

Your thoughts?

W8BYH out

Computers and Operating Systems - A Reality Check (Part 1)

I just emerged from one of my regular attacks of what I call 'laptop fever'; the unshakable feeling that somehow, in some way, I'm missing out on something important when it comes to laptop performance, and darn it, I probably need a new machine.

This latest bout of fever was triggered by my recent tests of the JS8CALL application and a desire to find the best computing platform for what I'll call a standardized EMCOMM package. The minimum hardware requirements for this platform are fairly easy to understand:

• Intel i5 processor or equivalent
• 4 gb of system memory
• 128 gb hard drive
• The ability to run WinLink, JS8CALL and Fldigi
• The ability to run an open source office suite like Star Office or Libra Office
• Using USB serial port emulators, the ability to interface with external sound card modems and radio CAT interfaces
• Battery life of at least 4 hours

Nice-to-have features include:

• 8 gb of system memory
• 256 gb solid state hard drive (SSD)
• Rugged water resistant construction
• Easily swappable batteries
• Internal GPS
• LTE broadband
• Backlit keypad

The minimum requirements are fairly easy to meet at around a $350 price point. Heck, just a few minutes of searching on Amazon turned up this first rate candidate:

When we start layering on the nice-to-have features the price quickly shoots up. At this point we are talking about a Panasonic Toughbook-grade computer, and even used from a reputable dealer like ToughRuggedLaptops.com we are looking at a $1,200.00 Panasonic CF-31 class machine. Are even used Toughbooks (or their Dell or GETAC equivalents) worth it? Yes. Are they necessary? No. For 99.5% of the ham radio population the inexpensive Dell Latitude is plenty.

Panasonic Toughbook. Truly tough, rugged and capable. And maybe a little too much...

Should we be discussing other hardware options? There's plenty of alternatives to the classic laptop format out on the market and we'll get to some of them in just a bit. First, we need to take a look at operating systems, with a focus on the two prominent operating systems in Amateur Radio today: Microsoft Windows and Linux.

Amateur Radio has always had what is described as a 'maker' focus (learning through doing). Heck, in the early days of ham radio being a maker was the only way to get on the air - you had to make your own radios, make your own antennas, make your own power supplies, etc. There were no factory made transmitters or receivers. Instead, you had to gather all the parts, put them together, test, adjust, and get on the air, all without electrocuting yourself (a very real hazard in those early days). This maker mentality was still in place when desktop computers hit the scene in the latter half of the 20th century. Amateur Radio operators rushed to find ways to integrate computers and ham radio, and Amateur Radio applications like contact logging, CW practice and packet radio were some of the first non-gaming applications to be developed for early home computers. As Forest Gump would say, Amateur Radio and personal computers "go together like peas and carrots". So, when the Linux operating system was introduced in the early 1990's, the Amateur Radio community showed a lot of interest. Many hams made their living in the Unix computing world, so an open source version of Unix that ran on the x86 processor was a big hit. Linux was and still is the maker's operating system.

Current MS Windows versions go to great lengths to hide the legacy command line window,
but Linux still puts it front-and-center, loud and proud.
Command line expertise is one of the essential skills for Linux partisans!

Mature Linux distributions and Windows 95 hit the market at about the same time (1995). (I bought my first Linux distro, Red Hat, at the University of Texas at Austin bookstore in 1995). Windows 95 was a crash-prone kludge, but it showed where Microsoft was headed with its preemptive multi-tasking operating systems. Amateur Radio operators pretty much ignored Windows 95, got a little more interested in the slightly improved Windows 98, but really sat up and took notice with the release of the 32-bit (and stable) Windows NT and, later, Windows 2000. While not a 'maker' OS, Microsoft Windows swiftly dominated the personal computing market, wiping away whole generations of earlier PC operating systems like CP/M, AmigaOS, OS/2, TOS, OS-9, and even Microsoft's own MS-DOS and PC-DOS. In the end the only viable operating systems left standing besides Windows were Linux and Apple's MacOS (but we're leaving the Mac out of this discussion, sorry).

Microsoft Windows won out in the Amateur Radio world through the sheer force of numbers. More and more application developers recognized that the huge installed base and the standardized user interface of Windows offered its own advantages, and development focus for Amateur Radio shifted heavily to the Windows platform. While many Amateur Radio operators fancy themselves 'makers', in truth, when it comes to computers, most are simply appliance operators. As Windows came to dominate in the market, most hams became comfortable with the Windows concept of 'plug-and-play' and appreciated the standardized user interface that spanned the increasing number of computers they came in contact with with on a daily basis. 

So what's it to be, the maker's OS that hews closely to the spirit of Amateur Radio, or the appliance operator's OS that focuses on ease of use? To answer that we need to think about the focus of this original requirement - EMCOMM - and what's happening in the OS space.

First, the appliance operators. Microsoft Windows is currently at Windows 10. Windows 10 has shown to be fast, stable, feature rich and runs well on a variety of hardware, from low end Intel i3 mobile CPUs to the high end eight core i9 workstation CPUs. In addition, Windows 10 is capable, ubiquitous, well understood by the user community and supports the largest available base of Amateur Radio software. Virtually everybody who develops an Amateur Radio application develops it for the Windows platform first - that's where the customer base is.

Raspberry Pi 4 - small, cheap, capable

Next, the makers. More specifically, the makers and their current love affair with the Raspberry Pi. The Raspberry Pi is a phenomenon unto itself. The Pi was originally designed as an ultra-low cost single board computer targeted at both students and experimenters. How low cost? The baseline Raspberry Pi 4 (the most current version) sells for a whopping $35.00 US! It runs a custom flavor of Linux called Raspbian, and this OS brings some incredible capabilities to such a low-end platform, to include a Windows-like desktop experience and a huge library of Amateur Radio-related apps. In fact, two key EMCOMM apps - Fldigi and JS8CALL - run natively, and well, on Raspbian. The adoption of the Pi brought a certain standardization to the Linux experience for the Amateur Radio community. Before the Pi there was a lot of Linux in use within the community, but it was various Linux distributions loaded on a wide variety of hardware, so the user experience varied from computer-to-computer. The Pi has brought a little bit of order out of chaos.

So back to the question - Linux (on the Pi) or Windows? What's the best solution for EMCOMM? 

We'll tackle that in Part 2, so stand by!

W8BYH out (for now)

OK, I Get It

I'm testing a new radio for portable EMCOMM work. This is a radio I've considered for years, and has a feature set that looks pretty impressive on paper, but the form factor always put me off. But a recent interest in finding a single radio that would serve as an excellent candidate for ARES, EMCOMM & MARS use in Georgia caused me to finally overlook my aversion to the form factor and give it a try.

The Icom IC-7100

I had been using the Yaesu FT-891 as a portable station, but it's shortcomings continued to grate on me. So much so that recently I had switched back to using the much larger Icom 7200 for portable work. It was a bit heavier to schlep to the field, but overall its performance was much better. 

What killed the FT-891 for me is that a few months back a small group of local hams went to a park for a few hours of playing radio and swapping lies. A good friend brought his FT-891 to operate. The phase noise from the FT-891 was so bad that it effectively drove all other radios off the air. That was it. My (second) FT-891 had to go.

At the same time I was doing some evaluation of JS8CALL for our local ARES group, and working on an implementation proposal for HF communications support for Emergency Management Agencies (EMA) in Georgia. Part of this effort was identifying a radio that came closest to meeting the HF and VHF/UHF EMCOMM needs in a single, easy to use and easy to support package. The requirements for this idealized radio included:

• A built-in sound card for HF digital modes - and ease of setup for digital modes
• Built-in antenna tuner
• DSTAR capability on VHF FM - DSTAR is an adopted communication standard with Georgia ARES, so DSTAR capability is important
• Ease of programming, with the possibility of programming 'over the air' or via the internet
• Full 100 watts on HF, 50 watts on VHF
• Overall ease of use - something a minimally trained ARES operator could fall in on and get up and running with little assistance
• Good build quality and reliability
• Ease of modification for MARS use

What I was really after was a 'shack-in-the-box', a single radio that can do it all. Initially I looked at the Yaesu FT-991A. I own this radio and really like it. It performs without most of the drama that came with the FT-891, but still has some shortcomings. Particularly the almost maddening firmware menu complexity which makes it difficult to configure for digital modes. Once it's all set up it's a digital mode champ, but don't you DARE adjust any one of the dozen or so settings that can impact digital operations or you'll screw everything up. It's as big a drama queen in this as the FT-891 (they share the same menu structure).

The FT-991A had two other shortcomings that are not really the fault of the radio, just a reflection of external issues that make it less than ideal. First, it lacks DSTAR capability. Yaesu is wedded to C4FM (System Fusion), a competing VHF/UHF digital mode. Nothing wrong with C4FM, it's just that DSTAR is the VHF digital mode standard in Georgia ARES. Next, Yaesu radios don't work well with the MARS digital software modem package, MS-DMT. Again, this is not the fault of the FT-991A. The developer of MS-DMT hasn't built any of the digital feature settings for the FT-991A into the configuration library for MS-DMT. This makes it very difficult to get any current production Yaesu HF radio working with MS-DMT.

So this left me searching for another 'shack-in-the-box' option, and it needed to be a radio that's in current production. The search immediately narrowed down to one option - the Icom IC-7100.

As I mentioned earlier, I've looked at the IC-7100 on-and-off over the years for my own personal use, but I was always put off by the form factor. I'm not alone in this - just read the reviews on eHam or QRZ.com. Folks just don't 'get' the odd control head configuration. It's so... well, it's just odd for a radio marketed as a mobile rig.

I'm sorry, it just reminds me of the old Radio Shack TRS-80 Model III desktop computer 😄:

But in this evaluation we're focusing on function, not form, and the TRS-80 IC-7100 hits most of the performance objectives I outlined above. 

A few weeks ago, through QRZ.com, I was lucky enough to find an Amateur Radio operator in Michigan who had an IC-7100 that he was willing to trade for my Yaesu FT-891. I've been evaluating the IC-7100 pretty heavily since I got it, and I have to say that now... I 'get it'. The control head is actually very well thought out, and perhaps the best (or only) way to incorporate both a large touch screen and traditional settings buttons in a single interface. The 'odd' control head is a winner. The only shortcoming is the relatively low screen resolution. The low resolution works against the otherwise excellent interface. 

The IC-7100 meets all of the evaluation criteria with the exception of a built-in tuner. Some may be surprised to hear me state that of all the criteria I could live without, a built-in tuner is at the top of the list. Most built-in tuners can only match 'almost resonant' antennas - they have at best a 4:1 impedance matching capability. In EMCOMM you may need to have to try to match anything from a busted CB antenna to a few hundred feet of chain link fence just to get a signal out. An internal tuner will be useless for this task, so you'll need a more robust external tuner anyway. Let me use my IC-7300 as an example. I run that radio with an end-fed wire antenna that is 'almost resonant' on the HF ham bands. But I also use the same setup for MARS, which operates well outside of the Amateur Radio frequency ranges, and the end fed wire has no close natural resonance on those frequencies. This forces me to bypass the 7300's internal tuner and use an external 200 watt tuner so I can safely run digital modes at 100 watts (a tuner's digital mode capability is usually half or less than its rated SSB capability, due to the more demanding full duty cycle of the digital modes). 

Icom has also slipped in a few additional 'parlor tricks' that add greatly to the radio's usefulness for EMCOMM work. First is the ability to sweep frequencies within a band for antenna resonance - a built-in SWR meter. While the functionality is somewhat limited, it is still very useful. Let's say you are supporting an EOC and you need to move over to a new HF antenna, but don't have a tuner. The built in SWR meter will at least let you know if the new antenna is close to resonance. Next is a built-in voltage meter. Very important if you are operating on battery power. Last, the IC-7100 incorporates a basic band sweep feature that can let you know where there's any band activity. While not really necessary for EMCOMM, for regular use it can let you know how busy the band is. Icom also incorporates a temperature monitor, so you can tell how hot your radio is running, and (Praise the Lord!) backlit buttons on the control head, so you can see what you are doing in the dark.

Icom has done a really good job with the information presentation on the IC-7100.
I just wish the resolution was better. But, it works!

Configuration for digital modes has been dead simple. I've found Icom radios - the 7100, 7200 and 7300 - to be as close to 'plug-and-play' on digital modes as you can possibly get. What helps is that this series of radios is very well supported by the digital software developers. So far I've run the IC-7100 on Winlink (using VARA on HF and on VHF with a TNC-X), and with JS8CALL and using HRD's Digital Master module. It works smoothly with all software. I've only got two recommendations - make sure you use the correct CI-V address (for the 7100 it's 88) and don't rely on the Icom baud rate 'Auto' setting. Manually set the radio's baud rate to something like 9600 and make sure it matches in the digital mode software's rig control interface. After that it should be smooth sailing.

Before closing let me discuss one of the features that the IC-7100 offers that I don't think gets a whole lot of attention, and that is the concept of 'over-the-air programming'. This is something that the military and commercial communications systems have used for decades. While implementation with the IC-7100 would be crude by comparison, it is still a concept that can work. The IC-7100 takes SD cards, and you can program the IC-7100 using an Icom .icf file stored on an SD card. The .icf files are small enough (< 300k) that they can be easily transferred as email attachments, even via Winlink. So, if an ARES EC working at the state or regional level needs to get a new settings file out to the operators in the field, even in a full 'lights out' scenario, the file can be easily transferred over the air as a Winlink attachment, downloaded to an SD card and uploaded to the radio, all in a matter of minutes. 

My evaluation of the IC-7100 will continue, but based on my testing so far I think it is perhaps the best available option for a fully featured EMCOMM radio. Icom really did a great job with this rig, so don't be like me and let the form factor put you off.

W8BYH out

The EMCOMM Layer Cake, Part 2

Happy New Year!

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 w8byh@arrl.net.

Thanks!

W8BYH out

The EMCOMM Layer Cake, Part 1

It's been a busy couple of months. Thanksgiving and Christmas, new granddaughter, some heavy requirements at work and, to top it all off, I was asked to do some digital mode software evaluations for our local ARES groups.

For a few years I've been holding familiarization and training sessions for Winlink. In my opinion, Winlink is one of the 'killer apps' for Amateur Radio in general, and the killer app for ARES and EMCOMM work. I make no secret of my admiration for the entire Winlink system, from the quality of the desktop client software to the extent and depth of the Winlink node infrastructure. It is a robust, professionally developed and maintained communications infrastructure that you can buy into for zero bucks. If it were up to me I'd make a high level of demonstrated Winlink proficiency a minimum requirement for ARES membership. If you can't prove that you can be up and running and sending ICS formatted message traffic via Winlink within 30 minutes of arrival at an EOC or other EMA location (fire station, etc.) then just don't bother showing up. So hold on to this thought for a bit.

What I've really been focusing on since November is a fairly new digital mode package called JS8CALL. I won't get too deep into the particulars about JS8CALL - it deserves its own blog post. I'll just say that JS8CALL seems to offer some real promise for EMCOMM work. JS8CALL is a low speed, weak signal free text communications tool, inspired by the FT8 protocol but modified to be able to handle longer message strings. As the developer, Jordan Sherer, KN4CRD, says, "JS8 is the mode, JS8CALL is the application". At work I spend a lot of time and money on software development. I don't do it myself, I pay developers to build focused applications that meet real world needs. I can spot good software a mile away. JS8CALL is really good software.

So what? There's lots of slick software out there for ARES to use. The real question is, does JS8CALL fill a real world need? Or if it's adopted will it end up being just another another ARES EMCOMM 'toy', fun to play with but fills no real need, or fills a need but falls short on performance?

So here, dear reader, is the real subject of this series of blog posts: what do our primary supported agencies - county and state EOCs and incident command posts - really need that they can't provide for themselves? What communications capability do most of these agencies lack and, in most cases, don't even realize they need? And how can ARES fill that gap?

Identifying real-world EMCOMM requirements gaps requires a needs assessment done in conjunction with emergency management agency (EMA) directors. Each EMA's needs will be slightly different, so it's important to sit down with the individual directors and go over their communications plans to see just where ARES can fit in. The killer question to ask each director is this: what happens in an unlikely but still plausible 'very bad day' scenario like Hurricane Maria - a scenario where all of your comms systems go dark, even for just an hour or two? No repeaters, no phones, no internet. What do you do then? How do you reach outside of your county to get critical information to adjacent county or state-level EOCs? I think we can make an accurate educated guess about the answer to this question.

Since Katrina, the professional EMCOMM community at the federal, state and local levels have made great strides in both expanding and hardening their VHF and UHF communications infrastructure. These guys and gals are good at what they do, and they take their jobs very seriously. The average EMA communications infrastructure in any county in the US is far more robust and capable than anything Amateur Radio can provide. Our UHF/VHF repeater-based services are crude and out-dated by comparison. In this realm we don't bring anything to the table that the average EMA doesn't already has, in spades.

It's also ludicrous for us to think that our Amateur Radio repeater infrastructure will survive any 'very bad day' event. If hardened EMCOMM systems go dark, ours will too. Consider this - in my county we have several Amateur Radio EMCOMM repeaters sitting on public service towers owned by state and county agencies. These repeaters are tied into the same power sources as the EMA systems on the same towers. If any of those tower sites go dark then everything on that tower goes dark, including the Amateur Radio repeaters. Many would say "yes, but there are other repeaters in the county on private towers that we can use!" Well OK - how many of those repeaters would survive a Maria-level storm event? Or an F1 tornado? Or a heavy flood? Or the owner forgetting to charge the back-up batteries?

The one operating mode that can answer the capabilities gap question is low-band HF (the high frequency 40, 60 & 80 meter bands). HF using NVIS antenna configurations can reach into the next subdivision, into the next county, into the next state, all while operating completely off-grid and independent of other systems. In addition, the newly created 60 meter interoperability channels give local, state and federal agencies a dedicated HF 'chat space', a place on the HF spectrum where everybody knows everyone else will be monitoring. HF is that last ditch, everything's else has gone dark, communications tool.

But very few (if any) local EMAs have organic HF capability. It simply isn't in their communications mix. For decades the federal government and the DoD have de-emphasized HF communications and pushed virtually everything over to point-to-point UHF and VHF (and SATCOMM for the feds with a lot of our tax dollars to throw around). The state and local EMCOMM communities just naturally followed along. HF communications systems were viewed as finicky, requiring special skills, radios and antennas, and reliability was too dependent on propagation. The emphasis in the EMCOMM world was to simplify - all an EMCOMM operator should need to do is press the PTT switch on an HT and all the magic takes place behind the curtain. Delivering that level of service is how Motorola became a multi-billion dollar company.

But starting with Hurricane Katrina, then Super Storm Sandy and then Hurricane Maria, the federal and state governments realized that it isn't just possible, but highly likely, that most point-to-point communications would go down during a catastrophic weather event like a hurricane. EMCOMM agencies worked to harden existing systems and build greater redundancy, but they also realized that HF, while imperfect, could give them the off-grid, short and long-haul comms capability they badly need in the hours immediately after a catastrophic event. This realization is what led directly to the creation of the federal government's SHARES program. For its part the DoD started pushing HF capability back into the force structure, mainly in the National Guard which has primary responsibility for civil/military interaction during disasters. There's even a renewed emphasis on the Army MARS program with a corresponding move to an all-HF infrastructure.

We can see the need, but just how would HF communications fit in to a local EMA EMCOMM support plan? We'll tackle that in Part 2 as we circle back to Winlink and JS8CALL, so stay tuned!

W8BYH out (for now)

You Can Go Home Again

I found out yesterday that you can go home again, at least in Amateur Radio.

Yesterday as I was leaving the Stone Mountain Hamfest in Lawrenceville, GA I made one last sweep through the boneyard and stopped to talk with David, AG4F. David looked like he was trying to unload the worlds largest collection of 32-bit computer parts, and reported he actually had some measure of success. Seems there's a buyer for EVERYTHING at a hamfest!

At the table next to David's I noticed the seller had two nice looking Radio Shack HTX-202 2-meter HTs for sale. One was in the box, with all accessories still in the unopened packaging. The only thing missing was the Ni-Cad battery pack, but that's to be expected for a radio that went out of production 20 years ago. The package did include the AA cell battery holder so I knew I could at least power it up and use it portable. We haggled a bit and I walked off with a part of my Amateur Radio past.

The HTX-202 was my first Amateur Radio transceiver. I bought it in 1995 after being licensed at Fort Hood, TX and assigned the callsign KC5YNP. The radio was an expensive purchase back then - something like $200. But the HTX-202 had a great reputation and, perhaps most important, the local Radio Shack store in Killeen, TX sold a lot of ham radio gear and did a great job of supporting the local Amateur Radio community so I figured it was a safe purchase.

But my experience shows the importance of mentoring (or 'elmering' as it's called in the ham radio world). I struggled with the radio for a few weeks and couldn't bring up most of the repeaters in the Fort Hood area. I ended up taking it back to the Radio Shack store and had them ship it off to the repair facility in Fort Worth. To say I was peeved that Radio Shack had sold me a defective radio would be an understatement. A week later the store called and told me my radio was back from Fort Worth and ready to be picked up. I dropped by the store after work and when the sales guy handed it back to me he said, "They didn't find anything wrong with it"

I fired the radio up right there in the store and tried to hit one of the local Killeen repeaters. No luck. I gave the sales guy a stern look. "It sure doesn't look to me like this thing works!"

"Have you set the PL tones?" he asked.

"What's a PL tone?"

I got a quick block of instruction (that 'elmering' thing again) and thirty minutes later I walked out of the store embarrassed as hell but with all the PL tones for every repeater between Dallas and Houston loaded in the radio.

That HTX-202 ended up doing yeoman work. I took it with me on field exercises on Fort Hood and allowed my Soldiers to use it to make phone patch calls home. It rode in the car with me everywhere, becoming my 'mobile' rig. I even took it to Six Flags Over Texas, and got the 'you're an embarrassment' look from the YL when I pulled it out of my backpack just before getting on the Yogi Bear ride. I eventually put up an MFJ ground plane antenna in my back yard and bought a used 35 watt amplifier. From my house on Fort Hood I could bring up repeaters in Austin, a good 60 miles away. When all you can afford is one radio, you make do.

One memorable day in May, 1997 my wife and I stood in our back yard at Fort Hood and watched an unbelievably ugly storm system pass just to our east. Weather systems don't usually scare me, but this one did. I told my wife to get the kids inside, and I rushed in to fire up the HTX-202. Just 20 miles south of us that storm system dropped an F5 tornado on the ground that literally wiped the small town of Jarrell off the map. If you were not under ground when the tornado hit you were dead. Period. I listened in morbid fascination as repeaters from Waco to San Marcos lit up with tornado and storm damage reports, weather warnings and calls for assistance. I was hooked. That little radio was my window into things well beyond my line of sight.

Later in 1997 we moved to Germany and the HTX-202 went into storage. In 2000 we found ourselves back in the US, in Fayetteville GA. Soon after settling in I pulled out the HTX-202, found a few local repeater frequencies and got back on the air. I'm still on the air, on the same repeaters, almost daily.

Somewhere along the way the old HTX-202 became just an obsolete piece of gear, and I sold it off to a local ham who wanted to run a packet station with it. Well, packet is dead, and I'm sure that old radio is too. I soon came to regret getting rid of the HTX-202; it was my 'first love' in ham radio and it taught me a lot. I always told myself that one day I'd find a replacement and bring it home, for nostalgia reasons. Well yesterday was that day.

The radio works, but returns an 'Er1' code, which means the internal memory battery is dead (dead, dead, dead...). But that's an easy fix, and a replacement battery is already on the way from Amazon. I did manage to get a local repeater frequency and tone loaded and confirmed the radio does work (just don't turn it off or all the memories get wiped - the dead battery thing).

So I'm tickled pink to have my first radio back. It'll assume an honored place among my collection of handheld radios and, who knows, maybe I'll fire it up sometime try to make a phone patch - for old times sake.

W8BYH out.

The S--- Truly Has Hit The Fan

We learned just a few days ago that the Kincade Fire in California has turned into a 'perfect storm' of high winds, dry conditions, political malfeasance, idiotic environmental policy, bad utility management practices and poor power grid maintenance. As a result, California is probably the first political entity in America to simultaneously shut off power to millions of residents, allow explosive fires to devour tens of thousands of acres of poorly managed state land, and cause entire critical communications networks to 'go dark' for no good reason. In short, a self-inflicted gunshot wound of the highest order.

When I started this blog a few years back I promised myself I'd keep it non-political. After all, dear reader, I want you to come here for pithy Amateur Radio content, not political bashing. But California is just too deserving a target. If what's happening in California were instead happening in south Georgia the press would be all over the story, blaming the toothless Bible-thumping rednecks of the region for the situation. But because this is happening in The Golden State - the land of feel-good environmental policy, the bullet train to nowhere, celebrity governors and beaches littered with Beautiful People - the mainstream media seems utterly uninterested in trying to find out how and why things got this bad.

Huge swaths of central California have 'gone dark' and will go dark again (and again) as Pacific Gas and Electric (PG&E) institutes wide area blackouts in an effort to reduce the risk of wildfire ignition. It seems that PG&E's power line infrastructure is so poorly maintained that the lines in many remote areas are prone to shorting out in high winds or high heat, causing showers of sparks that ignite the tinder-dry wood and vegetation sitting on the forest floor. So PG&E shuts off power to entire sections of its grid and a series of cascading failures begins. Without power cell phone sites (which are not required to have backup power in California) go dark. And of course, with no power there's no internet (either on phones or in homes). Then the remote repeater sites start to go dark as their backup systems - usually a combination of batteries and generators - go dead. What about landlines? Well, since most 'landline' these days is VOIP, that goes dark as soon as the power to everyone's internet modem goes out. The few left with old fashioned conventional landline service are OK for a time, but at some point the fires take out those lines too. Because, you see, even though PG&E is shutting down power over wide areas, their live lines are still sparking and igniting forest fires.

Hollywood screen writers couldn't have crafted a more zany set of interlocking failures involving mother nature and poor human decision making. And don't think for a moment your local politicians and utility owners can't bring the same level of incompetence and mismanagement to your hometown. We saw it in New Orleans in the wake of Katrina and in Puerto Rico in the wake of Maria. In this context California is not an outlier; 'civilized' countries or regions descend into chaos all the time, and no level of investment in hardened communications systems makes them invulnerable.

What's this all have to do with Amateur Radio? Actually, quite a bit. What's happening in California represents a real-world, full on communications blackout. EVERYTHING is down, even the federal government's vaunted 'FirstNet' system was having problems. Amateur Radio infrastructure is not exempt - I'm sure repeater sites were going down right along with the cell sites.

But there IS an Amateur Radio mode that can operate completely off the grid, with zero dependency on local power or other infrastructure. This is the same mode that came into play in Puerto Rico in the immediate aftermath of Hurricane Maria, and in the Bahamas right after Hurricane Dorian earlier this year. The solution is HF using Near Vertical Incidence Skywave (NVIS) antenna configurations. If you need to get a signal up and out of an affected area, but still retain the ability to communicate with the guy just on the other side of the ridge, then NVIS is your best - and often your only - bet.

NVIS Propagation

We'll be discussing more about NVIS in later postings. But for now just understand that 'when all else fails', even our highly touted repeater infrastructure, there is still one mode that can get the signal through - NVIS.

W8BYH out.