Actions

Difference between revisions of "Simulcast Distortion"

From The RadioReference Wiki

m (Update, clarifications, deletions & additions, rearrangement of layout slightly)
(Corrections and deletions.)
Line 1: Line 1:
Current generation digital scanners, even upgraded to the most recent firmware (where applicable), do a poor job of handling [[P25 CAI]] [[simulcast]] system transmissions.  This problem is most evident when monitoring a true [[Project 25]] Simulcast system that use the [[CQPSK]]/[[LSM]] and [[H-DQPSK]] modulation scheme that is not FM modulation based. This is most often noticed by a breaking up of a fairly strong transmission that one would normally expect to be crystal clear.   In this article, we'll describe and explain the most common reason for this sort of problem, and suggest some ways you might alleviate some of the simulcast digital distortion sididi your receiver experiences.  
+
Current generation digital scanners, even upgraded to the most recent firmware (where applicable), do a poor job of handling [[P25 CAI]] [[simulcast]] system transmissions.  This problem is most evident when monitoring a true [[APCO Project 25]] Simulcast system that use the [[CQPSK]] (Motrola [[LSM]]/Harris WCQPSK) and [[H-DQPSK]] modulation scheme that is not FM modulation based. This is most often noticed by a breaking up of a fairly strong transmission that one would normally expect to be crystal clear. In this article, we'll describe and explain the most common reason for this sort of problem, and suggest some ways you might alleviate some of the simulcast distortion your receiver experiences.  
  
 
=Problem=
 
=Problem=
 
This problem is rooted in the hardware design of all scanners.  In scanners, the received signal is the passed through a FM demodulator before being processed by the digital signal processor (DSP) where the digital information is recovered.  This design is cheap to implement, but also strips the critical components of an incoming simulcast signal that is needed to guarantee a successful decode.  In other words, part of the signal information lost with no way to recover it.  The end result is the significantly degraded ability for scanners to successfully decode a simulcast signal.
 
This problem is rooted in the hardware design of all scanners.  In scanners, the received signal is the passed through a FM demodulator before being processed by the digital signal processor (DSP) where the digital information is recovered.  This design is cheap to implement, but also strips the critical components of an incoming simulcast signal that is needed to guarantee a successful decode.  In other words, part of the signal information lost with no way to recover it.  The end result is the significantly degraded ability for scanners to successfully decode a simulcast signal.
  
===Multipath===
+
==Multipath Misconception==
The traditional explanation for simulcast digital distortion has often been blamed on multipath.  While this explanation is convenient and easier to understand, it is not the total root cause of simulcast digital distortion in scanners.  Scanners can continue to exhibit symptoms of simulcast digital distortion even after multipath has been eliminated.
+
The traditional explanation for simulcast distortion has often been blamed on multipath.  While this explanation is convenient and easier to understand, it is '''not''' the primary cause of simulcast distortion in scanners.  Scanners can continue to exhibit symptoms of simulcast distortion even after multipath has been eliminated.
  
Multipath reception describes the situation where your receiver receives the signal from one or more transmit sites, i.e. over paths of different lengths.  Generally, single-site multipath isn't a problem; the FM capture effect will pick the strongest signal, as multipath reflections will be of lower power, or the wrong polarization.  But on Sites that are Simulcast trunking, there are multiple transmitters on separate towers, and the power from more than one of them is strong enough for your receiver to pick-up both up.  When receiving multipath signals from an analog system you may hear just a bit of wavering in the signal and your ear/brain has no trouble detecting the correct sounds coming from the speaker. Older antenna based analog TV's experienced this by ghosting orShortwave signals that suffer this cause more trouble in single sideband [[SSB]] due to the nature of the way the signal is handled and those of you who have experienced listening to multipath SSB are well aware of how tiresome it is to listen to.  In a digital signal, the [[DSP]] in the scanner must detect every bit (0 or 1) that is coming in, assemble these bits into a packet, then, translate this stream into an analog audio signal that the speaking reproduces voice tthat understandable by us.  The problem we're discussing occurs because the signals which come in from separate towers are not in time synchronization ''when they get to your scanner'', because the paths are different lengths. As long as there is sufficient overlap in the bit positions, a good receiver can extract the audio in the face of this multipath interference, but when the slip is more than one bit time, it results in a broken transmission, usually resulting in what a lot of folks saying "you went digital" (in HD TV it's called "pixelated") which is loss of signal or interference occuring. It usually manifests itself as a readable signal followed by a broken signal then back to a readable one, etc, (just as today's modern HD signaling on OTA TV's use a QAM tuner to handle quadature based signalling), the signal can go from all or nothing all or nothing).
+
Multipath reception describes the situation where your receiver receives the signal from one or more transmit sites, i.e. over paths of different lengths.  Generally, single-site multipath isn't a problem; the FM capture effect will pick the strongest signal, as multipath reflections will be of lower power, or the wrong polarization.  But on Sites that are Simulcast trunking, there are multiple transmitters on separate towers, and the power from more than one of them is strong enough for your receiver to pick-up both up.   
  
 +
When receiving multipath signals from an analog system you may hear just a bit of wavering in the signal and your ear/brain has no trouble detecting the correct sounds coming from the speaker.  Older antenna based analog TV's experienced this by ghosting. Shortwave signals suffer this and cause more trouble in single sideband [[SSB]] due to the nature of the way the signal is handled. Those of you who have experienced listening to multipath SSB are well aware of how tiresome it is to listen to.
  
=Mitigating SDD=
+
The was believed that the signals come from separate towers and are not synchronized when they get to your scanner because the paths are different lengths. This is not correct. As long as there is sufficient overlap in the bit positions, properly designed receiver can extract the audio in the face of this multipath interference. Simulcast systems are specifically designed to synchronize the signal for the intended coverage area so that timing issues are minimized. When the slip is more than one bit time, it results in a broken transmission. This generally only occurs outside the intended coverage area.
==Scanners==
+
 
 +
If multipath was a significant issue for actual system users, then simulcast systems would not be acceptable for most public safety users.
 +
 
 +
=Mitigation=
 
The solution requires the manufacturers to redesign their hardware so that they can process the signal before the FM demodulation stage of the scanner.  Doing so would eliminate the loss of critical signal information required to successfully demodulate a simulcast signal and allow for scanners to perform much more closely to a commercial radio.  As this problem is the result of the physical hardware design within all scanners, there is little hope for a firmware solution.
 
The solution requires the manufacturers to redesign their hardware so that they can process the signal before the FM demodulation stage of the scanner.  Doing so would eliminate the loss of critical signal information required to successfully demodulate a simulcast signal and allow for scanners to perform much more closely to a commercial radio.  As this problem is the result of the physical hardware design within all scanners, there is little hope for a firmware solution.
  
 
Until the above happens, the only thing a scanner user can do is to attempt to mitigate the problem depending on the situation.  Many of these mitigations are aimed at reducing the potential contribution of multipath to the problem.  Some, mitigation techniques, could be in the scanner settings or scanner type; some mitigation techniques are going to be everything but the scanner.   
 
Until the above happens, the only thing a scanner user can do is to attempt to mitigate the problem depending on the situation.  Many of these mitigations are aimed at reducing the potential contribution of multipath to the problem.  Some, mitigation techniques, could be in the scanner settings or scanner type; some mitigation techniques are going to be everything but the scanner.   
  
The variables list may be large, but that shouldn't deter anyone from at least trying to "tweak" specific settings first, such as: P25 Threshold and/or Digital AGC in Unidens or GRE based scanner's DSP and ADC/DAC settings [[Data Decode Threshold]].
+
The variables list may be large, but that shouldn't deter anyone from at least trying to "tweak" specific settings first..
  
Also, keep your firmware updated in your scanner.  Some users report that SSD is the cause of all their headaches, when in reality the scanner doesn't have a perfect algorithm written to decode that kind of System or Voice Type, or Band Plan yet.  Of course, sometimes it may seem that the most current version of firmware takes a step backwards, but that's due to the fact that each system type is unique, it may well be what worked better on system 'A' actually causes system 'B' users to notice a backward step. For some, rolling back to a previous firmware in many models isn't difficult and should be done with recent problems corollary with the newest firmware, but be assured a System's control channel frequency hasn't changed. Also, don't re-write your programming at the same time as a firmware upgrade, because you ARE creating to many variables, to objectively deduce, where a new problem arose.
+
Keep your firmware updated in your scanner.  Some users report that simulcast is the cause of all their headaches, when in reality the scanner doesn't have a perfect algorithm written to decode that kind of System, Voice Type, or Band Plan yet.  Sometimes it may seem that the most current version of firmware takes a step backwards, but that's due to the fact that each system type is unique.  It may well be what worked better on system 'A' actually causes system 'B' users to notice a backward step. For some, rolling back to a previous firmware in many models isn't difficult and should be done with recent problems corollary with the newest firmware, but be assured a System's control channel frequency hasn't changed. Also, don't re-write your programming at the same time as a firmware upgrade because you are creating too many variables to objectively deduce where a new problem arose.
  
 +
==All Scanners==
 +
*Opening Squelch to 0 for Digital Systems. See this post by UPMan: {{Thread|uniden-scanners|267424-loose-open-squelch-improves-lsm-simulcast-reception.html#post1975319|Loose/Open Squelch Improves LSM Simulcast Reception|}}
  
===Uniden===
+
*Dwell or Hold Time increase, increasing the ability of the scanner to capture and decode all of a Systems data parameters sent on the Control channel.
*Opening Squelch to 0 for Digital Sytems See this post by UPMan: {{Thread|uniden-scanners|267424-loose-open-squelch-improves-lsm-simulcast-reception.html#post1975319|Loose/Open Squelch Improves LSM Simulcast Reception|}}
 
*Digital AGC if its ''ON'' try it ''OFF'' because it may be be making Voice transmissions less intelligable, espcially if there are multiple errors already in the decode.
 
*P25 Threshold option can be changed after monitoring the Site with Auto to see the best setting for that System to be be decoded on, so if decode is best at 6, switch the P25 decode threshold for that system to ''Manual'' and ''6''. While 6 isn't a panacea, it's at least a beginning numeric to try starting with, typically up-to 9 in Manual mode will make the biggest difference. Not all scanners allow this ability System/Site specific/individually.  
 
  
 +
*Limit the amount of systems scanned, or scan just one site without additional conventional, priorities, or weather.
  
===GRE\RS\Whistler===
+
==Uniden==
Closing Squelch to the 9-12 o'clock positions, some report in the various handhelds 11 o'clock to be the best, some report incrementally opening of the squelch as they lower the ADC & DAC, all three going hand in hand, but opening squelch totally will certainly allow all strong, nearby signals to spuriously inject themselves into the frontend, be that FM radio or a VHF Pager frequency, to the point where the scanner completely hangs on any frequency.
+
*Digital AGC if its ''ON'' try it ''OFF'' because it may be be making Voice transmissions less intelligible, especially if there are multiple errors already in the decode.
  
*[[DSP]] can be changed in some models and can vary the rate at which the colliding signals are dealt with, to low could slow the voice reproduced down, to-high could speed up the voice being reproduced, either could be good or bad.
+
*P25 Threshold option can be changed after monitoring the Site with Auto to see the best setting for that System to be be decoded on, so if decode is best at 6, switch the P25 decode threshold for that system to ''Manual'' and ''6''. While 6 isn't a panacea, it's at least a beginning numeric to try starting with, typically up-to 9 in Manual mode will make the biggest difference. Not all scanners allow this ability System/Site specific/individually.  
*[[ADC]] Gain and [[DAC]] could be lowered to help mitigate multipathing signals as well as reduce bit error rates, typically a Negative 2 and 4, respectively, have been used by some users to help the lower the issue.
 
  
 +
==GRE\RS\Whistler==
 +
*DSP Level Adapt can be changed in some models and can vary the rate at which the DSP attempts to adjust varying P25 levels.
  
===ALL SCANNERS===
+
*ADC Gain and DAC Gain could be lowered to help reduce bit error rates. Typically a -2 and -4, respectively, have been used by some users to help the lower the issue. See [[GRE/RS/Whistler based DSP ADC/DAC Adjustments]] for more information.
*Dwell or Hold Time increase, increasing the ability of the scanner to capture and decode all of a Systems data parameters sent on the Control channel.
 
*Limited amount of System's scanned, or just one Site, without additional conventional, priorities or weather
 
 
   
 
   
====Antenna and Reception based====
+
==Antenna and Reception==
If you are significantly closer to one Tower than another, you may not experience this problem at all.  This explains why in discussions about the problem on specific systems, some people find it intolerable, while others, hardly notice it at all.
+
This section attempts to address the issues that multipath might contribute to the problem.
  
 
*ATT - Attenuator -Attenuation of all the signals sometimes helps, typically the Attenuator in the most scanners is via hardware at a standard of -20db.  This is of course due to the fact that if you attenuate all of the signals, your receiver possibly loses the ability to hear the interfering signal from multiple sources.
 
*ATT - Attenuator -Attenuation of all the signals sometimes helps, typically the Attenuator in the most scanners is via hardware at a standard of -20db.  This is of course due to the fact that if you attenuate all of the signals, your receiver possibly loses the ability to hear the interfering signal from multiple sources.
Line 47: Line 50:
 
*Attenuation of the secondary signal(s) causing interference via all of an Antenna's nulling properties:  
 
*Attenuation of the secondary signal(s) causing interference via all of an Antenna's nulling properties:  
 
**A yagi has 2 null spots 130-140 degrees from where it's being pointed.
 
**A yagi has 2 null spots 130-140 degrees from where it's being pointed.
**A Omni-directional, also, has 2 null spots at its tip and bottom. So, if you have 3 towers, if Tower 1 and Tower 3 form a straight line 1<------->3; you may be able to most reliably monitor 'Tower 2' with the antenna laid horizontally in the the line between Towers 1 and 3.
+
**A Omni-directional, also, has 2 null spots at its tip and bottom. If you have 3 towers and if Tower 1 and Tower 3 form a straight line, then you may be able to most reliably monitor Tower 2 with the antenna laid horizontally in the the line between Towers 1 and 3.
:2
+
      2
1<------->3
+
1<-Antenna->3
**Or adding a corner reflector - beam width and attenuation can vary on the design, See Can tenna
+
**Or adding a corner reflector - beam width and attenuation can vary on the design. Search for "cantenna."
 
 
*Stationary Solution, the use of a directional "Yagi antenna," pointed at the site you want to monitor. If you are receiving all of the signal from only one site, there is no "multipath distortion" to deal with.  This, of course does infer, that there is NOT a second Tower behind the first Tower for a given Site. (One user actually pointed his Yagi at a tower with a second tower lying 4-5 miles behind the first. He could never get proper decode, but continued to insist, since a Yagi was from one small path, he couldn't be getting multipath; while true, he was still getting multiple signals (images) causing complete decode failure in his radio. )
 
  
 +
*A Yagi antenna pointed at the site you want to monitor.  If you are receiving all of the signal from only one site, there is no "multipath distortion" to deal with.  This, of course does infer, that there is NOT a second Tower behind the first Tower for a given Site. (One user actually pointed his Yagi at a tower with a second tower lying 4-5 miles behind the first. He could never get proper decode, but continued to insist, since a Yagi was from one small path, he couldn't be getting multipath; while true, he was still getting multiple signals (images) causing complete decode failure in his radio)
  
=====Scanner Location=====
+
==Scanner Location==
*One inch or six inches can be the biggest factor, when attempting to receiving a signal. The propagation of a 700-900mhz signal is typically between 4 and 8 inches high, separated by 4-8 inches of a "no propagation area", followed by another propagation area so on and so forth.  
+
*Moving a scanner a few inches can be a big factor. Signals can have peaks and nulls, which creates areas of strong and weak signals.
  
*As well, one inch to six inch, can be applied to find local-interfering-signals to receivers; like PC's - their memory, processor, psu, gpu and video cards, Wi-Fi routers, power cables & supplies, lights & bulbs of all kinds, weather stations (buy a bimetallic or alcohol based thermometer no interfering signals at 433 or 915mhz), home & cell phones, monitors and TV's, house-wiring including cable & phone lines, Car radio's, PCMs, ECU, blutooth transceivers, ignition system, charging system, coils and various other sensors basically everything used today can have RFI and EMI. Some things have components that continue to generate noise for hours and days after being unplugged.
+
*Moving a scanner can also help reduce local interfering signals. Many electronics in the house can create interference.
  
*Hairbrained solution get 'Joe' from the next county over to monitor your county and use your scanner to monitor Joes county, since they are both simulcast, You'll have to use a Third-party solution to control and stream Joe's scannero and let Joe do the same with your scanner.... :}
+
*Hairbrained solution get 'Joe' from the next county over to monitor your county and use your scanner to monitor Joe's county. You'll have to use a third-party solution to control and stream Joe's scanner and let Joe do the same with your scanner.
  
 +
=Solutions=
 +
==Commercial Radios==
 +
If this situation was present in commercial radios (the ones actually used by the subscribers), then [[P25 CAI]] would not be acceptable for a public safety use.  Commercial radios greatly benefit from utilizing properly designed hardware where the signal is processed prior to any FM demodulation stage.  This design allows the radio to process the signal without any loss of information, unlike the time tested, AM/FM based designs and implementations, still used in scanners today.  This solution may not be ideal as it can be expensive and extremely complicated to setup correctly.
  
 +
==Public Safety Pagers==
 +
[http://www.unicationusa.com Unication] has developed a couple models of receive only P25 capable public safety pagers. These pager/receivers are intended for commercial use, and therefore have the proper hardware design. They work without any "tweaks" that may be needed for a scanner.
  
==Commercial Solutions==
+
To be clear, these units are commercial receivers designed for public safety users, not scanners. Programming and operation of these pagers are designed for public safety usersThese pagers are designed to monitor a single system at a time.
===Commercial Radios===
 
If the above situation was present in commercial radios (the ones actually used by the subscribers), then [[P25 CAI]] would not be acceptable for a public safety use.  Commercial radios greatly benefit from utilizing properly designed hardware where the signal is processed prior to any FM demodulation stage.  This design allows the radio to process the signal without any loss of information, unlike the time tested, AM/FM based designs and implementations, still used in scanners today.
 
 
 
 
 
===Commercial "Public Safety" Pagers===
 
[[http://www.unicationusa.com Unication]] has developed a couple pager models, that have some limited scanner-like features. These pager/receivers are intended for Commercial use - therefore, have the "proper hardware design," and works without any "tweaks" but do involve unique System settings not typically entered in a scanner. Many hobbyists have obtained these "receive only" devices, in order to monitor Systems that use Simulcast from multiple towers on a Site.  To be clear, these units are Commercial receivers designed for Public Safety Users, intended to be: APCO Project 25 Phase I and/or II decoders, where a typical User would be listening for a Page out (of a Fire or EMS call) monitoring 1 channel, afterwards, said User would then switch to a second channel via a knob turn. These are not: wide band receivers with 400 Systems and 10,000's of TGID's with multiple system types, all kinds of voice decoding capabilities, but they do - what - they do far better than the current crop of scanners.
 
 
 
As of July 2017, these units are limited to Phase 1 capabilities.  However, it is reported that a Phase 2 firmware upgrade will be available at some point in 2018.
 
 
 
 
 
==Hardware Solutions==
 
===Software Defined Radio (SDR)===
 
PC based processed and decoding of radio signal, is as good as: the receive signal and the computer where all the work is done. Voice decode can be superior to scanners, once again because of how the hardware deals with incoming signals.  Most were originally designed with chipsets that were to work as OTA HD TV signal capture and compile to forward signal onto a PC for decode anyway. Most SDR's whether it be a little USB dongle or larger USB cable connected devices, all based on your home computer to be used as a complete "System Monitor" with Voice decode up-to Phase I with a Windows based machine, or Phase II with a Ubuntu Linux set-up. Models vary in bandwidth capture and coverage, let alone price and capabilitiesWhile not intrinsically difficult to set-up, following directions and being able to restart computer and programs with initial set-up is a must.  For most people, for less than $40 you can have 2 small SDR USB dongles scanning a simulcast Phase I system with one "voice decode" channel and a "complete system monitor" in a matter of a few hours on a Saturday.
 
  
 +
These units are currently limited to Phase 1 capabilities.  It is reported that a Phase 2 license will be available for purchase at some point in 2018.
  
 +
==[[Software Defined Radios]]==
 +
Software defined radios are made up of a receive device and a computer to process the incoming signal.  Voice decode can be superior to scanners as the signal is handled properly, similar to how actual radios would process the incoming signal.
  
 +
See [[APCO Project 25#Software Based Decoders]] for additional information.
  
 
=Related Pages=
 
=Related Pages=
Line 88: Line 86:
 
*[[P25 audio decode level adjustment]]
 
*[[P25 audio decode level adjustment]]
 
*[[GRE/RS/Whistler based DSP ADC/DAC Adjustments]]
 
*[[GRE/RS/Whistler based DSP ADC/DAC Adjustments]]
*[[Data Decode Threshold]]
 
 
See also the [https://en.wikipedia.org/wiki/Cliff_effect Cliff effect article] on  
 
See also the [https://en.wikipedia.org/wiki/Cliff_effect Cliff effect article] on  
 
Wikipedia.  
 
Wikipedia.  
Line 104: Line 101:
  
 
==External Links==
 
==External Links==
*http://rfic.eecs.berkeley.edu/~niknejad/ee242/pdf/eecs242_lect3_rxarch.pdf
 
 
*[http://www.lightlink.com/mhp/demod/ LSM 101]
 
*[http://www.lightlink.com/mhp/demod/ LSM 101]
 
*[http://www.lightlink.com/mhp/lsm/ LSM Gallery]
 
*[http://www.lightlink.com/mhp/lsm/ LSM Gallery]
 
*[http://www.lightlink.com/mhp/lsm2/lsm2.html LSM Gallery - Page 2]
 
*[http://www.lightlink.com/mhp/lsm2/lsm2.html LSM Gallery - Page 2]
 +
*http://rfic.eecs.berkeley.edu/~niknejad/ee242/pdf/eecs242_lect3_rxarch.pdf
 
*http://urgentcomm.com/mag/error-control-coding-p25-radios
 
*http://urgentcomm.com/mag/error-control-coding-p25-radios
 
*https://www.maximintegrated.com/en/app-notes/index.mvp/id/641
 
*https://www.maximintegrated.com/en/app-notes/index.mvp/id/641
Line 118: Line 115:
 
*http://www.rfwireless-world.com/Terminology/C4FM-vs-CQPSK.html
 
*http://www.rfwireless-world.com/Terminology/C4FM-vs-CQPSK.html
 
*http://www.ece.ualberta.ca/~hcdc/Library/MIMOchClass/ChannelCapacity.pdf
 
*http://www.ece.ualberta.ca/~hcdc/Library/MIMOchClass/ChannelCapacity.pdf
 
Return to the [[Uniden DMA FAQ]]
 
  
 
[[Category:RR Glossary]]
 
[[Category:RR Glossary]]

Revision as of 18:06, 23 October 2017

Current generation digital scanners, even upgraded to the most recent firmware (where applicable), do a poor job of handling P25 CAI simulcast system transmissions. This problem is most evident when monitoring a true APCO Project 25 Simulcast system that use the CQPSK (Motrola LSM/Harris WCQPSK) and H-DQPSK modulation scheme that is not FM modulation based. This is most often noticed by a breaking up of a fairly strong transmission that one would normally expect to be crystal clear. In this article, we'll describe and explain the most common reason for this sort of problem, and suggest some ways you might alleviate some of the simulcast distortion your receiver experiences.

Problem

This problem is rooted in the hardware design of all scanners. In scanners, the received signal is the passed through a FM demodulator before being processed by the digital signal processor (DSP) where the digital information is recovered. This design is cheap to implement, but also strips the critical components of an incoming simulcast signal that is needed to guarantee a successful decode. In other words, part of the signal information lost with no way to recover it. The end result is the significantly degraded ability for scanners to successfully decode a simulcast signal.

Multipath Misconception

The traditional explanation for simulcast distortion has often been blamed on multipath. While this explanation is convenient and easier to understand, it is not the primary cause of simulcast distortion in scanners. Scanners can continue to exhibit symptoms of simulcast distortion even after multipath has been eliminated.

Multipath reception describes the situation where your receiver receives the signal from one or more transmit sites, i.e. over paths of different lengths. Generally, single-site multipath isn't a problem; the FM capture effect will pick the strongest signal, as multipath reflections will be of lower power, or the wrong polarization. But on Sites that are Simulcast trunking, there are multiple transmitters on separate towers, and the power from more than one of them is strong enough for your receiver to pick-up both up.

When receiving multipath signals from an analog system you may hear just a bit of wavering in the signal and your ear/brain has no trouble detecting the correct sounds coming from the speaker. Older antenna based analog TV's experienced this by ghosting. Shortwave signals suffer this and cause more trouble in single sideband SSB due to the nature of the way the signal is handled. Those of you who have experienced listening to multipath SSB are well aware of how tiresome it is to listen to.

The was believed that the signals come from separate towers and are not synchronized when they get to your scanner because the paths are different lengths. This is not correct. As long as there is sufficient overlap in the bit positions, properly designed receiver can extract the audio in the face of this multipath interference. Simulcast systems are specifically designed to synchronize the signal for the intended coverage area so that timing issues are minimized. When the slip is more than one bit time, it results in a broken transmission. This generally only occurs outside the intended coverage area.

If multipath was a significant issue for actual system users, then simulcast systems would not be acceptable for most public safety users.

Mitigation

The solution requires the manufacturers to redesign their hardware so that they can process the signal before the FM demodulation stage of the scanner. Doing so would eliminate the loss of critical signal information required to successfully demodulate a simulcast signal and allow for scanners to perform much more closely to a commercial radio. As this problem is the result of the physical hardware design within all scanners, there is little hope for a firmware solution.

Until the above happens, the only thing a scanner user can do is to attempt to mitigate the problem depending on the situation. Many of these mitigations are aimed at reducing the potential contribution of multipath to the problem. Some, mitigation techniques, could be in the scanner settings or scanner type; some mitigation techniques are going to be everything but the scanner.

The variables list may be large, but that shouldn't deter anyone from at least trying to "tweak" specific settings first..

Keep your firmware updated in your scanner. Some users report that simulcast is the cause of all their headaches, when in reality the scanner doesn't have a perfect algorithm written to decode that kind of System, Voice Type, or Band Plan yet. Sometimes it may seem that the most current version of firmware takes a step backwards, but that's due to the fact that each system type is unique. It may well be what worked better on system 'A' actually causes system 'B' users to notice a backward step. For some, rolling back to a previous firmware in many models isn't difficult and should be done with recent problems corollary with the newest firmware, but be assured a System's control channel frequency hasn't changed. Also, don't re-write your programming at the same time as a firmware upgrade because you are creating too many variables to objectively deduce where a new problem arose.

All Scanners

  • Dwell or Hold Time increase, increasing the ability of the scanner to capture and decode all of a Systems data parameters sent on the Control channel.
  • Limit the amount of systems scanned, or scan just one site without additional conventional, priorities, or weather.

Uniden

  • Digital AGC if its ON try it OFF because it may be be making Voice transmissions less intelligible, especially if there are multiple errors already in the decode.
  • P25 Threshold option can be changed after monitoring the Site with Auto to see the best setting for that System to be be decoded on, so if decode is best at 6, switch the P25 decode threshold for that system to Manual and 6. While 6 isn't a panacea, it's at least a beginning numeric to try starting with, typically up-to 9 in Manual mode will make the biggest difference. Not all scanners allow this ability System/Site specific/individually.

GRE\RS\Whistler

  • DSP Level Adapt can be changed in some models and can vary the rate at which the DSP attempts to adjust varying P25 levels.
  • ADC Gain and DAC Gain could be lowered to help reduce bit error rates. Typically a -2 and -4, respectively, have been used by some users to help the lower the issue. See GRE/RS/Whistler based DSP ADC/DAC Adjustments for more information.

Antenna and Reception

This section attempts to address the issues that multipath might contribute to the problem.

  • ATT - Attenuator -Attenuation of all the signals sometimes helps, typically the Attenuator in the most scanners is via hardware at a standard of -20db. This is of course due to the fact that if you attenuate all of the signals, your receiver possibly loses the ability to hear the interfering signal from multiple sources.
  • In lieu of attenuation, remember that with Digital Signals: the *less* gain your antenna has, the better off you'll be; reducing the overall signal at the receiver input will (generally) increase the signal-to-noise ratio, so the "capture effect" will ameliorate the problem for you.
  • Attenuation of the secondary signal(s) causing interference via all of an Antenna's nulling properties:
    • A yagi has 2 null spots 130-140 degrees from where it's being pointed.
    • A Omni-directional, also, has 2 null spots at its tip and bottom. If you have 3 towers and if Tower 1 and Tower 3 form a straight line, then you may be able to most reliably monitor Tower 2 with the antenna laid horizontally in the the line between Towers 1 and 3.
      2
1<-Antenna->3
    • Or adding a corner reflector - beam width and attenuation can vary on the design. Search for "cantenna."
  • A Yagi antenna pointed at the site you want to monitor. If you are receiving all of the signal from only one site, there is no "multipath distortion" to deal with. This, of course does infer, that there is NOT a second Tower behind the first Tower for a given Site. (One user actually pointed his Yagi at a tower with a second tower lying 4-5 miles behind the first. He could never get proper decode, but continued to insist, since a Yagi was from one small path, he couldn't be getting multipath; while true, he was still getting multiple signals (images) causing complete decode failure in his radio)

Scanner Location

  • Moving a scanner a few inches can be a big factor. Signals can have peaks and nulls, which creates areas of strong and weak signals.
  • Moving a scanner can also help reduce local interfering signals. Many electronics in the house can create interference.
  • Hairbrained solution get 'Joe' from the next county over to monitor your county and use your scanner to monitor Joe's county. You'll have to use a third-party solution to control and stream Joe's scanner and let Joe do the same with your scanner.

Solutions

Commercial Radios

If this situation was present in commercial radios (the ones actually used by the subscribers), then P25 CAI would not be acceptable for a public safety use. Commercial radios greatly benefit from utilizing properly designed hardware where the signal is processed prior to any FM demodulation stage. This design allows the radio to process the signal without any loss of information, unlike the time tested, AM/FM based designs and implementations, still used in scanners today. This solution may not be ideal as it can be expensive and extremely complicated to setup correctly.

Public Safety Pagers

Unication has developed a couple models of receive only P25 capable public safety pagers. These pager/receivers are intended for commercial use, and therefore have the proper hardware design. They work without any "tweaks" that may be needed for a scanner.

To be clear, these units are commercial receivers designed for public safety users, not scanners. Programming and operation of these pagers are designed for public safety users. These pagers are designed to monitor a single system at a time.

These units are currently limited to Phase 1 capabilities. It is reported that a Phase 2 license will be available for purchase at some point in 2018.

Software Defined Radios

Software defined radios are made up of a receive device and a computer to process the incoming signal. Voice decode can be superior to scanners as the signal is handled properly, similar to how actual radios would process the incoming signal.

See APCO Project 25#Software Based Decoders for additional information.

Related Pages

Related Wiki Articles

See also the Cliff effect article on Wikipedia.

Discussions on RR Forums

Other Resources

  • This article about HDTV has some additional information about multipath and other distortion / interference problems. The discussion "maps" well to public safety multipath issues, as well.

External Links