Date   
FLAmp on VHF through linked repeaters

Bart N5BLP
 

I participate in a digi net that works VHF on a linked repeater system with four repeaters.  They mostly do FLMsg traffic, but I've tried to send FLAmp traffic on it.

It just doesn't seem to work as well as it does on HF (which, of course, is simplex). For a nice, clean signal environment it drops a lot of blocks.  Some operators eventually get it completed when I retransmit the missing blocks, and others don't. 

We've done everything we can to cope with the repeater environment.  We've enable TX/RX interval so the repeaters don't time out, use a 2.5 second pre-signal tone on the RSID, and have the SignaLink delay set to about 60%. 

FLMsg works pretty well (although sometimes parts of it get scrambled), but FLAmp just doesn't seem to.  Is there something about the way FLAmp does it's error checking that isn't compatible with a linked repeater environment?  Has anyone else ever tried it over linked repeaters?

Bart N5BLP

Re: Problem with FLDIGI Input.

Dave
 

What version and on what operating system ?

David

On 4/7/19 5:20 AM, Edward Feustel, N5EI wrote:
I have configured my FLDIGI to notify on receipt of a txid indicator
message.
It has worked properly for multiple versions, but no longer works as
previously.
Now it locks up input to FLDIGI until I close the notification or go to
the frequency in the mode indicated.
That is, I cannot enter text, run macros, etc. What do I need to do to
fix the situation?

73,
Ed, N5EI

Problem with FLDIGI Input.

Edward Feustel, N5EI
 

I have configured my FLDIGI to notify on receipt of a txid indicator
message.
It has worked properly for multiple versions, but no longer works as
previously.
Now it locks up input to FLDIGI until I close the notification or go to
the frequency in the mode indicated.
That is, I cannot enter text, run macros, etc. What do I need to do to
fix the situation?

73,
Ed, N5EI

--

Zen Calendar for 2019/03/19

I have just three things to teach: simplicity,
patience, compassion. These three are your
greatest treasures.

Lao-Tzu

Re: Oops - sorry

David Ranch
 


Hello Ralph,

Ok, and are you still seeing the same issue?

--David
KI6ZHD


On 04/06/2019 01:23 PM, Ralph Alden Brigham wrote:
	David,

	My system is now configured in the same way under NBEMS - my bad!

Oops - sorry

Ralph Alden Brigham
 

David,

My system is now configured in the same way under NBEMS - my bad!

-- ***** ---
Ralph Brigham KG4CSQ -- EM64RQ2OOQ
W5YI VE 33080; ARRL VE
ARRL #1000033463
ARES/RACES SKYWARN
(931) 906-9277
-- ****

Re: Problem with FLdigi & FLmsg

David Ranch
 


Hello Ralph,

Ok, thanks for the versions but if you want our full help, you need to answer our full question.  We need to know how Fldigi is configured as well.

--David
KI6ZHD


On 04/06/2019 01:06 PM, Ralph Alden Brigham wrote:
	Hello All,

	Thanks for the response.

	Win10   64bit
	FLdigi  -  4.1.0.1
	FLmsg  -  4.0.8


	-- ***** ---
Ralph Brigham KG4CSQ -- EM64RQ2OOQ
W5YI VE  33080;  ARRL VE
ARRL #1000033463
ARES/RACES SKYWARN
(931) 906-9277
-- ****





Re: Problem with FLdigi & FLmsg

Ralph Alden Brigham
 

Hello All,

Thanks for the response.

Win10 64bit
FLdigi - 4.1.0.1
FLmsg - 4.0.8


-- ***** ---
Ralph Brigham KG4CSQ -- EM64RQ2OOQ
W5YI VE 33080; ARRL VE
ARRL #1000033463
ARES/RACES SKYWARN
(931) 906-9277
-- ****

Re: Problem with FLdigi & FLmsg

David Ranch
 


Hello Ralph,

You need to give more details:

   - What OS and version are you running?

   - What versions of Fldigi, Flmsg, etc?  Be sure to be running the current version if possible.

   - IN Fldigi: Configuration --> Misc --> NBEMS, what do you have set here?  I have:
     - NBEMS data file interface: enabled
     - Open message foler: disabled
     - Transfer direct to executing flmsg: enabled
     - open with flmsg: enabled
     - open is browser: disabled

--David
KI6ZHD


On 04/06/2019 10:57 AM, Ralph Alden Brigham wrote:
	Hello All,

	I have been having a problem with my FLdigi suite.

	Whenever I get a message via FLmsg, I have the following situation:

	After I get the pop-up,  I find and see two sessions of FLmsg running and 
also starts printing an .xml file into the receive block and transmitting a 
signal without my action.  Is there some auto-send mode active that I am not 
aware of?  I have to manually stop the transmission.  I have an ICOM 7100.

	This is my third or fourth attempt to get help from the group.  Assistance is 
greatly desired and appreciated!

-- ***** ---
Ralph Brigham KG4CSQ -- EM64RQ2OOQ
W5YI VE  33080;  ARRL VE
ARRL #1000033463
ARES/RACES SKYWARN
(931) 906-9277
-- ****

Problem with FLdigi & FLmsg

Ralph Alden Brigham
 

Hello All,

I have been having a problem with my FLdigi suite.

Whenever I get a message via FLmsg, I have the following situation:

After I get the pop-up, I find and see two sessions of FLmsg running and
also starts printing an .xml file into the receive block and transmitting a
signal without my action. Is there some auto-send mode active that I am not
aware of? I have to manually stop the transmission. I have an ICOM 7100.

This is my third or fourth attempt to get help from the group. Assistance is
greatly desired and appreciated!

-- ***** ---
Ralph Brigham KG4CSQ -- EM64RQ2OOQ
W5YI VE 33080; ARRL VE
ARRL #1000033463
ARES/RACES SKYWARN
(931) 906-9277
-- ****

Re: Mode sync between FLDigi, FLMsg, and FLAmp

Dave
 

noted

On 4/6/19 10:42 AM, bartpearl via Groups.Io wrote:
I have my software configured so that FLMsg and FLAmp sync modems with FLDigi.   I do not have FLAmp set up to change mode on transmit, or for FLDigi to auto sync it's mode to FLAmp.  In other words, i only want the mode selected in one place to avoid mode mismatches.

I've noticed that if I manually change modes in FLDigi, the other two programs follow as expected.  However, if FLDigi auto-changes the mode based on the RSID, the other two programs do not.

1.  Is this normal?
2.  Any chance of an update so the other two follow FLDigi even when the mode is auto-switched?

Bart N5BLP

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

 

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

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

Dennis Zabawa
 

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

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

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


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