toggle quoted messageShow quoted text
Interesting idea and I like the concept. Since this isn't
available today, I do have some alternative ideas for you.
For basic messaging, Fldigi's FSQ support can do most of what you
ask as it does have the ability to store and retrieve messages.
It only uses a the IFKP mode, has a unique user interface, and
doesn't use the power of the Flamp multicast transport but it does
work well. Digging a little deeper, you could use any packet
programs that have messaging store/forward capability with Fldigi
via Fldigi's KISS interface. This also wouldn't leverage the
Flamp multicast concept but it would give you a lot of powerful
options. The selection of the packet program would depend on the
OS you're running be it Windows, Linux, Mac, etc. Finally,
similar to Fldigi's FSQ functionality is the ARiM program with the
ARDOP v1 modem.
On 03/30/2019 06:26 AM, AD5XJ, KEN
The point I would like to re-emphasize is that the concept is
intended for smaller groups of connecting stations that do not
necessarily all have repeaters, Internet access, or
WinLINK access. This happens quite often in emergency
The concept is designed to allow NBEMS groups to still operate
over a wide area without the need of expensive external TNC
The NBEMS suite has that capability with FLDIGI / FLMSG / FLAMP
and a central connecting station with Internet access. The
"postoffice" station could act as a temporary message relay
station for all types of messages - not just Internet email. The
message formatting capability is already built in to FLMSG so
the receiver of the message is familiar with the format.
To do all this, added functionality has to exist to reduce the
effort needed in message handling with large volume. This could
be a separate module similar to FLAMP or part of FLAMP. It seems
logical to fit into FLAMP since some messages may be used to
broadcast, and others sent to specific stations who have
reported for this duty, or forwarded to an email address using
store and forward software methods.
I think the new feature would require routing tags in the
message so the "postoffice" would know what to do with it.
Also, to limit traffic and abuse, the "postoffice" should have a
registry of participating stations and only respond to those
stations for routing functions.
The suggestion has been made that this is like PACKET used to
be. That is true. But PACKET was for the most part VHF/UHF. To
get this type of functionality on HF currently HF PACKET exists
but very sparse. It leans more to widely separated nodes not
always available (not to mention it is slower than VHF/UHF).
I know this concept is sort of - been there done that - kind of
thing. The effort is to not only revive it but improve it for
use in very flexible situations using any available mode over
any available media path using NBEMS software only.