Batboard

I can enable the switch to "scan list program", but once in program mode I cannot edit the scan list. I made sure that the scan list is set up and enabled for all channels. The user's manual says nothing about user-programmable scan and there is nothing in the CPS help for this topic. Anyone have any ideas?

Okay... I really dislike these radios. But I did manage to figure it out. In case anyone else runs into this problem:

- You have to make sure that the priority 1, priority 2, and non-priority channels priority assignment type is set to "operator select".

That's not unique to XTS2500 radios; true of all the M portables I'm aware of.

By the way, you can make the Priority 1 channel "user selectable" only if it is set for a discrete channel, versus "Selected Channel." Priority 1 should always be set for "Selected Channel" on a working radio, else you won't be able to maintain a conversation without first disabling scan.

By the same token, Tx steering should always be set for "Selected Channel" or you'll end up transmitting on an unintended channel.

Dave518 wrote:Okay... I really dislike these radios. But I did manage to figure it out. In case anyone else runs into this problem:

- You have to make sure that the priority 1, priority 2, and non-priority channels priority assignment type is set to "operator select".

That's been the case for many previous generations of Moto radios - in order to edit any part of the scanlist (P1, P2, NP members) from the radio's controls, has to be set to some combination of operator select.

Dave518 wrote:Okay... I really dislike these radios. But I did manage to figure it out. In case anyone else runs into this problem:

- You have to make sure that the priority 1, priority 2, and non-priority channels priority assignment type is set to "operator select".

You find it unusual that the scan list must be set to OPERATOR SELECT in order use the operator selectable scan list function???????

RKG wrote:That's not unique to XTS2500 radios; true of all the M portables I'm aware of.

By the way, you can make the Priority 1 channel "user selectable" only if it is set for a discrete channel, versus "Selected Channel." Priority 1 should always be set for "Selected Channel" on a working radio, else you won't be able to maintain a conversation without first disabling scan.

By the same token, Tx steering should always be set for "Selected Channel" or you'll end up transmitting on an unintended channel.

All of the Motorola radios that are programmed with Astro25 CPS perhaps. I know Professional Series doesn't work that way.

nmfire10 wrote:

Dave518 wrote:Okay... I really dislike these radios. But I did manage to figure it out. In case anyone else runs into this problem:

- You have to make sure that the priority 1, priority 2, and non-priority channels priority assignment type is set to "operator select".

You find it unusual that the scan list must be set to OPERATOR SELECT in order use the operator selectable scan list function???????

No, I find it unusual that you have to tell the radio that the priority and non-priority channels can be edited via user-programmable scan function even after you've told the radio that the user-programmable scan function has been enabled. It seems like an extra step. The only purpose of doing it this way would be to prevent the user from editing the priority channel(s) while still having the ability to edit the non-priority channels.

And there's no reason to be such a smart ass...

Dave518 wrote:
And there's no reason to be such a smart ass...

If all the smart asses left Bl, there'd be very few people left

Dave518 wrote:

nmfire10 wrote:

Dave518 wrote:Okay... I really dislike these radios. But I did manage to figure it out. In case anyone else runs into this problem:

- You have to make sure that the priority 1, priority 2, and non-priority channels priority assignment type is set to "operator select".

You find it unusual that the scan list must be set to OPERATOR SELECT in order use the operator selectable scan list function???????

No, I find it unusual that you have to tell the radio that the priority and non-priority channels can be edited via user-programmable scan function even after you've told the radio that the user-programmable scan function has been enabled. It seems like an extra step. The only purpose of doing it this way would be to prevent the user from editing the priority channel(s) while still having the ability to edit the non-priority channels.

And there's no reason to be such a smart ass...

The reason (which is sound) why operator access to the non-priority members and the priority members is by different parameters is because it is not unusual to allow subscribers to change the non-priority members of the list but force them to use the department-programmed Priority 2 member (usually the dispatch channel).

Priority 1 should always be "Selected Channel" or else you won't be able to maintain a conversation without first disabling scan.

Priority 1 should always be "Selected Channel" or else you won't be able to maintain a conversation without first disabling scan.

I don't understand what the priority assignment type has to do with maintaining a conversation. As long as you have the designated TX channel set to "selected channel" you should be fine.

Until the guy you're trying to listen to on the selected channel gets bounced off by some other fixed Priority 1 channel.

Trust me on this.

RKG wrote:Until the guy you're trying to listen to on the selected channel gets bounced off by some other fixed Priority 1 channel.

Trust me on this.

That is the purpose of a priority 1 scan list member.

I agree with RKG on the selected channel as priority 1... especially for public safety use.

I can make an exception for a commercial use where I have the following:
CH1 is Dispatch
Ch2 is Car-Car

Ch1 would be forced priority 1 as to not miss a call from dispatch.

tpg

1) Perhaps, but better hope you're not dealing with life-or-death traffic on the "car-to-car" channel.

2) As a practical matter, after the first two or three times when the guy is interrupted in his "car-to-car" comms, he'll just learn to turn off scan, in which case your purpose is defeated unless you make scan forced.

3) Not to nit pick, but in most cases wouldn't the "car-to-car" be the direct of dispatch, in which case you'd hear the dispatch traffic anyhow?

4) Notwithstanding all the above, I plead guilty to a public safety bias; it is pretty much all I do.

As a practical matter, before the Micor Mobile, while we had multi-channel radios, we did not have scanning receivers, and their use in public safety radio was quite controversial. In the 70s, PDs in the greater Boston area set up BAPERN; each mobile had four channels: 1 was local dispatch; 2 was sub-district common, 3 was district-wide common and 4 was district-wide special ops. Cruisers were equipped with the scanning receiver head on the theory that, if a guy switched off Ch. 1 for a legitimate reason and then forgot to switch back, he still had a good probability (but not a certainty) of hearing dispatch traffic nonetheless. (And, at the same time, if his local dispatch was quiet, he'd also hear BOLOs from neighboring towns directly, without having to wait for local dispatch read-back; this was considered to be (and has proved to be) a great enhancement in officer safety.) However, the head had no priority feature, and scan was defeated when the guy went off hook anyhow (as it still does today with mobiles).

Nowadays we have fancy portables with sophisticated scan capabilities (and the concept of being "off hook" has become meaningless). My pretty much inflexible rules have been:

SelCh is Priority 1.
Priority 2 is seldom (if ever) used.
"Talkback scan" is never used.
Tx follows the selector at all times.

They have served me well.

RKG wrote:1) Perhaps, but better hope you're not dealing with life-or-death traffic on the "car-to-car" channel.

2) As a practical matter, after the first two or three times when the guy is interrupted in his "car-to-car" comms, he'll just learn to turn off scan, in which case your purpose is defeated unless you make scan forced.

3) Not to nit pick, but in most cases wouldn't the "car-to-car" be the direct of dispatch, in which case you'd hear the dispatch traffic anyhow?

4) Notwithstanding all the above, I plead guilty to a public safety bias; it is pretty much all I do.

I am #4, strictly public safety here too. But I can see the application in a non-PS system. I'm going to counter most of your points, but understand this first. I am a public safety radio geek, and full time user. My belief is:
Priority 1= Selected Channel
Priority 2= Dispatch

I also believe in TURNING SCAN OFF when communicating with someone. Hence, while in a burning building, I don't give a flucking f what the agency next town over is doing. My guys outside know what channel I'm on inside, and there are WAY too many variables to be having scan on during an incident....

#1 counter= you're a moron if you're dealing with life or death on a car-car channel. (not you personally, but anyone in general) Also, I specifically stated "make an exception for commercial use..."

#2 counter= Then that's the user preference. Turn scan off, but if he misses a call.... Which brings the point to your orig argument, why be scanning if you are communicating on your priority channel anyways? Next point, do you have scan disabled off hook? if so, scan is disabled during comms as well.

#3 counter= Yes and no. Most of the time yes, but where I am there is too much car-car to be shared with dispatch, both fire and PD.

I'm not trying to be a cack, I can see both sides of it, that's all. I'd much rather have the "extra step" that the OP is bitching about to give me the flexibility to do what I want though.

Not flaming anyone (for a change) just trying to be in the other's shoes.

tpg

Though it may not be obvious to some readers, tpg and I are more in agreement than in disagreement. In particular, his point about being in scan at all during an assignment (save possibly at the IC level) is very valid and warrants emphasis. Scan, in the main, is for when you are between assignments, at which time your selector should be on the dispatch channel.

I really didn't envision "life or death" traffic on a chit-chat channel, but rather if you have moved off dispatch for a comms -- say to a tac or fireground channel -- it is probably for a good reason.

In my area, most dispatch systems are repeated, employ voted receivers and are wireline controlled. This means that dispatch will not hear "direct" (on the output freq), which can be both a plus and a minus.

Finally (and I really mean that), I wholeheartedly endorse tpg's last point: at least the Motorola metaphors give us the option of designing things for our particular applications. That of which the OP complained is actually a feature, not a flaw.

We're in agreement. The differences are really preferences more than anything.

Traffic on a car-car channel is typically / implied non life or death and are either "what are you up to" or "where are you to swap calls" or "get a load of this" type traffic. It was your post that said "life or death" to start that off. I was just retorting it. If you DO go off to a Tac or fireground channel, you're not "technically" on a car-car channel as dispatch is almost always with you should you need something. We have a BOATLOAD of BS ChitChat channels that we use for non-hazardous calls / car-car stuff that is not dispatch monitored. But any "working" event is on a dispatch monitored channel, regardless of task.

In my area the same set-up is true, but there is simply too much radio traffic on dispatch to have car-car on the same channel for some agencies. Thus, car-car is a sep channel.

Nice chat... I'm done on this one.

tpg

I'm not trying to be a cack, I can see both sides of it, that's all. I'd much rather have the "extra step" that the OP is bitching about to give me the flexibility to do what I want though.

I said I disliked the PR1500. I never bitched about the extra step. I understand why it is done the way that it is done. For 99% of the programming I do, however, it is an extra step.