RTCM simplex node question for the group

App_rpt-users
1

Our current system has a hub node, that has Echolink on a private node number “1000”. Then we have another private node running on a raspberry pi, that ties back to the hub (node 1200). And a third node that is a RTCM (node 1100) that is connected to a RLC-Club Deluxe at a site. We are having a delayed echo effect on audio coming from Echolink on the private node, and also the private node running on the raspberry pi. When we disconnect the RTCM node, all echo’ing goes away. What am I missing here? Do we have to have GPS on that RTCM and another one here at the HUB to get this to stop? Thank you for any guidance. (I removed all private info below and replaced with x’s)

Voter Ping from cli:

ING (client1): Packets tx: 100, rx: 100, oos: 0, Avg.: 45.370 ms
PING (client1): Worst: 72 ms, Best: 41 ms, 100.0% Packets successfully received (0.0% loss)

rpt.conf:

[1000]

rxchannel = DAHDI/pseudo
duplex = 0
linktolink = yes
erxgain = 3
etxgain = 3
link_functions = functions
context = radio-secure
accountcode = echo

[1100]

rxchannel = Voter/1100
duplex = 0
linktolink = yes
linkmongain = 0
erxgain = 4
etxgain = 3
eannmode = 2
controlstates = controlstates
scheduler = schedule
functions = functions
remote_dtmf_allowed=1
propagate_phonedtmf = yes
propogate_dtmf = yes
phone_functions = functions
link_functions = functions
telemetry = telemetry
morse = morse
wait_times = wait-times
context = radio
callerid = “Repeater” <0000001100>
accountcode = RADIO

voter.conf:

[general]
port = 667
buflen = 250
password = xxxxx
utos = y

[1100]
client1 = xxxxx,transmit,nodeemp
plfilter = y
txctcss = 77.0
txctcsslevel = 0
txtoctype = none
thresholds = 255,110=5

extensions.conf:

[general]

static = yes ; These two lines prevent the command-line interface
writeprotect = yes ; from overwriting the config file. Leave them here.

[globals]
HOMENPA = xxx ; change this to your Area Code
NODE = xxxxxx ; change this to your node number

[default]

exten => i,1,Hangup

[radio-secure]
exten => 1000,1,Rpt(1000|X)

[radio-secure]
exten => 1100,1,Rpt(1100|X)

[radio-secure]
exten => 1200,1,Rpt(1200|X)

[radio-secure]
exten => ${NODE},1,rpt,${NODE}

RTCM settings:

  • Serial # (xxxx) (which is MAC ADDR xx:xx:xx:xx:xx:xx)
    2 - VOTER Server Address (FQDN) (xxxxxxxxxxxxxxxxxx)
    3 - VOTER Server Port (667), 4 - Local Port (Override) (0)
    5 - Client Password (xxxxxxx), 6 - Host Password (xxxxxx)
    7 - Tx Buffer Length (1200)
    8 - GPS Data Protocol (0=NMEA, 1=TSIP) (0)
    9 - GPS Serial Polarity (0=Non-Inverted, 1=Inverted) (0)
    10 - GPS PPS Polarity (0=Non-Inverted, 1=Inverted, 2=NONE) (2)
    11 - GPS Baud Rate (4800)
    12 - External CTCSS (0=Ignore, 1=Non-Inverted, 2=Inverted) (2)
    13 - COR Type (0=Normal, 1=IGNORE COR, 2=No Receiver) (1)
    14 - Debug Level (9)
    15 - Alt. VOTER Server Address (FQDN) (0)
    16 - Alt. VOTER Server Port (Override) (0)
    17 - DSP/BEW Mode NOT SUPPORTED
    18 - “Duplex Mode 3” (0=DISABLED, 1-255 Hang Time) (1/10 secs) (0)
    19 - Simulcast Launch Delay (0) (approx 200 ns, 5 = 1us, > 0 to ENA SC)
    97 - RX Level, 98 - Status, 99 - Save Values to EEPROM
    i - IP Parameters menu, o - Offline Mode Parameters menu
    q - Disconnect Remote Console Session, r - reboot system, d - diagnostics

73’s - Ian

2

Nope, a GPS won’t fix that. Make sure the port on the RLC is not set up to repeat. On node 1100 set linktolink = yes in rpt.conf. Also, in voter.conf under [1100] you might need mixminus = y.

1 Like
3

Thanks Tim!

Do I also want linktolink = yes for node 1000 the Echolink node? It’s set for duplex = 0 and nounkeyct = 1, with the id commented out.

73’s - Ian

4

Alright, it seems like that fixed everything. The only small detail is a long hangtime coming from the RTCM to the RLC-Club Deluxe. I assume this is from the buffer settings? Any way to reduce it and not affect the buffer?

5

Just to clarify, I have verified that the repeater controller the RTCM is interfaced to has no hang timer. When the RTCM TX’s audio over the network, there is little to no hang time at the end of transmission. But when a signal comes in to the RTCM from the network it presents around 4-5 seconds of hangtime, even with duplex=0, and linktolink=yes. I am hoping that there is something that I am missing, but if that is how it generally goes for a RTCM deployed over the internet and not a direct microwave link to the site, then that’s all there is to that matter. :slight_smile: Thoughts?

6

In rpt.conf change hangtime to zero for the RTCM node.

hangtime = 0				; squelch tail hang time (in ms) (optional, default 5 seconds, 5000 ms)
7

Thanks Tim. That worked. Funny though, I thought the duplex=0 and linktolink=yes took out the hangtimes. But making that adjustment got rid of the 4-5 seconds of hangtime we we’re seeing.