[arm-allstar] Looping problem
David McGough
kb4fxc at inttek.net
Wed May 5 17:43:05 EDT 2021
Don,
Thanks for the clarification about this. I just experimentally confirmed
your finding and will fix this issue in the software.
73, David KB4FXC
On Wed, 5 May 2021, Don Rolph wrote:
> We will use an effort link to a repeater.
>
> We will set the id timer for the repeater at 10 minutes after a transmission.
>
> We will set the id timer for the Allstar link at 10 minutes after a transmission.
>
> A transmission comes into the repeater.
>
> 10 minutes later the repeater ids.
>
> 10 minutes later + a bit the Allstar node ids.
>
> 10 minutes after the Allstar node ids, the repeater ids.
>
> 10 minutes after the repeater ids, the Allstar node ids.
>
> And we have an id loop. I have demonstrated this experimentally (and the repeater owner did not get any sleep that night).
>
> If this was an EchoLink node, I would set the node to ided at the end of a transmission. Now the id and the transmission trigger the repeater id BUT in 10 minutes when the repeater ids, the node stays silent because there is no transmission from the node.
>
> There is a potential issue with this design as well, but it does not trigger the id loops.
>
> This is one of a series of repeated help requests in the Allstar rpt group.
>
> Sent from my iPad
>
> > On May 5, 2021, at 11:36 AM, David McGough <kb4fxc at inttek.net> wrote:
> >
> > 
> > Don,
> >
> > I'm not understanding your statement about the "id looping behavior is an
> > artifact of the AllStar design decisions" ??? AllStar is inherently a
> > full-duplex audio system. This is a HUGE, advantageous feature, which
> > neither IRLP nor echolink provide.
> >
> > Further, I'm not understanding how any other software is realistically
> > going to be superior?? AllStar behavior can easily be adjusted to resolve
> > ping-pong problems. Repeater hang-times, IDer broadcasts, etc., will
> > impact any linking system, whether VoIP based or RF.
> >
> > As for the place to start, setting up HamVoIP, I would recommend initially
> > setting the rpt.conf node-stanza mode to "duplex = 0" .....Then, in the
> > simpleusb.conf config for the node, set "rxondelay = -250" ...And,
> > restart asterisk. This *should* resolve the ping-pong. Then, start
> > reducing the "rxondelay = -250" to lower delays (like -100) and keep
> > testing until the ping-pong returns; increasing the delay, at that point.
> >
> > Note that you can change all the simpleusb settings in REAL TIME, using
> > the simpleusb-tune-menu program. Use option "m" to adjust the rxondelay
> > values. NOTE that the negative rxondelay values are HamVoIP specific.
> > This feature activates the rxondelay only immediately after the AllStar
> > node's PTT has been asserted. This reduces the audio chops normally
> > associated with using the rxondelay parameter.
> >
> > Once you've got duplex=0 working successfully, then you can switch to
> > duplex=1 and add more AllStar features, as desired.
> >
> >
> > 73, David KB4FXC
> >
> >
> >
> >
> >> On Wed, 5 May 2021, "Don Rolph via ARM-allstar" wrote:
> >>
> >> Hmm, the id looping behavior is an artifact of the AllStar design decisions.
> >>
> >> IRLP and Echolink also face the same design problems AND Echolink has
> >> adopted a design response which seems to resolve the ID looping issue.
> >> Is there a reason you would not want to consider design approaches of
> >> similar software in an effort to address the Allstar id looping issue?
> >>
> >> Why would you not look at similar software to see how they address similar
> >> design challenges?
> >>
> >> On Wed, May 5, 2021 at 9:47 AM "Chris Smart via ARM-allstar" <
> >> arm-allstar at hamvoip.org> wrote:
> >>
> >>> Hi don. At present, we're trying to solve a specific problem. Let's
> >>> leave Echolink to the side for now...
> >>>
> >>>
> >>> besides, ever compared the audio between Echolink and Allstar? :)
> >>>
> >>>
> >>>
> >>> On 2021-05-05 7:34 a.m., "Don Rolph via ARM-allstar" wrote:
> >>>> Actually easily resolved IF one can ensure that telemetry and id only
> >>>> occurs at the end of an AllStar/Echolink connection, This is one of the
> >>>> options in Echolink software, but not present in AllStar, which greatly
> >>>> mitigates this problem.
> >>>>
> >>>> A paper study suggests that with an appropriate id interval AND an
> >>>> appropriate politeid interval, it seems this Echolink software behavior
> >>> can
> >>>> be approximated, but I need to experiment some more.
> >>>>
> >>>> On Wed, May 5, 2021 at 7:21 AM "Patrick Perdue via ARM-allstar" <
> >>>> arm-allstar at hamvoip.org> wrote:
> >>>>
> >>>>> And also, if you can, use gated PL on the repeater such that only PL
> >>>>> comes through with voice, not telemetry. This way, IDs, hangtime and
> >>>>> repeater tones won't come back across the network. If you can't directly
> >>>>> connect the node to a controller and must use an RF link, this is the
> >>>>> next best thing. Not only will this (hopefully) eliminate pingponging,
> >>>>> it will also make things much more responsive for remote users.
> >>>>>
> >>>>> This is a problem I see with many remote echolink connections. No gated
> >>>>> PL, and driven by vox. Makes for a pretty painful experience.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 5/5/2021 6:20 AM, "Don Rolph via ARM-allstar" wrote:
> >>>>>> Try setting duplex to 0.
> >>>>>>
> >>>>>> If you set duplex to 1, turn off courtesy tones with nounkeyct=1. This
> >>>>>> however results in ping ponging of the 10 minute id of the repeater and
> >>>>> the
> >>>>>> AllStar node.
> >>>>>>
> >>>>>> This is a deep nagging problem with using AllStar on a repeater link.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, May 4, 2021 at 7:45 PM "Mark Richardson via ARM-allstar" <
> >>>>>> arm-allstar at hamvoip.org> wrote:
> >>>>>>
> >>>>>>> I am setting up an AllStar node with the plan to link it to our local
> >>>>>>> repeater by RF.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Everything is working fine if I put the radio on a Simplex frequency,
> >>>>> but
> >>>>>>> if
> >>>>>>> I use a Repeater split I get a looping where the radio cycles between
> >>>>>>> transmit and receive and a beep is heard with each cycle. It seems to
> >>>>> begin
> >>>>>>> the first time the radio transmits and then continues.
> >>>>>>>
> >>>>>>> I'm hoping someone has encountered something like this before and will
> >>>>> have
> >>>>>>> some suggestions for me.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> I am using a Standard GX3000V radio with a Masters Communications
> >>> AR-35
> >>>>>>> interface and a Raspberry PI 3.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks in advance,
> >>>>>>>
> >>>>>>> Mark Richardson
> >>>>>>>
> >>>>>>> VA3OBO
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>>
> >>>>>>> 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/4 web page - http://hamvoip.org
> >>>>>>>
> >>>>> _______________________________________________
> >>>>>
> >>>>> 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/4 web page - http://hamvoip.org
> >>>>
> >>>>
> >>> _______________________________________________
> >>>
> >>> 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/4 web page - http://hamvoip.org
> >>>
> >>
> >>
> >>
> >
>
More information about the ARM-allstar
mailing list