BCD436HP/BCD536HP: Annoying delay behavior

[W8RMH]

I think what you are experiencing is just the nature of simulcast distortion. It does it a little on my HP-2 (which handles it the best), as well as the 436 I had and sold, my BCD396XT and my BCD996XT. We don't have any Phase II yet but I have the same issues on Phase I.

Our new county P25 Phase I system has a simulcast site and 3 regular single sites. If I listen to our single site it is fine just like an analog trunked system (except for the tin-ey, muffled digital sound). But if I listen to the same transmission on the simulcast site I experience, on-and-off, everything you describe, on all four scanners.

 

[sallen07]

I think what you are experiencing is just the nature of simulcast distortion.

I disagree. This certainly could be *triggered* by LSM, but I maintain that it's a bug.

I can sit here and stare at the scanner. It stops on a talk group, I hear the audio (not garbled at all), the audio stops, and the scanner starts scanning again IMMEDIATELY, even though the delay on that talk group is set to 2 seconds.

But that doesn't happen every time ... sometimes it stops on the same talk group and delays just like it should.

 

[Voyager]

How can you make that blanket statement?

I can make it because many people (myself included) scan P25 systems and don't have that issue.

Do you have any idea how software bugs actually work?

I know very well having written firmware for radios.

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.

And interesting statement. I wish I had thought of that...

OH WAIT! I DID!: "Could very well be a Harris issue" (post 19)

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?

Well, that's one more thing eliminated. Sooner or later the issue will be found. But I don't need your abuse resulting my MY trying to HELP YOU.

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.

Again, I said above it might be an issue with Harris systems.

But, you're on your own. I no longer care to try to help you.

Congrats. You are among a very elite group.

 

[sallen07]

I can make it because many people (myself included) scan P25 systems and don't have that issue.

Flawed logic. "I scan a different system in a different location and don't have this problem, thus there isn't a problem."

Or are you suggesting that I'm lying? Or just imagining the behavior? Do you have an alternate explanation other than a bug, probably triggered by some combination of factors unique to this system?

I have a delay set. Sometimes it delays, sometimes it does not, on the same talk group. That's NOT what it's supposed to do. Sure sounds like a bug to me. Even if the LSM is causing signal drop-out, it should still delay, right?

But, you're on your own. I no longer care to try to help you.

Sorry if you took offense, although I'm by far not the only one who has pointed out that you constantly defend Uniden's scanners and blame the user for any issue. Even the resident Uniden REP doesn't do that.

 

[Voyager]

Your logic is flawed because bugs don't change depending on location - either they are there or they are not. The firmware does not change with location.

I never said you are lying. You are reading a lot into what people are saying who are trying to help you (or were). I even suggested it was a Harris system issue - before you suggested it.

It still might not be a bug. There are lots of things that can cause scan to resume.

I never blamed you, but for someone to categorically suggest user error is not possible is ridiculous.

What I take offense to is that you obviously have a preconceived notion about my motives which WERE to help you identify and resolve the problem. My motives were never about proving it's not a bug. My mind was, and is, open.

As I suggested twice previously, it may be an issue that involves only Harris systems which is why not everyone experiences it. But, I'm not going to continue to provide experienced suggestions if I get a smart donkey reply such as "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?"

The attitude is obvious in that reply, and it takes no reading into it to see that you are more concerned with proving me wrong and gloating about it than solving the issue. If it's not a priority for you, it's not a priority for me.

 

[W8RMH]

Why do you ask for help and any ideas then doubt, correct, and bash everyone who makes suggestions and tries to help. You are the perfect example of a TROLL.

 

[sallen07]

Why do you ask for help and any ideas then doubt, correct, and bash everyone who makes suggestions and tries to help. You are the perfect example of a TROLL.

You're kidding, right? I think if you read some of the other posts I've made in different threads, you'll find that I'm no troll.

I also didn't "ask for help". I posted the annoying behavior that I was seeing, and ended with, "has anyone else seen this?" So far, there was one poster that said they'd seen it too.

I've tried everything that has been suggested, but the odd delay behavior hasn't changed.

If that makes me a troll, I guess I'll go shave my knuckles or something.

 

[sallen07]

Your logic is flawed because bugs don't change depending on location - either they are there or they are not. The firmware does not change with location.

That was a poor choice of words on my part. What I meant was that you were listening to different systems because you are located somewhere else.

It still might not be a bug. There are lots of things that can cause scan to resume.

Can you expound on that? I mean I can see that the scanner might stop decoding the digital transmission (for whatever reason), but shouldn't it still delay? Or maybe that's what's going on, that it drops mid-transmission and for whatever reason it ignores the delay setting in that case?

What I take offense to is that you obviously have a preconceived notion about my motives which WERE to help you identify and resolve the problem. My motives were never about proving it's not a bug. My mind was, and is, open.

And I do appreciate the suggestions ... I really do. But you have also stated (and I'm paraphrasing) that "it can't be a bug, because if it was everyone would be seeing it" and "it can't be a bug, because I'm not seeing it". I think we can agree that if it has something to do with this Harris system that would explain both of those, yes?

As I suggested twice previously, it may be an issue that involves only Harris systems which is why not everyone experiences it. But, I'm not going to continue to provide experienced suggestions if I get a smart donkey reply such as "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?"

OK sorry if I was a smart alec, but I *do* read these forums, and I'm well aware of all the corrupted SD card issues. As a matter of fact, one of the things I really dislike about the BCD436HP is the whole 'write to SD card' method of programming. But I knew that going in. If the delay didn't work at all, I could see that being an issue with the card, but this whole "sometimes it works, and sometimes it doesn't" does not seem to fit that scenario.

There is one talk group on this system where the dispatcher and all the units are completely on the TRS, and there is no rebroadcast to/from a VHF frequency. It seems like I never see this issue on that TG. Perhaps as the others are moved over this will all go away.

 

[adcockfred]

all I have to say about ph ll and lsm 500 800 or 436 is fox hunter loop

 

[Voyager]

Apology gladly accepted.

Now, without the diversions (continuation of the left field topic), you saw that setting the HOLD TIME to 0 made the issue worse. BTW, did you confirm that you're using the latest firmware?

Are you using the control channels only or are all the channels programmed?

With respect to what RMH said, if the scanner is returning to the control channel only to find that the data is unusable, that could trigger a scan to find one that is usable.

Can you give some more details about how many site(s) you are scanning, if this is a FL or main dB, how many other systems you are scanning (not that it should matter, but I want to get a better overall picture), and the other questions?

Oh, and are there any encrypted or data TGs on the system? BTW, encryption is one of the things that will cause an immediate resume of scan without the delay.

 

[sallen07]

... setting the HOLD TIME to 0 made the issue worse. BTW, did you confirm that you're using the latest firmware?

Yes, setting HOLD TIME to 0 seemed to make it worse, but I can try that test again.

Firmware is 1.10.02, which I believe is current, correct?

Are you using the control channels only or are all the channels programmed?

Tried it both ways. Right now just the CC.

With respect to what RMH said, if the scanner is returning to the control channel only to find that the data is unusable, that could trigger a scan to find one that is usable.

I wonder if that's what is going on. When there is no delay it also seems like the scanner has a hard time locking onto any traffic (takes several seconds) as compared to my Pro-668 sitting a couple feet away.

Can you give some more details about how many site(s) you are scanning, if this is a FL or main dB, how many other systems you are scanning (not that it should matter, but I want to get a better overall picture), and the other questions?

One site. Scanning from a FL with main DB disabled. This one system is the only thing I'm scanning.

Oh, and are there any encrypted or data TGs on the system? BTW, encryption is one of the things that will cause an immediate resume of scan without the delay.

No encryption or data TGs, and I'm scanning a grand total of five TGs (everything else is avoided). I also thought maybe "search" vs "scan" would matter ... but it does not.

 

[johnnyg828]

Same Issues

Located in lehigh valley PA ..

Having exact same issues... side by side my 436 and 125 ...125 outperforms and never loses signal.

436 breaks losses signal and transmissions.. i will replicate your experiment side by side and post video as well.. Not looking for drama. there is a bug for sure. i have bean pleased with uniden and there steadfast Firmware updates enhancing and making the 436 an exceptional piece of gear.

Uniden please look in to this bug.

Thanks, John

 

[Voyager]

System type? (and same questions in post 30)

@ sallen: What happens if you program just the control channel in a new FL and use ID SEARCH with nothing avoided? (curious to see if other TGs show the same behavior) Also, is this happening on one TG or any?

 

[johnnyg828]

Analog

 

[johnnyg828]

Press hold on channel and signal loss as well..

 

[Voyager]

Analog

Harris? Motorola? EFJ? LTR? EDACS?
(more than one answer may apply)

Are you using the latest firmware? (and yes, sallen, 1.10.02 is the latest)

Are you using the control channels only or are all the channels programmed?

Can you give some more details about how many site(s) you are scanning, if this is a FL or main dB, and how many other systems you are scanning?

Are there any encrypted or data TGs on the system?

 

[darunimal]

Same problem experienced multiple times with a Motorola SmartNet II setup, consistently "Inconsistent" 'Delay operation, even when holding on one channel and always with only that system enable, zero hold time makes it so much worse, I can't believe it was even recommended, just as foolish setting the sequenlch to 0. Don't even get me started on a scanning 2 systems 1 a Moto smart net II and a P1/P2 system. I have no idea what and where Voyagers suggestion "Search" with nothing avoided, would yield unless you want your scanner to be a searcher. but it does sound as pointless as him not understanding or using reason, his incessant un-openmindedness when it comes to anything he perceives negative about Uniden. This is the same person that didn't believe there was a RTC clock problem for 4-5 months or the LED failures of many users for many months, If he would simply stop trying to help with his screwed perspective, he could start helping a lot of people. I messages him many months ago about him affecting people's health, with his antics of disputing all things that could possibly have a "Uniden negative connotation," I surely didn't get a reply then.

1 System, 1 Site, 1 Department , 11 Channels: 5 scanned - 6 Locked out (4 seldom used if ever, 2 used frequently) 2 other Departments not enable, 68 other systems not enabled, Hold time set to 8, Delay 2 for all channels in system, 4 CC (1 main) (3 alternate), CC Only, Squelch 2, Attenuation Off, step 12.5khz, Volume 7, Dimmer Low, Contrast 7, recharable battery powered, South facing window 3 feet from said window, in a 44oz empty cup from WAWA, Firmware 1.10.02, current Db but never used, all service types enabled, Location Control Off, Digital Voice, Analog End Code, encrypted channels are Avoided and seldom used in current jurisdiction, data channel programmed Avoided and it's department is not enabled.

 

[johnnyg828]

I do feel confident that uniden will address this issue in time.

If you do notice Firmware updates...."Fixed an issue"

Be patient my friends, hoping with next couple of Firmware updates the 436 will be a powerhouse.

 

[sallen07]

@ sallen: What happens if you program just the control channel in a new FL and use ID SEARCH with nothing avoided? (curious to see if other TGs show the same behavior) Also, is this happening on one TG or any?

OK, so I created a new favorites list, and inside it set up a new system (P25 Trunk) and defined one site with just the control channel. It *works*, but I cannot see where you can even set a delay ... that seems to be by department or by TG only. So it's not really a good test, unfortunately.

What I do see is the same delay in reacquiring a conversation once it drops. If the system is idle, my BCD436HP and Pro-666 pick up a new transmission almost simultaneously. But there seems to be an issue with the BCD436HP locking onto the *next* transmission, whether on the same TG or another one.

I'll keep playing with it.

 

[Voyager]

OK, so I created a new favorites list, and inside it set up a new system (P25 Trunk) and defined one site with just the control channel. It *works*, but I cannot see where you can even set a delay ... that seems to be by department or by TG only. So it's not really a good test, unfortunately.

I don't think you can program a delay for "unknown" TGs. Maybe try programming some you know with the delay and see if the issue recurs.

And for Dia - it's called diagnosis; looking for issues that can be the cause of the behavior seen. Sometimes the oddest combinations will cause issues. But, if you dismiss something out of hand, you're not able to perform the diagnosis and you're not doing the job correctly.

And if you know the answer, DO please share it with the rest of us who are still looking.

People have reported solving issues with 0 squelch, with modulation changes (something I should have thought to suggest earlier), and with setting HOLD times differently. I'm suggesting these fixes to see if they work in this case. Again - diagnosis.

I'm affecting people's health? Really? Is there no blow too far below the belt for you? That's ridiculous.

Sallen, is your 800 MHz (or whatever band this is) set to AUTO, FM, or NFM in your bandplan? (and please try to ignore the real trolls who only want to criticize Uniden and have no interest in helping you identify the issue)