[arm-allstar] Issue with TXCTCSS Control

[Mike Besemer]

Hey David,

Good morning and happy Easter. 

Duplex = 1 and linktolink is commented out.  I don't think I've ever noticed
the linktolink line before.

Also forgot to mention that TXCTCSS control is set to active high.

73 es tnx,

Mike
WM4B

-----Original Message-----
From: David McGough [mailto:kb4fxc at inttek.net] 
Sent: Sunday, April 21, 2019 1:34 AM
To: "Mike Besemer via ARM-allstar"
Cc: Mike Besemer
Subject: Re: [arm-allstar] Issue with TXCTCSS Control


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
>