[App_rpt-users] Simulcasting with RTCM/voter

Joe Moskalski kc2irv at gmail.com
Tue Mar 14 03:33:30 UTC 2017


I have two sites on UHF 18 miles apart simulcasting with the RTCM's. use
the 9.6 MHz OCXO's for the clock in the RTCM improves their simulcast
usability greatly but I do have some CTCSS wobble in some areas between the
sites. It does not cause any issues with the intelligibility of the audio
but you can hear it is there in non capture overlap areas. This is the
first I am hearing of the DAC issue which certainly explains it. I tailored
the system for minimum overlap and my CTCSS tones are deviating at 400 Hz
to further reduce the audio of the CTCSS wobble. 400 Hz is more than enough
CTCSS level for any modern radio to decode almost right down to the noise.
Anyway this is what I have done and so far its been working very well.

On Mon, Mar 13, 2017 at 11:15 PM, Joe Leikhim <rhyolite at leikhim.com> wrote:

> Thanks Tim!
>
> So the CTCSS is starting out of phase. Does this affect voice audio and
> tones in that bandwidth as well?
>
> I am a long time lurker, wishing to put this technology to use someday. I
> was saddened to learn that Jim Dixon passed away. I hope someone can take
> the torch and further develop this promising product.
>
> As you probably know commercial simulcast is very expensive to deploy and
> for a single channel system the cost is ridiculous because commercial
> hardware is scaled for larger networks.  So this could have applications in
> commercial applications as well.
>
>
> Joe
>
>
> On 3/13/2017 11:01 PM, Tim Sawyer wrote:
>
> Joe's statement about launch delay is critical and that unfortunately is
> the problem with RTCMs in simulcast. The problem is the DAC used in the
> RTCM does not start at the exact time every time. I remember Jim Dixon
> working on this issue and was unable to workaround the problem that is
> build into the silicon. The problem is particularly noticeable when humming
> tone on the TX. If you can get by with no PL and limit your coverage
> overlap you can simulcast with RTCM but it's never going to be perfect.
>
> On Mon, Mar 13, 2017 at 6:41 PM, Joe Leikhim <rhyolite at leikhim.com> wrote:
>
>> Wow;
>>
>> Great project. I suggest documenting everything and permanently posting
>> for others to review the system design as a reference.
>>
>> 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.
>>
>> Here is an example, picture two sites x1 and x2 spaced exactly 13 miles
>> apart.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> There are a couple very proprietary computer programs for modeling this,
>> however it can be worked out by hand.
>>
>> Some thoughts.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 4) The audio chain needs to be identical. Any filters, amps etc, in the
>> transmitter audio chain must be same at each site.
>>
>> 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.
>>
>> 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.
>> I hope this helps!
>>
>>
>> On 3/13/2017 7:15 PM, Hayden Honeywood wrote:
>>
>> Hi All,
>> Thanks for all on the list who have given me a hand with getting the
>> RTCM/voter boards running.
>>
>> I currently have 1/3 of my system installed at the sites. It's as follows:
>>
>> 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.
>>
>> 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.
>>
>> 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).
>>
>> 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.
>>
>> 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?
>>
>> Hayden
>>
>>
>> _______________________________________________
>> App_rpt-users mailing listApp_rpt-users at lists.allstarlink.orghttp://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.
>>
>> --
>> Joe Leikhim
>>
>>
>> Leikhim and Associates
>>
>> Communications Consultants
>>
>> Oviedo, Florida
>> JLeikhim at Leikhim.com
>> 407-982-0446 <%28407%29%20982-0446>
>> WWW.LEIKHIM.COM
>>
>> _______________________________________________ App_rpt-users mailing
>> list App_rpt-users at lists.allstarlink.org http://lists.allstarlink.org/c
>> gi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list
>> please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rp
>> t-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.
>
> --
> --
> Tim
>
> _______________________________________________
> App_rpt-users mailing listApp_rpt-users at lists.allstarlink.orghttp://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.
>
> --
> Joe Leikhim
>
>
> Leikhim and Associates
>
> Communications Consultants
>
> Oviedo, Florida
> JLeikhim at Leikhim.com
> 407-982-0446 <(407)%20982-0446>
> WWW.LEIKHIM.COM
>
>
> _______________________________________________
> 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/20170313/e03f2dcf/attachment.html>


More information about the App_rpt-users mailing list