[arm-allstar] Echolink and Asterisk issues
Doug Crompton
wa3dsp at gmail.com
Fri Mar 2 09:20:28 EST 2018
Mark,
I do not understand the rxondelay you have set. Setting rxondelay is
almost never needed. If you have a rekey situation on carrier drop you need
to find out where it is coming from. You did not describe your connection
map so I have no idea if this is coming from your nodes or someone else.
You can certainly determine this by observing the node number that is
pinging back when you unkey. If it is not your problem then you need to
resolve it with that offending node or restrict their connection to your
node. Setting rxondelay to some high value is not the answer. This would
cut off the beginning of others transmissions.
Ping pong'ing often happens when another node has an RF issue causing their
own rig to repeatedly key their node. We have seen this in Baofeng node
radio modifications where the RF is not separated from the radio by using a
dummy load or remote antenna. It can also be caused by connecting a simplex
node to a repeater. This sets up the ideal ping-pong. The repeater keys
then the node courtesy tone keys and that goes on forever. The answer is to
turn off the courtesy tone response on the simplex node. You do not want
anything automatically keying back to a repeater.
So I think if you identify the problem you can eliminate or greatly reduce
the rxondelay.
We will be looking into the other issues you mentioned as there seems to be
a relationship between them. The problem with issues like this is
reproducing them. It is very hard to fix a problem if you cannot reproduce
it. So if you can identify a situation that always causes the problem it
would be very helpful. Many of us run Echolink without the issues you
mention but there apparently is some combination of things that can cause
the problem.
*73 Doug*
*WA3DSP*
*http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*
On Thu, Mar 1, 2018 at 11:42 PM, "Mark Szlaga via arm-allstar" <
arm-allstar at hamvoip.org> wrote:
> We are seeing three issues on the WW8GM node (47185) that I have not been
> able to find a straight solution for when searching.
>
> 1) Echolink randomly drops audio carrier entirely.
>
> While I realize the Echolink module is meant for compatibility, we are
> using the module to replace an existing SVXlink node and expand in to
> Allstar, with the goal of moving as many nets to utilize Allstar where
> possible.
>
> That said, there is one net held on the ALARA conference node that is still
> Echolink that we connect in to.
>
> Tonight and on previous occasions we have had instances where the audio
> drops. The connection still shows in Allstar and Echolink, I see the node
> updating names as the participants transmit, but no audio.
>
> Every time a drop and reconnect fixes the issue.
>
> The question is, what causes this? Is this a "known issue" with the
> module, or are there workarounds.
>
> If this is new, what debugging can I run to capture the necessary
> information to troubleshoot?
>
> 2) Ping-pong, bumping, pulsing... I'v heard it called a number of
> different names, but the result is the same...
>
> We have had some issues tuning both the Allstar and Echolink sides when
> connected to nets.
>
> NOTE: This issue is ONLY seen during nets with other nodes, not locally or
> when we are connected to one node.
>
> Configuration:
> Hardware: Motorola Radius 1225
> Software: Raspberry Pi3 running the HamVoIP image, updated to latest last
> night.
> Audio interface: RB_RIM_RC210 from repeater-builder.com
> Carrier config: CoS is set to TSQL and repeater only transmits Tone before
> courtesy tone during nets.
>
> Why this interface, because the node will be connected to the RC210 at the
> main repeater site once the bugs are worked out.
>
> But... At this point we have RXOnDelay set to 75, with RXAudioDelay set to
> 7. This is enough that we aren't having bumps or bouncing, but 1.5 seconds
> is a lifetime!
>
> Any thoughts on things to try to reduce this and get a more manageable
> delay timing?
>
> 3) Last but not least, we do have occasional Asterisk restarts when
> connected to Echolink.
>
> We are seeing Asterisk restarts when connected to Echolink nodes. Allstar
> and normal usage does not cause restarts.
>
> What can I do to the system to log these restarts to see why it is doing
> this? I have been letting a console run with the following
> debugging/logging:
>
> core set verbose 99
> core set debug 99
> rpt debug level 7
> echolink debug level 7
>
> Unfortunately it seems that when the connection is dropped, no error is
> shown on the screen other than the disconnect.
>
> Thoughts?
>
> Thanks to the team. You have made a great product and the GMARC club is
> loving it. I just want to get the last of the gremlins squashed so they
> will love this more!
>
> Regards and 73,
> Mark - AC8LT
> _______________________________________________
>
> arm-allstar mailing list
> arm-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>
More information about the arm-allstar
mailing list