Date   
Re: Updating Fldigi on the Raspberry Pi 3 running Raspian

David Ranch
 


Hey Ed,

Why not just change it to Rpi and be done with it.

Just my $0.02 but since Fldigi needs some decent horsepower to run properly, that negates the use of a Raspberry Pi v1, Raspberry Pi Compute module, Raspberry Pi Zero, and Raspberry Pi Zero W.  It's due to them being based on a single, old ARM CPU with too little RAM.  I've generally found if documentation isn't prescriptive enough, people will try it anyway and complain when it doesn't work.  :-)


Hope you all are planning on testing the build on all of them before you
make changes to the wiki.

Well..  I can't imagine anyone has actually built and tested Fldigi builds on every Debian based Linux distribution.  That would be an immense job.

--David
KI6ZHD

Re: Updating Fldigi on the Raspberry Pi 3 running Raspian

Ed W3NR
 

On Sat, 17 Mar 2018 10:31:44 -0700
"David Ranch" <linuxham-fld@...> wrote:

Hey Ed,

Why not just change it to Rpi and be done with it.
Just my $0.02 but since Fldigi needs some decent horsepower to run
properly, that negates the use of a Raspberry Pi v1, Raspberry Pi
Compute module, Raspberry Pi Zero, and Raspberry Pi Zero W. It's due
to them being based on a single, old ARM CPU with too little RAM.
I've generally found if documentation isn't prescriptive enough,
people will try it anyway and complain when it doesn't work. :-)
You would be surprised at what I've seen people try and do with respect
to fldigi & friends. Never ceases to amaze me. There is someone
somewhere that will try the above. Guaranteed.

Hope you all are planning on testing the build on all of them
before you make changes to the wiki.
Well.. I can't imagine anyone has actually built and tested Fldigi
builds on every Debian based Linux distribution. That would be an
immense job
I meant the Rpi's

--David
KI6ZHD

Ed W3NR

alpha testers wanted

Dave
 

Would you like to use fldigi with keyline keyed CW and/or FSK ?

If you answered yes then read on.

If you own a Navigator, a US Navigator, or a Timeline Navigator, then skip this next section.  This test version of fldigi has a built-in Navigator interface to allow it to work with the Navigator to produce a keyline FSK signal.

Are you Arduino aware or would like to learn more about the Arduino and like the smell of solder?  Then read this next section.

NanoIO

Authors:

David Freese, W1HKJ

Ervin Hegedüs, HA2OS


An FSK / CW interface based on the Arduino nano. nanoIO sketch is expanded version of

tinyFSK, http://www.frontiernet.net/~aflowers/tinyfsk/

FSK Specifications:

  • 5 bit Baudot

  • baud rates 45.45, 50, 75 and 100

CW Specifications:

  • 5 to 100 WPM

  • dash/dot ratio adjustable 2.5 to 3.5

  • in-line increment decrement WPM using ^ and | characters

  • incremental size user adjustable

PTT signal generated by Arduino

Both: an internal buffer of 200 characters is available for buffered transmit.

Hardware requirement

  • Arduino nano or compatible (author used nano from Elegoo)

  • LTV-847 quad opto-isolator

  • 4 620 ohm ¼ watt resistor (should work with 500 < R < 820 ohm)

  • suitable connectors to interface to transceiver

























Default pin assignments defined in Arduino Sketch:

  • D9 / PIN 9 – spare

  • D10 / PIN 10 – PTT

  • D11 / PIN 11 - FSK_PIN

  • D12 / PIN 12 – CW

All interface commands consist of the tilde ‘~’ character followed by a command string.

  • C,c set CW mode

  • F,f set FSK mode

  • T,t enable CW Tune

  • Snnns Set wpm 10 ... 60

  • Dnnnd Set dash/dot 250 ... 350 (2.5 to 3.5)

  • In Set CW incr/decr (1..9)

  • 0 Set FSK mark = HIGH

  • 1 Set FSK mark = LOW

  • 4 Set 45.45 baud

  • 5 Set 50.0 baud

  • 7 Set 75.0 baud

  • 9 Set 100.0 baud

  • ? Show current config

  • W Save config to EEPROM

  • ~ Show commands

for example:

  • ~C – set CW mode

  • ~S30s – set CW speed to 30 WPM

  • ~I5 – set WPM increments to 5

nanoIO Special characters:

  • [ - PTT on, start FSK transmit (CW does not need the [ to start)

  • ] - PTT off, complete sending internal nanoIO buffer

  • \ - escape character, end character, clear internal buffer PTT off

  • ^ - increase CW one incremental

  • | - decrease CW one incremental

for example, a CW string might contain:

  • ~C~S24s[tu ^^5nn|| k]

PTT would enable before begining the CW transmission.

PTT would disable after the last CW character (k) was completed.


A set of compatible versions of fldigi and nanoIO are located at the www.w1hkj.com web site

73, David, W1HKJ


Re: alpha testers wanted

deirdre@...
 

This is perfect - I'm planning on an experiment where this might come in handy!


On 3/17/2018 4:32 PM, Dave wrote:
Would you like to use fldigi with keyline keyed CW and/or FSK ?

If you answered yes then read on.

If you own a Navigator, a US Navigator, or a Timeline Navigator, then skip this next section.  This test version of fldigi has a built-in Navigator interface to allow it to work with the Navigator to produce a keyline FSK signal.

Are you Arduino aware or would like to learn more about the Arduino and like the smell of solder?  Then read this next section.

NanoIO

Authors:

David Freese, W1HKJ

Ervin Hegedüs, HA2OS


An FSK / CW interface based on the Arduino nano. nanoIO sketch is expanded version of

tinyFSK, http://www.frontiernet.net/~aflowers/tinyfsk/

FSK Specifications:

  • 5 bit Baudot

  • baud rates 45.45, 50, 75 and 100

CW Specifications:

  • 5 to 100 WPM

  • dash/dot ratio adjustable 2.5 to 3.5

  • in-line increment decrement WPM using ^ and | characters

  • incremental size user adjustable

PTT signal generated by Arduino

Both: an internal buffer of 200 characters is available for buffered transmit.

Hardware requirement

  • Arduino nano or compatible (author used nano from Elegoo)

  • LTV-847 quad opto-isolator

  • 4 620 ohm ¼ watt resistor (should work with 500 < R < 820 ohm)

  • suitable connectors to interface to transceiver

























Default pin assignments defined in Arduino Sketch:

  • D9 / PIN 9 – spare

  • D10 / PIN 10 – PTT

  • D11 / PIN 11 - FSK_PIN

  • D12 / PIN 12 – CW

All interface commands consist of the tilde ‘~’ character followed by a command string.

  • C,c set CW mode

  • F,f set FSK mode

  • T,t enable CW Tune

  • Snnns Set wpm 10 ... 60

  • Dnnnd Set dash/dot 250 ... 350 (2.5 to 3.5)

  • In Set CW incr/decr (1..9)

  • 0 Set FSK mark = HIGH

  • 1 Set FSK mark = LOW

  • 4 Set 45.45 baud

  • 5 Set 50.0 baud

  • 7 Set 75.0 baud

  • 9 Set 100.0 baud

  • ? Show current config

  • W Save config to EEPROM

  • ~ Show commands

for example:

  • ~C – set CW mode

  • ~S30s – set CW speed to 30 WPM

  • ~I5 – set WPM increments to 5

nanoIO Special characters:

  • [ - PTT on, start FSK transmit (CW does not need the [ to start)

  • ] - PTT off, complete sending internal nanoIO buffer

  • \ - escape character, end character, clear internal buffer PTT off

  • ^ - increase CW one incremental

  • | - decrease CW one incremental

for example, a CW string might contain:

  • ~C~S24s[tu ^^5nn|| k]

PTT would enable before begining the CW transmission.

PTT would disable after the last CW character (k) was completed.


A set of compatible versions of fldigi and nanoIO are located at the www.w1hkj.com web site

73, David, W1HKJ



Re: Updating Fldigi on the Raspberry Pi 3 running Raspian

KE3KQ
 

Being St Patrick's Day yesterday, I spent some time trying to figure out if the RPi load of FLdig can send and received the symbol for the Shamrock?

Just the basic compiled code, not some alteration to the code. I think it might be able to do this (unicode and all) but could not get very far on this burning question<grin>.

In a somewhat related question, I swear I saw a waterfall of a transmission that started with an image "CQ" in the waterfall.

*** Ben KE3KQ

Re: Updating Fldigi on the Raspberry Pi 3 running Raspian

David Ranch
 


Hello Ben,

Your eyes weren't lying when you saw a "visual" CQ on the waterfall.  You can enable it in Fldigi via:

   Configure --> ID --> Video --> "Transmit Video Text"

You can also configure it as a macro.


As for the shamrock symbol, Fldigi might be able to send the unicode symbol for a Shamrock but I don't know if will work
(an extreme corner case and I would suspect that Fldigi only supports basic ASCII text here):

   http://www.fileformat.info/info/unicode/char/2618/index.htm


Btw, Fldigi doesn't offer waterfall elaborate bitstream transmissions to create something like this:

   http://www.qsl.net/py4zbz/arq.htm#p

While cute, I would argue that's a waste of a large swath of spectrum for an extended period of time.

--David
KI6ZHD



On 03/18/2018 09:07 AM, alchemy wrote:
Being St Patrick's Day yesterday, I spent some time trying to figure out if the RPi load of FLdig can send and received the symbol for the Shamrock?

Just the basic compiled code, not some alteration to the code.   I think it might be able to do this (unicode and all) but could not get very far on this burning question<grin>.

In a somewhat related question, I swear I saw a waterfall of a transmission that started with an image "CQ" in the waterfall.

*** Ben KE3KQ

New RPi3 Fldigi install on Raspian not showing "Hamradio" menu

Randy Houk
 

I just wiped an Ubuntu Mate install, due to multiple issues, and replaced with the latest Raspian stretch.

I followed the Wiki instructions to a letter, with no error messages.
I expected to see a Hamradio menu with the NBEMS selections, but it's not there.
I can run Fldigi just fine from the command line.

Last time I did this on another Rpi3 the Hamradio menu appeared.
Any ideas?

Randy, KI6DGU and USCG Auxiliary

Re: New RPi3 Fldigi install on Raspian not showing "Hamradio" menu

Ed W3NR
 

On Mon, 19 Mar 2018 15:41:27 -0700
"Randy Houk" <realengr@...> wrote:

I just wiped an Ubuntu Mate install, due to multiple issues, and
replaced with the latest Raspian stretch.

I followed the Wiki instructions to a letter, with no error messages.
I expected to see a Hamradio menu with the NBEMS selections, but it's
not there. I can run Fldigi just fine from the command line.

Last time I did this on another Rpi3 the Hamradio menu appeared.
Any ideas?

Randy, KI6DGU and USCG Auxiliary
Google makes it really easy.

https://packages.debian.org/wheezy/hamradio/hamradiomenus

Ed W3NR

Re: New RPi3 Fldigi install on Raspian not showing "Hamradio" menu

Marty Hartwell
 

Hi Randy

I just answered a question like this on the Linuxham group.
From an old build instruction this is copied.

=======================Copied instuction==========
Making things spiffy :>)
System Hamradio Menu
So ... everything is up and running but you want to streamline the desktop and launching the applications. The first to do is to
add a new system menu "Hamradio"

sudo apt-get install extra-xdg-menus

It takes a few seconds to download and install and you now have a new system menu "Hamradio" fully populated by the fl_xxx apps that you have installed.

==============End of copied Instruction=======================

Marty kd8bj

On 03/19/2018 05:41 PM, Randy Houk wrote:
I just wiped an Ubuntu Mate install, due to multiple issues, and replaced with the latest Raspian stretch.
I followed the Wiki instructions to a letter, with no error messages.
I expected to see a Hamradio menu with the NBEMS selections, but it's not there.
I can run Fldigi just fine from the command line.
Last time I did this on another Rpi3 the Hamradio menu appeared.
Any ideas?
Randy, KI6DGU and USCG Auxiliary

Re: New RPi3 Fldigi install on Raspian not showing "Hamradio" menu

Randy Houk
 

Thanks, Ed.

Randy

On 3/19/2018 3:53 PM, Ed W3NR wrote:
On Mon, 19 Mar 2018 15:41:27 -0700
"Randy Houk" <realengr@...> wrote:

I just wiped an Ubuntu Mate install, due to multiple issues, and
replaced with the latest Raspian stretch.

I followed the Wiki instructions to a letter, with no error messages.
I expected to see a Hamradio menu with the NBEMS selections, but it's
not there. I can run Fldigi just fine from the command line.

Last time I did this on another Rpi3 the Hamradio menu appeared.
Any ideas?

Randy, KI6DGU and USCG Auxiliary
Google makes it really easy.

https://packages.debian.org/wheezy/hamradio/hamradiomenus

Ed W3NR


Re: New RPi3 Fldigi install on Raspian not showing "Hamradio" menu

Randy Houk
 

Thanks, Marty. That worked fine.

Randy KI6DGU

On 3/19/2018 4:09 PM, Marty Hartwell wrote:
Hi Randy

I just answered a question like this on the Linuxham group.
From an old build instruction this is copied.

=======================Copied instuction==========
Making things spiffy :>)
System Hamradio Menu
So ... everything is up and running but you want to streamline the desktop and launching the applications. The first to do is to
add a new system menu "Hamradio"

sudo apt-get install extra-xdg-menus

It takes a few seconds to download and install and you now have a new system menu "Hamradio" fully populated by the fl_xxx apps that you have installed.

==============End of copied Instruction=======================

Marty kd8bj


On 03/19/2018 05:41 PM, Randy Houk wrote:
I just wiped an Ubuntu Mate install, due to multiple issues, and replaced with the latest Raspian stretch.

I followed the Wiki instructions to a letter, with no error messages.
I expected to see a Hamradio menu with the NBEMS selections, but it's not there.
I can run Fldigi just fine from the command line.

Last time I did this on another Rpi3 the Hamradio menu appeared.
Any ideas?

Randy, KI6DGU and USCG Auxiliary

Some Thoughts Re EmComm and Red Cross Message Traffic

n6med@...
 

I’m a Red Cross volunteer who wears two hats: Disaster Health Services as an RN and as our regional liaison to ARES and the amateur radio community. Our region consists of 24 northern Calif counties encompassing an area of widely varying terrain. As a disaster responder in a “served agency,” I’m offering the following as some insight into our local disaster comm problems that are similar to the comm problems that can exist nationally.

Nature of Red Cross Disaster Message Traffic

During “blue skies” (every day, non-disaster periods), Red Cross staff and volunteers – like everyone else – depend heavily on both dial-up and cellular telephone networks and on the Internet. This dependency spills over during “gray skies” during disaster responses with typical messages that includes but is not limited to:

·           Authoring disaster messages addressed to Red Cross staff between locations such as a shelter and a Division Operations Center or a Disaster Operations Center (DOC), a community service center and the DOC, etc.

·           Status reports (addressed daily to all staff and volunteers)

·           Incident Action Plans (IAPs) (addressed daily to all staff and volunteers)

·           Safety Messages (addressed daily to all staff and volunteers)

·           Logistics Requisitions (requesting from staff/location to Logistics Group at the DOC)

·           Requisitions for additional staff (requests from response entities, e.g., a shelter)

·           Client injury and death reports

·           Staff injury Reports

·           Disaster Health Services statistical data

·           Safe and Well registration

·           Emergency welfare inquiries

·           Unaccompanied minor and separated child reports

With a normally intact communications infrastructure in the area of a disaster, passing messages is without problem. However, as the readers of this thread already know, when a disaster occurs (wild-land fires, land slides, flooding, etc.), the telecom infrastructure is frequently impacted in the disaster hot and warm zones.

Therein lies the decisions for what message traffic must be passed from hour 0 through hour 96 of a disaster response or later if the telecom infrastructure becomes severely degraded. This period approximates the latency of a response for the Verizon ERT or AT&T’s equivalent arrive to re-establish telecom with their COWs and earth stations and/or Red Cross Disaster Services Technology (DST) sets up earth stations for telecom at the District Operations Center(s).

During the initial response period, Amateur Radio has the opportunity to “show its stuff.” But it can lack the necessary capability to handle anything more than short messages that can be easily handled over a voice circuit (e.g., “To the Shelter Manager: how many clients do you have?”). Singing to the choir here I know, using digital communications over radio circuits for messages of more than a few words (status reports, long logistics lists, etc.) becomes an imperative.

Part of The Communications Problem

Red Cross volunteers have varying levels of computer skills varying from casual use (e.g., email, web surfing, etc.) to experts as Disaster Service Technologists. Volunteers working at service sites (shelters, community outreach, etc.) have these skill levels and many in between. >And< they tend to resist learning “yet another computer program.”

And therein is the rub. I know that everyone on this Group is here because they know and love Winlink Exp (as a techie, I do to). BUT:

Hams responding to a disaster are >serving< an agency that needs some form of comm support. Wearing my ARC hat, in our region hams are our mail room. >We< initiate messages. >We< put them into an “envelope” with an address on it. During the early hours of a response, we look to the hams to move our envelope to our addressee – intact - as we have given it to them We don’t really care HOW they get the message to its destination. Move it via Winlink HF or VHF, legacy AX.25 packet, NBEMS, Chevy Net, Sneaker Net – we just don’t care! Just get it there.

Every time I have given a talk on our disaster messaging needs to a group of Hams, I have to work hard to keep the discussion from becoming one of which kind of transport mechanism and mode to use: HF, VHF, etc. etc. Notwithstanding the unique disasters that were Hurricane Irma/USVI and Hurricane Maria/Puerto Rico, it’s operative to know that our message traffic is most typically short and medium haul.

Nature of Our Traffic

We’ve identified nine types of messages as that cannot wait for any minimal telecom infrastructure restoration to pass during a telecom infrastructure outage (i.e., the 0-96 hours of a response):

·           Short messages of few words (passed over a voice circuit)

·           Moderately to lengthy general messages

·           Logistics requests

·           Unaccompanied minor reports

·           Safe and well (legacy as “Health and Welfare”) registration

·           Emergency welfare inquiry

·           Client incident / death

·           Staff Request(s)

·           Contact/Assignments Roster

Of necessity, the above messages all have agency-specific forms for each. Those of you who are familiar with the .xls Safe and Well worksheets that the ARC wanted passed from Puerto Rico are familiar with the demand for passing a template intact.

Generally understood is that voice / phone communications can be and are extremely useful and efficient for short messages. However, for traffic that is more than a few words or contains language that is profession-specific is at high risk for transcription error when passed from one message handler to another who is unfamiliar with the terminology.

And, thus are the strengths of digital modes, of which Winlink is becoming a de facto tool. It shines in being able to send a message directly to an addressee’s email in-box.

 Parochialism

Revisit what I mentioned above re resistance to learning “yet another computer program.” When looking for a tool for ARC volunteers that they could use to initiate messages, it was this resistance that stopped cold bringing in something like Winlink Express, Outpost, etc. At high risk of being heretical, there was just too damned much of a learning curve. It is too much to expect an ngo ‘civilian’ to learn something -- to them -- with a complex interface such as Winlink, or worse, fldigi. Because the templates within Winlink are proprietary, they are inflexible and necessitate the message initiator to work within Winlink to author the traffic. 

It is in this, from my small corner of the world, this is why I am critical of Winlink Express. It is an absolutely terrific tool for email with attachments over radio. It is abysmal for a civilian already burdened with numerous other software tools to learn. Regardless how good you believe you might be, the risk of transcribing the traffic from a message originator. [To anyone interested, I can offer a sample of how complex a nurse-to-nurse message. Further, long lists of medications and antibiotics were moved in Puerto Rico. Huge risk of transcription error even by an RN unless certain spelling protocols were observed.]

Our Regional Solution

With the help of W1HKJ, author of fldigi, we have flmsg with an “agency” (simple interface). It has only three options for messaging: New, Edit, and View. Pick “New” and the user selects an agency specific template that opens in a browser. If “Edit,” the user uses Windows Explorer to select and open an flmsg object file (a text file) that opens in a browser.  When done with creating a message, the user “Submits” the message which saves as an flmsg object file of typically less than 1.5kB. Handed off to the RADO, the RADO creates an email message with the flmsg file as an attachment and sends it. Done: message remains intact as the originator typed it and the RADO sends it without having to transcribe it. From my perspective, the RADO would use Winlink to send it directly to an addressee’s email address.

I welcome response and discussion as I am continually looking at ways for RADOs to improve the handling of our disaster traffic during that crucial 0-96 hour response period.

Re: Some Thoughts Re EmComm and Red Cross Message Traffic

Jeff Moore
 



On Wed, Mar 21, 2018 at 7:35 PM, <n6med@...> wrote:

I’m a Red Cross volunteer who wears two hats: Disaster Health Services as an RN and as our regional liaison to ARES and the amateur radio community. Our region consists of 24 northern Calif counties encompassing an area of widely varying terrain. As a disaster responder in a “served agency,” I’m offering the following as some insight into our local disaster comm problems that are similar to the comm problems that can exist nationally.

Nature of Red Cross Disaster Message Traffic

During “blue skies” (every day, non-disaster periods), Red Cross staff and volunteers – like everyone else – depend heavily on both dial-up and cellular telephone networks and on the Internet. This dependency spills over during “gray skies” during disaster responses with typical messages that includes but is not limited to:

·           Authoring disaster messages addressed to Red Cross staff between locations such as a shelter and a Division Operations Center or a Disaster Operations Center (DOC), a community service center and the DOC, etc.

·           Status reports (addressed daily to all staff and volunteers)

·           Incident Action Plans (IAPs) (addressed daily to all staff and volunteers)

·           Safety Messages (addressed daily to all staff and volunteers)

·           Logistics Requisitions (requesting from staff/location to Logistics Group at the DOC)

·           Requisitions for additional staff (requests from response entities, e.g., a shelter)

·           Client injury and death reports

·           Staff injury Reports

·           Disaster Health Services statistical data

·           Safe and Well registration

·           Emergency welfare inquiries

·           Unaccompanied minor and separated child reports

With a normally intact communications infrastructure in the area of a disaster, passing messages is without problem. However, as the readers of this thread already know, when a disaster occurs (wild-land fires, land slides, flooding, etc.), the telecom infrastructure is frequently impacted in the disaster hot and warm zones.

Therein lies the decisions for what message traffic must be passed from hour 0 through hour 96 of a disaster response or later if the telecom infrastructure becomes severely degraded. This period approximates the latency of a response for the Verizon ERT or AT&T’s equivalent arrive to re-establish telecom with their COWs and earth stations and/or Red Cross Disaster Services Technology (DST) sets up earth stations for telecom at the District Operations Center(s).

During the initial response period, Amateur Radio has the opportunity to “show its stuff.” But it can lack the necessary capability to handle anything more than short messages that can be easily handled over a voice circuit (e.g., “To the Shelter Manager: how many clients do you have?”). Singing to the choir here I know, using digital communications over radio circuits for messages of more than a few words (status reports, long logistics lists, etc.) becomes an imperative.

Part of The Communications Problem

Red Cross volunteers have varying levels of computer skills varying from casual use (e.g., email, web surfing, etc.) to experts as Disaster Service Technologists. Volunteers working at service sites (shelters, community outreach, etc.) have these skill levels and many in between. >And< they tend to resist learning “yet another computer program.”

And therein is the rub. I know that everyone on this Group is here because they know and love Winlink Exp (as a techie, I do to). BUT:

Hams responding to a disaster are >serving< an agency that needs some form of comm support. Wearing my ARC hat, in our region hams are our mail room. >We< initiate messages. >We< put them into an “envelope” with an address on it. During the early hours of a response, we look to the hams to move our envelope to our addressee – intact - as we have given it to them We don’t really care HOW they get the message to its destination. Move it via Winlink HF or VHF, legacy AX.25 packet, NBEMS, Chevy Net, Sneaker Net – we just don’t care! Just get it there.

Every time I have given a talk on our disaster messaging needs to a group of Hams, I have to work hard to keep the discussion from becoming one of which kind of transport mechanism and mode to use: HF, VHF, etc. etc. Notwithstanding the unique disasters that were Hurricane Irma/USVI and Hurricane Maria/Puerto Rico, it’s operative to know that our message traffic is most typically short and medium haul.

Nature of Our Traffic

We’ve identified nine types of messages as that cannot wait for any minimal telecom infrastructure restoration to pass during a telecom infrastructure outage (i.e., the 0-96 hours of a response):

·           Short messages of few words (passed over a voice circuit)

·           Moderately to lengthy general messages

·           Logistics requests

·           Unaccompanied minor reports

·           Safe and well (legacy as “Health and Welfare”) registration

·           Emergency welfare inquiry

·           Client incident / death

·           Staff Request(s)

·           Contact/Assignments Roster

Of necessity, the above messages all have agency-specific forms for each. Those of you who are familiar with the .xls Safe and Well worksheets that the ARC wanted passed from Puerto Rico are familiar with the demand for passing a template intact.

Generally understood is that voice / phone communications can be and are extremely useful and efficient for short messages. However, for traffic that is more than a few words or contains language that is profession-specific is at high risk for transcription error when passed from one message handler to another who is unfamiliar with the terminology.

And, thus are the strengths of digital modes, of which Winlink is becoming a de facto tool. It shines in being able to send a message directly to an addressee’s email in-box.

 Parochialism

Revisit what I mentioned above re resistance to learning “yet another computer program.” When looking for a tool for ARC volunteers that they could use to initiate messages, it was this resistance that stopped cold bringing in something like Winlink Express, Outpost, etc. At high risk of being heretical, there was just too damned much of a learning curve. It is too much to expect an ngo ‘civilian’ to learn something -- to them -- with a complex interface such as Winlink, or worse, fldigi. Because the templates within Winlink are proprietary, they are inflexible and necessitate the message initiator to work within Winlink to author the traffic. 

It is in this, from my small corner of the world, this is why I am critical of Winlink Express. It is an absolutely terrific tool for email with attachments over radio. It is abysmal for a civilian already burdened with numerous other software tools to learn. Regardless how good you believe you might be, the risk of transcribing the traffic from a message originator. [To anyone interested, I can offer a sample of how complex a nurse-to-nurse message. Further, long lists of medications and antibiotics were moved in Puerto Rico. Huge risk of transcription error even by an RN unless certain spelling protocols were observed.]

Our Regional Solution

With the help of W1HKJ, author of fldigi, we have flmsg with an “agency” (simple interface). It has only three options for messaging: New, Edit, and View. Pick “New” and the user selects an agency specific template that opens in a browser. If “Edit,” the user uses Windows Explorer to select and open an flmsg object file (a text file) that opens in a browser.  When done with creating a message, the user “Submits” the message which saves as an flmsg object file of typically less than 1.5kB. Handed off to the RADO, the RADO creates an email message with the flmsg file as an attachment and sends it. Done: message remains intact as the originator typed it and the RADO sends it without having to transcribe it. From my perspective, the RADO would use Winlink to send it directly to an addressee’s email address.

I welcome response and discussion as I am continually looking at ways for RADOs to improve the handling of our disaster traffic during that crucial 0-96 hour response period.


Re: Some Thoughts Re EmComm and Red Cross Message Traffic

Jeff Moore
 

If your emergency message initiators can do email, they can use winlink.  in most situations they don't need to!  You (or they) create the message, take it to or pass it to the comms center, it is handed to an operator who attaches it to an email and sends it on it's way.  What's so difficult about that?  The people initiating the messages are the ones responsible for content, spelling etc.

You're making it way more complicated than it needs to be!  As for TOOLS, software or otherwise, you use what you have to the best of your ability.  Ham radio volunteers should never initiate any messages, they should all be initiated by the appropriate person and passed to the radio room to be sent. Same with incoming messages, they should be saved, printed, and distributed as needed.

Jeff Moore  --  KE7ACY
Oregon

On Wed, Mar 21, 2018 at 7:35 PM, <n6med@...> wrote:

I’m a Red Cross volunteer who wears two hats: Disaster Health Services as an RN and as our regional liaison to ARES and the amateur radio community. Our region consists of 24 northern Calif counties encompassing an area of widely varying terrain. As a disaster responder in a “served agency,” I’m offering the following as some insight into our local disaster comm problems that are similar to the comm problems that can exist nationally.

Nature of Red Cross Disaster Message Traffic

During “blue skies” (every day, non-disaster periods), Red Cross staff and volunteers – like everyone else – depend heavily on both dial-up and cellular telephone networks and on the Internet. This dependency spills over during “gray skies” during disaster responses with typical messages that includes but is not limited to:

·           Authoring disaster messages addressed to Red Cross staff between locations such as a shelter and a Division Operations Center or a Disaster Operations Center (DOC), a community service center and the DOC, etc.

·           Status reports (addressed daily to all staff and volunteers)

·           Incident Action Plans (IAPs) (addressed daily to all staff and volunteers)

·           Safety Messages (addressed daily to all staff and volunteers)

·           Logistics Requisitions (requesting from staff/location to Logistics Group at the DOC)

·           Requisitions for additional staff (requests from response entities, e.g., a shelter)

·           Client injury and death reports

·           Staff injury Reports

·           Disaster Health Services statistical data

·           Safe and Well registration

·           Emergency welfare inquiries

·           Unaccompanied minor and separated child reports

With a normally intact communications infrastructure in the area of a disaster, passing messages is without problem. However, as the readers of this thread already know, when a disaster occurs (wild-land fires, land slides, flooding, etc.), the telecom infrastructure is frequently impacted in the disaster hot and warm zones.

Therein lies the decisions for what message traffic must be passed from hour 0 through hour 96 of a disaster response or later if the telecom infrastructure becomes severely degraded. This period approximates the latency of a response for the Verizon ERT or AT&T’s equivalent arrive to re-establish telecom with their COWs and earth stations and/or Red Cross Disaster Services Technology (DST) sets up earth stations for telecom at the District Operations Center(s).

During the initial response period, Amateur Radio has the opportunity to “show its stuff.” But it can lack the necessary capability to handle anything more than short messages that can be easily handled over a voice circuit (e.g., “To the Shelter Manager: how many clients do you have?”). Singing to the choir here I know, using digital communications over radio circuits for messages of more than a few words (status reports, long logistics lists, etc.) becomes an imperative.

Part of The Communications Problem

Red Cross volunteers have varying levels of computer skills varying from casual use (e.g., email, web surfing, etc.) to experts as Disaster Service Technologists. Volunteers working at service sites (shelters, community outreach, etc.) have these skill levels and many in between. >And< they tend to resist learning “yet another computer program.”

And therein is the rub. I know that everyone on this Group is here because they know and love Winlink Exp (as a techie, I do to). BUT:

Hams responding to a disaster are >serving< an agency that needs some form of comm support. Wearing my ARC hat, in our region hams are our mail room. >We< initiate messages. >We< put them into an “envelope” with an address on it. During the early hours of a response, we look to the hams to move our envelope to our addressee – intact - as we have given it to them We don’t really care HOW they get the message to its destination. Move it via Winlink HF or VHF, legacy AX.25 packet, NBEMS, Chevy Net, Sneaker Net – we just don’t care! Just get it there.

Every time I have given a talk on our disaster messaging needs to a group of Hams, I have to work hard to keep the discussion from becoming one of which kind of transport mechanism and mode to use: HF, VHF, etc. etc. Notwithstanding the unique disasters that were Hurricane Irma/USVI and Hurricane Maria/Puerto Rico, it’s operative to know that our message traffic is most typically short and medium haul.

Nature of Our Traffic

We’ve identified nine types of messages as that cannot wait for any minimal telecom infrastructure restoration to pass during a telecom infrastructure outage (i.e., the 0-96 hours of a response):

·           Short messages of few words (passed over a voice circuit)

·           Moderately to lengthy general messages

·           Logistics requests

·           Unaccompanied minor reports

·           Safe and well (legacy as “Health and Welfare”) registration

·           Emergency welfare inquiry

·           Client incident / death

·           Staff Request(s)

·           Contact/Assignments Roster

Of necessity, the above messages all have agency-specific forms for each. Those of you who are familiar with the .xls Safe and Well worksheets that the ARC wanted passed from Puerto Rico are familiar with the demand for passing a template intact.

Generally understood is that voice / phone communications can be and are extremely useful and efficient for short messages. However, for traffic that is more than a few words or contains language that is profession-specific is at high risk for transcription error when passed from one message handler to another who is unfamiliar with the terminology.

And, thus are the strengths of digital modes, of which Winlink is becoming a de facto tool. It shines in being able to send a message directly to an addressee’s email in-box.

 Parochialism

Revisit what I mentioned above re resistance to learning “yet another computer program.” When looking for a tool for ARC volunteers that they could use to initiate messages, it was this resistance that stopped cold bringing in something like Winlink Express, Outpost, etc. At high risk of being heretical, there was just too damned much of a learning curve. It is too much to expect an ngo ‘civilian’ to learn something -- to them -- with a complex interface such as Winlink, or worse, fldigi. Because the templates within Winlink are proprietary, they are inflexible and necessitate the message initiator to work within Winlink to author the traffic. 

It is in this, from my small corner of the world, this is why I am critical of Winlink Express. It is an absolutely terrific tool for email with attachments over radio. It is abysmal for a civilian already burdened with numerous other software tools to learn. Regardless how good you believe you might be, the risk of transcribing the traffic from a message originator. [To anyone interested, I can offer a sample of how complex a nurse-to-nurse message. Further, long lists of medications and antibiotics were moved in Puerto Rico. Huge risk of transcription error even by an RN unless certain spelling protocols were observed.]

Our Regional Solution

With the help of W1HKJ, author of fldigi, we have flmsg with an “agency” (simple interface). It has only three options for messaging: New, Edit, and View. Pick “New” and the user selects an agency specific template that opens in a browser. If “Edit,” the user uses Windows Explorer to select and open an flmsg object file (a text file) that opens in a browser.  When done with creating a message, the user “Submits” the message which saves as an flmsg object file of typically less than 1.5kB. Handed off to the RADO, the RADO creates an email message with the flmsg file as an attachment and sends it. Done: message remains intact as the originator typed it and the RADO sends it without having to transcribe it. From my perspective, the RADO would use Winlink to send it directly to an addressee’s email address.

I welcome response and discussion as I am continually looking at ways for RADOs to improve the handling of our disaster traffic during that crucial 0-96 hour response period.


Re: Some Thoughts Re EmComm and Red Cross Message Traffic

Larry Levesque
 

Since you indicate that you are using flmsg for most of your applications, do you have copies of the standard ARC forms that you use in html format for flmsg already?
If so, do you mind sharing them?
If not, send me the source documents and I can help convert them if you would like.



On Wed, Mar 21, 2018 at 07:35:34PM -0700, n6med@... wrote:
I’m a Red Cross volunteer who wears two hats: Disaster Health Services as an RN and as our regional liaison to ARES and the amateur radio community. Our region consists of 24 northern Calif counties encompassing an area of widely varying terrain. As a disaster responder in a “served agency,” I’m offering the following as some insight into our local disaster comm problems that are similar to the comm problems that can exist nationally.

Nature of Red Cross Disaster Message Traffic

During “blue skies” (every day, non-disaster periods), Red Cross staff and volunteers – like everyone else – depend heavily on both dial-up and cellular telephone networks and on the Internet. This dependency spills over during “gray skies” during disaster responses with t ypical messages that includes but is not limited to:
.........
snip


--
Larry Levesque
KA1VGM

Re: Some Thoughts Re EmComm and Red Cross Message Traffic

Dave Colter
 

Jeff,

The devil is in the details, as always. What you say makes sense until you try to put it into action. First, it adds more steps. A message file (hopefully a simple text file) must be created by the SA staff person, and then somehow transferred to the radio operator, who must then “import” it to his own laptop and prepare it to be sent.

 

Second, how do you transfer the message from creator to sender? On a network? (that requires a sharing software platform on the same network), with USB drives (if you have enough, and some agencies don’t allow their use, even to the point of shutting off USB ports for anything other than mouse use,) or do you plan to have them hand you a paper message that you’ll have to type into Winlink Express (or FLMSG), increasing the possibility of errors being introduced?

 

During an emergency, time and complexity are our enemies. We’ll be short-handed, so every second counts.  I like the idea of a simple agency-user message-creation interface – as long as it’s easy to connect with the radio operator’s laptop and software. In all things disaster related, simplicity is our friend.

 

The best solutions would be ones that work over a simple peer to peer network. Think a half-dozen laptops plugged into a simple 10/100 switch, all set up for file sharing. However, that’s not so easy to implement. Red Cross’ IT department locks down access to all network (and most other) settings, so you can’t change the NIC’s IP address, etc. Installation of new software requires the use of administrator privileges. The only workable solution (absent lots of cooperation from  ARC’s IT department – good luck!) is to provide all the required agency-input laptops with no administrator lockdowns. I know these things because I’m a vendor to the Red Cross and deal with the issues on a regular basis.

 

Most of us can’t afford to keep a pile of up-to-date laptops on hand (our club has four five year old Lenovos), but, two might be workable. Set up a peer to peer connection with full access to each other’s files enabled. One computer is the radio operator’s, the other is an agency staff message input device. They create the file, you fetch and send it.

 

One thing we’ve been successful with is using FLMSG to create message files, and then send them as Winlink attachments.  As long as the receiving station has FLMSG, it should be fairly quick and seamless. It sounds like from N6MED’s message that N1HKJ has already created the simple to use software for the agency input laptop, and probably some form of integration.

 

Dave WA1ZCN

ASEC - Training

NH-ARES

Re: Some Thoughts Re EmComm and Red Cross Message Traffic

Dennis Zabawa
 

Keeping in mind that the majority of message traffic is accomplished by voice, and should be initiated via an ICS-213 form, these are the forms and supporting documentation I have devised.  There is nothing to preclude this methodology from being used with WinLink or other forms of digital transmission.

NIMS ICS-213 Modified for ARES/RACES use - PDF Fillable Format

Instructions for filling out an ICS-213 Form modified for ARES use - PDF Forma

A graphic illustrating the flow of information while handling an ICS-213 Message Form - JPG Format

Re: Some Thoughts Re EmComm and Red Cross Message Traffic

n6med@...
 

On Wed, Mar 21, 2018 at 08:04 pm, Jeff Moore wrote:
KE7ACY
First of all, when analyzing our comm needs during that initial 0-96 hours, we looked at Winlink. When I introduced the idea to our volunteers I faced immediate push back: "What?!?! We have to learn yet another program?"

It is simplistic to suggest that if one can use email, one can use Winlink. Close but no cigar. We who use and love Winlink tend to be techie and it looks simple enough to us. However, it is not to the average Red Crosser. Your following comments in your first paragraph suggest that you might have missed what I posted. I think we are on the same page: the message initator creates the message and hands it off to the RADO.

We completely agree that a RADO should >never< initiate a message (with the qualification for an emergency that the RADO on-views (e.g., a fire breaks out or similar). Further, unless the a message is less that 25 words (an arbitrary number), the RADO should not transcribe a message at either the near end of the far end.

Further, we have not over complicated anything. Quite the opposite for these reasons:
-- The message initiator should not/ cannot be concerned with how the message traffic is moved to the addressee.

-- Using a utility in which the Red Crosser fills out official templates (in a browser) and saving the populated template to a >small< text file creates a message in a form that can then be handed to a RADO to transport anyway the RADO sees fit. (I like using Winlink because I can attach the file to an email message.) The RADO can use Winlink, one of the NMBEMS/fldigi modes/ legacy AX.25 packet, Chevy Net, Sneaker Net.

We look at the RADO as our mail room. "here's my envelope with my message in it. Send it to my addressee."

If you've not looked at it, I recommend downloading flmsg 4.0.3.4 or later together with the Red Cross custom templates from the fldigi download site. You'll find them both in a zip library and individually. Install flmsg to use its "simple" interface. It take me less than 10 minutes to train a Red Crosser to use it.

Re the Red Cross forms: from outside the Red Cross I have heard the argument in the context "why not just use plain text for the messages?" The Red Cross has and lives in a world of forms and templates. as a NIMS ERF ESF 6, we are following IC. During a disaster, our Director of Operation (aka IC) publishes a Incident Action Plan (IAP) that consists of several Red Cross specific ICS forms. we also have proprietary forms for the types of messages I bulleted in my original post. For a Level 3 or high disaster response, we have personnel coming in from all over the country. The forms are an absolute necessity. If the telecom infrastructure is still intact, our personnel retrieve the templates (fillable PDFs of .docx files), populate them and send them on as attachments via email if originating from a service site.So, if the telecom infrastructure is impacted, we start with the templates. If the Red Crosser doesn't have flmsg and the templates available n a flash drive or doesn't have a laptop, fall back would be, hopefully, to the RADO who always Semper Gumby, is fully equipped with the tools necessary to help move the traffic. Military calls it "graceful degradation.

What is of paramount importance to remember is, as RADOs reporting to help the Red Cross or any other served agency, one must remember who is the dog and who is the tail.

Re: Some Thoughts Re EmComm and Red Cross Message Traffic

n6med@...
 

On Thu, Mar 22, 2018 at 02:25 am, Larry Levesque wrote:
KA1VGM
Forms have been replicated from those in the Red Cross national repository (we call it the "Exchange." You must be a registered volunteer or paid staff to access.)

Go to the fldigi download web site (SourceForge?) and drill to the custom templates page. You should find a zip library and the individual templates available for download. Also download flmsg 4.0.3.x
Also, check your email for some sample populated templates I use for presentations and training.

Re: Some Thoughts Re EmComm and Red Cross Message Traffic

n6med@...
 

"... majority of message traffic ... voice..."  All depends. Maybe, maybe not. Bear in mind that this thread is re time 0-96 hours into a disaster response where the telecom infrastructure is impacted. Messages of 25 words or less >should < limited to a phone circuit, else would be best handled via a digital circuit.

When this project began over a year ago (and I presume would still be true), one can search for an ARES 213 and find >numerous< versions. As I mentioned in a previous post in this thread the Red Cross is a NIMS ERF ESF6 Mass Care. As such, the Red Cross has implemented the ICS disaster management model, albeit with some changes that tailor the ICS  to specific Red Cross needs. The Red Cross uses both ICS and proprietary forms templates. For the 0-96 hour response period as I described, we have created flmsg custom HTML templates that replicate those in our national library (the "Exchange").

Using the flmsg tool and templates simplifies message handling. The Red Crosser creates the message and saves it to a text flmsg object file and hands it off on a flash drive to the RADO who then forwards the message to the addressee provided by the message originator. We don't care >how< the RADO moves the traffic. That's up to him/her. Just get it there intact. In our ARC, our Red Crossers have (or will soon have as we fully deploy it) flmsg and templates on a flash drive. >Already tested<, flmsg runs fine on our laptops, despite the need for knowing the secret handshakes, passwords, and special incantations to install software ON the laptops.

When the message addressee receives an email with the message attached (presuming that the RADO used Winlink to forward it or the RADO at the far end (e.g., at the Division or Disaster Operations Center) copies the message to a flash drive and hands it to the addressee who then opens it using flmsg.

What we asks is that the RADOs who come to support us embrace Semper Gumby. Come equipped with a bit more than a Boafeng in one hand and two spare dead batteries clutched in the other. BTW: to all who are equipped to handle digital traffic: do you have a printer as part of your "kit?"

I'm going to attempt to post a couple of files that are samples of what real Red Cross message traffic could be, including a 213  that would be frm an RN in a shelter to the RN lead at the DOC. Note that the message field has >200 words in it.