ScanRiverside.com

I am hearing RPD dispatch on 460.4625 151.4 PL. Simulcast w/ 460.175.

brandon wrote:I am hearing RPD dispatch on 460.4625 151.4 PL. Simulcast w/ 460.175.

460.4625? That one doesn't sound familiar to me.

i know it covering traffic on ch. 4. big ed

That is the Canyon Springs translator (CH 6) to provide fill-in coverage to the Day St. / 60 FWY areas of the City as well as coverage out to Riverside County Regional Medical Center for prisoner transports to and from that facility. "Big Ed" your scanner probably lacks the selectivity and adjacent channel rejection that commercial two-way gear offers, so .4625 is "bleeding" onto .4750. This is a common problem, especially for some of the older scanners when trying to run 12.5 kHz "narrowband" channel spacing in an area with relatively high levels of signal strength from adjacent channels.

Thank you n6 thats true thats ok will deal with it. Big ed

If your scanner features PL decode, you can "hide' the problem by decoding PL on 460.475, however if .4625 is REAL strong where you are at, it may capture over .475 and just mute audio. It will depend on how well you see each site.

N6AJB wrote:That is the Canyon Springs translator (CH 6) to provide fill-in coverage to the Day St. / 60 FWY areas of the City as well as coverage out to Riverside County Regional Medical Center for prisoner transports to and from that facility. "Big Ed" your scanner probably lacks the selectivity and adjacent channel rejection that commercial two-way gear offers, so .4625 is "bleeding" onto .4750. This is a common problem, especially for some of the older scanners when trying to run 12.5 kHz "narrowband" channel spacing in an area with relatively high levels of signal strength from adjacent channels.

Excellent! Thanks for the info

N6AJB wrote:That is the Canyon Springs translator (CH 6) to provide fill-in coverage to the Day St. / 60 FWY areas of the City as well as coverage out to Riverside County Regional Medical Center for prisoner transports to and from that facility. "Big Ed" your scanner probably lacks the selectivity and adjacent channel rejection that commercial two-way gear offers, so .4625 is "bleeding" onto .4750. This is a common problem, especially for some of the older scanners when trying to run 12.5 kHz "narrowband" channel spacing in an area with relatively high levels of signal strength from adjacent channels.

The Uniden scanners that trunktrack, both base units and portables, let you adjust the spacing from 12.5KHz to any other value such as 6.25KHz. I know that some channels like to bleed when they're off by as little as .05MHz which can be a pain. I neve knew you could try the PL/DPL code decoding to prevent the bleeding. Good stuff.

The Uniden scanners that trunktrack, both base units and portables, let you adjust the spacing from 12.5KHz to any other value such as 6.25KHz. I know that some channels like to bleed when they're off by as little as .05MHz which can be a pain. I neve knew you could try the PL/DPL code decoding to prevent the bleeding. Good stuff.[/quote]

Don't confuse channel spacing with IF filter response. Just because a receiver allows selectable channel spacing or "step" does not mean any adjustment to the IF filter bandwidth (the important part when it comes to selectivity/adjacent channel rejection) is made. All it means for most radios is simply changing the synthesizer (PLL) step size; the IF filter bandwidth is not affected. Many hobbyists get this confused so you're not alone. Even switching to "narrow" FM ("NFM" or "FMN") may not necessarily affect the bandwidth depending on the model.

In my experience, modern GRE scanners have slightly better IF selectivity than their Uniden counterparts especially when "NFM" mode is used. I do prefer the Uniden's superior front end performance greatly, however. It's a pity the two performance characteristics (front end response and IF bandwidth) can't be made decent together in one good consumer grade scanner - price, of course, and laziness, I think. I don't know how the new upcoming Uniden models will do in this respect - won't be able to find out for myself, unfortunately (money, or the lack thereof).

As to the CTCSS ("PL") usage - as was stated, it only "hides" the issue - it doesn't cure it. The "bleedover" is still there and still could potentially interfere with and/or completely cover your desired signal during transmissions but you just don't have to hear it when your desired signals aren't transmitting (though, in some cases, depending on the IF filter response and audio processing of the receiver, if both the desired on-frequency signal and the interfering undesired adjacent channel signal use the same CTCSS ("PL") tone then it may not help at all or only sporadically).

And just in case, cvrules90, before you ask - "IF" means "Intermediate Frequency". For the purposes of this discussion, you just need to understand that the bandwidth of the filter in the IF section of a receiver determines how well it handles rejection or attenuation of off frequency but near in frequency (relative to the desired tuned center) signals. It is a common problem area for lower cost receivers such as consumer grade scanners (cost being relative - understand that $600 is nothing compared to $5000 gear or $200K lab gear!). Most scanners have only one IF selection intended to cover all narrow band modes and it is often a severe compromise at best; together with poor LO ("Local Oscillator"...uhhh...another time, cvrules90, just trust me on this...) stability this can and does cause many issues in consumer gear (though, if you have bad LO drift then you may actually want a broader "more forgiving" IF bandwidth ).

-Mike

Thanks for the lengthy but informative explanation Mike.