BCD325P2/BCD996P2: Multiple Units trouble with Phase 2 Audio

[policefreak]

So last week I had shared in the Tech Support forum how my new BCD996P2 would have trouble locking onto the right voice frequencies only when monitoring Phase 2 audio, and only when having to scan through a P25 system and another system. Here is the video for those that haven't seen it...

https://www.youtube.com/watch?v=FIUdlylttcI

So having tried literally "everything" including Firmware Upgrade 1.04.03, that unit was exchanged for a new unit. That new unit showed up on my doorstep today, shipped from Virginia. And it seems to have the same issue with Phase 2 audio. The other odd thing about this new unit is that upon checking the Scanner Info, it already had Firmware Version 1.04.03. So...unless it was being manufactured in Japan on 3/31 when that firmware upgrade came out, and somehow managed to make its way to Virginia on 4/9 when it was shipped out to me, then did I just get someone else's updated, returned, and repackaged unit...?? That seems a little odd. I've been contacted by another 996P2 owner who seems to have the same issues on Phase 2. Here's another example video.

https://www.youtube.com/watch?v=1l3T15TIlcY

So unless I just received 2 bad units among a lot of good ones (That's some bad luck!) and this poor fella received another bad unit, perhaps this is a firmware issue that needs to be addressed...?

 

[KevinC]

And not to hijack your thread, but the BCD325P2 has the exact same issue.

 

[policefreak]

Thank you that's very important info. Just to confirm, does the problem show itself in the same way I've described, where the rogue frequencies only come up on Phase 2 transmissions when the radio is monitoring more than one system (of any kind) at a time?

 

[KevinC]

Thank you that's very important info. Just to confirm, does the problem show itself in the same way I've described, where the rogue frequencies only come up on Phase 2 transmissions when the radio is monitoring more than one system (of any kind) at a time?

Exactly as you described.

I'm not trying to beat up Uniden, but you'd think something so easy to reproduce would have been caught in beta testing.

 

[GTR8000]

We have noticed the same issue with a 996P2 scanning our ASTRO 25 Phase II system. The inability to properly identify the TDMA voice channel frequencies seems to occur most often when other systems are also being scanned at the same time (conventional and/or trunked). If you let the unit scan nothing but the trunked system itself, the issue is less likely to occur.

It's worth noting that our system is 100% TDMA; there are no FDMA or DDM talkgroups. Therefore, I have not been able to test how the scanner would react in a mixed FDMA/TDMA system, whether the issue also occurs when the scanner jumps from decoding an FDMA talkgroup to decoding a TDMA talkgroup.

It's also worth noting that when the scanner does figure out the correct TDMA voice channel frequency, it sounds pretty darn good.

Edited to add: The issue persists even with the latest firmware 1.04.03. Updating the firmware made no difference.

 

[W8RMH]

Some of these new scanners seem to appear out of nowhere and no one seems to know anything about them until they are released to the public.

With all the issues the purchasers are experiencing I don't think any beta testing is being done at all and I don't recall ever seeing any test data except the post-purchase evaluations here on RR.

 

[eaf1956]

I wonder if any of these issues improved when they updated the P2 firmware!

 

[policefreak]

No. Many of us did the firmware upgrades with no difference in performance.
Oh! And just so everyones clear, this does not seem to be a simulcast reception issue. I know I have sat directly under a tower for a Phase 2 p25 system with attenuator on and have experienced this issue. A few other people have said the same thing.

 

[ke4wkp]

I was going to get a BCD996p2 and a BCD325P2 because our county is going Phase II. Bummer. Uniden should do more testing. I am available to be a tester for my area if Uniden is interested.

 

[troymail]

We have noticed the same issue with a 996P2 scanning our ASTRO 25 Phase II system. The inability to properly identify the TDMA voice channel frequencies seems to occur most often when other systems are also being scanned at the same time (conventional and/or trunked). If you let the unit scan nothing but the trunked system itself, the issue is less likely to occur.

I have previously reported seeing something similar to this on the x36 radios. It is as if something in the scanner memory/processing isn't cleared/initialized properly before the next system / system type is scanned.

FWIW - I've also seen this lack of clearing memory in the headers of x36 recordings.

 

[plato]

Ref: BCD996P2

If the problem only occurs when your scanning other TRS systems with Camden County’s TRS system, not when your scanning only Camden Co.’s TRS system, correct? If so, you may be getting interference from the other TRS systems you are scanning. Make a note of the bougus channel or freq. that comes up and then see if belongs to any other TRS system you are scanning. If so, it may be “bleeding over” into Camden County’s system. A software”bug”? Who knows. I recently purchased a BCD996P2 and a BCD325P2.Both radios work GREAT!! Very easy to program by hand.(Both are similar to my BCD396T,XT) I am very happy with both of them! Dave Richman.

 

[KevinC]

If the problem only occurs when your scanning other TRS systems with Camden County’s TRS system, not when your scanning only Camden Co.’s TRS system, correct? If so, you may be getting interference from the other TRS systems you are scanning. Make a note of the bougus channel or freq. that comes up and then see if belongs to any other TRS system you are scanning. If so, it may be “bleeding over” into Camden County’s system. A software”bug”? Who knows. I recently purchased a BCD996P2 and a BCD325P2.Both radios work GREAT!! Very easy to program by hand.(Both are similar to my BCD396T,XT) I am very happy with both of them! Dave Richman.

It's not "bleeding over" or interference.

The bogus frequencies are not even in the correct part of the spectrum.

 

[RoninJoliet]

The bogus freqys seem to be in the rebanded traded off area that the cell phone people have received...In the trade off all freqys in 866 dropped 15 mgz and became 851.... Its like the scanner is choosing the old Motorola #ing freqy system .....That was a rebanding problem the early 346XT scanners showed until they Uniden had a new firmware change.....I had one and after new firmware was fine.....

 

[GTR8000]

Clarifications

A few clarifications:

1) It has nothing whatsoever to do with multipath interference from simulcast cells

2) It has nothing whatsoever to do with "interference" or "bleed over"

3) The updated 1.04.03 firmware made no difference whatsoever

4) This issue has only been reported with TDMA talkgroups; so far it does not appear to affect FDMA talkgroups

5) We are experiencing this issue with a 700 MHz system, whereby the scanner is attempting to tune to invalid frequencies in the 78x MHz range for TDMA voice frequencies. Those frequencies have nothing to do with 800 MHz rebanding.

6) The fact that it's trying to tune to frequencies that high in the 700 MHz band indicate that it's not calculating the correct TDMA voice frequencies with any degree of consistency.

There are at least two of us in this thread who have technical knowledge and firsthand experience with these ASTRO 25 TDMA systems far beyond that of the average hobbyist. I do not say that to come across as arrogant, it's simply a fact that is important to understand before taking stabs in the dark at offering up possible causes or solutions. Rest assured that if we say there is a bug with the scanner processing the TDMA band plan, then the problem is real.

 

[KevinC]

What's ironic is it exhibits this issue on the very system that is shown on the radio on the box that the unit comes in (City of Irving, Texas).

 

[AZScanner]

The bogus freqys seem to be in the rebanded traded off area that the cell phone people have received...In the trade off all freqys in 866 dropped 15 mgz and became 851.... Its like the scanner is choosing the old Motorola #ing freqy system .....That was a rebanding problem the early 346XT scanners showed until they Uniden had a new firmware change.....I had one and after new firmware was fine.....

The "Phoenix" bug returns! This was what we called it back in the early days of the 296D and 796D because on the Phoenix RWC the same thing would happen with FDMA talkgroups. IIRC, Uniden had to send engineers out here to Phoenix to monitor the system for themselves before they were able to successfully fix it.

It is ironic that one of the systems this is happening on is the Irving TX one. Forget the Beta team, how come Paul didn't catch this one?

My amateur guess as to the cause of this (and the inconsistencies reported with the x36 line) is not a failure of the beta team, but rather a failure in manufacturing. Seems that the test units are made differently than what hits the streets, which really is defeating the purpose of having a beta test and leaving Uniden with a black eye after customers take home radios with undiscovered bugs in them.

-AZ

 

[phask]

If you look at what it sets as the bandplan - is it correct?

Just a wild guess.

A few clarifications:

1) It has nothing whatsoever to do with multipath interference from simulcast cells

2) It has nothing whatsoever to do with "interference" or "bleed over"

3) The updated 1.04.03 firmware made no difference whatsoever

4) This issue has only been reported with TDMA talkgroups; so far it does not appear to affect FDMA talkgroups

5) We are experiencing this issue with a 700 MHz system, whereby the scanner is attempting to tune to invalid frequencies in the 78x MHz range for TDMA voice frequencies. Those frequencies have nothing to do with 800 MHz rebanding.

6) The fact that it's trying to tune to frequencies that high in the 700 MHz band indicate that it's not calculating the correct TDMA voice frequencies with any degree of consistency.

There are at least two of us in this thread who have technical knowledge and firsthand experience with these ASTRO 25 TDMA systems far beyond that of the average hobbyist. I do not say that to come across as arrogant, it's simply a fact that is important to understand before taking stabs in the dark at offering up possible causes or solutions. Rest assured that if we say there is a bug with the scanner processing the TDMA band plan, then the problem is real.

 

[policefreak]

For me, the 3 P25 Phase 2 capable systems that have issues are the correct bandplan on the 996P2. That was checked against a BCD436HP that picks up Phase 2 constantly and a GRE PSR 800 that has stellar response times on Phase 2 transmissions.

 

[GTR8000]

If you look at what it sets as the bandplan - is it correct?

Just a wild guess.

It is 100% correct, otherwise it would've been the very first thing mentioned.

 

[KevinC]

It's worth noting that our system is 100% TDMA; there are no FDMA or DDM talkgroups. Therefore, I have not been able to test how the scanner would react in a mixed FDMA/TDMA system, whether the issue also occurs when the scanner jumps from decoding an FDMA talkgroup to decoding a TDMA talkgroup.

On a system with both FDMA and TDMA it "appears: to function properly on the FDMA TG's, only the TDMA TG.s have the issue.