Many of you already know I’m a huge advocate of JS8Call. What you may not know is my opinion of JS8Call as an unorthodox but effective Emergency Communications networking tool.
Two of general misconceptions about js8 are its similarity to FT8, and its purpose. Often, operators don’t understand the point of JS8 since the assumption is, it must be nearly identical to FT8. This is where the discussion goes terribly wrong. There are features implemented in js8, making it a magnificent mode for group communications, or managing remote stations in a grid down scenario.
Leave whatever preconceptions you might have about amateur radio emergency communications, JS8, WinLink, NBEMS or any of the SOP used today. Also try to remember the goal here is near real-time tactical messaging, and the management of resources over HF, without network infrastructure. Above all, keep an open mind.
JS8Call stations can send out beacons at set intervals, announcing themselves to the network. Stations hearing that beacon or “in range” of a station, are announced and populated on your JS8Call screen. Stations having bi-directional Communications with your own station are listed with an an asterisk on your JS8Call screen. At that point you can hover over a station listed on your screen, to see what stations it can hear directly. Your network just became bigger!
Now your station not only has the stations you can hear directly, but also has access to the stations heard directly by stations hearing you.
Managing and Tracking Stations
Like APRS, JS8 stations choosing to send a JS8Call beacon, can send a 4-10 digit maidenhead locator. In a normal qso, this information can be used to determine the distance and bearing of a station from your own. As part of an emergency communication network, this information can be used to understand where your resources are, whether or not you can communicate with them, and have a near real-time view of stations participating in the emergency network.
Imagine a scenario where we have deployed teams to the field, and need to manage them. I always like to use the grid down scenario from Hurricane Maria in Puerto Rico, as an example. This time is no different! When deploying stations to various locations, we need a robust way to manage and communicate with those stations now. Traditionally in the Amateur radio world, we would use WinLink as a tool for managing communications to or from those stations. WinLink is an excellent tool for moving data, but it fails as a real-time tactical information tool. Even with a standard SOP, WinLink simply can’t manage stations in a rapidly changing environment. This is absolutely okay, since it was never designed to do that. I propose using JS8Call as a near real-time tool for managing remote stations on the emergency network.
Certainly we won’t try using JS8Call for sending huge amounts of data to the network (it wasn’t designed to do that). We’ll simply use it for near real-time, delayed messaging and coordination with stations on the network.
The benefits of this are:
- Robust text messaging in near real-time or delayed.
- Near real-time status of stations within the emergency Network.
- Multiple messaging routes for stations.
- Every station in the emergency Network supports and contributes to the network.
- Not reliant on infrastructure.
JS8Call has several types of messaging built in.
- Direct QSO – In this mode we are having a direct keyboard to keyboard qso with one or more stations.
- Relayed messages – In this mode, two stations who can’t hear one another, use a third station both can hear, to send messages to one another
- Stored delayed message 01 – In the case a station is not on the network now, we can leave a message with a station on the network. When the recipient queries the network for their messages, the message will be delivered.
- Stored delayed message 02 – After determining the station is in the network, but its operator is busy, not at the keyboard, … we can leave a message for the operator to be read and/or responded to later.
- Directed group messaging – In this mode, our messaging is directed to a group of stations specified.
Most Operators use JS8 for for its keyboard QSO capabilities. Since the mode is something between psk31 and ft8, offering the free text capabilities of psk, with a weak signal capabilities of ft8, its an attractive option. What’s often ignored are the network capabilities if JS8, in some way similar to a single band ALE.
Many of these features weren’t developed at the time I published the video I’m sharing below. However, this video does show very well the weak signal capabilities of JS8. It also shows how quickly a station can set up, using minimal gear, join the network, initiate messaging or a keyboard to keyboard qso, all without much work or complexity for the radio operator. I envision two use cases for this mode:
- Emergency Communications in support of disaster relief.
- Group communications for preparedness.
JS8Call was designed to be lightweight and robust. It has very modest requirements and runs quite comfortably on a Raspberry Pi. It lacks a offline mapping functionality to plot stations locally on a map, but does have a documented API, allowing all sorts of additional functionalities to be added. Whether for traditional EMCOMM, or Communications Preparedness, we should be taking a serious look at JS8Call.