I have been meaning to bring this up as well, but I have a little different scenario. I have a macro that runs the following: Cop 33, *71, then a series of node connects and then COP 34 If this is performed on the RF side, the CLI verbose output shows a stuck RX carrier. (I use PL decode via discriminator) All that is needed is a onetime quick PTT on the input and it clears. Seems as it gets back into sync. If I issue the macro via CLI I don't get this issue. It happens to all of my nodes and it is pretty consistent. -----Original Message----- From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of Ramesh Dhami (VA3UV) Sent: Saturday, October 29, 2011 9:20 PM To: app_rpt Subject: [App_rpt-users] cop 2 - causing PTT lock Hi Jim and all; Running app_rpt v0.287 (full duplex); when I issue a DTMF command to re-enable the repeater (from it's disabled cop 3 state), the repeater keys up, we hear Alison announce 'RPT ENA' and then the PTT remains keyed. I have to send a '*0' to get the PTT to drop. This is on a system that I just rebuilt recently. AFAIK, this problem did not exist with an earlier version of app_rpt (sorry, I can't be more specific than that!). Wonder if this is a bug or something that I am missing from my config file, etc? Cheers! Ramesh. www.freestar.us _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users