<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Jeff;</p>
<p>Yes True; It is indeed the <u>audio phasing</u> that needs to be
synced at midpoint. I was trying to state in as few words as
possible a very complex topic. And yes, in the "real world" the
reception will have exaggerated multi-path effects due to the
frequency error which are unavoidable. I worked on some of the
early crude analog 800 MHz FM simulcast and my ears hurt
listening to them. <br>
</p>
<p>Going from two transmitters to three or four (or more) becomes
very complex in short order. I have used computer software to
simulate all the effects to timing offset signal strength
(reliability) and signal capture. EIA/TIA TSB-88D describes monte
carlo power weighted methodology used in the computer models. Some
software models can do automatic iterations of timing to choose
best fit. <br>
</p>
<p><br>
</p>
<p>Joe<br>
</p>
<br>
<div class="moz-cite-prefix">On 3/14/2017 12:34 AM, Jeff DePolo
wrote:<br>
</div>
<blockquote cite="mid:68E55B6AFB4B4211AA31948BDCFCC852@OUTLAW"
type="cite">
<blockquote type="cite">
<pre wrap="">First: They both need to launch the audio waveform at exactly
the same time T=0 in same phase. This also means that there
may need to be bulk delay to ensure that the most distant
(with respect to the IP back haul network) transmitter site,
receives the entire data payload before it is transmitted. I
am just learning about the RTCM so I believe that bulk delay
is inherent to the process.
Assuming both sites are exactly synced T=0, then where the
wave fronts meet midway will be in exactly sync even though
35.1us (6.5 miles x 5.4 us = 35.1 us) has passed due to
propagation delay.
</pre>
</blockquote>
<pre wrap="">
That's not correct (the part about "the wave fronts"). Simulcast audio/PL
launch delay only guarantees AF synchronicity to the extent
practical/possible (e.g. within a few microseconds of each other), but
certainly not at the same RF phase. A microsecond at 150 MHz is 150 cycles.
</pre>
<blockquote type="cite">
<pre wrap="">The wave fronts will also form a pair of theoretical opposing
hyperbolic curves that meet at the center of the two sites
like this: x1 )( x2 with the x representing each site.
</pre>
</blockquote>
<pre wrap="">
Again, you can't look at it in the RF domain; AF sync is what you're working
hard to achieve; you'll never get it at RF.
Also keep in mind that sync at the midpoint isn't necessarily the goal. In
a perfect world with no terrain, identical antenna patterns, identical ERP,
etc. it might be, but not in the real world. You need to do coverage models
for each of the sites (using actual ERP's and antenna patterns), see where
the most-problematic areas are (i.e. the areas where capture effect isn't
going to hide potential sins), and make decisions as to where to optimize
and where to tolerate degradation, and then set delays accordingly.
</pre>
<blockquote type="cite">
<pre wrap="">1) Don't worry about frequency offset until you are sure the
timing and other parameters are correct.
</pre>
</blockquote>
<pre wrap="">
Agree. Until the delays are correct (and again, that doesn't necessarily
mean equal at the midpoint), there's no sense in adding another variable to
the equation. Offsetting carrier frequency only helps mitigate cancellation
nulls, it does nothing to mitigate delay errors.
--- Jeff WN3A
---
This email has been checked for viruses by Avast antivirus software.
<a class="moz-txt-link-freetext" href="https://www.avast.com/antivirus">https://www.avast.com/antivirus</a>
_______________________________________________
App_rpt-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:App_rpt-users@lists.allstarlink.org">App_rpt-users@lists.allstarlink.org</a>
<a class="moz-txt-link-freetext" href="http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users">http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users</a>
To unsubscribe from this list please visit <a class="moz-txt-link-freetext" href="http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users">http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users</a> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button"
You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Joe Leikhim
Leikhim and Associates
Communications Consultants
Oviedo, Florida
<a class="moz-txt-link-abbreviated" href="mailto:JLeikhim@Leikhim.com">JLeikhim@Leikhim.com</a>
407-982-0446
<a class="moz-txt-link-abbreviated" href="http://WWW.LEIKHIM.COM">WWW.LEIKHIM.COM</a></pre>
</body>
</html>