[arm-allstar] Is CTCSS enable/disable possible using dtmf?
Doug Crompton
doug at crompton.com
Fri May 15 20:22:47 EST 2015
carrierfrom= and ctcssfrom= are really meaningless in that they are just bits that are set high or low when an outside event occurs.
We generally use carrierfrom= which corresponds to pin 8 of the DMK-URI. It is just a bit that you read. This bit in turn is connected to a receiver (transceiver) that asserts that bit either positive (usb) or negative (usbinvert) with RX signal generally PL decoded.
Some radios (not many) have the ability to provide both squelch and CTCSS decode levels. This would allow you to connect both bits and have the capability to turn off PL decode if desired by not "anding" the two bits.
In most cases you would use carrierfrom=usb|usbinvert that is asserted when the RX receives the set PL tone. In simpleusb that tone is set in the receiver or transceiver. CTCSS would be left set to 'no'
If you so desired you could use the ctcssfrom=usb|usbinvert (pin 7 of the DMK-URI and set carrierfrom=no It makes no difference which you use. We have just generally standardized in using carrierfrom and leaving ctcssfrom set to no.
Bottom line is they are just bits and neither have anything to do with CTCSS directly. Both CTCSS encode and decode is done in your transceiver or receiver/transmitter.
73 Doug
WA3DSP
http://www.crompton.com/hamradio
Date: Fri, 15 May 2015 10:50:57 -0500
From: lmccann at dtisp.com
To: arm-allstar at hamvoip.org
Subject: Re: [arm-allstar] Is CTCSS enable/disable possible using dtmf?
OK, I figured it out.
I had ctcssfrom=no in simpleusb.conf.
We normally would leave tone off, but want to turn it on if there
was interference issues.
I was trying to turn ctcss on with the cop,56 command. This would
not work.
But, If if set ctcssfrom=usb, then I can turn it off with the
cop,57 command.
So, you can turn it off if it is on by default, but you can't turn
it on if it is off by default.
Thanks,
LaRoy McCann, K5TW
On 5/15/2015 10:34 AM, Corey Dean wrote:
I just looked at my configurations and these are what I
have for enable and disable. It does work as it should on
mine.
920=cop,56
921=cop,57
Corey N3FE
On Fri, May 15, 2015 at 11:29 AM, LaRoy
McCann <lmccann at dtisp.com>
wrote:
Corey,
Thanks for the reply.
I did not realize the reload only reloaded rpt.conf.
Good to know.
As for enabling and disabling ctcss, it looks like there
should be someway to do that . Most dedicated repeater
controllers have that capability.
I think I'll start digging thru the source to see if I
can figure out how it works.
LaRoy McCann, K5TW
On 5/15/2015 10:14 AM, Corey Dean wrote:
I use those commands with no issues, but I am
also using DSP and Xipar on the node I do this on.
the rpt reload will only reload the rpt.conf file.
The file you are changing is simpleusb.conf so the rpt
reload wouldn't read that.
On Fri, May 15, 2015 at 11:10
AM, LaRoy McCann <lmccann at dtisp.com>
wrote:
I
posted this to the app_rpt list but got no
response so I am posting here.
First, I am using RPI2 for the controller but I
think this is more a generic question than a
specific RPI2 question.
I can set "ctcssfrom=usb" in simpleusb.conf and
then I have to use tone to make the controller
receive commands or key the repeater.
After changing simpleusb.conf I issued the command
'asterisk -rx "rpt reload"'. This would not make
ctcss be required to key the repeater.
I had to 'astres.sh' before it would require tone
to key the repeater. Not sure if the 'asterisk
-rx "rpt reload"' should have worked or there is a
bug somewhere?
Doing this shows that the CTCSS input does work.
What I am actually trying to be able to do is to
enable/disable Rx CTCSS from dtmf commands.
I have configured a function for the cop=56(Rx
CTCSS enable) and cop=57(Rx CTCSS disable)
commands.
When I enter the dtmf for the cop=56 function the
controller talks back "rx pl ena", so I know the
function is working. But I can still access the
repeater without a CTCSS tone.
Are cop=56 and cop=57 commands supposed to work
when using simpleusb.conf?
I have searched and can not find any reference to
using these commands.
LaRoy McCann, K5TW
---
This email has been checked for viruses by Avast
antivirus software.
http://www.avast.com
_______________________________________________
arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
Visit the BBB web page - http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/
--
This message has been scanned for viruses and
dangerous content by the DTISP
MailScanner, and is
believed to be clean.
_______________________________________________
arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
Visit the BBB web page - http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/
This email has been checked for viruses by Avast
antivirus software.
www.avast.com
_______________________________________________
arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
Visit the BBB web page - http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/
--
This message has been scanned for viruses and
dangerous content by the
DTISP
MailScanner, and is
believed to be clean.
_______________________________________________
arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
Visit the BBB web page - http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/
This email has been checked for viruses by Avast antivirus software.
www.avast.com
_______________________________________________
arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
Visit the BBB web page - http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20150515/3457f823/attachment.html>
More information about the arm-allstar
mailing list