Re: [App_rpt-users] Voter RTCM TX buffer hardware limitation?
Exactly, Tim. Jim, According to the firmware release notes, Duplex mode 3 will not solve my problem because I am using voting via app_rpt.Duplex mode 3 just loops RX audio to TX audio inside the RTCM, and app_rpt inject ID and telemetry. Even with all the equipment in one room plugged to a router, the latency is still existant. How could this be network latency if the lowest possible buffer value in app_rpt and in the RTCM works, but it is still not fast enough? If this were a network latency issue, than the lowest possible buffer (which is working for me) simply woldn't be able to work! In my case, the lowest buffer value that the RTCM will allow me to enter (800) works, and that tells me that the network isn't what's keeping me from reducing the latency. By putting the server and the RTCMs in a room and plugging them up to a router/switch, the latency is still too high for full-duplex operation, with the buffer values set to lowest value that RTCM and app_rpt will allow to be inputted. This cleary tell me that the limitation is in the RTCM minumum TX buffer limit of 800 samples. Is there any for me to trick the RTCM into accepting buffer values lower than 800? This would be a HUGE help to us. Thank you! Harshad
The chan_voter/Voter Board/RTCM stuff is *NEVER* going to be without audible delay. In no way, shape or form, was it EVER even considered to be a valid or viable option for systems where full-duplex USER operation is needed (because of the inherent delays involved). Now, what I am interested in, is: 1) What are you doing that requires or even has full duplex user operation as a "desirable" aspect? 2) What are you using for full-dupex user hardware (radios)? Jim WB6NIL Date: Sun, 28 Jul 2013 14:51:50 -0400 From: pyaslagna@gmx.com To: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Voter RTCM TX buffer hardware limitation? Exactly, Tim. Jim, According to the firmware release notes, Duplex mode 3 will not solve my problem because I am using voting via app_rpt.Duplex mode 3 just loops RX audio to TX audio inside the RTCM, and app_rpt inject ID and telemetry. Even with all the equipment in one room plugged to a router, the latency is still existant. How could this be network latency if the lowest possible buffer value in app_rpt and in the RTCM works, but it is still not fast enough? If this were a network latency issue, than the lowest possible buffer (which is working for me) simply woldn't be able to work! In my case, the lowest buffer value that the RTCM will allow me to enter (800) works, and that tells me that the network isn't what's keeping me from reducing the latency. By putting the server and the RTCMs in a room and plugging them up to a router/switch, the latency is still too high for full-duplex operation, with the buffer values set to lowest value that RTCM and app_rpt will allow to be inputted. This cleary tell me that the limitation is in the RTCM minumum TX buffer limit of 800 samples. Is there any for me to trick the RTCM into accepting buffer values lower than 800? This would be a HUGE help to us. Thank you! Harshad _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
participants (2)
-
Harshad Rangarajan -
Jim Duuuude