I'm the new owner of a Uniden BCD996XT. I mostly love this scanner (so far). However, I've noticed that it's occasionally a bit 'laggy' as far as squelch-opening response. That is, when a signal becomes present on the frequency that it happens to be listening to, the first one or two words of the transmission are often not heard. This not only applies to trunked talk groups, but as well to conventional single frequencies that have no PL tone/code enabled - and it makes no difference if the CSQ is set at its minimum threshold. On short transmissions it's not uncommon to only hear a brief blank carrier.

I'd like to ask if anyone besides myself has noticed similar behavior with any of Uniden's recent models? If this behavior is typical of these units I can learn to live with it because there's so much else about the 996XT that I find very nice.

I haven't really compared my 996T to another scanner but I have noticed that a lot of the sheriff deputies in my county don't really acknowledge a dispatch, they just click their mic. I guess it's just too much trouble for them to pick the mic up out of the hanger, put it to their lips and actually SAY something. The Sheriff's radio system is a hi-band repeater and my scanner's squelch doesn't close until the repeater drops so I should hear almost all of the acknowledgments. The Sheriff really needs to conduct a class on radio procedures. Maybe that's what you are getting as well.

I haven't really compared my 996T to another scanner but I have noticed that a lot of the sheriff deputies in my county don't really acknowledge a dispatch, they just click their mic. I guess it's just too much trouble for them to pick the mic up out of the hanger, put it to their lips and actually SAY something. The Sheriff's radio system is a hi-band repeater and my scanner's squelch doesn't close until the repeater drops so I should hear almost all of the acknowledgments. The Sheriff really needs to conduct a class on radio procedures. Maybe that's what you are getting as well.

No, I'm familiar with the phenomenon you describe and this isn't it. I've confirmed the laggy response of the 996XT by monitoring the same frequencies simultaneously on an Icom R7000. Sometimes on the 996 the exchanges consist of very brief transmissions between field units, or between a field unit and its dispatch, and I don't hear a single word on the 996 -only the brief carrier signals- whereas I hear the entire quick voice exchange of the conversation on the R7000. It's a genuine squelch-opening 'slowness' on the 996.

Of course one would never encounter this issue on repeaters that use a delayed transmitter drop, as what you've described.

Try setting the HOLD time and DELAY time in the system options to "0" on every system you have programmed in the radio. My 996XT scanner seems to perform better with these settings this way.
Enjoy
Wmbio

Try setting the HOLD time and DELAY time in the system options to "0" on every system you have programmed in the radio. My 996XT scanner seems to perform better with these settings this way.
Enjoy
Wmbio

The hold time currently is set to 0 (zero) on every system in my scanner. I don't want the delay at zero simply because that will make the scan resume immediately when a transmission ends. In that case there would be no way to hear the responses on systems whose transmitters drop immediately upon unit unkey. And I happen to have a lot of those systems in my area.

No it's not the delay time they are talking about. There is also a setting that determines how long the radio waits before it unmutes the audio ("P25 wait time"). I set this to zero (default is 400ms.) so none of the beginning of the transmissions are missed. Are you using Freescan software? If not, on the radio, go to Program system-(choose system)- Edit SYS Options-P25 Waiting Time- 0 ms.

No it's not the delay time they are talking about. There is also a setting that determines how long the radio waits before it unmutes the audio ("P25 wait time"). I set this to zero (default is 400ms.) so none of the beginning of the transmissions are missed. Are you using Freescan software? If not, on the radio, go to Program system-(choose system)- Edit SYS Options-P25 Waiting Time- 0 ms.

Bob

Yes, ka3jjz mentioned that very setting. However, wmbio said: "Try setting the HOLD time and DELAY time in the system options to "0" on every system..." That's who my response about DELAY time was addressed to.

I'm using ARC-XT Pro and the P25 wait time for each system is easily settable. As you said, and as I mentioned earlier, the default P25 wait time is 400. Per your advice, I'm going to set all systems to a P25 wait time of zero and see how it works.

Well, amazingly that made a big difference. There's one conventional system upon which I set zero as the P25 wait time and now I can even hear that system's key-up beep, and on every transmission. There was no way to hear that beep before changing the P25 wait time value to zero.

Obviously the P25 wait time variable is settable on non-P25 systems. And obviously it has a significant effect on how quickly the receiver unmutes upon signal presence.

I experimented a bit and learned that if (in the software) I set an actual P25 system to a P25 wait time of zero, after uploading that system to the scanner it defaults back to a value of 400. But that's only on P25 systems. The value of zero is retained on the Motorola trunked systems. But I suspect that I may be able to set a numerical value other than 400ms for the P25 systems and have that value retained as long as that value is not zero, I just haven't tried it yet.

That should only effect P25 systems and should not have any effect on analog. The OP said that he was seeing it on both.

Actually it affects all modes, even analog. The setting is meant to allow the radio to determine if the conventional frequency has P25 characteristics so it could decode it accordingly, which subsequently will cause a delay on any conventional frequency within the system.

Actually it affects all modes, even analog. The setting is meant to allow the radio to determine if the conventional frequency has P25 characteristics so it could decode it accordingly, which subsequently will cause a delay on any conventional frequency within the system.

Bob

I've learned something new, thanks. I wonder if you would still get the delay if the mod was set to FM or NFM on conventional systems?