On 3/6/18 08:05, Bill Somerville wrote: > > Our experience of users using the Elecraft remote kit using IP streaming > is that latency and delay are a problem, this being because of our > dependence on external wall clock synchronization. Can RTP provide > absolute time-stamp information that we can leverage to capture UTC time > sync relative to the source? Is there a recovery mechanism to "unbuffer" > when delays accumulate?
Bill, I'm finally reading through the RTCP spec (have only implemented RTP so far) and I see it already solves your exact problem. Every participant in a multicast group periodically multicasts reports to the group. Every RTCP sender report includes a 32-bit RTP timestamp and a corresponding NTP (Network Time Protocol) timestamp. This lets every receiver derive absolute clock time (to the sender's accuracy) for any received sample in the RTP stream. The 64-bit NTP timestamp is divided into two 32-bit parts: an integer count of seconds since January 1, 1900 (at 00:00:00 UT, presumably) and a 32-bit count of fractional seconds. As much as I dislike NTP's use of universal time, which introduces the many headaches of leap seconds, and the fact that this timestamp will roll over in 2036, I will probably switch to using it to timestamp my I/Q samples to avoid inflicting yet another "standard" on the world. Phil ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
