[arm-allstar] Issue with TXCTCSS Control

[Brad Trogdon]

David,

Your reply sparked a thought that you may have an answer to.   When HamVoIP
is used as a repeater controller between two Motorola GM-300's is it
possible to reject (Not repeat) CTCSS tones received that are not
defined?   This would be the fix for a issue I have an the inability to use
it as a stand alone controller.

In my scenario we have other repeaters coordinated on same Freq and need to
prevent the distant traffic from opening the repeater.  If only a single
tone we could address by adding PL to the Rec radio but more than one tone
is in play.

Thanks in advance.

-Brad
~~

-----Original Message-----
From: David McGough [mailto:kb4fxc at inttek.net]
Sent: Sunday, April 28, 2019 8:18 AM
To: Mike Besemer - WM4B
Cc: arm-allstar at hamvoip.org
Subject: Re: [arm-allstar] Issue with TXCTCSS Control


Hi Mike,

I have looked at these scenarios carefully this morning. I can't seem to
duplicate the EXACT condition that I THINK you're describing, however I
did find a bug related to how TXCTCSS is working.

Trying to explain this failure scenario in e-mail may be difficult, but
here it goes....

Basically, what I found is a case where TX-CTCSS is asserted when RX-CTCSS
is asserted in duplex=0 or duplex=1. PTT isn't keyed, so I don't think
this should create a ping-pong situation, but, it might be confusing the
MaxTrac since TX-CTCSS is asserted improperly. This condition
shouldn't happen, of course.

I'm working on fixing the bug ASAP (hopefully today). It'll be later this
afternoon before this code is ready for beta---it also includes some more
features/updates for some other minor issues.

I'll send out a follow-up when I've got a package ready.

Thanks for reporting this problem!

73, David KB4FXC