[arm-allstar] Issue with TXCTCSS Control

Mike Besemer mwbesemer at cox.net
Sat Apr 20 18:59:47 EDT 2019


Greetings,

I’m hoping the development team will have a look at this.

I have a node at my home that provides ASL and Echolink access to my
repeater which is at a different location.  Access is provided via a
Motorola Maxtrac attached to my node.

My interface is a Masters Communications RA-42, but I have also tested a URI
with the same results.  I have also tried several different link radios with
the same results.  Since the issue occurs with 2 different interfaces and
several different radios, I believe there is a glitch with the HamVoIP
software.  

The node is set up to require COS (low) and CTCSS Decode (low) from the
Maxtrac.  This works fine and provides a Composite COS to the node only when
both the receiver is active and CTCSS Decode is valid.  My repeater does not
encode CTCSS during courtesy tones, ID, and announcements, so using the node
to AND the COS and CTCSS Decode keeps everything but user audio off the
node.  

The problem arises when I attempt to used TXCTCSS control as well.  TXCTCSS
Control by itself works fine, however with both TXCTCSS control enable *AND*
PL Decode enabled, the radio will attempt to duplex whenever a signal both
COR and PL Decode are valid.  

To clarify, imagine a test bench setup with the node programmed as described
above with TXCTCSS control enabled.  The radio is connected to my service
monitor.  With the service monitor set for TX test, I can connect remotely
to my node with DVSwitch Mobile or Echolink, press PTT and verify that the
node goes into Transmit and encodes CTCSS properly.  

Now, with the service monitor set to test the RX, I first send RF to the
receiver without encoding CTCSS and I can see the COS go low in the
Simple-USB Tune menu.  Then I encode my CTCSS on the signal and can
momentarily see both COS and CTCSS go low and produce a momentary Composite
COS.  At that point things go wrong because the node then issues a PTT low
and the radio goes in to transmit.  This starts cycle of ‘BEEP’ – TX –
‘BEEP’ – TX at about ½ second intervals and it continues forever.  (And yes,
I have tested the ability of the radio to deal with all these signals at the
same time, and it works fine.  I’ve even removed the TXCTCSS wire from the
connector and the behavior is the same.)  

By way of further troubleshooting, I reset the node so that it ignores the
CTCSS Decode logic, then pulled the COS wire out of the connector at the
interface and replaced it with the CTCSS Decode wire (effective turning
CTCSS Decode into COS).  The behavior remains the same – a cycling between
RX and TX.  Going in to simpleusb.conf and disabling the TXCTCSS control
will resolve the problem.  

Bottom line is that it appears that there is some incorrect interaction
between the CTCSS Decode logic and the TXCTCSS Encode logic.  

It’s really important that this work properly; there is no need for either
side of the system to transmit PL along with their various beeps, squawks,
ID’s, etc.

73,

Mike
WM4B


More information about the ARM-allstar mailing list