BCD536HP - Slow Scan - My Workaround

[4436time]

UPMan's post #11 is all you need to know. A good starting point would be to put all systems into one FL and managing at the dept level using QK's, avoids/unavoids, service types, and going from there. One of the beauties in the HP line of scanners is in the simplicity of the programming.

 

[Gilligan]

The whole point of having favorites lists in the first place is to group your systems into lists according to your favorite listening scenarios. That's why the firmware needs to be updated to sort through the systems scanned and group all the talkgroups together before scanning -- so the end users don't have to start a thread like this in the first place.

 

[CKennedy4812]

I've noticed that the trunk site frequencies are listed in numerical order. Would there be any benefit to moving the control channels to the top of the list?

 

[RF23]

I think the 536 & 436 have the same scan capabilities as suggested by the x36 Sentinel name. Of course, I suppose behind the scenes Sentinel could be able to tell them apart.

 

[troymail]

I've noticed that the trunk site frequencies are listed in numerical order. Would there be any benefit to moving the control channels to the top of the list?

I think I've seen times where they are somewhat random. It would certainly seem to be best if the primary and alternate CCs are listed first but then again, I don't know what the radio is doing with this information. Also, various reports in the past suggest that any system/site frequency could potentially actually be used as a CC.

I've had a habit for a while now to create some custom programming which results in removing all but the known control channel frequencies and ordering them such the the primary listed on RR is always first -- particularly for the P25 systems (with simulcast modulation issues). I'm looking forward to the day when this really isn't necessary to improve performance. It's possible that the 536 is better but I'm still testing out various configurations.

I agree with the earlier posts that say the radio firmware should be able to detect that the same system CCs are programmed more than once and then only check the system once per pass. On the other hand, the ability to program the same system CC multiple times with multiple favorites lists has a potential benefit - the user could program that system multiple times to force that system being checked more often (say you have 10 systems programmed - you could force the radio to check your primary or most important system more than once during each "pass" through the programmed systems). I don't think that's the reason favorites lists work - just a side effect.

 

[CKennedy4812]

The whole point of having favorites lists in the first place is to group your systems into lists according to your favorite listening scenarios. That's why the firmware needs to be updated to sort through the systems scanned and group all the talkgroups together before scanning -- so the end users don't have to start a thread like this in the first place.

I agree. If I wanted to listen to just fire channels, and they are a mixture of conventional and trunked, I would have to use a combination of FLs and departments and that is a lot of extra work.

Also, someone in one of the threads ran into a size limit for FLs. The advice was to break his large FL into parts. This seems to go against that.

 

[UPMan]

Or just turn off the service types other than Fire.

 

[whsbuss]

Control Channels

Is it better to just have the control channels programmed per system instead of all the freq.'s in the DB?

 

[UPMan]

It makes virtually no difference (unless a frequency not documented as control channel becomes a control channel, in which case it would make a lot of difference). Skipping the non control channels takes a fraction of a second.

 

[shonc182]

Instead of having six favorites lists with the counties divided by police/fire, think about how you typically scan those systems. For example, I would think the following scenarios would generally apply:


1) All police for all 3 counties
2) All fire for all 3 counties
3) Police/Fire for 1st county
4) Police/Fire for 2nd county
5) Police/Fire for 3rd county


If you wanted to take it a step further, and only if there were a fair number of times when you only listened to one type of each county, like police only for 2nd county for example, you could add 6 more scenarios that match your original favorites list setup.

Still working on what has become a major rework of my present setup, but I have opted to do something similar to the above. I will actually end up with 10 lists; 1-'Master' list containing all 3 counties and all police/fire channels (though this is quite large), 6-'County/Service' specific lists -each county will have 2 FL's (police and fire), and 3-'County' specific lists (containing both police and fire). The intent is that while listening to the big list, I hear about a major fire in Multnomah Co. - I turn off the big list and turn on the Multnomah Fire list....or maybe Multnomah Police/Fire.

What I am starting to notice - in an effort to have some ease of controllability, especially in the big list, I am combining some individual departments from the database into larger departments (i.e. Portland Central Precinct now gets lumped in with all other precincts to 'Portland Police'). So it initially looks like I am sacrificing some controllability in the interest of speed, but I am reserving judgment until I can get his loaded up.

 

[Gilligan]

The end result of all this is that in order not to sacrifice scan speed, due to the firmware not building it's own master scanlist, you pretty much have to put all the talkgroups from a particular system into one favorites list. If you have a system with many groups, for example a variety of smaller towns, you will have to put them all into the same list and simply use quick keys to activate the particular towns/agencies or use the Department Hold key to hold on one at a time.

Again, Uniden could fix this in a future modification of the firmware:

FL1, SystemX has 5 Departments
FL2, SystemX has 3 Departments (different from the first 5)

Scanner should build master list of scannable talkgroups from all 8 departments for SystemX and only scan it once per cycle instead of FL1,Sys1, FL2,Sys1, etc.

In this way, it would scan from the master list like so:

1) SystemX -- scan all active talkgroups from all active favorites lists for this system
2) SystemY -- scan all active talkgroups from all active favorites lists for this system
3) SystemZ -- scan all active talkgroups from all active favorites lists for this system

Now you would be able to scan everything you want efficiently.

And as the end user, you don't have to worry about working around this problem since it's something that CAN be changed in the firmware. The end user should be able to have an efficient scan routine as described. Remember, the radio was designed for both novices and experts.

 

[shonc182]

Much Improved!

After a couple evenings of a complete rework. I am very happy to report that performance is greatly improved. Thanks to all for the advice.

I have created a single 'master' FL for my main three counties containing police and fire. I still need to create additional smaller FL's that will contain smaller chunks of this master FL, but that should be easy at this point. This ends up containing about 60 departments within primarily two trunking systems and some in 3 conventional systems. I could have created a single conventional system, but for organization it made more sense to me to break these freq's up.

Some logically separate departments got lumped together to try and keep the overall number of departments as low as possible for ease of control later (recalling dept QK's by memory for quick on/off). Ability to control this is still a concern, but the speed is much better.

I have both the BC785D and 536HP scanning side by side. Initial observation puts the 536HP near even on speed now, but I plan on doing some data collection to really see. Getting it closer has put a bit of an exclamation point on another issue - missed and cutoff transmissions - it is more obvious now as I am hitting channels at the same time with both scanners....but this is another topic.

 

[RF23]

After a couple evenings of a complete rework. I am very happy to report that performance is greatly improved. Thanks to all for the advice.

I have created a single 'master' FL for my main three counties containing police and fire. I still need to create additional smaller FL's that will contain smaller chunks of this master FL, but that should be easy at this point. This ends up containing about 60 departments within primarily two trunking systems and some in 3 conventional systems. I could have created a single conventional system, but for organization it made more sense to me to break these freq's up.

Some logically separate departments got lumped together to try and keep the overall number of departments as low as possible for ease of control later (recalling dept QK's by memory for quick on/off). Ability to control this is still a concern, but the speed is much better.

I have both the BC785D and 536HP scanning side by side. Initial observation puts the 536HP near even on speed now, but I plan on doing some data collection to really see. Getting it closer has put a bit of an exclamation point on another issue - missed and cutoff transmissions - it is more obvious now as I am hitting channels at the same time with both scanners....but this is another topic.

That is really good news for all of us. However, the missed & cutoff transmissions may also have been solved - see the following tread, post #7.

http://forums.radioreference.com/uniden-scanners/283688-squelch-broken-end-tx-bcd536hp.html

 

[shonc182]

This is a significant improvement - specifically:

Prior to the FL modifications, the 536HP captured 85% as many transmissions as my old BC785D. After the restructuring of FL's, The 536 actually outperforms the old scanner by 9%.

Based on my previous data, there is potentially another 10% to be gained by correcting the missed or cutoff transmissions. Dealing with this next - but for me - the slow scan issue is fixed for the main trunking systems that I monitor. I haven't really dug too far into my conventional FL's and analyzed the performance here.

My FL's look nothing like they did after originally building them out of the database. It required a lot of manipulation in an extremely user unfriendly editor (Sentinel), but well worth the effort.

 

[tbakken]

Might no be a slow scan problem!

How about a firmware update to fix the P25 receive that doesn't work! My 536HP only receives some of the P25 transmissions. My 396xt will be talking away and nothing on my new $600 scanner. I am seeing a few of complaints but has anyone noted that even when a channel is on hold (presumably so that you can hear every word being said) it still does not receive! That needs to be fixed now! To me this scanner is worthless if it can't receive quickly enough to get all of the conversation. I would ask that Uniden stop selling this radio until that issue is resolved.

I am wondering if the slow scan issue is more of a doesn't #$%*@* receive issue!

 

[tbakken]

Is nobody else having a "slow" receive issue?

My BCD536HP is not receiving every thing. I can put it on channel hold and my 396XT will be talking away while the 536 just sits there. What the heck... This is on a conventional P25 channel. Sometimes it will work but most of the time it misses the first part of the transmission and sometimes seconds and multiple transmissions go by and nothing is heard from the 536 while my other scanner gets all of it. Anyone else noticing this? Uniden please respond. I will post a video on youtube when I can.

 

[RF23]

My BCD536HP is not receiving every thing. I can put it on channel hold and my 396XT will be talking away while the 536 just sits there. What the heck... This is on a conventional P25 channel. Sometimes it will work but most of the time it misses the first part of the transmission and sometimes seconds and multiple transmissions go by and nothing is heard from the 536 while my other scanner gets all of it. Anyone else noticing this? Uniden please respond. I will post a video on youtube when I can.

Some things you might want to check:

1. Is "Attenuation" Turned ON on the 536?

2. Is the P25 frequency the same as the 396XT?

3. Do you have the NAC set for both radios or is the 536 in "tone search mode" ? This is the default of the 536 and it will search for both analog and digital at the same time which is slower than searching for only one at a time (analog or digital) which in turn is slower than having the "tone code" already set. Some users have reported that the chopping off of the first parts of transmissions were almost gone when they set the Tone instead of letting the 536 search for it.

4. Are both radios on the same antenna or does one have a better antenna or better receive location than the other?

5. Are both radios set for the same "System Type"?

6. Have you changed the P25 "Threshold Mode or Level" settings on the 536?

7. Are both radios in "ID Search" or "ID Scan"?

Hope some of these help since I would find this kind of performance a bit frustrating!

 

[tbakken]

1. No attenuation is not on...
2. Same frequency...I am receiving it sometimes.
3. Tried both setting the NAC and searching the NAC.
4. Handheld is on rubber antenna....536 is on the antenna it came with. Only a mile or so from 100watt repeater.
5. Same type...
6 I have not changed a thing for threshold.
7. Its a convential P25 frequency...no trunking ID. (Did I mention its on HOLD! and acts like there is no signal there for somestimes 4 seconds then the next transmission is instant then back to seconds before audio is coming out of the speaker.)

Check out Uniden BCD536HP receive problem - YouTube

Got a second BCD526HP to compare. Same problem. There is a fundamental issue. Going to get out the IFR 2975 tomorrow to see if a good test signal can be received quickly. I will post a video of that so Uniden can watch that on youtube too.

 

[RF23]

1. No attenuation is not on...
2. Same frequency...I am receiving it sometimes.
3. Tried both setting the NAC and searching the NAC.
4. Handheld is on rubber antenna....536 is on the antenna it came with. Only a mile or so from 100watt repeater.
5. Same type...
6 I have not changed a thing for threshold.
7. Its a convential P25 frequency...no trunking ID. (Did I mention its on HOLD! and acts like there is no signal there for somestimes 4 seconds then the next transmission is instant then back to seconds before audio is coming out of the speaker.)

Check out Uniden BCD536HP receive problem - YouTube

Got a second BCD526HP to compare. Same problem. There is a fundamental issue. Going to get out the IFR 2975 tomorrow to see if a good test signal can be received quickly. I will post a video of that so Uniden can watch that on youtube too.

You are correct about my number 7 being no help but for some reason I thought you had programmed it as a P25 Single Frequency Trunk (which is what I do with all of my P25 conventional channels) as it allows me to get more info from the channel.

See post number 6 of the Thread below to find out more about this, it might even get read for your delay, but don't hold your breath.

http://forums.radioreference.com/uniden-scanners/277914-p25-one-frequency-trunk-programming.html

I sure will be interested in how this turns out as I plan on getting a 536 eventually (already have a 436).

 

[tbakken]

So here is another video. This time comparing the 536hp to the 436hp. Its actually embarrassing. The handheld is seconds ahead. I wouldn't be able to follow the traffic if I didn't have the 436hp running. Both radios are on hold on a single conventional P25 channel.

Another even better video. - YouTube