[App_rpt-users] Voter RTCM TX buffer hardware limitation?

[Tim Sawyer]

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 at 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 at ohnosec.org
> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20130727/39d550fd/attachment.html>