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?


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.


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

Reply via email to