[arm-allstar] Issue with TXCTCSS Control

[David McGough]

Hi Mike,

I'll try to duplicate this issue. As for node setup for your link radio, 
is it set duplex=1 or duplex=0 / linktolink=yes, or otherwise??


73, David KB4FXC



On Sat, 20 Apr 2019, "Mike Besemer via ARM-allstar" wrote:

> 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
> _______________________________________________
> 
> 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
>