1. nbems@groups.io
Topics

FLAMP New feature idea - maybe

AD5XJ, KEN
 

From time to time it would be nice to have the ability to put FLAMP into what I call "postoffice mode".
It would operate something like this:
    A single station would be the "postmaster" with FLAMP in this mode. It may operate attended or unattended.
    Any station with a need to send messages to the "postmaster" for all stations or to a single station can put their FLAMP in the same mode and indicate if the destination is another
    station or for "postmaster" to broadcast to all stations.
    FLAMP in "postmaster" mode would save the message sent in a special folder and periodically check for messages.
    If messages are in the send-all folder, they should be broadcast at the pre-configured interval until removed. If any in the send-one folder then sent to the recipient when that
    station is acknowledged or forwarded to destination if Internet bound.
   The prerequisite is that all stations would have to be on the version of FLAMP that supports it and know to put FLAMP in "postal" mode to function that way and a "postmaster"
   would need Internet access to be most effective.

The justification for this feature is to allow ad-hoc operation of a group of stations that can pass messages peer-to-peer in any mode of choosing and provide localized message store and forward over the wide area where WinLINK or PACKET is not accessible. This is sort of like PSKMail but within the FLDIGI/NBEMS software suite and in a limited user group.

There are a number of conceptual questions yet to be answered but I think this could be useful to groups like ARES and SATERN. I think it is worthy of discussion within this group. Or you can email me directly with questions.

  
Al Massaro
 

Conceptually similar to D-RATS messages. Just Sayin.
AL M
KF5SMH
AD5XJ, KEN
 

You are not always near a D-Rats repeater nor do you always have 2-meters in the network of stations.
Al Massaro
 

Conceptually, in function is all I was alluding to, mailbox, direct messaging, delayed receipt.
Although D-RATS will send via FLDIGI, and has the internet connection you stated as the default connection. 
AL M
KF5SMH
Don Poaps
 

I don’t know how JS8CALL has done it but it has the ability to store a message for someone to pick up at a later day.

Been talking about its use in Emergency with the fldigi suite of programs. 

73

Don va7dgp/va7qu


On Wed, Mar 20, 2019 at 08:53 AD5XJ, KEN <ad5xj@...> wrote:
From time to time it would be nice to have the ability to put FLAMP into what I call "postoffice mode".
It would operate something like this:
    A single station would be the "postmaster" with FLAMP in this mode. It may operate attended or unattended.
    Any station with a need to send messages to the "postmaster" for all stations or to a single station can put their FLAMP in the same mode and indicate if the destination is another
    station or for "postmaster" to broadcast to all stations.
    FLAMP in "postmaster" mode would save the message sent in a special folder and periodically check for messages.
    If messages are in the send-all folder, they should be broadcast at the pre-configured interval until removed. If any in the send-one folder then sent to the recipient when that
    station is acknowledged or forwarded to destination if Internet bound.
   The prerequisite is that all stations would have to be on the version of FLAMP that supports it and know to put FLAMP in "postal" mode to function that way and a "postmaster"
   would need Internet access to be most effective.

The justification for this feature is to allow ad-hoc operation of a group of stations that can pass messages peer-to-peer in any mode of choosing and provide localized message store and forward over the wide area where WinLINK or PACKET is not accessible. This is sort of like PSKMail but within the FLDIGI/NBEMS software suite and in a limited user group.

There are a number of conceptual questions yet to be answered but I think this could be useful to groups like ARES and SATERN. I think it is worthy of discussion within this group. Or you can email me directly with questions.

  

Steve Hansen
 

One thought that I've had would be to be able to set up flamp to respond to DTMF. A message gets placed flamp and then other stations can retrieve the message by using a fldigi DTMF macro. That then triggers the station holding the message to transmit it. Unlike ARQ store/forward this would permit multiple parties to receive the message at the same time.

This is a similar process by which simplex repeaters can accept and then relay messages. With my Argent simplex repeater I can store a message using flmsg or flamp and then another station can retrieve it with the appropriate DTMF command. Generally this would be done on VHF using the DTMF buttons on the mic.

73, Steve KB1TCE


  

kd8ftr@...
 

Kind of similar to the old packet BBS? A store and forward system, I know at least one of the BBS software has integrated with the ability to receive other modes via fldigi in a fashion close to what you're referring to


On Wed, Mar 20, 2019 at 12:19 PM, Don Poaps
<va7dgp@...> wrote:
I don’t know how JS8CALL has done it but it has the ability to store a message for someone to pick up at a later day.

Been talking about its use in Emergency with the fldigi suite of programs. 

73

Don va7dgp/va7qu


On Wed, Mar 20, 2019 at 08:53 AD5XJ, KEN <ad5xj@...> wrote:
From time to time it would be nice to have the ability to put FLAMP into what I call "postoffice mode".
It would operate something like this:
    A single station would be the "postmaster" with FLAMP in this mode. It may operate attended or unattended.
    Any station with a need to send messages to the "postmaster" for all stations or to a single station can put their FLAMP in the same mode and indicate if the destination is another
    station or for "postmaster" to broadcast to all stations.
    FLAMP in "postmaster" mode would save the message sent in a special folder and periodically check for messages.
    If messages are in the send-all folder, they should be broadcast at the pre-configured interval until removed. If any in the send-one folder then sent to the recipient when that
    station is acknowledged or forwarded to destination if Internet bound.
   The prerequisite is that all stations would have to be on the version of FLAMP that supports it and know to put FLAMP in "postal" mode to function that way and a "postmaster"
   would need Internet access to be most effective.

The justification for this feature is to allow ad-hoc operation of a group of stations that can pass messages peer-to-peer in any mode of choosing and provide localized message store and forward over the wide area where WinLINK or PACKET is not accessible. This is sort of like PSKMail but within the FLDIGI/NBEMS software suite and in a limited user group.

There are a number of conceptual questions yet to be answered but I think this could be useful to groups like ARES and SATERN. I think it is worthy of discussion within this group. Or you can email me directly with questions.

  

AD5XJ, KEN
 

Yes you are right about the flavor of it.I would be interested in the software you mention. If you can leave the name I will explore.
Don Poaps
 

BPQ32 can use fldigi. There a couple of stations that were using it a few years ago when I was running BPQ32 

73

Don va7dgp 

On Wed, Mar 20, 2019 at 09:58 AD5XJ, KEN <ad5xj@...> wrote:
Yes you are right about the flavor of it.I would be interested in the software you mention. If you can leave the name I will explore.

--
Don Poaps
New Westminster, BC
VA7DGP DATA
VA7QU   VOICE


Winlink: va7qu@...
Subject://wl2k           



                    
  




 
AD5XJ, KEN
 

BPQ32 is only on Windows. LinBPQ does work woth FLDIGI but would have to use ARIM or something for messages and still would not fill out the conceptual functions needed.
Don Poaps
 

Like Linbpq and BPQ32 will do the same thing. They use fldigi as an engine similar to what n1mm uses

The only difference of the two os is comport and /dev/ttyUSB0?

If I remember you could use fldigi to connect c callsign-7 to the 40 m using bpq 

Later

Don

On Fri, Mar 22, 2019 at 08:39 AD5XJ, KEN <ad5xj@...> wrote:
BPQ32 is only on Windows. LinBPQ does work woth FLDIGI but would have to use ARIM or something for messages and still would not fill out the conceptual functions needed.

--
Don Poaps
New Westminster, BC
VA7DGP DATA
VA7QU   VOICE


Winlink: va7qu@...
Subject://wl2k           



                    
  




 
AD5XJ, KEN
 

Yes functionally, BPQ32 and LinBPQ are both data directors.

The problem is what to do with the data (a message) after FLDIGI decodes and passes it to BPQ32. For mail that could be AirMail or ARIM for LinBPQ. But if you review my original post the purpose exceeds those simple functionality of most mail clients.

Additionally, the idea is to be self-contained so that there is no internal reliance on Internet mail or WinLINK. My initial concept was to use FLAMP to decode the message error free, get the "postoffice" token and perform the sort and store functions for "mail" or other type messages.

In WinLINK-Like terms, this is sort of like RMS Relay. Except it uses FLDIGI as the modem and not WinMOR or ARDOP. The Internet could be used for a email destination, but not for broadcast to the group and not for another ham on that frequency, possibly a group member.

Remember not all messages are email. Some may be reports (like ICDS-213or 214) or plaintext messages of any type destined for another station nearby.
Don Poaps
 

You create bulletin when you send a message to Linbpq. SB ad5xj-7

All who call connect to ad5xj-7 can either do RMS, or BBS where the bulletin is. I know you want to broadcast to reception centres. Here the reception Center uses tnc to log into Vancover va7eoc-11 where the radio Room is. The radio guys log into the bbs using network computer they post bulletin. Using fldigi could be done the same way. 

Later

73

Don


On Fri, Mar 22, 2019 at 10:39 AD5XJ, KEN <ad5xj@...> wrote:

Yes functionally, BPQ32 and LinBPQ are both data directors.

The problem is what to do with the data (a message) after FLDIGI decodes and passes it to BPQ32. For mail that could be AirMail or ARIM for LinBPQ. But if you review my original post the purpose exceeds those simple functionality of most mail clients.

Additionally, the idea is to be self-contained so that there is no internal reliance on Internet mail or WinLINK. My initial concept was to use FLAMP to decode the message error free, get the "postoffice" token and perform the sort and store functions for "mail" or other type messages.

In WinLINK-Like terms, this is sort of like RMS Relay. Except it uses FLDIGI as the modem and not WinMOR or ARDOP. The Internet could be used for a email destination, but not for broadcast to the group and not for another ham on that frequency, possibly a group member.

Remember not all messages are email. Some may be reports (like ICDS-213or 214) or plaintext messages of any type destined for another station nearby.

--
Don Poaps
New Westminster, BC
VA7DGP DATA
VA7QU   VOICE


Winlink: va7qu@...
Subject://wl2k           



                    
  




 
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 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.
Don Poaps
 

Ken

I have had my 3 windows pc disabled by windows up dates. Mic privacy on but no audio even when I’ve switched Signalink and cables. Looks like I have to learn how to load load fldigi and the suites into my Pi and get back on the air. 
Locally our incident commander showed an interest in sending a copy of the declaration of emergency to the reception Center. We use Winlink to communicate to our provincial and local EOC. 
May 12 there a massive Earthquake Exercise in the city of Vancouver BC and the Salvation Army is having a tabletop exercise as well. I heard that for an hour in the city  event there will be no phones. 

If I get a chance I’ll try use fldigi from our EOC in Abbotsford depending on how busy I get

Later

Don va7dgp 

On Sat, Mar 30, 2019 at 06:26 AD5XJ, KEN <ad5xj@...> 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.

--
Don Poaps
New Westminster, BC
VA7DGP DATA
VA7QU   VOICE


Winlink: va7qu@...
Subject://wl2k           



                    
  




 
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.

--David
KI6ZHD



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.
AD5XJ, KEN
 

Modes like FSQ and IFKP are fun and work great.
However, they are of little practical use in the concept discussed here. We need to leverage the fastest and most reliable mode FLDIGI can provide for conditions in order to handle high traffic situations. This is often the case in a disaster where there is a lot of ICS or H&W traffic that needs to be moved. Support organizations like The Salvation Army, or Red Cross may want to use this concept to move H&W messages out of the area quickly to a remote station that is online.

Once again the concept is to make NBEMS less reliant on other software and media and to leverage the strong aspects of FLAMP. Since NBEMS is available on almost all platforms including Raspberry Pi (Raspian) it is also economically more desirable than SCS modes or hardware TNC equipment.

ARIM is a good messaging program and works well on the Linux platform with LinBPQ but is not part of NBEMS and requires a modem like ARDOP or direwolf. The goal is to make a good fit in NBEMS and be independent of other software.
Ole Helgerson KI7MBR
 

Hi Don and greetings to all from the Evergreen state to the south. Commiserating re windows 10 tanking in an upgrade, needing now to reinstall Fldigi and winlink. If of use, the 12 yr old Lenovo laptop, former xp now Linux mint 18.1, keeps plugging along and seems quite happy with Fldigi, Flmsg et al, communicating ok in tests across the house between the ht and the base station using MT63 2000 LG via simple audio connection.

Re csz earthquake, that's one of the big concerns locally. Been giving a talk on it to whomever will listen. Interesting to know winlink use in BC. Here winlink seems  used along similar lines, with an Ares exercise today accordingly. In my limited experience Fldigi is simpler to learn.  Appreciate knowing about May 12 exercise. Long time friends in Coquitlam. 

The node system described sounds very interesting, though I am still way down low on the learning curve.

Hope this is useful.
73 KI7MBR, Ole, Carson WA


On Sat, Mar 30, 2019, 7:09 AM Don Poaps <va7dgp@...> wrote:
Ken

I have had my 3 windows pc disabled by windows up dates. Mic privacy on but no audio even when I’ve switched Signalink and cables. Looks like I have to learn how to load load fldigi and the suites into my Pi and get back on the air. 
Locally our incident commander showed an interest in sending a copy of the declaration of emergency to the reception Center. We use Winlink to communicate to our provincial and local EOC. 
May 12 there a massive Earthquake Exercise in the city of Vancouver BC and the Salvation Army is having a tabletop exercise as well. I heard that for an hour in the city  event there will be no phones. 

If I get a chance I’ll try use fldigi from our EOC in Abbotsford depending on how busy I get

Later

Don va7dgp 

On Sat, Mar 30, 2019 at 06:26 AD5XJ, KEN <ad5xj@...> 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.

--
Don Poaps
New Westminster, BC
VA7DGP DATA
VA7QU   VOICE


Winlink: va7qu@...
Subject://wl2k           



                    
  




 
Randy
 

Check this> https://groups.io/g/pactor/topic/uz7ho_soundmodem_and_easyterm/28974385?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,28974385

 

 

Randy

KJ0RE

http://mit.midco.net/rpratt

 

-----Original Message-----
From: nbems@groups.io [mailto:nbems@groups.io] On Behalf Of AD5XJ, KEN
Sent: Saturday, March 30, 2019 8:27 AM
To: nbems@groups.io
Subject: Re: [nbems] FLAMP New feature idea - maybe

 

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.
AD5XJ, KEN
 

Randy thanks for your update.

Bear in mind we are talking about NBEMS alone. Enhancements to it. Or additions that make these functions work with NBEMS. It is like saying that HRD/DM780 are the same as NBEMS. Not if you want error free messages. That is why we use FLDIGI/FLMSG/FLAMP (i.e. NBEMS).
Any message handled should be received/sent error free in an emergency situation as fast as conditions will allow.
Previous Topic Next Topic