25 January 2020

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

01 January 2020

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.


W8BYH out