<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>RTCM's need rebooting too for the delay to take effect. At least my RTCM's seemed to require it when I set them. <br><br>Also when I was experimenting I set the launch delay on the RTCM under test to the propagation time from the remote side to the site I was at. Then I put a dummy load on it (which I could hear from ~20 ft away). I could enable the remote site and listen to the two signals, see how the sounded and make sure that the settings were doing what was expected. Once set properly I could run audio through the remote site and key/unkey the local site under test with no noticeable distortion. Of course this only works if theres a decent RF path from one site to the other. <br><br>Cheers,<br><div>Jesse</div></div><div><br>On Mar 13, 2017, at 6:41 PM, Joe Leikhim <<a href="mailto:rhyolite@leikhim.com">rhyolite@leikhim.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<p>Wow; <br>
</p>
<p>Great project. I suggest documenting everything and permanently
posting for others to review the system design as a reference.</p>
<p>My background is in Public Safety LMR design so I have dabbled a
bit in VHF, UHF and 800 MHz simulcast both analog and digital. I
might be able to do some computer modelling for you. <br>
</p>
<p>Here is an example, picture two sites x1 and x2 spaced exactly 13
miles apart. <br>
</p>
<p>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 <u>bulk delay</u> 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. <br>
</p>
<p>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. <br>
</p>
<p>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. <br>
</p>
<p>As a mobile travels away from center and along or behind the
hyperbolic curves )(, the time differential will increase,
creating time differential interference (TDI), or intersymbol
interference (ISI) in a digital system. This can be calculated at
any point location by using a map and a mileage scale.<br>
</p>
<p>A mobile very close to or behind either site (paced 13 miles)
will experience the delay of 70.2 us or more. This is somewhat
mitigated by the capture effect of the closest site and the
capture ratio afforded by the modulation index. TDI at 70.2 us is
not too bad for analog FM. 135 us, the distortion might be
intolerable. <br>
</p>
<p>Adding a third site will require consideration that its signal
may arrive earlier or later than the sites described above, In the
event the third site is closer than 6.5 miles, the adjustment
would be to increase the launch delay for the third site to meet
with sites 1 and 2. If it is further than 6.5 miles, the delay of
sites 1 and 2 could be increased equally by the amount required
for site 3 to travel.</p>
<p>A variation of this scheme, is one where a central site is
predominant and is ringed by remote sites. In one configuration,
the central site has an omni directional antenna and the remote
sites have directional antennas facing outward. The central site
would be timed to transmit first, and the remote sites would be
delayed until the wavefront reaches them. If the distances are
unequal, the remote sites would be timed +/- the time differential
of the central site reaching them.<br>
</p>
<p>There are a couple very proprietary computer programs for
modeling this, however it can be worked out by hand.</p>
<p>Some thoughts.</p>
<p>1) Don't worry about frequency offset until you are sure the
timing and other parameters are correct. Set everything dead on
with GPS to start. In commercial systems using GPS disciplined
reference frequency offset is usually not performed.<br>
</p>
<p>2) Make 100% sure that the modulators are wired for the same
polarity. It makes no sense to have one transmitter deviating +4
KHz while another is going -4KHz. Same goes for voice and CTCSS
modulation.</p>
<p>3) Are your transmitters the exact same make/model and version?
This can be a non starter. You can get away with different RF
amps, filters etc, but if you have a Micor exciter and a Mastr II
exciter it is going to be funky.</p>
<p>4) The audio chain needs to be identical. Any filters, amps etc,
in the transmitter audio chain must be same at each site.<br>
</p>
<p>5) Adjust the modulation limiting such that the transmitter audio
is never in limiting. For Part 97 work, you could get away with
the limiter adjusted beyond system deviation and set the RTCM so
that deviation is equal to 5 KHz. Voice deviation for each
transmitter must be identical, same with CTCSS.<br>
</p>
<p>For my commercial projects I recommend the entire simulcast
system be staged in a warehouse so that all these parameters can
be set at same time with same test equipment in a controlled
environment. Any errors must track the same direction. You can do
this remotely, but noisy signals will make the setting of values
less than ideal. If you reach a level of frustration, bring it all
home and tweak it.<br>
</p>
I hope this helps!<br>
<br>
<div class="moz-cite-prefix">On 3/13/2017 7:15 PM, Hayden Honeywood
wrote:<br>
</div>
<blockquote cite="mid:CAC0VLD3XjAnq=j7XQsDOpvcmha5FmD9BORJ8G92EWPXjcVsjQg@mail.gmail.com" type="cite">
<div dir="ltr">Hi All,
<div>Thanks for all on the list who have given me a hand with
getting the RTCM/voter boards running.</div>
<div><br>
</div>
<div>I currently have 1/3 of my system installed at the sites.
It's as follows:</div>
<div><br>
</div>
<div>A TX only site - running a VOTER board, latest "Chuck"
firmware. 9.6MHz OCXO replacing the onboard crystal and a
10MHz OCXO to keep the transmitter stable all on 53MHz.</div>
<div><br>
</div>
<div>On my bench at home I have an identical setup except with a
receiver in addition. Both radios are the same, audio injected
in the same spot.</div>
<div><br>
</div>
<div>I've been testing various frequency offsets to avoid the
cancelling of the signal due to the inherent propagation
effects at 6 metres. I've been able to run my bench radio into
a dummy load and place it so that another radio nearby
connected to an external antenna is receiving them almost the
same (i.e. overlap). </div>
<div><br>
</div>
<div>Currently 1-2Hz sounds the best. I have been encoding tone,
however there is a very audible hum, as if the CTCSS tone from
each transmitter is not in phase. The tone is 91.5Hz. I've
checked/readjusted deviation levels etc, also checked the
9.6MHz OCXO etc but I cannot seem to null it out.</div>
<div><br>
</div>
<div>I've also tested the Simulcast Launch Delay.The main site
is about 13 miles away, so I put a value of 330 in there to
represent a delay of 66uS on the bench test radio. This makes
a little bit of improvement, but not an overall huge
improvement. Does anyone have an ideas that I've missed or
more information on the usage of the Simulcast Launch delay?</div>
<div><br>
</div>
<div>Hayden </div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>App_rpt-users mailing list</span><br><span><a href="mailto:App_rpt-users@lists.allstarlink.org">App_rpt-users@lists.allstarlink.org</a></span><br><span><a href="http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users">http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users</a></span><br><span></span><br><span>To unsubscribe from this list please visit <a 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"</span><br><span>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. </span></div></blockquote></body></html>