Use 2 nodes to link with repeaters
Using a receive on time delay, (/etc/asterisk/usbradio.conf - rxondelay=20), to prevent a keying loop between the two nodes goes something like this: 1. User w7abc keys up repeater 'A' and node 28174 receives the signal and sends it out the VoIP gateway to the Internet to node 28210 which then transmits what it receives from VoIP and repeater 'B' keys up and is now linked. 2. W7ABC finishes the conversation, repeater 'A' stops transmitting, node 28174 stops receiving and the audio to the VoIP gateway is closed. Node 28210 does not receive audio from VoIP and so it stops transmitting, and repeater 'B' stops transmitting and the link is down. 3. Repeater 'B' does not stop transmitting instantly when node 28210 stops transmitting, it has a hang time of approximately 1.6 seconds. Node 28210 will receive this signal as soon as it stops transmitting and send that audio out the VoIP Gateway to node 28174 which will then transmit and key up repeater 'A'. 4. This causes a "keying loop" between nodes 28210 and node 28174. 5. There is a variable called "rxondelay" in /etc/asterisk/usbradio.conf that controls when the node receiver can send what it receives out the VoIP gateway. I would expect that if 'rxondelay=90' which is approximately 1.8 seconds, that this delay would account for the hang time of repeater 'B', but it is insufficient. Through trial and error I have found that 'rxondelay=200', or 4 seconds, is required to prevent a single keying loop. 6. A 'rxondelay=90' is sufficient to prevent an ongoing keying loop that does not end, but it is not sufficient to prevent a keyup of node 28174 "one time". 7. Node 28174 uses a 'rxondelay=60' to account for the repeater 'A' hang time. So this is a mystery that I have not solved. A 4 second receive on delay for the link over VoIP is a long time for the repeater users to work with. Many replies and short conversations take less time. This method of linking is not a real good one, but it is a portable solution for quick linking repeaters. Is there something I am missing in the configurations that would shorten the link timing? Ron KA7U
At 07:16 AM 1/4/2012, Ron Morell wrote:
So this is a mystery that I have not solved. A 4 second receive on delay for the link over VoIP is a long time for the repeater users to work with. Many replies and short conversations take less time. This method of linking is not a real good one, but it is a portable solution for quick linking repeaters. Is there something I am missing in the configurations that would shorten the link timing?
This is a problem best dealt with by hardware configuration. The ideal fix is to bring the Internet up to the repeater sites and use AllStar as the controller. That way, there is no hang time to propagate back into the network. app_rpt is particularly well suited to this role, as it has all the necessary functionality built in. You could alternatively connect the AllStar node to a link port on the existing controller, which has the advantage that if the AllStar box dies, you still have local repeater functionality. The other advantage of having the node at the repeater is better audio quality. :) You can successfully setup a link on the user frequency, but you need to take steps to ensure that the hang time is not seen by the node, such as using CTCSS gated by the receiver's COS. 73 de VK3JED / VK3IRL http://vkradio.com
Tony, Thank you for the reply! Eventually, I hope the club will install the Asterisk+app_rpt solution at the repeater sites and to that end, I have started to design an 802.11b network solution over microwave between the sites. http://ka7u.us/*/Path_Between_Repeaters.html http://ka7u.us/*/TVRAREPEATERS.kmz Your input on microwave network solutions is solicited, as I see from your web site, you have put time into this study. The CTCSS solution is probably the best idea for the interim, or just repair the existing 440 link radios that are already up there. Hi Hi. It is just that when the two simplex nodes are connected to each other and the repeaters frequencies are tuned to the node radios, it is an instant link between any two repeaters. If I could find a combination of repeater hang time, and node receive on delay that was acceptably short, this would be a great, quick and dirty solution. Interestingly, the audio quality is reasonable, although it is better in one link direction than the other. The node with the discriminator audio is a bit shrill and the node using speaker audio is a bit on the bass or muffled side, but both are good and readable. The deviation on the nodes was set as follows: 1. radio-tune-menu opton 3). transmit DTMF 1 with a handheld and find the value that yeilds no more than 3KHz deviation. 2. from the asterisk cli: radio tune txvoice and watch the recieve deviation on the other node, using option 3) as shown above. Set the radio tune txvoice value to achieve the 3KHz deviation on the other node. 3. Repeat process for the other node. 4. Right or wrong, they are both set about the same for transmit and receive deviation and no test equipment required. So, how would I go about setting up CTCSS gated by the receiver's COS? I think I know, but have never done it. Ron Morell KA7U On 01/03/2012 01:42 PM, Tony Langdon, VK3JED wrote:
At 07:16 AM 1/4/2012, Ron Morell wrote:
So this is a mystery that I have not solved. A 4 second receive on delay for the link over VoIP is a long time for the repeater users to work with. Many replies and short conversations take less time. This method of linking is not a real good one, but it is a portable solution for quick linking repeaters. Is there something I am missing in the configurations that would shorten the link timing?
This is a problem best dealt with by hardware configuration. The ideal fix is to bring the Internet up to the repeater sites and use AllStar as the controller. That way, there is no hang time to propagate back into the network. app_rpt is particularly well suited to this role, as it has all the necessary functionality built in. You could alternatively connect the AllStar node to a link port on the existing controller, which has the advantage that if the AllStar box dies, you still have local repeater functionality. The other advantage of having the node at the repeater is better audio quality. :)
You can successfully setup a link on the user frequency, but you need to take steps to ensure that the hang time is not seen by the node, such as using CTCSS gated by the receiver's COS.
73 de VK3JED / VK3IRL http://vkradio.com
I'm putting together a Syntor X w/XCAT as a frequency agile remote base. I see the XCAT PC software recognizing the COS state as sent from the XCAT CI-V. Does app_rpt use that CI-V statement? Or, do I need to bring COS out to the URI? Any other hints, or suggestions on this project are appreciated. -- Robert A. Poff Loganville, PA WB3AWJ - Allstar 27784 Powered by Linux
You'll really like the XCAT/Syntor/Allstar set up. We have remote bases on 10, 6, 2 meters, and UHF. Bring out the COS line to the URI. -- Tim :wq On Jan 3, 2012, at 4:21 PM, Robert Poff wrote:
I'm putting together a Syntor X w/XCAT as a frequency agile remote base.
I see the XCAT PC software recognizing the COS state as sent from the XCAT CI-V. Does app_rpt use that CI-V statement? Or, do I need to bring COS out to the URI?
Any other hints, or suggestions on this project are appreciated.
-- Robert A. Poff Loganville, PA
WB3AWJ - Allstar 27784 Powered by Linux
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Thanks Tim, I suspected that but wasn't sure. I've been playing with the radio on the workbench attached to an antenna. Pretty nifty. I've always been more of a GE type though...... Haven't started the interfacing yet. I have a junk control cable coming to scavenge the radio connector from. Sort of thinking of building a mini-control head in the shell along with the signals to/from the URI. That way I can keep the control group I now have for later projects. This thing is going to on a Station Master (and actually cut for 2 meters) 200' up a tower where the ground height above average is about 375'. Gonna be fun! -- Robert A. Poff Loganville, PA WB3AWJ - Allstar 27784 Powered by Linux On Sat, 2012-01-07 at 16:41 -0800, Tim Sawyer wrote:
You'll really like the XCAT/Syntor/Allstar set up. We have remote bases on 10, 6, 2 meters, and UHF.
Bring out the COS line to the URI.
participants (4)
-
Robert Poff -
Ron Morell -
Tim Sawyer -
Tony Langdon, VK3JED