Priority Delay: 396XT vs PRO-95/97

[gfontes]

Just curious if there is a quick fix or if this is just a Uniden quirk. I've read other posts in regards to P25 delay time, but I'm currently only scanning conventional systems.

When Priority is enabled on the 396XT, I always get a minimum 1-second pause while the scanner checks stored priority channels. This is really annoying, as it almost always drops the key words in a conversation (ie. addresses, etc). Compare that to my older Pro-95 & Pro-97, the audio-drop is almost undetectable, and certainly doesn't compromise listening.

Thoughts? Suggestions?

 

[UPMan]

How many priority channels do you have set? 1 second is quite long.

 

[Avery93]

If you have a CTCSS/DCS tone set on the non-priority channels, you will notice an increased "pause" of about 250-300 milliseconds. This is because the Uniden firmware requires successful decode of the tone after every priority sample, before the audio will unmute.

Also if any interference is present on your priority channels during the priority sample, and there is a CTCSS/DCS tone set on them, expect this to add another 250-300 msec per channel as the radio tries to detect the tone.

If both of those examples are true, then you're getting pretty close to your 1 second sample time.

I like to only have 1 or 2 priority channels to keep sample time at a minimum, and on my Unidens most of my channels are set as carrier squelch (no CTCSS/DCS) because of the first issue noted above, along with a couple others. When setup like this, I find the sample time on Unidens perfectly acceptable, although not quite as fast as GRE/RS.

 

[UPMan]

The TONE decode time will only come into play if there is a signal strong enough to break squelch (so another thing to check would be to be sure squelch is not set too open).

 

[gfontes]

Thank you for the replies and suggestions. Upon checking, I did have 3 or 4 priority channels activated (some of which did have CTCSS tones), so I reduced that to just one channel with no tone. I also closed the squelch up a bit, so that wouldn't cause any issues.

There was (possibly) a slight improvement in the priority-check pause / loss of audio, however, it still hovers around that damn 1 second mark, dropping key bits of audio during transmissions. Still frustrated, but now realizing that it's just something I'm going to have to get used to, and was perhaps spoiled a bit all these years with my Pro-95 and Pro-97. Hell, even my old Patrolman and BC-760xlt radios kill this new(er) Uniden, when it comes to the priority-check.

 

[UPMan]

1 second is still excessive. I would expect to have 100+ priorities enabled to get that latency, not 3 or 4.

 

[Avery93]

I just conducted an experiment to measure the priority sample time of my 996XT and PSR-500, and believe I found the problem you are having.

I set up both scanners to scan two channels, my counties Fire Net and the Sheriff's repeater, with priority on the Fire Net. I ran the headphone jack audio to my computer and used Audacity 1.3 to measure the sample time.

I first tested the PSR-500, and the sample time was pretty consistent at 30 milliseconds.

Next test was the 996XT, with both channels set to carrier squelch. The sample time ranged from 79 to 87ms. Not too bad but the GRE was over twice as fast.

I then added the CTCSS tone to the Sheriff's repeater (the non-priority channel). After adding the tone, the sample time increased dramatically, with the fastest being 364ms and longest 420ms, with an average of 390ms.

The only thing I can think of that would cause this is Uniden firmware requires the tone to be decoded after every priority check, before the audio will unmute. There is a reason no commercial grade radios do this, it adds too much time to the priority check and serves no useful purpose. Combine this with Unidens already slow tone decode time and it makes using priority with CTCSS almost useless. It may not be a whole one second, but it clips enough audio to make following a conversation extremely difficult.

I'm not trying to hate on Uniden here, they make some great radios, and most things work just like the should; but the CTCSS/DCS issues and lack of true conventional mixed-mode P25 really let them down in my opinion. I hope they look into fixing these issues before the next firmware upgrade, or the next generation of Uniden scanners.

 

[gfontes]

Thanks to everyone who replied to this thread, for your suggestions and recommendations... especially Avery93, who broke it down into something that even I was able to understand.

Uniden: Please try and address this unacceptable delay in audio during the priority-check in the next firmware update.

 

[Boatanchor]

I just conducted an experiment to measure the priority sample time of my 996XT and PSR-500, and believe I found the problem you are having.

I set up both scanners to scan two channels, my counties Fire Net and the Sheriff's repeater, with priority on the Fire Net. I ran the headphone jack audio to my computer and used Audacity 1.3 to measure the sample time.

I first tested the PSR-500, and the sample time was pretty consistent at 30 milliseconds.

Next test was the 996XT, with both channels set to carrier squelch. The sample time ranged from 79 to 87ms. Not too bad but the GRE was over twice as fast.

I then added the CTCSS tone to the Sheriff's repeater (the non-priority channel). After adding the tone, the sample time increased dramatically, with the fastest being 364ms and longest 420ms, with an average of 390ms.

The only thing I can think of that would cause this is Uniden firmware requires the tone to be decoded after every priority check, before the audio will unmute. There is a reason no commercial grade radios do this, it adds too much time to the priority check and serves no useful purpose. Combine this with Unidens already slow tone decode time and it makes using priority with CTCSS almost useless. It may not be a whole one second, but it clips enough audio to make following a conversation extremely difficult.

I'm not trying to hate on Uniden here, they make some great radios, and most things work just like the should; but the CTCSS/DCS issues and lack of true conventional mixed-mode P25 really let them down in my opinion. I hope they look into fixing these issues before the next firmware upgrade, or the next generation of Uniden scanners.

Fantastic work Avery93!

It's more data link this that is needed for people to make informed decisions about which radios they buy and for the Manufacturers to take note of their products shortcomings for future firmware designs and firmware fixes,

The development engineers and software designers in these companies need to take note of issues such as these, raised by enthusiasts on forums such as this.

Keep up the good work..

 

[ke4wkp]

I just conducted an experiment to measure the priority sample time of my 996XT and PSR-500, and believe I found the problem you are having.

I set up both scanners to scan two channels, my counties Fire Net and the Sheriff's repeater, with priority on the Fire Net. I ran the headphone jack audio to my computer and used Audacity 1.3 to measure the sample time.

I first tested the PSR-500, and the sample time was pretty consistent at 30 milliseconds.

Next test was the 996XT, with both channels set to carrier squelch. The sample time ranged from 79 to 87ms. Not too bad but the GRE was over twice as fast.

I then added the CTCSS tone to the Sheriff's repeater (the non-priority channel). After adding the tone, the sample time increased dramatically, with the fastest being 364ms and longest 420ms, with an average of 390ms.

The only thing I can think of that would cause this is Uniden firmware requires the tone to be decoded after every priority check, before the audio will unmute. There is a reason no commercial grade radios do this, it adds too much time to the priority check and serves no useful purpose. Combine this with Unidens already slow tone decode time and it makes using priority with CTCSS almost useless. It may not be a whole one second, but it clips enough audio to make following a conversation extremely difficult.

I'm not trying to hate on Uniden here, they make some great radios, and most things work just like the should; but the CTCSS/DCS issues and lack of true conventional mixed-mode P25 really let them down in my opinion. I hope they look into fixing these issues before the next firmware upgrade, or the next generation of Uniden scanners.

I have this same problem and I wanted to throw a possible fix out there. The fix would be to update the firmware telling the scanner to unmute the audio while it is decoding the tone. That way immediately following the priority scan the audio will come back and there will be no pause while it is decoding the tone. And if the tone is not found it will resume scanning. I had to remove all the tones from my bcd396xt, bc125at, bct15x and bcd996xt because I use priority to monitor my local district (only 2 channels set to priority) and the pause became very frustrating. There are a few channels that I had to leave a tone on because other agencies nearby use the same frequency and other interference issues.

I have been waiting patiently for a fix but I wanted to bring this back up so it is not forgotten and to be sure that UPMAN has seen this. Please UPMAN if you see this pass it along to the techs or whoever is responsible for firmware so we can get a fix for this. Unmute the audio upon return from a priority scan while the scanner is decoding the tone. This should be an easy fix I would think. I am a huge Uniden fan I hope you don't let me down.