[arm-allstar] Issue with TXCTCSS Control

[Mike Besemer - WM4B]

Hey David,

I know you're paddling as fast as you can; just wondering if you've had 
time to take a glance at this.

Thanks es 73,

Mike
WM4B


On Sun, Apr 21, 2019 at 1:33 AM, David McGough wrote:

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