Date   
Re: FLAMP New feature idea - maybe

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.

Re: FLAMP New feature idea - maybe

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           



                    
  




 

Re: WEFAX question

kd8ftr@...
 

Step 1 is calibration of the sound card. Use NIST signal and set fldigi to wwv let it run a while to verify a vertical line on the scope. 
Step 2 is adjusting the slant while receiving. This will compensate for the timing difference from processing. Once set your future receiptions will be correct



On Fri, Mar 29, 2019 at 2:35 PM, Mitch Smith
<m.smith64@...> wrote:
When I receive WEFAX images they are crooked. They have been this way
thorough many versions of fldigi going back several years.

Slant and align are both set to 0. If I change either it just makes the
images worse.

What am I doing wrong?

I'm attaching an example.

Thanks for any help you can offer.

--
Mitchell Smith
Chief Engineer
M/V Elizabeth Anne

--
Mitchell K Smith
Millstone Forge
5197 Millstone Rd
Monroeton, PA  18832
570-265-0673
KB3GKC





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.

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


Re: FLAMP New feature idea - maybe

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.

Yaesu FT-897D New In The Box

Dave
 

We do not usually post for sale items on this group, but Toney, K2MO, has a never used FT-897D for sale that would be a great buy for use on the digital modes.  The FT-897D is fully supported by fldigi and flrig.  I would snap this one up myself, but I already have more than one two three ... many rigs.

Dave

All:

I purchased a new unopened box Yaesu FT-897D from an estate sale. It came with the FP-30 A/C power supply and a Yaesu 300 Hz CW filter that was also unopened in the box. I tested the radio and it looks and functions like a new transceiver.

It's an all-mode HF, 50/144/430 MHz transceiver that comes with 60 meters and the TXCO from the factory. It can be used with internal batteries or the internal FP-30 A/C power supply that it came with.

I can provide pictures for those interested. My email address is: dxdx@...

Tony -K2MO

Re: FLAMP New feature idea - maybe

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           



                    
  




 

Re: WEFAX question

Mitch Smith
 

Thanks!
I think this is my problem. I'll let you know the results.

Mitch
kb3gkc

On 3/30/2019 11:38, kd8ftr via Groups.Io wrote:
Step 1 is calibration of the sound card. Use NIST signal and set fldigi to wwv let it run a while to verify a vertical line on the scope.
Step 2 is adjusting the slant while receiving. This will compensate for the timing difference from processing. Once set your future receiptions will be correct
<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
On Fri, Mar 29, 2019 at 2:35 PM, Mitch Smith
<msmith64@...> wrote:
When I receive WEFAX images they are crooked. They have been this way
thorough many versions of fldigi going back several years.
Slant and align are both set to 0. If I change either it just makes the
images worse.
What am I doing wrong?
I'm attaching an example.
Thanks for any help you can offer.
--
Mitchell Smith
Chief Engineer
M/V Elizabeth Anne
--
Mitchell K Smith
Millstone Forge
5197 Millstone Rd
Monroeton, PA  18832
570-265-0673
KB3GKC
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: WEFAX question [SOLVED]

Mitch Smith
 

Using Slant "While receiving" fixed my problem.
Thanks for the help!

Mitch
kb3gkc

On 3/31/2019 08:49, Mitch Smith wrote:
Thanks!
I think this is my problem. I'll let you know the results.
Mitch
kb3gkc
On 3/30/2019 11:38, kd8ftr via Groups.Io wrote:
Step 1 is calibration of the sound card. Use NIST signal and set fldigi to wwv let it run a while to verify a vertical line on the scope.
Step 2 is adjusting the slant while receiving. This will compensate for the timing difference from processing. Once set your future receiptions will be correct


<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>

    On Fri, Mar 29, 2019 at 2:35 PM, Mitch Smith
    <msmith64@...> wrote:
    When I receive WEFAX images they are crooked. They have been this way
    thorough many versions of fldigi going back several years.

    Slant and align are both set to 0. If I change either it just makes the
    images worse.

    What am I doing wrong?

    I'm attaching an example.

    Thanks for any help you can offer.

    --     Mitchell Smith
    Chief Engineer
    M/V Elizabeth Anne

    --
    Mitchell K Smith
    Millstone Forge
    5197 Millstone Rd
    Monroeton, PA  18832
    570-265-0673
    KB3GKC







<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>     Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: FLAMP New feature idea - maybe

Randy
 

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

Re: FLAMP New feature idea - maybe

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.

NBEMS New feature idea

Dave
 

Ken,

I'm nearly the completion on a round of code changes to several programs in the NBEMS suite.  When these are published I could be ready to consider the best way to add "drop box" capability to the NBEMS suite.  Would you please take the lead on formulating  a requirements document for me?  Several others including Steve, KB1TCE, and Frank, WQ1O, have shown an interest, but with some variation on your original proposal.

73, Dave, W1HKJ

Re: NBEMS New feature idea

Steve Hansen
 

Great news. Thanks Dave.

73, Steve KB1TCE

On 4/1/19 7:22 AM, Dave wrote:
Ken,

I'm nearly the completion on a round of code changes to several
programs in the NBEMS suite.  When these are published I could be
ready to consider the best way to add "drop box" capability to the
NBEMS suite.  Would you please take the lead on formulating  a
requirements document for me?  Several others including Steve, KB1TCE,
and Frank, WQ1O, have shown an interest, but with some variation on
your original proposal.

73, Dave, W1HKJ


Re: NBEMS New feature idea

AD5XJ, KEN
 

Yes, great news Dave. I would be more than happy to do that. I can draw up a conceptual diagram and prospective GUI if you wish as well. Let me know if there is anything else I can do to help. You can email me direct if that is faster.

Re: FLAMP New feature idea - maybe

Randy
 

Comparison of HRD/DM780 to a combination of EasyTerm and Soundmodem is incorrect thinking.  EasyTerm has KISS interface and ability to transmit using FLDIGI.  See this link: https://www.qsl.net/nf4rc/EasyTermTutorial.pdf  It currently does not support ax25 with FLDIGI however.

 

UZ7HO Soundmodem is a soundcard TNC to operate packet radio with the same hardware setup you have for NBEMS.  As noted here: https://www.soundcardpacket.org/5modes.aspx

      Another option for HF packet is the UZ7HO modem (free)…... 

 

I have not personally tried HF packet but this program combination does work on VHF and using these programs you do have error correction.  

 

I don’t discourage adding to NBEMS but you can try sound card packet radio operations with your current hardware and work from there without reinventing the entire wheel.

 

Randy

KJ0RE

http://mit.midco.net/rpratt

 

-----Original Message-----
From: nbems@groups.io [mailto:nbems@groups.io] On Behalf Of AD5XJ, KEN
Sent: Monday, April 01, 2019 6:09 AM
To: nbems@groups.io
Subject: Re: [nbems] FLAMP New feature idea - maybe

 

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.

Re: FLAMP New feature idea - maybe

AD5XJ, KEN
 

Randy thanks for your comment. But I think you miss the point (forgive me if that sounds rude, not my intention).  

If you read through this thread, you will find that the consistent theme is to make this "postoffice" idea an integral part of NBEMS. THAT is the point of this idea.

While other products and combination of products may do something similar, we have put forth a notion that NBEMS should not be dependent on any other software outside the NBEMS suite. That is on purpose.

Where NBEMS is used in emergency situations (notice the name - Narrow Band EMERGENCY messaging software), there is no guarantee of media availability or number of relay stations. There may be no access to VHF/UHF repeaters, or WinLINK RMS stations that are reliable, or band conditions that support high speed digital traffic, or even Internet access. That media may have to come from non-affected areas at another location or on a different band entirely.

We contend that if we are to make an add-in product for use by NBEMS, it should be fully integrated with and non-dependent on anything other than FLDIGI/FLAMP/FLMSG/FLARQ (NBEMS).

Re: FLAMP New feature idea - maybe

Dennis Zabawa
 

So maybe make it an adjunct program called "FLMAIL"?

Re: FLAMP New feature idea - maybe

AD5XJ, KEN
 

Actually, this project is designed to be more than mail in the traditional email sense of the word. The project should be able to create and deliver any of the many FLMSG forms to anyone. Whether that is in the form of Internet Email or just a ICS-213 message matters little. This IS radio so the send should always keep in mind how long it will take to send a message. This project will not embrace the idea of creating messages with attachments.

Re: FLAMP New feature idea - maybe

Bob Cameron
 

I'd suggest a small change that would generally help NBEMS usage even though I am not involved in any.

FLAMP is a broadcast mode system that relies on repeats to fill missing blocks. Last time I used it, block resends could be requested, but only with operator intervention. I suggest that a semi-automatic function be added so that (multiple) receiving stations can only re-request what they need and the transmitting station have a method to gather multiple requests (a timeout) for the next TX run.

Changing modem speed "requests" with RsID would also help. FLAMP already has a multimodem option that could be expanded for this. RX snr could be used.

Some more specific setup documentation would also be needed. PSM/persist/slot and limiting RsID mode change would make channel utilisation better.

In the end a 2 station link would be able to do transfers at the channel optimum. Star or haphazard networks would have less network overhead. If the RX station is not setup to TX then multiple block transmissions would still work. An RX with a very noisy environment could "request" a rebroadcast at a very low rate as needed.

Cheers Bob VK2YQA

Re: FLAMP New feature idea - maybe

Randy
 

Hi Ken,

 

I understand exactly.  Routing to simplex stations where all can not hear all others in addition to networks that already work.  The proposal will require some routing, some store and forward, and error corrections.  Essentially what a TNC and packet provide.  The auto-routing will require something running on a master node or more broadly a mesh if that can be achieved.  That portion of NBEMS is what you want.  My suggestion was only that the concept is available. NBEMS is already 4 programs that work together.   I simply pointed out some other programs that can provide an initial capability.  Simply adding a terminal capability to send packet from fldigi and adding soundmodem as a 5th package could be the easy answer.

 

Sent from Mail for Windows 10

 

From: AD5XJ, KEN
Sent: Wednesday, April 3, 2019 7:19 AM
To: nbems@groups.io
Subject: Re: [nbems] FLAMP New feature idea - maybe

 

Randy thanks for your comment. But I think you miss the point (forgive me if that he rude, not my intention).  

If you read through this thread, you will find that the consistent theme is to make this "postoffice" idea an integral part of NBEMS. THAT is the point of this idea.

While other products and combination of products may do something similar, we have put forth a notion that NBEMS should not be dependent on any other software outside the NBEMS suite. That is on purpose.

Where NBEMS is used in emergency situations (notice the name - Narrow Band EMERGENCY messaging software), there is no guarantee of media availability or number of relay stations. There may be no access to VHF/UHF repeaters, or WinLINK RMS stations that are reliable, or band conditions that support high speed digital traffic, or even Internet access. That media may have to come from non-affected areas at another location or on a different band entirely.

We contend that if we are to make an add-in product for use by NBEMS, it should be fully integrated with and non-dependent on anything other than FLDIGI/FLAMP/FLMSG/FLARQ (NBEMS).