Echolink Client Remains in Receive Mode

Hello All,

We’re into our baby steps mode of using ASL on our club repeater. We have used a remote Echolink node (transceiver, computer, Echolink software) to connect via RF with that repeater for some time with good results. We have now implemented an ASL node on the repeater, BUT have not yet enabled Echolink on it, so the remote Echolink connection/link remains in place and is active…just haven’t gotten to the point of configuring the ASL node to do Echolink yet.

We have confirmed reports that users are experiencing problems with Echolink client software (iPhone, etc.) in which the client software remains in receive mode after their initial key-up. Is this caused by some interaction of the ASL node and the remote Echolink radio-based link? For now, we’ve disabled the remote, radio-based Echolink connection pending a better understanding of this situation.

I’m just not sure of what we’re dealing with here, so your suggestions and guidance would be appreciated. Thank you.

when you go to echolink on ASL you need to apply for a -R for your repeater for it’s own node number then you edit the echolink.conf file in the /etc/asterisk directory and place the information in for it to work.

ASL itself will not interfere with your echolink since it is not configured and I assume your remote node is not on the same network as your ASL is.

Are you running the latest version of echolink on your remote node?

Kinda a mixed bag of complaints…

know a couple of things here.
It is mandatory that all echolink connections are ‘full duplex’
And if you are on a iphone app and tx, you will be able to hear at the same time if something is TX’d.
So, if this is what you are seeing, it is somewhat normal for that app on that phone.
There is nothing wrong with your config.
I guess the problem is it is the only full duplex app showing the full duplex audio when in TX…
I do know my android app is half dulplex only. But my iPhone app is full duplex on all 5 of my iphones.

iPhones in particular I don’t think are about to port using the 5198/5199 UDP - TX and RX
It needs the TCP 5200.

But so goes their full duplex in their own android app. While the connection may be FDX the app is not.
The iphone app is, but only while in TX.

Take some time to work with it and I’m sure you will see what I mean.

Thanks to all that have replied.

Echolink functionality has NOT been enabled on the ASL node at the repeater site, though I have read and looked at the files that require adjustment to enable it to work. I assume that regardless of version of ASL/HamVoIP, the same is true, i.e., no Echolink configuration, no effect upon the existing Echolink Remote node (RF).

I’ll contact those that have reported the problem of it staying in receive mode to determine how and what app/platform they’re using to see if I can shed more light on this.

Thanks to everyone again.