[App_rpt-users] Simulcasting with RTCM/voter

[Joe Moskalski]

Jeff is correct for pointing out the need for coverage modeling. This saves
a great deal of time, effort and guess work. Terrain makes a huge
difference when it comes to where you have overlap and also where you have
overlap and lack capture of any one transmitter site. One thing many people
get wrong with simulcast is that more power can be detrimental to achieving
your goal. Modeling the coverage from each site and choosing the particular
antenna and pattern for where you want to cover in respect to the other
transmitters is key. In my humble opinion and it has worked for me, my main
goal when creating a simulcast system is not how to get the audio sounding
good in overlap but how to reduce the overlap areas with no capture to a
minimum. This has to do mainly with the terrain causing issues where you
audio is not arriving to the field unit(s) with the calculated delay due to
anomalies in the terrain.
You also need to pay attention to particular antenna characteristics such
as gain, electrical down tilt, mechanical down tilt and so on. I have found
normally the site within a simulcast system that has the greatest coverage
is often the site with one of the lowest ERP's. Once the RF coverage side
of the house is right, the rest is adjustable. This is coming from a
commercial simulcast standpoint.

On Tue, Mar 14, 2017 at 12:34 AM, Jeff DePolo <jd0 at broadsci.com> wrote:

> > 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.
>
> 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.
>
> > 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.
>
> 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.
>
> > 1) Don't worry about frequency offset until you are sure the
> > timing and other parameters are correct.
>
> 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.
> https://www.avast.com/antivirus
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit http://lists.allstarlink.org/
> cgi-bin/mailman/listinfo/app_rpt-users 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20170314/c55e8a98/attachment.html>