<div dir="ltr"><div class="gmail_extra">

<pre style="font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="arial, sans-serif"><span style="font-size:12.8px;white-space:normal">Interesting thoughts Tim... perhaps worth documenting on the wiki? Even though it was just "in theory", what kind of sync error was it? Were we talking microseconds or even more?</span></font></pre><pre style="font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="arial, sans-serif"><span style="font-size:12.8px;white-space:normal">I have a receiver on a yagi pointed at a distant simulcasted site. I have noticed on occasion, I can hear the distant simulcasted site start to send audio underneath the carrier of the site that is closest (and strongest to me). The distant site is also the master site, and has the lowest latency, but I'm talking two words worth of audio is send before my other site starts sending audio. Once they are both transmitting, I  have not noticed any timing issues (i.e. distortion etc). I'm not sure if this issue was related to what I posted previously about the variable audio delay on unkey.</span></font></pre><pre style="font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="arial, sans-serif"><span style="font-size:12.8px;white-space:normal">I'm running app_rpt on a Raspberry Pi using a cut down image we use here in VK.</span></font></pre><pre style="text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="arial, sans-serif"><span style="font-size:12.8px;white-space:normal"><a href="http://vklink.com.au">http://vklink.com.au</a><br></span></font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">"When simulcasting the audio from all (non captured) transmitters needs to
arrive at the receiver with in an acceptable time frame (80 us). The DAC
theory was that it didn't start sending audio at correct clock cycle every
time. That would cause the audio to be out of sync between RTCMs causing
simulcast distortion.

As I said, that was the theory. The new theory is that the external clock
source was causing the DAC to trigger inappropriately. I spoke with someone
I met here on the list (Kevin I think its was) who is using a different
external clock and reports perfect simulcast operations"</pre>

<br></div></div>