[arm-allstar] Issue with TXCTCSS Control

[Mike Besemer]

Thanks David... much appreciated.  

I've temporarily swapped in my spare TM-V71A in place of the Maxtrac, but of
course that radio does not provide for TXCTCSS control, so I'll be moving
back to the Maxtrac if we can clear up the issue with TXCTCSS.  

Many thanks for all you and the rest of the team do.

73,

Mike
WM4B 

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



On Wed, 24 Apr 2019, Mike Besemer - WM4B wrote:

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