Re: FLAMP New feature idea - maybe

David Ranch

Hello Ken,

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 wrote:

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 situations.

The concept is designed to allow NBEMS groups to still operate over a wide area without the need of expensive external TNC equipment.

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.

Join to automatically receive all group messages.