Topics

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.

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

Dennis Zabawa
 

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

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.

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

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

 

Aaron Jones
 

has anyone played around with FSQ in FLDIG?  It has some options for directed messaging and "allcall" broadcast messaging, ironically I'd say "similar to JS8Call" but it's clear JS8 call modeled itself after FSQCall which was also integrated or functionally adopted into FLDIGI.  I'd love to see that FSQ op mode allow variations in OPmode but with the same "directed" and "non-directed" messaging.  Add in some integration to FLAMP or FLMSG and you are getting pretty close to some store and forward capabilities. 

Any thoughts along those lines since the previous posts in this thread?

AD5XJ, KEN
 

aaron

See my post from Mar 30.