Voter RTCM TX buffer hardware limitation?
Hi I get two rtcm module for use as voting controller for my repeater as an upgrade from a home-made controller/IDer. Almost all the user of the repeater rely on duplexing (listening to the repeater while you talk). Ever since I put the rtcm module, several are slightly annoyed and confused by the audio delay in the repeater. The rtcm modules and the app_rpt server are connected on Ubiquiti with less than 3ms ping directly into a 4 port ethernet switch. I have my chan_voter config set for 180 buffer, and the RTCM TX buffer set at 800 (lowest the console will let me enter), and the delay is great enough to where it's a problem for this type of application. Is this a matter of using less data-intensive audio codec, or is this RTCM hardware limitation? Maybe to make a firmware upgrade that allows rtcm voting TX buffer to decrease to a acceptable value for this type of full-duplex application? I was exicted to see lastest RTCM firmware update until I realized it would not work with voting. Sorry for the bad English and Have a nice dayde Harashad
I have a similar setup, Ubiquiti equipment and network has low latency. RX buffer is 180, TX is 1200. And like you say it's not possible to operate full duplex as the delay is too great. The the delay is mostly in the network. It takes time to buffer up the UDP packets. -- Tim :wq On Jul 26, 2013, at 11:17 PM, Harshad Rangarajan <pyaslagna@gmx.com> wrote:
Hi I get two rtcm module for use as voting controller for my repeater as an upgrade from a home-made controller/IDer. Almost all the user of the repeater rely on duplexing (listening to the repeater while you talk). Ever since I put the rtcm module, several are slightly annoyed and confused by the audio delay in the repeater. The rtcm modules and the app_rpt server are connected on Ubiquiti with less than 3ms ping directly into a 4 port ethernet switch. I have my chan_voter config set for 180 buffer, and the RTCM TX buffer set at 800 (lowest the console will let me enter), and the delay is great enough to where it's a problem for this type of application. Is this a matter of using less data-intensive audio codec, or is this RTCM hardware limitation? Maybe to make a firmware upgrade that allows rtcm voting TX buffer to decrease to a acceptable value for this type of full-duplex application? I was exicted to see lastest RTCM firmware update until I realized it would not work with voting. Sorry for the bad English and Have a nice dayde Harashad
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
"I was exicted to see lastest RTCM firmware update until I realized it would not work with voting. " Of course it works with voting.... What are you talking about??? Jim WB6NIL Date: Sat, 27 Jul 2013 02:17:20 -0400 From: pyaslagna@gmx.com To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Voter RTCM TX buffer hardware limitation? Hi I get two rtcm module for use as voting controller for my repeater as an upgrade from a home-made controller/IDer. Almost all the user of the repeater rely on duplexing (listening to the repeater while you talk). Ever since I put the rtcm module, several are slightly annoyed and confused by the audio delay in the repeater. The rtcm modules and the app_rpt server are connected on Ubiquiti with less than 3ms ping directly into a 4 port ethernet switch. I have my chan_voter config set for 180 buffer, and the RTCM TX buffer set at 800 (lowest the console will let me enter), and the delay is great enough to where it's a problem for this type of application. Is this a matter of using less data-intensive audio codec, or is this RTCM hardware limitation? Maybe to make a firmware upgrade that allows rtcm voting TX buffer to decrease to a acceptable value for this type of full-duplex application? I was exicted to see lastest RTCM firmware update until I realized it would not work with voting. Sorry for the bad English and Have a nice dayde Harashad _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
I think he is taking about duplex mode 3 support. -- Tim :wq On Jul 27, 2013, at 10:24 AM, Jim Duuuude <telesistant@hotmail.com> wrote:
"I was exicted to see lastest RTCM firmware update until I realized it would not work with voting. "
Of course it works with voting....
What are you talking about???
Jim WB6NIL
Date: Sat, 27 Jul 2013 02:17:20 -0400 From: pyaslagna@gmx.com To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Voter RTCM TX buffer hardware limitation?
Hi I get two rtcm module for use as voting controller for my repeater as an upgrade from a home-made controller/IDer. Almost all the user of the repeater rely on duplexing (listening to the repeater while you talk). Ever since I put the rtcm module, several are slightly annoyed and confused by the audio delay in the repeater. The rtcm modules and the app_rpt server are connected on Ubiquiti with less than 3ms ping directly into a 4 port ethernet switch. I have my chan_voter config set for 180 buffer, and the RTCM TX buffer set at 800 (lowest the console will let me enter), and the delay is great enough to where it's a problem for this type of application. Is this a matter of using less data-intensive audio codec, or is this RTCM hardware limitation? Maybe to make a firmware upgrade that allows rtcm voting TX buffer to decrease to a acceptable value for this type of full-duplex application? I was exicted to see lastest RTCM firmware update until I realized it would not work with voting. Sorry for the bad English and Have a nice dayde Harashad
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
participants (3)
-
Harshad Rangarajan -
Jim Duuuude -
Tim Sawyer