These are my comments on digital communications and are not necessarily all there is to know on the subject. As with everything computer related – there are at least six ways to do the same thing. Given this caveat, let me say this is opinion and not the complete story. I only relate to you my experience of 10 or more years using digital modes to give you the benefit of my experience. I will leave the rest for you to research as you see fit.
Sooooo – What to make of all the knowledge up to this point?
As you can see from the previous installments, a decision as to what is the right mode, or even which software to use, can be confusing. We have waited until now to talk about the decision on the SATERN International Digital Net to use the FLDIGI, FLMSG, FLAMP software suite generally known as Narrow Band Emergency System (NBEMS). NBEMS is the default software for use on the SATERN 20 meter Digital Net (and frankly, several other emergency nets around the country).
This decision was not arrived at lightly, or without considerable investigation into the aforementioned modes and software products. We had several considerations which influenced the decision.
SATERN, as an organization, has a long history of providing SSB voice communication during emergency situations. SATERN is the brainchild of then, Captain Patrick McPherson, WW9E Emergency Disaster Services (EDS) coordinator for Central Illinois and Eastern Iowa in the Heartland Division. SATERN’s first network consists of Pat, EDS volunteer Arthur Evans, and two Canadian Salvationists. The possibility that the fledgling network could accommodate international emergencies begins to dawn on its founders. (you can read the complete 30 year history of SATERN here)
Since then SATERN has grown to a worldwide network of thousands of volunteer radio operators. In recent years, the adaptation of new technology has allowed SATERN to embrace available computer software technology to develop a considerable digital presence on the SATERN network. A number of local and regional digital nets, as well as an International SATERN Digital Net are meeting regularly with faithful and capable volunteers sending and receiving digital messages each week over ham radio frequencies.
In an emergency, messages need to be sent and received without error to reach their destination. The effectiveness of the media of radio may be diminished when digital messages do not reach their intended destination or reach the destination in some state of error, whether that error is completeness, accuracy, or failure to arrive.
So, the desire is to select a software base that has the capabilities to send and received error–free message passing with minimal operator skill needed.
Amateurs operate on radio channels that are not guaranteed a perfect path. We, in fact experience considerable variations minute to minute on most (if not all) amateur radio frequencies. We are influenced by and are susceptible to, ionospheric variations and malicious and incidental interference. The strong influence by “Mother Nature” presents the requirement to change method to cope with a change in conditions. What works for us on one day, or even hourly, may not the next. Propagation of radio signals between various locations may vary for particular operators in different directions for different times during the day. We have all experienced the phenomenon of directional favorability during the aftermath of a CME, a magnetospheric disruption, or solar flare. Amateurs attempt to overcome such variations by using different modes that may fit the situation. So we needed computer software that would allow digital radio volunteers to change modes with changing conditions, ad–hoc, and creating networks of stations across large geographic areas.
Any software chosen should be capable of general acceptance and interoperability with the services and agencies we serve – whether government based or NGO. This is an area of much discontent between agencies and is still not fully resolved. As technology advances and certain modes become more popular, adaptation and acceptance in Emcomm organizations is slow at best and yet to be accomplished in others.
MARS, for instance, used RTTY for many years as the commonly accepted digital mode. That soon fell to MT–63 and was later joined by ALE. ALE has changed MARS quite a bit as well. Many MARS volunteers are adapting commercially made surplus gear that has ALE embedded into the hardware. Others are using PCALE MARS version software for signaling.
Today, MARS is still adapting with some general use of other modes, like PACTOR, OLIVIA, THOR, and MFSK64 on a very limited basis. The paradigm shift has been more to getting the message error–free than how it gets there.
FEMA has adopted standardized forms for messages (like ICS-213, etc.) which needed to be moved from one location to another during an emergency. These paper forms do not exactly lend themselves to use in a ARRL radiogram format. Early on, there was an attempt by the National Traffic System, to add the ICS–213 to the ARRL Radiogram format. This presented a problem for NTS Digital, in that, their default format is always the ARRL Radiogram form. They, too, are adapting. But, how to get the adapted message from one location to another error–free, remained a problem. Their solution is to have a widespread use of hardware based communication with the SCS Pactor modems. This hardware solution is very expensive for most hams who would otherwise become more active with NTS Digital and ARES.
Enter WinLink 2000. The popularity of WinLink 2000 began to soar with the introduction of the WinMOR protocol in WinLINK, in addition to Pactor. This software based protocol allows just about any digital ham radio station to become a client of the WinLink system and pass Internet Email style messages over the radio media of WinLink 2000. In fact, WinMOR as a digital mode, has added pre–formatted versions of some of the FEMA forms to format email by the client user. When the new experimental mode ARDOP is fully developed and deployed on the WinLink 2000 network, the level of use will no doubt increase again.
This is the area where SATERN has the most potential. The inevitable paradyme shift, of all agencies, from paper–based communication to digital, allows SATERN a “golden” opportunity. Where local SATERN groups have formed, and are active in support of NGOs and others, SATERN is demonstrating the utility of ham radio and digital radio in the practice activities that are sponsored by local ham radio groups and NGOs. SATERN and ARES often cooperate in local activities like bike rides and runner races for charity. These events act as a platform to practice message passing and pre–formatted message use, providing a clear demonstration of how well suited digital ham radio can be, in passing information quickly and accurately in more desperate situations.
After evaluating at lease a dozen different possible softwares and / or combinations of software, SATERN International Digital Net Mgr. decided to use the FLDIGI suite of programs as a software basis for the digital net for common text messages. The following describes this software suite and why it fits our stated mission and purpose.
This extremely capable application functions as a mulit–mode controller and logger for more than 18 protocol families. The mode families included are based on common use in the ham radio digital radio community and by operators who have a need for error–corrected message passing.
Like MixW, MultiPSK, and DM-780 (Digital Master 78 from Ham Radio Delux), FLDIGI provides all that one would expect from an all–in–one software platform approach to digital communication.
Also like MultiPSK, the graphical user interface (GUI) is not as pretty as commercial products like MixW and Digital Master, but also like MultiPSK this is only consmetic and not a serious fault in the utility of either MultiPSK nor FLDIGI.
Among the many protocol families FLDIGI includes (not in any particular order):
...plus a tuning feature that allows CW output and WWV timing for the soundcard.
Of particular interest to SATERN is the companion software suite of FLMSG and FLAMP.
FLMSG provides a mechanism to send and receive messages using any mode available in FLDIGI. FLMSG can use FLDIGI as a remotely activated modem to send and receive messages created and sent from FLMSG.
FLMSG uses ASCII text formatting markup that describe the message, as plain text, or a more graphical version of the message, and may contain formatting marks to denote compression level and error correction checksums. This is an important and unique feature of FLMSG. Even if the receiving station does not use FLDIGI for the modem, FLMSG can re–constitute a complete error free message as sent.
There are traditional entry forms for the text content of certain pre- formatted messages. The list of messsage forms is impressive:
In addition, the user has the option to design and use a custom–designed HTML based form. It should be noted that HTML is a verbose raw text source, so even a small, and somewhat visibly simple form, can be quite large in terms of the total text sent. In designing and formatting the full page Salvation Army Form FIA–30 custom form for the West Palm Beach regional SATERN group, we were only able to reduce the total text sent to just over 124K. Since this group primarily uses local VHF / UHF media, the faster modes made impressive use of it for local SALVATION ARMY EDS leaders during training and practice sessions. Smaller, and less complex forms may be even more impressive.
FLMSG–formatted messages received, may be viewed and printed in their intended graphical version if opened with FLMSG and viewed with the local browser or sent by email as a exported PDF attachment. For instance, a ICS–213 message may be filled with the appropriate text from FLMSG and sent over radio channels in a few seconds completely error–free. The receiving station will not see the formatted document in FLDIGI, it must be opened with FLMSG to see what looks like a picture of the form with the entered text in the appropriate places – as though the sender had typed it up and faxed it – only faster and without error.
FLAMP is a program for AMP or Amateur Multicast Protocol. An FLAMP session will transmit one or more files with one or more iterations of the transmission. Each file is converted to compressed text and the binary text is broken into blocks, each of which has a check sum.
The receiving station saves the blocks that pass check sum. Successive transmissions will fill in the missing blocks provided that the new blocks pass the check sum. After the transmission sequence, the entire file is assembled and may be saved. “Fills” may be provided by retransmitting the entire file, or by the sending station, only the missing blocks.
Like FLMSG, FLAMP can use FLDIGI as a modem for any mode FLDIGI is capable of.
The receiving stations must have FLDIGI running then FLAMP open. FLDIGI will not “wake up” FLAMP as it does with, for example, FLMSG. You may, however, include FLAMP and other NBEMS tools in the AutoStart list of programs to auto execute when FLDIGI starts. See FLDIGI user manual for details.
The receive operation is hands–off. As the blocks are received the file information is filled in (file name, date/time, etc.) and the successfully received blocks will be depicted as dark blue rectangles on the progress bar. The blocks are positional. That is, a missing block will simply be a white space where the block would be if received correctly. On subsequent receptions that block will fill in when received correctly. The percent complete on the respective line also shows the state of each file being received.
You will also see block numbers showing up in the Missing line. When the complete file is received, that line should be blank. Received text files will appear in complete form and readable in the Data panel. To save a file, click Save with the file highlighted. This will place the file in the received message folder in the default directory.
The received file size is the actual file size, i.e. the actual bytes being transported (per repeat) less all of the Amp header information. The Send to information does not appear on the FLAMP screen.
If a transmission sequence has been completed and one or more stations have missing blocks or header information, the receiving operators may request the fill–ins using the Report button seen just to the right of the Missing: edit box. The Report button adds a text stream to the FLDIGI Tx buffer, but does not start the FLDIGI transmit processing (unless this option is enabled in the config panel, "Enable TX on Report"). The recipient sends the Tx buffer using the T/R command when it is his or her turn to make the report.
If there were no missing data, a report of receipt confirmation will be sent.
For small files, another transmission of the complete file should suffice for fill–ins. In the case of a large file where only a few blocks are missing, FLAMP permits the sending station to just transmit the missing blocks.
When the sender has received all of the block missing reports he or she then retrieves the reports from FLDIGI by pressing the Fetch button on the Transmit tab. Any missing reports for the selected transmit queue item will be display in the blocks field. FLAMP parses all of the received data from one or more reporting stations. It combines them, discards duplicates and sorts the missing blocks numerically. It then updates the “blocks” entry control with the requested blocks. Missing header information assigns ’0’ to the missing block list, triggering a retransmission of the header information.
FLAMP will send any file format. For example, ICS forms from FLMSG may be sent as well as spreadsheets in CSV format or binary data such as image files (with longer transmit times).
So now we have a capable tool to use, what does this mean for the SATERN volunteer.
All over the U.S. and Canada, local SATERN groups have developed working relationships with other NGOs and first–responding agencies to demonstrate SATERN capabilities for both voice and digital communication. Some enterprising groups have worked with Salvation Army Corps personnel to create a much more effective response to local events and provide timely and accurate information to Salvation Army leadership.
While not the prettiest, FLDIGI and the NBEMS suite provide a concise group of applications that allow the maximum flexibility and minimum error induction in the message passing process, whether keyboard–to–keyboard or pre–formatted for transfer to WinLink 2000 or Internet destinations, FLDIGI / NBEMS provides a capable method to send and receive error–free messages. This group of programs is adaptable to any band where digital communication is allowed on the ham bands.
When working with cooperating agencies, modes and pre–formatted forms are provided that are both expected and preferred (interoperable). When supporting the Salvation Army, Corps leadership and field personnel are provided an available, and cooperative media to communicate swiftly and accurately within and externally to the affected area of the event, in addition to the commercial radio media normally used for tactical communication.
If your area does not have a local SATERN group organized to assist first responders and relief agencies, your radio and the FLDIGI / NBEMS software suite can be an important starting point to begin one. Developing relationships with cooperating agencies and Corps personnel takes time and patience, but can be rewarding and vital in an emergency event in your area.