Problems using tonemacro, rptinactmacro, and event management to manage connections with scripts

App_rpt-users
1

I use event management to manage connections when certain events occur.
To manage connections, scripts are executed that execute a series of commands to the asterisk.

Below is an example of using the event.

[1997001]
events=events

[events]
REMOTEKEYED_VAR = v|e|${RPT_ALINKS} =~ “”,1997002[TRC]K""
sudo -u root /bin/bash /etc/asterisk/Scripts/event_1.sh > /dev/null 2>&1 = s|t|REMOTEKEYED_VAR

SCRIPT: event_1.sh

#!/bin/bash

tempfile=/tmp/hub_conn

/usr/sbin/asterisk -rx “rpt nodes 28554” > $tempfile

grep “1200” $tempfile > /dev/null ||
CONNECTSTATUS=0

grep “1200” $tempfile > /dev/null &&
CONNECTSTATUS=1

if [[ “$CONNECTSTATUS” == “0” ]]
then
exit
fi

if [[ “$CONNECTSTATUS” == “1” ]]
then
/usr/sbin/asterisk -rx “rpt cmd 1200 ilink 1 28554”&&
/usr/sbin/asterisk -rx “rpt cmd 1200 ilink 11 28554”
fi

exit

To restore the previous connection configuration, I use rptinacttimer. Below is an example of its use.

[1200]
rptinacttimer=1
rptinacttime=180
rptinactmacro=*D9901#
macros=macros

[macros]
D9901 = cmd,/etc/asterisk/Scripts/act_timer.sh > /dev/null 2>&1

SCRIPT: act_timer.sh

#!/bin/bash

tempfile=/tmp/hub_conn

/usr/sbin/asterisk -rx “rpt nodes 28554” > $tempfile

grep “1200” $tempfile > /dev/null ||
CONNECTSTATUS=0

grep “1200” $tempfile > /dev/null &&
CONNECTSTATUS=1

if [[ “$CONNECTSTATUS” == “1” ]]
then
exit 0
fi

if [[ “$CONNECTSTATUS” == “0” ]]
then
/usr/sbin/asterisk -rx “rpt cmd 1200 ilink 18 28554”
fi

exit 0

The problem is that after some time, it can be 4-10-20 hours, problems occurs, expressed in crackles and sound distortions or short interruptions of the subtone at the transmitter output.
These problems appear all the time, not just when an event triggers a script, and are fixed by restarting the asterisk.

When this functionality is disabled, the node works as expected.
I had exactly the same problem when I used tonemacro and similar script to manage connections using subtones.

What could be the problem?

2

I think for a clue, you might want to check cpu utilization and memory usage while it is occurring.
Compare to when it is not.
DSP functions are going to use more of both and perhaps in a Pi (guessing you are using), it’s not enough with other background processes.

3

If you are using a Pi, try the ASL beta6. If fixes the stuttering problems. Download from the AllStarLink Wiki.

4

Did more testing. ASL version beta6. RAM, CPU and HDD usage are the same as always.
The problem occurs on two nodes, the first one hosted on ESXi, the second one on rpi.

5

Well, I’m outta ideas.
With exception to looking at the sound fob having issues.

6

Sound devices work fine. When this functionality (macros/events+scripts) is disabled, both nodes work fine.

7

While this is revolving in my mind from time to time,
Can you say which PL tone you are using ?
And are you also using a ASL audio filter in your set-up ?

8

wiki

Receiver Audio High Pass Filter Options:[edit]

  • rxhpf=0; 300 Hz cutoff. Default value to reduce sub-audible signals for retransmission, and also in the receiver speaker.
  • rxhpf=1; 250 Hz cutoff for additional received and retransmitted bass response. We recommend using this filter with a CTCSS tone no higher than 186.2 Hz.