Simulcasting with RTCM/voter

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

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 list
To unsubscribe from this list please visit 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
407-982-0446

App_rpt-users@lists.allstarlink.orghttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usersJLeikhim@Leikhim.comWWW.LEIKHIM.COM

Hayden; How are you generating CTCSS tone?

···

On 3/13/2017 9:41 PM, Joe Leikhim
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!


-- Joe Leikhim
Leikhim and Associates
Communications Consultants
Oviedo, Florida
407-982-0446
    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 list
To unsubscribe from this list please visit 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.

App_rpt-users@lists.allstarlink.orghttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users


-- Joe Leikhim
Leikhim and Associates
Communications Consultants
Oviedo, Florida
407-982-0446

JLeikhim@Leikhim.comWWW.LEIKHIM.COM


_______________________________________________
App_rpt-users mailing list
To unsubscribe from this list please visit 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.

App_rpt-users@lists.allstarlink.orghttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usersJLeikhim@Leikhim.comWWW.LEIKHIM.COM

RTCM’s need rebooting too for the delay to take effect. At least my RTCM’s seemed to require it when I set them.

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.

Cheers,
Jesse

···

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 list
To unsubscribe from this list please visit 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.

App_rpt-users@lists.allstarlink.orghttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users


-- Joe Leikhim
Leikhim and Associates
Communications Consultants
Oviedo, Florida
407-982-0446

JLeikhim@Leikhim.comWWW.LEIKHIM.COM

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@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 list
App_rpt-users@lists.allstarlink.org
[http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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@Leikhim.com

407-982-0446

[WWW.LEIKHIM.COM](http://WWW.LEIKHIM.COM)

App_rpt-users mailing list

App_rpt-users@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.

Tim

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@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 list
App_rpt-users@lists.allstarlink.org
[http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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@Leikhim.com

407-982-0446

[WWW.LEIKHIM.COM](http://WWW.LEIKHIM.COM)


App_rpt-users mailing list
App_rpt-users@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.

Tim




_______________________________________________
App_rpt-users mailing list
To unsubscribe from this list please visit 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
407-982-0446

App_rpt-users@lists.allstarlink.orghttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usersJLeikhim@Leikhim.comWWW.LEIKHIM.COM

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@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.

_______________________________________________
App_rpt-users mailing list
App_rpt-users@lists.allstarlink.org
[http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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@Leikhim.com

407-982-0446

[WWW.LEIKHIM.COM](http://WWW.LEIKHIM.COM)

App_rpt-users mailing list

App_rpt-users@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.

      On Mon, Mar 13, 2017 at 6:41 PM, Joe

Leikhim rhyolite@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 list
App_rpt-users@lists.allstarlink.org
[http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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@Leikhim.com

407-982-0446

[WWW.LEIKHIM.COM](http://WWW.LEIKHIM.COM)


App_rpt-users mailing list
App_rpt-users@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.

Tim

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.

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@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@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.

Jeff;

Yes True; It is indeed the audio phasing 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.

  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.

Joe

···

On 3/14/2017 12:34 AM, Jeff DePolo
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.
_______________________________________________
App_rpt-users mailing list
To unsubscribe from this list please visit 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
407-982-0446

https://www.avast.com/antivirusApp_rpt-users@lists.allstarlink.orghttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-usersJLeikhim@Leikhim.comWWW.LEIKHIM.COM