PSR-500 and CTCSS on low band VHF

[gmclam]

My go to scanner for monitoring CHP has been the PSR-310. Especially when mobile, I monitor CHP above most else. Because they are on low band VHF, and the re-use of frequencies throughout the state of CA, I always program CTCSS codes. ALL of my scanners handle them well except for the PSR-500.

With lots of agencies going digital, I'm now facing either running two scanners when mobile (one just for CHP) or getting a PSR-500 to do it all. I can park the '500 on a full strength CHP signal and it will cut out. PRIority is off. Tonight I am sitting here with a '500 and '400 side by side each connected to the same outside antenna. The '400 works flawlessly and the '500 cuts in and out.

At first I thought perhaps a lemon '500. Now I have a 2nd '500 (and equivalent base model) and they all do the same thing. My question here - do any of you experience this? Perhaps there is some setting which needs to be changed to fix this.

Thank you in advance.

 

[ScannerSK]

Yes, this is a known problem. The only solution that I am aware of that helps is to increase the "HD5 Fade" time in the "advanced" settings menu. To get to the "advanced" settings menu press PGM, FUNC, F3.

The latest firmware version allows a setting up to 10000 ms (10 seconds) however something around a setting of 5000-7000 ms (5-7 seconds) should be sufficient. The default is currently 2000 ms (audio cuts out 2 seconds after CTCSS tone was last decoded).

This setting controls how soon the scanner cuts out the audio after it last decoded the CTCSS tone. The problem appears to be that the PSR-500/600 has a difficult time decoding the CTCSS tone especially in the presence of other loud sounds occurring simultaneously on the broadcast.

I don't remember offhand but you may also have to increase the delay time on the channel(s) experiencing this problem to at least match the time entered into the "HD5 Fade" setting. The reason is that the delay timer starts counting whenever the scanner stops decoding the CTCSS tone. If the delay time is set for 2 seconds and the HD5 Fade time is set to 5 seconds then the scanner will start to scan again 2 seconds after it last decoded the CTCSS tone even with the increased HD5 Fade time. (In other words, the scanner could start to scan again in the middle of a conversation.) Entering a delay time equal to the HD5 Fade time setting would prevent the scanner from scanning until the full HD5 Fade time expires. I hope that makes sense.

Shawn

 

[gmclam]

Hello and thank you for the reply.

I understand what you wrote completely. I already have my channel dwell time set to 3 seconds for all objects. I'll try different values for the HD5 value and see what happens. It makes me wonder how the '500 ever is able to stop on one of these channels if the CTCSS is absent for over 2 seconds (otherwise we wouldn't hear the cut out).

Fortunately I typically program with WIN500. I see those settings under the Extended Settings tab in the CTCSS/DCS/NAC section. I have not found a place where these settings are really described in detail.

 

[KB7MIB]

Try this:
Easier to Read Pro-106/197/PSR500/600 Digital Scanner Manual

Some of the dispatch tones put out by the Phoenix, AZ fire department on their analog conventional VHF frequency seem to cancel out the CTCSS tone, and the audio cuts out in my '500, so I frequently listen in CSQ, or have the tone set to 'Search' rather than having it set.

 

[gmclam]

Thanks

Thank you for the link. I've never found the 'easier to read' manuals to be easier to read, but can see that Mark has described some of these settings much better AND included the parameter name is both WIN500 and PSRedit500.

I write firmware for a living, and desire a much deeper understanding of the settings and their interaction. I can see there are other settings that will affect this behavior as well. This link also shed some light on the topic.

 

[AuntEnvy]

GM ~ I'm curious to know how you made out with the settings.

I adjusted some of the settings per Mark's recommendations and it seemed to help. I can't really say how much but I'm wondering if I should tweak some more.

I have a 197 and the vhf 150 range channels do not sound very good at all considering the unit and audio/reception of other frequency ranges, that being analog uhf and 400/800 digital trunked systems.

I can't say much on low band because there isn't a lot in use around here anymore but they appear to come in without issue.

 

[gmclam]

PSR-500 Extended Settings

The settings helped, but I am still working on a recipe of the best combination of settings. The "Easier To Read" manual at least has some explanation of the parameters, but I can interpret them many ways. So, unfortunately, it is trial and error.

As I have written on RR many times, I monitor pretty much whatever CHP channel I can receive. From home that may extend as far north as the Red channel to the Ruby channel in the Bay area and Orange to the south. The Sac Valley White signal comes in with 5 bars of RF and lots of noise, so that's my best for testing this. Of course the settings should make Gold, Green & Black 'perfect' (as they are on something like a PSR-300).

I always use CT codes because these signals are on low band, which also means any tone decoder must be able to filter well to do its job. All my prior scanners with CT decoding do at least a good job. But I think they're using an IC dedicated to that function whereas the '500 uses its DSP. Hence this programmability is needed. And I doubt the manufacturer or person responsible for determining these values used these real world signals when they published their defaults.

Presently I have things set to the following (these are the names used by WIN500):
Fade timeout 5000
Delay after end 100
End detect qualify 50
Search interval 500 (unchanged)
Query interval 50
RF SQ Fade timeout 4

If I only changed the Fade timeout I would end up hearing the very atmospheric noise I don't want to hear when the transmission completed. My thinking is to make the scanner detect (CT/DC) more frequently, and close the squelch "immediately" if the RF signal disappears. Of course, most of the time there is enough signal to break the squelch if it weren't for this decoding.

I am still working on this and would love to hear what others think (good or bad). Not using CT is not an option.

 

[AuntEnvy]

I'm using psredit so it gets confusing trying to decipher what translates to what.

I'm not sure how much comparison can be made with regard to what we're monitoring and where etc. but I'm guessing when it comes to vhf/conventional the issues are pretty much equal...?

And since we aren't the only two having this problem with gre vhf, there is an obvious flaw somewhere, and that seems to have been focusing on trunk/digital abilities while ignoring vhf/conventional, which makes no sense to me at all. There just isn't any reason for that.

 

[gmclam]

PSR-500 CT/DC vs WIN500 vs PSRedit

I use CT/DC/NAC codes on almost everything these days. If I don't, I am likely to hear someone else on the same frequency. I do have many channels programmed with the same frequency, but different codes in order to display the proper text tag.

I only experience the issue on VHF Low. I just don't see the same issue on VHF high or UHF (including 700/800). However, a significant reason I use them on VHF Low (CHP) is because of the significant atmospheric noise. If I park a scanner on a CHP channel with the squelch open, it is "amazing" that the ICs in the older scanners are able to decode the tones so reliably.

I am certain the issue has to do with how the DSP is coded. What is needed first is a "brick wall" 300 Hz low pass filter. I'd have to look at that spectrum to see how clean that leaves the signal. The next thing I'd want to see is the process the DSP uses to decode. I wonder if this was "the best it could do" or they just got something basically working.

RF SQ Fade Length of time to wait before closing the squelch after lost signal (squelch tail).
WIN500: RF SQ Fade Timeout
PSRedit: RF Fade Time

ACSQ PolInt The interval of time to check for a CTCSS/DCS/NAC signal.
WIN500: Query Interval
PSRedit: Query Interval

HD5 Fade Length of time to wait after losing a CTCSS/DCS/NAC signal. If the scanner loses programmed CTCSS, DCS, or NAC for the time specified in that parameter, it will mute audio. Increasing the time may help with the above-described behavior under weak signal or overload conditions.
WIN500: Fade Timeout
PSRedit: Fade Delay

HD2 Qualify Length of time to check to detect an end of signal turn off code command.
WIN500: End detect qualify
PSRedit: Qualify Time (Analog)

HD2 Holdoff Length of time to mute a signal after an end of signal turn off code command.
WIN500: Delay after end
PSRedit: Mute Time

 

[AuntEnvy]

Thanks for the input gm

I'm not sure if I mentioned my unit is a 197 but the way I understand it, it's the same radio. The most prominent issue I'm having is the vhf hi signal. I have a couple of frequencies in the 154-155 range that sound as though they are competing with the "noise floor" and that they are far more distant than they normally would be on any other scanner, and in certain locations you can hear their transmissions with a FM radio station behind it, almost as loud. I've never seen this in any unit ever.

I'm pretty sure those settings aren't going to fix that but I could be wrong.

My 197 is a mobile work unit so I don't get a lot of opportunity to fiddle with it. The next time I get it home I plan on changing the settings and see what happens.

 

[pepsima1]

I have always had this issue with the GRE PSR 600 and now still have the same issue on the Whistler 1065 with VHF Low Band for CHP.

On my Uniden BCD996XT I have no issues with VHF Low Band CHP

 

[gmclam]

PSR-500 & CT/DC on VHF

I have always had this issue with the GRE PSR 600 and now still have the same issue on the Whistler 1065 with VHF Low Band for CHP.

On my Uniden BCD996XT I have no issues with VHF Low Band CHP

All of the scanners in my tag line do a fine job with CHP. They use dedicated ICs for CT/DC decoding. The designer/manufacturer of the '500 felt the DSP could do the job. So far, it can't. It's really sad that an otherwise outstanding scanner has such a defect.

 

[pepsima1]

Airband is not great either but trunking is the best out there on the market. The digital decode on trunking systems blows everything away. IMHO

 

[W4KRR]

Does this CTCSS issue happen only on the VHF low band, or does it affect all bands?

 

[pepsima1]

Yup I am only hearing the squelch tail on VHF low band.

 

[gmclam]

PSR-500 & CTCSS on low band VHF

Does this CTCSS issue happen only on the VHF low band, or does it affect all bands?

For me, yes. I have CT/DC/NAC codes programmed for virtually any channel that uses them (and search for those that don't) and I am not seeing this issue except on low band VHF.

I was out of the area for the past week or so, and heavily using my '500 as I was in a 'digital area'. I had no issues with this whatsoever. But upon returning to California, and in range of CHP, I realized I was using my '500 the moment a (strong) signal cut out. Solution for now is to use '310/etc.

However, I do notice that the new settings, posted above, have made a significant improvement. I believe there is still room for more improvement, which I will work on when I get time to dedicate to just this issue.

 

[KB7MIB]

Does this CTCSS issue happen only on the VHF low band, or does it affect all bands?

As I mentioned, it's an issue for me on the Phoenix FD VHF-Hi dispatch frequency, 154.190, when certain tones drop.
I only monitor one VHF-Low band channel, 47.660, which is a city/county EOC net, but reception without a dedicated VHF-Lowband antenna is poor. I can only realiably hear two-three of the closest member stations during the weekly roll calls anyway, so I haven't noticed any issues with the CTCSS decoding.

John
Peoria, AZ