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

  1. Simple AllStar link “Radio 2” connected to same hub keys and brings up

“Repeater B”

  1. “Repeater A” unkeys, “Radio 1” COS goes inactive, “Radio 2” unkeys.

  2. “Radio 2” hears “Repeater B” TX audio and/or hang time, keys hub,

“Radio 1” and “Repeater A”.

  1. “Repeater B” unkeys, “Radio 2” COS goes inactive, “Radio 1” unkeys.

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

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.

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 list
To unsubscribe from this list please visit 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"

App_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

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

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

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

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
[http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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"
      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.
  1. Simplex AllStar link “Radio 1” hears “Repeater A” TX audio and/or hang

time and repeats to the hub.

  1. Simple AllStar link “Radio 2” connected to same hub keys and brings up

“Repeater B”

  1. “Repeater A” unkeys, “Radio 1” COS goes inactive, “Radio 2” unkeys.
  1. “Radio 2” hears “Repeater B” TX audio and/or hang time, keys hub,

“Radio 1” and “Repeater A”.

  1. “Repeater B” unkeys, “Radio 2” COS goes inactive, “Radio 1” unkeys.
  1. 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

[mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of David McGough

···

-----Original Message-----
From: app_rpt-users-bounces@ohnosec.org
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.

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

···

On Fri, Aug 26, 2016 at 5:18 AM, David McGough <kb4fxc@inttek.net> 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.

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.

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

···

On Fri, Aug 26, 2016 at 10:08 AM, Stephen - K1LNX <k1lnx@k1lnx.net> wrote:

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