BCD436HP/BCD536HP: Annoying delay behavior

Status
Not open for further replies.

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY
OK so about three weeks ago I got a BCD436HP. Yes, I know there are issues with it. But overall I'm very impressed. The thing I really like is that it DOES handle the Phase II LSM system that's being rolled out in our county very well, much better than my Pro-668 does. The 668 is very finicky about where it's located; as others have described, move it a few inches in either direction and you get garbled audio. On the other hand, I can carry the 436 around the house, go for a walk with it, even take it for a ride in the car and it stays locked on. It also seems to output audio at the same level for Phase I and Phase II, unlike the 668 which likes to absolutely SCREAM out Phase II transmissions!

But that brings me to something I am finding VERY annoying about the 436. Does anyone know if there is a known bug in how "delay" is handled, particularly as it relates to talk groups within a P25 Phase II system?

Here's what I'm seeing. I have both scanners running, a couple feet apart on my desk. I am monitoring the P25 system ONLY on both scanners. No conventional, no other trunked systems, no weather alert, no priority channels enabled, no close call / signal stalker / whatever.

I would say that, at least 90 or 95% of the time, if the dispatcher keys up with a call, both scanners will lock on within a second of each other. But here comes the annoying part ... probably 50% of the time (or even more), once the dispatcher stops transmitting, the 436 will go back to scanning, and it will take several seconds for it to lock back onto that talk group. In the meantime, most or all of the reply is lost.

But that's not ALWAYS what happens. Sometimes the 436 will sit there on that talk group happily waiting for a response that may or may not come, and after 2 (or 5, or however many seconds I have set) it will go back to scanning.

The other odd thing I noticed (which is perhaps unrelated) is that when I turned the 436 on it would take a LONG time (like a minute) for it to lock onto the control channel for the system. I went in and created a new site with just the CC and that problem went away, but this other one continues.

Anyone else seen this?
 

Voyager

Member
Joined
Nov 12, 2002
Messages
12,058
Reaction score
53
What is your squelch setting? If you're scanning only the trunked system, you could actually set it for 0. That may improve things.

You are running the latest firmware, right?
 

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY
What is your squelch setting? If you're scanning only the trunked system, you could actually set it for 0. That may improve things.

You are running the latest firmware, right?

I had it set to 2 since I had been listening to some conventional frequencies a few days ago. But setting it to 0 doesn't change the behavior. (Just verified that.)

And yes. Just double-checked earlier this morning.
 

BenScan

Member
Premium Subscriber
Joined
May 12, 2001
Messages
1,093
Reaction score
411
Location
D/FW
Yes, and I assume that's also a result of poor simulcast reception and decoding.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,981
Reaction score
32
Location
Supply (Lockwood Inlet area), NC
Yes, and I assume that's also a result of poor simulcast reception and decoding.

Agree -- it is true that if/when the x36 radios stop on and decode simulcast voice, it tends to sound better and hold the talkgroup (most of the time). However, from my experience - both stationary and mobile - there are many times where my GRE/Whistler radios stop on activity and maybe have trouble holding a lock but the Uniden never even stops on the activity at all. It seems even worse if you are scanning various types of systems - almost like it has trouble "shifting" from conventional, Motorola or EDACS to P25. This is much more obvious on Phase 2 over Phase 1.

As far as the squelch - setting it lower than 2 will likely just slow down acquisition of the control channel even more.

As is always said - YMMV - and some folks don't understand or deal with the digital simulcast issues so they really can't speak to YOUR situation unless they are where you are and listening to the exact same thing. Just moving around (a bit close or farther from any given tower) between transmitter/tower sites in a simulcast system can make a huge difference.
 

Voyager

Member
Joined
Nov 12, 2002
Messages
12,058
Reaction score
53
Many people have posted that squelch setting 0 improves their scanner's performance. When scanning, the scanner starts with the last heard control channel, so acquisition is not an issue.
 

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY
Yes, I totally understand the "YMMV" aspect, and the fact that unless someone is listening to the same system from a nearby location their experience is not going to be the same.

But again, the behavior I'm seeing is this: The delay is not working as it should. *Sometimes* the scanner pauses for 2 (or whatever) seconds at the end of a transmission. Other times it starts scanning immediately after the transmission is over. I increased the delay to 5 seconds and that made it more obvious.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,981
Reaction score
32
Location
Supply (Lockwood Inlet area), NC
Yes, I totally understand the "YMMV" aspect, and the fact that unless someone is listening to the same system from a nearby location their experience is not going to be the same.

But again, the behavior I'm seeing is this: The delay is not working as it should. *Sometimes* the scanner pauses for 2 (or whatever) seconds at the end of a transmission. Other times it starts scanning immediately after the transmission is over. I increased the delay to 5 seconds and that made it more obvious.

Seen that also....no idea why that happens.
 

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY

Voyager

Member
Joined
Nov 12, 2002
Messages
12,058
Reaction score
53
Also make sure you do not have duplicate systems programmed (one with a delay and one without).
 

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY
Also make sure you do not have duplicate systems programmed (one with a delay and one without).

I do not.

I wiped the whole scanner, and added ONE favorite list with ONE system, this one. I thought maybe that was what was going on, but nope.

Changing the "end code" setting seemed promising for about 5 minutes, then I saw the behavior again.

This looks very much like a firmware bug to me. Sometimes it works; sometimes it doesn't.
 

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY
What is your HOLD TIME set to?

5 seconds, which is the default.

Not sure how that is relevant ... if I'm not mistaken, hold time is, "I should listen to this control channel (or system) for this many seconds before I go on to the next thing". No?

Don't see why that would make the scanner ignore the delay setting. I have nothing else programmed other than this one system. So even if hold time expired, it would start listening again immediately since there is nothing else to scan.
 

Voyager

Member
Joined
Nov 12, 2002
Messages
12,058
Reaction score
53
Sometimes the HOLD TIME will affect the scanning. Try a HOLD TIME of 0 just to see if it resolves the issue.
 

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY
Sometimes the HOLD TIME will affect the scanning. Try a HOLD TIME of 0 just to see if it resolves the issue.

Ha. Not only does that not resolve the issue, if anything it made it much worse. I saw it drop from a talk group immediately after a transmission ended within 30 seconds of when I started scanning, and now it seems to be doing it at least 80% of the time instead of maybe 30%.

It's a bug in the firmware. The scanner definitely does not do what it's supposed to do.
 

Voyager

Member
Joined
Nov 12, 2002
Messages
12,058
Reaction score
53
If it's a bug, others would be seeing it too.

But, even that setting making it worse is good info.

Have you tried another Micro SD card?
 

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY
If it's a bug, others would be seeing it too.

But, even that setting making it worse is good info.

Have you tried another Micro SD card?

Uh, I think there's a post a few before this one where someone else says the've seen it too, so I'm not the only one. Perhaps there is something about this system (Harris?) that makes it happen.

Haven't tried another card, but since the programming is only read at boot-up (and I am NOT recording) not sure how that could be the problem here.
 

Voyager

Member
Joined
Nov 12, 2002
Messages
12,058
Reaction score
53
Could very well be a Harris issue. But my point was that if it were a bug everyone would be seeing it.

And trust me - corrupted SD cards can cause all sorts of issues. That's been well documented.
 

sallen07

Member
Premium Subscriber
Joined
Dec 22, 2013
Messages
1,390
Reaction score
1,211
Location
Rochester, NY
Nope, not the card either

Could very well be a Harris issue. But my point was that if it were a bug everyone would be seeing it.

How can you make that blanket statement? Do you have any idea how software bugs actually work? Many are VERY obscure ... maybe it's Harris system, combined with the fact that they are rebroadcasting from UHF, and the fact that I have RIDs entered, and who knows what else.

Not every bug is easily detected. Indeed, most of the ones that ARE, never make it out the door.

And trust me - corrupted SD cards can cause all sorts of issues. That's been well documented.

Yes, I read these forums too. And guess what? I switched to a different SD card, and the behavior continues. Guess it wasn't the card, was it?

You really ARE the resident Uniden apologist, aren't you? Every time someone has an issue, it's *their* fault ... must be programmed wrong, or user-corrupted SD card, or who knows what. But it's never a problem with the scanner or its firmware.
 
Status
Not open for further replies.
Top