Connecting several sites together on a hub using link radios
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub. What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this. The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal. Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge. 73 Stephen K1LNX
What is your node structure at the repeater and hub ends of the link? In other words, how is the repeater end of the link tied to the repeater, as well as the hub end of the link? It seems to me that both ends of the link cannot be full-duplex because they will feedback on themselves. You may consider full-duplex at the hub end, and half-duplex at the repeater end of the link, where the hub is the master, and the satellite repeaters are the slaves, but each repeater itself operates as full-duplex. Curious... what are you using for radios for the link portion of the system? Thanks, Bob k6ecm 73 Sent from iPad
On Aug 26, 2016, at 2:48 AM, Stephen - K1LNX <k1lnx@k1lnx.net> wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Hi Bob... basically each site is linked with a linking radio on the repeater pair. The link radio is connected to a Raspberry Pi and a suitable USB interface. Each node is then linked permanently to our hub node, which is a pseudo node with no hardware connected. The repeater nodes are built as half-duplex, hub is full-duplex. As for radios.. we are using either a Motorola SM50, MaxTrac, and one CDM. 73 Stephen K1LNX On Fri, Aug 26, 2016 at 6:54 AM, Bob Pyke <k6ecm1@gmail.com> wrote:
What is your node structure at the repeater and hub ends of the link? In other words, how is the repeater end of the link tied to the repeater, as well as the hub end of the link?
It seems to me that both ends of the link cannot be full-duplex because they will feedback on themselves. You may consider full-duplex at the hub end, and half-duplex at the repeater end of the link, where the hub is the master, and the satellite repeaters are the slaves, but each repeater itself operates as full-duplex.
Curious... what are you using for radios for the link portion of the system?
Thanks, Bob k6ecm 73
Sent from iPad
On Aug 26, 2016, at 2:48 AM, Stephen - K1LNX <k1lnx@k1lnx.net> wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/ mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Hi Stephen, I guess, in your scenario, the ping-pong is generated from repeater TX hang times? So, something like: 1) User keys up "Repeater A" directly. 2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or hang time and repeats to the hub. 3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B" 4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys. 5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A". 6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys. 7) Goto 2 and repeat forever 73, David KB4FXC On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
David, Yes, this is the exact scenario. I think it can be solved by eliminating the hangtime from propagating across the hub alltogether, but not sure what the best approach is. Thanks, Stephen K1LNX On Fri, Aug 26, 2016 at 6:58 AM, David McGough <kb4fxc@inttek.net> wrote:
Hi Stephen,
I guess, in your scenario, the ping-pong is generated from repeater TX hang times? So, something like:
1) User keys up "Repeater A" directly.
2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or hang time and repeats to the hub.
3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B"
4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys.
5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A".
6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys.
7) Goto 2 and repeat forever
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
No reason for a hub to have hang time. Nor should the link radios from the "client" repeaters. 73, Steve N4IRS On 8/26/2016 7:49 AM, Stephen - K1LNX wrote:
David, Yes, this is the exact scenario. I think it can be solved by eliminating the hangtime from propagating across the hub alltogether, but not sure what the best approach is.
Thanks, Stephen K1LNX
On Fri, Aug 26, 2016 at 6:58 AM, David McGough <kb4fxc@inttek.net <mailto:kb4fxc@inttek.net>> wrote:
Hi Stephen,
I guess, in your scenario, the ping-pong is generated from repeater TX hang times? So, something like:
1) User keys up "Repeater A" directly.
2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or hang time and repeats to the hub.
3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B"
4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys.
5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A".
6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys.
7) Goto 2 and repeat forever
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
> Hi guys... I am in the midst of deploying a 5 site system. All of the sites > with the exception of my own will be using link radios sitting on the > repeater pair, some sites do not have internet access so this is the only > option. Each node will be permalinked to our hub. > > What we discovered when we brought site number 3 online was the dreaded > "ping-pong" effect, and I did some digging and found out about the > rxondelay parameter, that seems to be the place to start with this. > > The other option we are considering is dropping the hang time off each > repeater and using app_rpt to do hang time and courtesy tones instead > (duplex = 1 instead of 0) but not sure that would work real well or be > optimal. > > Anyone have any experience with a setup like this that can offer some > advice? This is my first foray into this unfortunately, I've always just > interfaced the radio or repeater directly to app_rpt in the past or through > a controller so it's been a bit of a challenge. > > 73 > Stephen > K1LNX >
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
-- "Just say no to world domination" > "ping-pong" effect, and I did some digging and found out about the<br> > rxondelay parameter, that seems to be the place to start with this.<br> ><br> > The other option we are considering is dropping the hang time off each<br> > repeater and using app_rpt to do hang time and courtesy tones instead<br> > (duplex = 1 instead of 0) but not sure that would work real well or be<br> > optimal.<br> ><br> > Anyone have any experience with a setup like this that can offer some<br> > advice? This is my first foray into this unfortunately, I've always just<br> > interfaced the radio or repeater directly to app_rpt in the past or through<br> > a controller so it's been a bit of a challenge.<br> ><br> > 73<br> > Stephen<br> > K1LNX<br> ><br> <br> </div> </div> </blockquote> </div> <br> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. </pre> </blockquote> <br> <pre class="moz-signature" cols="72">-- "Just say no to world domination" </pre> </body> </html>
Thanks Steve... no hang time on the hub, and the hang time off the repeaters is fixed. All the link radios are set to duplex = 0 On Fri, Aug 26, 2016 at 8:16 AM, Steve Zingman <szingman@msgstor.com> wrote:
No reason for a hub to have hang time. Nor should the link radios from the "client" repeaters.
73, Steve N4IRS
On 8/26/2016 7:49 AM, Stephen - K1LNX wrote:
David, Yes, this is the exact scenario. I think it can be solved by eliminating the hangtime from propagating across the hub alltogether, but not sure what the best approach is.
Thanks, Stephen K1LNX
On Fri, Aug 26, 2016 at 6:58 AM, David McGough <kb4fxc@inttek.net> wrote:
Hi Stephen,
I guess, in your scenario, the ping-pong is generated from repeater TX hang times? So, something like:
1) User keys up "Repeater A" directly.
2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or hang time and repeats to the hub.
3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B"
4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys.
5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A".
6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys.
7) Goto 2 and repeat forever
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
_______________________________________________ App_rpt-users mailing listApp_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
-- "Just say no to world domination"
Stephen, Yes, eliminating the Repeater TX hang time, one way or another, is the best solution....I'm not sure what kind of controllers you've got?? One possibility would be to have a Repeater transmitted PL tone directly follow the Repeater COS....Then, the simplex link radios would look for that PL tone. If the Repeater's RX COS isn't active, no PL tone transmitted, and no ping-pong. Then, you could still have a Repeater generated TX carrier hang time. The problem with rxondelay is that it'll force users to slow down their chatter, since the first parts of words during the delay period will get chopped off. If TX hang times are long, the rxondelay will be long...Not ideal. 73, David KB4FXC On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
David, Yes, this is the exact scenario. I think it can be solved by eliminating the hangtime from propagating across the hub alltogether, but not sure what the best approach is.
Thanks, Stephen K1LNX
On Fri, Aug 26, 2016 at 6:58 AM, David McGough <kb4fxc@inttek.net> wrote:
Hi Stephen,
I guess, in your scenario, the ping-pong is generated from repeater TX hang times? So, something like:
1) User keys up "Repeater A" directly.
2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or hang time and repeats to the hub.
3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B"
4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys.
5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A".
6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys.
7) Goto 2 and repeat forever
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
I'm not sure what kind of controllers you've got??
No controllers on 3 out of 5 sadly.. 4 out of 5 of these are DR-1X's, and the fifth is a GE Master II with a ID-O-Matic IV board. My repeater (also a DR-1X) will have an SCOM 7330 on it, but has not been brought online yet. On Fri, Aug 26, 2016 at 8:18 AM, David McGough <kb4fxc@inttek.net> wrote:
Stephen,
Yes, eliminating the Repeater TX hang time, one way or another, is the best solution....I'm not sure what kind of controllers you've got?? One possibility would be to have a Repeater transmitted PL tone directly follow the Repeater COS....Then, the simplex link radios would look for that PL tone. If the Repeater's RX COS isn't active, no PL tone transmitted, and no ping-pong. Then, you could still have a Repeater generated TX carrier hang time.
The problem with rxondelay is that it'll force users to slow down their chatter, since the first parts of words during the delay period will get chopped off. If TX hang times are long, the rxondelay will be long...Not ideal.
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
David, Yes, this is the exact scenario. I think it can be solved by eliminating the hangtime from propagating across the hub alltogether, but not sure what the best approach is.
Thanks, Stephen K1LNX
On Fri, Aug 26, 2016 at 6:58 AM, David McGough <kb4fxc@inttek.net> wrote:
Hi Stephen,
I guess, in your scenario, the ping-pong is generated from repeater TX hang times? So, something like:
1) User keys up "Repeater A" directly.
2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or
hang
time and repeats to the hub.
3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B"
4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys.
5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A".
6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys.
7) Goto 2 and repeat forever
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
Okay about your setup....Well, the Mastr II should be easy to hack into submission... As for the DR-1X repeaters, some solutions I've seen would make Rube Goldberg smile. On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
I'm not sure what kind of controllers you've got??
No controllers on 3 out of 5 sadly.. 4 out of 5 of these are DR-1X's, and the fifth is a GE Master II with a ID-O-Matic IV board. My repeater (also a DR-1X) will have an SCOM 7330 on it, but has not been brought online yet.
On Fri, Aug 26, 2016 at 8:18 AM, David McGough <kb4fxc@inttek.net> wrote:
Stephen,
Yes, eliminating the Repeater TX hang time, one way or another, is the best solution....I'm not sure what kind of controllers you've got?? One possibility would be to have a Repeater transmitted PL tone directly follow the Repeater COS....Then, the simplex link radios would look for that PL tone. If the Repeater's RX COS isn't active, no PL tone transmitted, and no ping-pong. Then, you could still have a Repeater generated TX carrier hang time.
The problem with rxondelay is that it'll force users to slow down their chatter, since the first parts of words during the delay period will get chopped off. If TX hang times are long, the rxondelay will be long...Not ideal.
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
David, Yes, this is the exact scenario. I think it can be solved by eliminating the hangtime from propagating across the hub alltogether, but not sure what the best approach is.
Thanks, Stephen K1LNX
On Fri, Aug 26, 2016 at 6:58 AM, David McGough <kb4fxc@inttek.net> wrote:
Hi Stephen,
I guess, in your scenario, the ping-pong is generated from repeater TX hang times? So, something like:
1) User keys up "Repeater A" directly.
2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or
hang
time and repeats to the hub.
3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B"
4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys.
5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A".
6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys.
7) Goto 2 and repeat forever
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
I believe the DR-1X is nothing more than a controller with two FTM-400XDR radios (sans the interface panels). It appears the interfacing issues relate to interfacing an Allstarlink controller to the DR-1X controller. It seems to me Allstar is easiest to interface to a radio directly. What has been your experience? Thanks, r/Bob k6ecm -----Original Message----- From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of David McGough Sent: Friday, August 26, 2016 7:01 AM To: Stephen - K1LNX Cc: app_rpt mailing list Subject: Re: [App_rpt-users] Connecting several sites together on a hub using link radios Okay about your setup....Well, the Mastr II should be easy to hack into submission... As for the DR-1X repeaters, some solutions I've seen would make Rube Goldberg smile. On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
I'm not sure what kind of controllers you've got??
No controllers on 3 out of 5 sadly.. 4 out of 5 of these are DR-1X's, and the fifth is a GE Master II with a ID-O-Matic IV board. My repeater (also a DR-1X) will have an SCOM 7330 on it, but has not been brought online yet.
On Fri, Aug 26, 2016 at 8:18 AM, David McGough <kb4fxc@inttek.net> wrote:
Stephen,
Yes, eliminating the Repeater TX hang time, one way or another, is the best solution....I'm not sure what kind of controllers you've got?? One possibility would be to have a Repeater transmitted PL tone directly follow the Repeater COS....Then, the simplex link radios would look for that PL tone. If the Repeater's RX COS isn't active, no PL tone transmitted, and no ping-pong. Then, you could still have a Repeater generated TX carrier hang time.
The problem with rxondelay is that it'll force users to slow down their chatter, since the first parts of words during the delay period will get chopped off. If TX hang times are long, the rxondelay will be long...Not ideal.
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
David, Yes, this is the exact scenario. I think it can be solved by eliminating the hangtime from propagating across the hub alltogether,
but
not sure what the best approach is.
Thanks, Stephen K1LNX
On Fri, Aug 26, 2016 at 6:58 AM, David McGough <kb4fxc@inttek.net> wrote:
Hi Stephen,
I guess, in your scenario, the ping-pong is generated from repeater
TX
hang times? So, something like:
1) User keys up "Repeater A" directly.
2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or hang time and repeats to the hub.
3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B"
4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys.
5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A".
6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys.
7) Goto 2 and repeat forever
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Just interfaced an MMDVM to a DR-1X and from what I found an external controler is very easy to connect. what you need to do is put the repeater in external mode (shorting a pin to ground) and then use the flat audio in and out on the db-15 connector in the back. there are pins for ptt and cos. A nice little RPI and a URI-X and you have yourself a first class controler for that repeater -----Message d'origine----- From: Bob Sent: Friday, August 26, 2016 11:09 AM To: 'David McGough' ; 'Stephen - K1LNX' Cc: 'app_rpt mailing list' Subject: Re: [App_rpt-users] Connecting several sites together on a hubusing link radios I believe the DR-1X is nothing more than a controller with two FTM-400XDR radios (sans the interface panels). It appears the interfacing issues relate to interfacing an Allstarlink controller to the DR-1X controller. It seems to me Allstar is easiest to interface to a radio directly. What has been your experience? Thanks, r/Bob k6ecm -----Original Message----- From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of David McGough Sent: Friday, August 26, 2016 7:01 AM To: Stephen - K1LNX Cc: app_rpt mailing list Subject: Re: [App_rpt-users] Connecting several sites together on a hub using link radios Okay about your setup....Well, the Mastr II should be easy to hack into submission... As for the DR-1X repeaters, some solutions I've seen would make Rube Goldberg smile. On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
I'm not sure what kind of controllers you've got??
No controllers on 3 out of 5 sadly.. 4 out of 5 of these are DR-1X's, and the fifth is a GE Master II with a ID-O-Matic IV board. My repeater (also a DR-1X) will have an SCOM 7330 on it, but has not been brought online yet.
On Fri, Aug 26, 2016 at 8:18 AM, David McGough <kb4fxc@inttek.net> wrote:
Stephen,
Yes, eliminating the Repeater TX hang time, one way or another, is the best solution....I'm not sure what kind of controllers you've got?? One possibility would be to have a Repeater transmitted PL tone directly follow the Repeater COS....Then, the simplex link radios would look for that PL tone. If the Repeater's RX COS isn't active, no PL tone transmitted, and no ping-pong. Then, you could still have a Repeater generated TX carrier hang time.
The problem with rxondelay is that it'll force users to slow down their chatter, since the first parts of words during the delay period will get chopped off. If TX hang times are long, the rxondelay will be long...Not ideal.
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
David, Yes, this is the exact scenario. I think it can be solved by eliminating the hangtime from propagating across the hub alltogether,
but
not sure what the best approach is.
Thanks, Stephen K1LNX
On Fri, Aug 26, 2016 at 6:58 AM, David McGough <kb4fxc@inttek.net> wrote:
Hi Stephen,
I guess, in your scenario, the ping-pong is generated from repeater
TX
hang times? So, something like:
1) User keys up "Repeater A" directly.
2) Simplex AllStar link "Radio 1" hears "Repeater A" TX audio and/or hang time and repeats to the hub.
3) Simple AllStar link "Radio 2" connected to same hub keys and brings up "Repeater B"
4) "Repeater A" unkeys, "Radio 1" COS goes inactive, "Radio 2" unkeys.
5) "Radio 2" hears "Repeater B" TX audio and/or hang time, keys hub, "Radio 1" and "Repeater A".
6) "Repeater B" unkeys, "Radio 2" COS goes inactive, "Radio 1" unkeys.
7) Goto 2 and repeat forever
73, David KB4FXC
On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
On Fri, Aug 26, 2016 at 5:18 AM, David McGough <kb4fxc@inttek.net> wrote:
possibility would be to have a Repeater transmitted PL tone directly follow the Repeater COS....Then, the simplex link radios would look for that PL tone. If the Repeater's RX COS isn't active, no PL tone transmitted, and no ping-pong.
I picked this quote out because it's really the most important point in this thread and was dismissed due to not having the right controllers. This can be solved! As Pete said:
what you need to do is put the repeater in external mode (shorting a pin to ground) and then use the flat audio in and out on the db-15 connector in the back. there are pins for ptt and cos. A nice little RPI and a URI-X and you have yourself a first class controler for that repeater
And my recommendation is to not only use this for the controller, but to use it for the link. I've deployed a ton of 5 GHz wireless ethernet links with Ubiquiti and Mikrotik equipment. It works great between high repeater sites with line of sight between them. This is almost always cheaper than link radio + isolator + filters + hardline + antenna and will give you a full-duplex link with out-of-band control. Tom KD7LXL
what you need to do is put the repeater in external mode (shorting a pin to ground) and then use the flat audio in and out on the db-15 connector in the back.
there are pins for ptt and cos.
A nice little RPI and a URI-X and you have yourself a first class controler for that repeater
I have considered this... but we have one site that has no internet access and a linking radio is the only option we have. I am also worried about potential lockups of the repeater as these will be running in AMS mode. I think this has gotten corrected in the recent firmware release, but we do have one that has an older release and didn't want to take a chance on that. I do agree though, this is the optimal way to go. The only caveat I see with that is the potential for the digital hash to be fed into the USB interface and propagated across the network when the repeater is in C4FM mode. 73 Stephen K1LNX On Fri, Aug 26, 2016 at 12:04 PM, Tom Hayward <tom@tomh.us> wrote:
On Fri, Aug 26, 2016 at 5:18 AM, David McGough <kb4fxc@inttek.net> wrote:
possibility would be to have a Repeater transmitted PL tone directly follow the Repeater COS....Then, the simplex link radios would look for that PL tone. If the Repeater's RX COS isn't active, no PL tone transmitted, and no ping-pong.
I picked this quote out because it's really the most important point in this thread and was dismissed due to not having the right controllers. This can be solved!
As Pete said:
what you need to do is put the repeater in external mode (shorting a pin to ground) and then use the flat audio in and out on the db-15 connector in the back. there are pins for ptt and cos. A nice little RPI and a URI-X and you have yourself a first class controler for that repeater
And my recommendation is to not only use this for the controller, but to use it for the link. I've deployed a ton of 5 GHz wireless ethernet links with Ubiquiti and Mikrotik equipment. It works great between high repeater sites with line of sight between them. This is almost always cheaper than link radio + isolator + filters + hardline + antenna and will give you a full-duplex link with out-of-band control.
Tom KD7LXL _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/ mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
On Fri, Aug 26, 2016 at 10:08 AM, Stephen - K1LNX <k1lnx@k1lnx.net> wrote:
I have considered this... but we have one site that has no internet access and a linking radio is the only option we have.
They make great standalone controllers. Add a second URI for the link radio.
I am also worried about potential lockups of the repeater as these will be running in AMS mode. I think this has gotten corrected in the recent firmware release, but we do have one that has an older release and didn't want to take a chance on that.
There is a hardware watchdog you can enable. Any time the software stops responding, the board will reboot. http://blog.ricardoarturocabral.com/2013/01/auto-reboot-hung-raspberry-pi-us...
I do agree though, this is the optimal way to go. The only caveat I see with that is the potential for the digital hash to be fed into the USB interface and propagated across the network when the repeater is in C4FM mode.
If you use CTCSS instead of carrier squelch, this can be avoided. Tom KD7LXL
I agree that you *must* have a reliable way to control the hardware remotely--internal watchdogs are helpful, but not foolproof; I'm speaking from hard learned experience here with Ubiquiti radios, various SBC's and even one occasionally cantankerous Kenwood repeater I manage. ...Of course, this is an FCC requirement, too. Otherwise, the RPi3 can make a nifty, inexpensive stand-alone controller. If you're able to use duplex=3 mode, there is zero audio delay thru the sound FOB/URI/RIM, etc. On a final note for now, make sure the turn the TX power WAY down on those DR-1X repeaters and keep them cool. I understand they are prone to heat issues from ham conversations, which are almost always high-duty-cycle, particularly in a full-time linked system. 73, David KB4FXC On Fri, 26 Aug 2016, Stephen - K1LNX wrote:
what you need to do is put the repeater in external mode (shorting a pin to ground) and then use the flat audio in and out on the db-15 connector in the back.
there are pins for ptt and cos.
A nice little RPI and a URI-X and you have yourself a first class controler for that repeater
I have considered this... but we have one site that has no internet access and a linking radio is the only option we have. I am also worried about potential lockups of the repeater as these will be running in AMS mode. I think this has gotten corrected in the recent firmware release, but we do have one that has an older release and didn't want to take a chance on that. I do agree though, this is the optimal way to go. The only caveat I see with that is the potential for the digital hash to be fed into the USB interface and propagated across the network when the repeater is in C4FM mode.
73 Stephen K1LNX
On Fri, Aug 26, 2016 at 12:04 PM, Tom Hayward <tom@tomh.us> wrote:
On Fri, Aug 26, 2016 at 5:18 AM, David McGough <kb4fxc@inttek.net> wrote:
possibility would be to have a Repeater transmitted PL tone directly follow the Repeater COS....Then, the simplex link radios would look for that PL tone. If the Repeater's RX COS isn't active, no PL tone transmitted, and no ping-pong.
I picked this quote out because it's really the most important point in this thread and was dismissed due to not having the right controllers. This can be solved!
As Pete said:
what you need to do is put the repeater in external mode (shorting a pin to ground) and then use the flat audio in and out on the db-15 connector in the back. there are pins for ptt and cos. A nice little RPI and a URI-X and you have yourself a first class controler for that repeater
And my recommendation is to not only use this for the controller, but to use it for the link. I've deployed a ton of 5 GHz wireless ethernet links with Ubiquiti and Mikrotik equipment. It works great between high repeater sites with line of sight between them. This is almost always cheaper than link radio + isolator + filters + hardline + antenna and will give you a full-duplex link with out-of-band control.
Tom KD7LXL _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/ mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Hi guys... I am in the midst of deploying a 5 site system. All of the sites with the exception of my own will be using link radios sitting on the repeater pair, some sites do not have internet access so this is the only option. Each node will be permalinked to our hub.
What we discovered when we brought site number 3 online was the dreaded "ping-pong" effect, and I did some digging and found out about the rxondelay parameter, that seems to be the place to start with this.
The other option we are considering is dropping the hang time off each repeater and using app_rpt to do hang time and courtesy tones instead (duplex = 1 instead of 0) but not sure that would work real well or be optimal.
Anyone have any experience with a setup like this that can offer some advice? This is my first foray into this unfortunately, I've always just interfaced the radio or repeater directly to app_rpt in the past or through a controller so it's been a bit of a challenge.
73 Stephen K1LNX _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
I can only speak to the PING-PONG... One or more of your systems are broadcasting past the rx cor into your network. Can't say how to fix because of unknown set-up but that is where you need to look. Setting the proper squelch type may be the answer. First find the culprit systems allowing a cor into it past the valid cos. This happens a lot when folks take a easy route to connect a echolink system through a simple radio link to the repeater. Easy fix is a tone and tone pass-through on the repeater and a tone squelch on the transceiver with the echolink connection. If both systems are not compliant with that, you still get PING and no PONG. The network should "not" be listening to a repeater tail or anything past a cos. Everything has to be playing by the same rules. To find it, just follow the logic of what is exactly happening. Network broadcast only on valid cor. Find the invalid cos into the tail. Must be more than one if ping-pong. ...mike/kb8jnm
participants (8)
-
Bob -
Bob Pyke
-
David McGough -
mike＠midnighteng.com -
petem001＠gmail.com -
Stephen - K1LNX -
Steve Zingman -
Tom Hayward