Wait for the repeater to drop before you can transmit?

App_rpt-users
1

On an arcom/repeater with allstar drving a USB-RA40, I noticed the allstar users don’t hear the next transmission, if they don’t first allow the repeater to completely drop (ie, if you transmit on RF before the allstarlink courtesey tone, none of the allstarlink users hear the transmission – none of it).

So we always say “let the repeater drop” before you transmit…

Is that normal? fix? arcom side? allstar side?

curiously,
-craig

2

Assuming the RA40 is connected to a port on the Arcom controller, be sure to set duplex=0 by editing /etc/asterisk/rpt.conf

3

Confirmed, RA40 connected to port on Arcom, duplex=0 in rpt.conf.

Still lookin’ for hints. Is it the Arcom? something to do with COS signal overlap?

4

Something is not full duplex. What is the node number so I can connect to it?

5

51018

let me know a time you connect so i can replicate the problem. if I transmit on RF before i hear your allstar courtesey tone, you wont hear any of my transmission, not just the overlap, but none of it.

thanks!
-craig

6

Calling you now from our hub… I didn’t get a response from you. I’ll leave the connection up and listen for your call back. You might hear some traffic from our side.

1 Like
7

The result of our QSO is that there is a courtesy tone and short hang time from node 51018 when when you unkey. This almost sounds like I am hearing your repeater output except for the fact that there is no tone or hang time when I unkey.

That being the case, I have to assume the arcom controller’s port is configured as repeater or remote base. This must be changed as it is improper to send curtesy tones, hang time or IDs down AllStar links as it can cause an endless keying cycle.

I did come up with another thought since we talked. In addition to the arcom changes, please try setting hangtime = 0 and linktolink = yes in rpt.conf.

1 Like
8

thanks for the help today… settings changed (hangtime and linktolink) will restart after our Net.

repeater custodian will look into link vs repeater and ptt priority on arcom side

9

Also noticed the arcom port AllStar is connect to is not full duplex. That may be part of the issue.

10

ok, we tried a few combinations of duplex and linktolink.

duplex=0
linktolink=1

We didn’t have to wait for the repeater to drop, worked great!
Except… bad echoes for all internet-to-internet connections (no echoes heard on rf)

Should arcom port be half duplex? full?

11

I think the echo is coming from the arcom. See if there is a way to make it full duplex without repeat. It’s a link so there should no audio path from the port’s own Rx to Tx.

12

I think you will find the ARCOM repeats in hardware and there is nothing you can do about it. I would be curious to hear if you do find a way (!)

Obvious solution to this is to eliminate the ARCOM and go Allstar direct to the repeater itself.

Ken
KE2N

13

Whichever Port you have Allstar connected to the RC210, make sure that Port is NOT set to Repeater Mode and also make sure you have zero hangtime programmed for it

14

All Ports on the RC210 are indeed full duplex. Just don’t set that Port to Repeater Mode and you’re good to go

15

okay, thanks to all of you and all your comments, everything is working perfectly!

to recap, we had to,

duplex=0
linktolink=yes
hangtime=0

and on the arcom, we had to disable “repeat” on the port connected to the allstarlink pi

perfect!! thank you!

-craig
KM6LYW

16

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.