OT? Police/fire/etc. scanner usage

[Don Y]

Hi,

Apologies as this isn't strictly on-topic. But, figured
*some* folks here could provide hints or pointers to other
forum...

I rescued a handheld scanner with some battery issues.
Now that it's working, it seems an interesting "toy"
to add to my bug out bag. (I don't have much interest
in listening to that sort of sporadic chatter on a
daily basis!)

But, I'm clueless as to the most *practical* way of
"programming" it. To be clear, I understand how to get
the parameters *into* it; rather, I'm curious as to the
best way to map those frequencies onto the scanning
order, etc.

The device has 10 groups of 10 channel assignments.
The first of each can be treated as a "priority"
channel (there is a mode that gives preference to
monitoring these above the others). Entire groups
can be (easily) enabled/disabled. And, individual
channels can be disabled (though a bit more work to
do this for many channels).

After a bit of thought *imagining* how it might be
most useful in an emergency, I think the best
approach is to group similar services (from different
municipalities, etc.) into each group. E.g., fire
in group 1, police in group 2, etc. So, in a
given geographical region, you would tend (??) to just
be able to pick up one set of services -- and, they would
be distributed across multiple groups. This would allow
you to easily disable that particular service without
affecting other services from that municipality
(e.g., wanting to listen to the police chatter without
being distracted by activity on the fire channel(s)).

Since there often are several frequencies for each
service, you could assign N groups for police traffic,
M others for fire, etc. This would afford you the
same sort of easy "gating" for those individual
channels -- instead of having them compete with each
other in the same *group*.

Having neighboring municipalities also present in
these same groups (but "out of broadcast range?")
would allow you to migrate with the device picking up
the *local* services as you move between jurisdictions
(without having to manually reprogram or enable/disable
new groups for each locality).

[Remember, this sits in my BoB, not on my desk!]

Any hams or "casual listeners" who can comment on the
utility of various approaches to this?

Thanks!

 

[Martin Riddle]

Hi,

Apologies as this isn't strictly on-topic. But, figured
*some* folks here could provide hints or pointers to other
forum...

I rescued a handheld scanner with some battery issues.
Now that it's working, it seems an interesting "toy"
to add to my bug out bag. (I don't have much interest
in listening to that sort of sporadic chatter on a
daily basis!)

But, I'm clueless as to the most *practical* way of
"programming" it. To be clear, I understand how to get
the parameters *into* it; rather, I'm curious as to the
best way to map those frequencies onto the scanning
order, etc.

The device has 10 groups of 10 channel assignments.
The first of each can be treated as a "priority"
channel (there is a mode that gives preference to
monitoring these above the others). Entire groups
can be (easily) enabled/disabled. And, individual
channels can be disabled (though a bit more work to
do this for many channels).

After a bit of thought *imagining* how it might be
most useful in an emergency, I think the best
approach is to group similar services (from different
municipalities, etc.) into each group. E.g., fire
in group 1, police in group 2, etc. So, in a
given geographical region, you would tend (??) to just
be able to pick up one set of services -- and, they would
be distributed across multiple groups. This would allow
you to easily disable that particular service without
affecting other services from that municipality
(e.g., wanting to listen to the police chatter without
being distracted by activity on the fire channel(s)).

Since there often are several frequencies for each
service, you could assign N groups for police traffic,
M others for fire, etc. This would afford you the
same sort of easy "gating" for those individual
channels -- instead of having them compete with each
other in the same *group*.

Having neighboring municipalities also present in
these same groups (but "out of broadcast range?")
would allow you to migrate with the device picking up
the *local* services as you move between jurisdictions
(without having to manually reprogram or enable/disable
new groups for each locality).

[Remember, this sits in my BoB, not on my desk!]

Any hams or "casual listeners" who can comment on the
utility of various approaches to this?

Thanks!

There are websites that list your local frequencies. Just search for
'scanner frequencies'
FYI, some departments are/have switched to trunking equipment, so you
cant listen to them with a non-trunking scanner.

My old Bearcat has the group buttons. I used to scan and add the
frequencies of interest manually.

Cheers

 

[Don Y]

Hi Martin,

There are websites that list your local frequencies. Just search for
'scanner frequencies'

Yes, I already have those. My question concerns how best to *map*
those onto the channel assignments in the scanner.

E.g., if I put every service for my local community into Group 1,
the next municipality into Group 2, etc. then I can easily disable
"there" vs. "here". But, *being* "here" (instead of "there") already
does that for me -- the signals just don't propagate that far!

So, it seems more *useful* to spread the services across different
groups so that they can be (easily) enabled/disabled and let
geographical location take care of enabling/disabling different
municipalities services sharing a single group.

(e.g., if you're in D.C., channel 1x receives the fire dept for
D.C. while channel 2x receives D.C. police; move to NYC and
channel 1y receives NYC FD while 2y receives NYC PD; etc. Being
*in* NYC means the ?x channels (from D.C.) are out of range.
So, no need to explicitly be able to disable them, individually.
OTOH, being able to disable group 1? allows you to keep fire
chatter from interfering with police chatter)

[this example is intentionally naive as I realize certain
frequencies can be "reused" in different localities, etc.]

FYI, some departments are/have switched to trunking equipment, so you
cant listen to them with a non-trunking scanner.

Yes. Again, consider the application: emergencies. Presumably,
there would be an interest in disseminating information instead of
*hiding* it (though obviously there would also be interest in hiding
certain *types* of information).

E.g., I also have a portable CB radio in the BoB as it would allow
contact with other folks when other means of communication are down.

My old Bearcat has the group buttons. I used to scan and add the
frequencies of interest manually.

But, *where*? To which particular channel assignment? Or, just
"ad hoc"?

(In an emergency, you wouldn't want to be wasting time trying to find
or think of particular frequencies to monitor -- hence my idea to just
cover the surrounding localities)

 

[Martin Riddle]

Hi Martin,

There are websites that list your local frequencies. Just search for
'scanner frequencies'

Yes, I already have those. My question concerns how best to *map*
those onto the channel assignments in the scanner.

E.g., if I put every service for my local community into Group 1,
the next municipality into Group 2, etc. then I can easily disable
"there" vs. "here". But, *being* "here" (instead of "there") already
does that for me -- the signals just don't propagate that far!

So, it seems more *useful* to spread the services across different
groups so that they can be (easily) enabled/disabled and let
geographical location take care of enabling/disabling different
municipalities services sharing a single group.

(e.g., if you're in D.C., channel 1x receives the fire dept for
D.C. while channel 2x receives D.C. police; move to NYC and
channel 1y receives NYC FD while 2y receives NYC PD; etc. Being
*in* NYC means the ?x channels (from D.C.) are out of range.
So, no need to explicitly be able to disable them, individually.
OTOH, being able to disable group 1? allows you to keep fire
chatter from interfering with police chatter)

[this example is intentionally naive as I realize certain
frequencies can be "reused" in different localities, etc.]

FYI, some departments are/have switched to trunking equipment, so you
cant listen to them with a non-trunking scanner.

Yes. Again, consider the application: emergencies. Presumably,
there would be an interest in disseminating information instead of
*hiding* it (though obviously there would also be interest in hiding
certain *types* of information).

E.g., I also have a portable CB radio in the BoB as it would allow
contact with other folks when other means of communication are down.

My old Bearcat has the group buttons. I used to scan and add the
frequencies of interest manually.

But, *where*? To which particular channel assignment? Or, just
"ad hoc"?

(In an emergency, you wouldn't want to be wasting time trying to find
or think of particular frequencies to monitor -- hence my idea to just
cover the surrounding localities)

The Bearcat with the group buttons is meant for race team monitoring, so
1 team per group.
1 fire dist per group, 1 police department per group, 1 airport per
group, etc.

Get it?

Each group can be added or left out of the scan on the Bearcat
(Sportcat).

I'm sure yours is similar.


Cheers

 

[John S]

Hi,

Apologies as this isn't strictly on-topic. But, figured
*some* folks here could provide hints or pointers to other
forum...

I rescued a handheld scanner with some battery issues.
Now that it's working, it seems an interesting "toy"
to add to my bug out bag. (I don't have much interest
in listening to that sort of sporadic chatter on a
daily basis!)

But, I'm clueless as to the most *practical* way of
"programming" it. To be clear, I understand how to get
the parameters *into* it; rather, I'm curious as to the
best way to map those frequencies onto the scanning
order, etc.

The device has 10 groups of 10 channel assignments.
The first of each can be treated as a "priority"
channel (there is a mode that gives preference to
monitoring these above the others). Entire groups
can be (easily) enabled/disabled. And, individual
channels can be disabled (though a bit more work to
do this for many channels).

After a bit of thought *imagining* how it might be
most useful in an emergency, I think the best
approach is to group similar services (from different
municipalities, etc.) into each group. E.g., fire
in group 1, police in group 2, etc. So, in a
given geographical region, you would tend (??) to just
be able to pick up one set of services -- and, they would
be distributed across multiple groups. This would allow
you to easily disable that particular service without
affecting other services from that municipality
(e.g., wanting to listen to the police chatter without
being distracted by activity on the fire channel(s)).

Since there often are several frequencies for each
service, you could assign N groups for police traffic,
M others for fire, etc. This would afford you the
same sort of easy "gating" for those individual
channels -- instead of having them compete with each
other in the same *group*.

Having neighboring municipalities also present in
these same groups (but "out of broadcast range?")
would allow you to migrate with the device picking up
the *local* services as you move between jurisdictions
(without having to manually reprogram or enable/disable
new groups for each locality).

[Remember, this sits in my BoB, not on my desk!]

Any hams or "casual listeners" who can comment on the
utility of various approaches to this?

Thanks!

I don't know if this is the best way for you, but I used the group for
geographical location. Mainly because my county home is about 80 miles
from my city home and, believe it or not, the Sheriff's repeaters will
frequently break the squelch from that far away, especially if I'm using
an external antenna. If the signal breaks the squelch, it will tie up
the scanning until that signal goes away.

Just a thought.

John

 

[Don Y]

Hi John,

I don't know if this is the best way for you, but I used the group for
geographical location. Mainly because my county home is about 80 miles
from my city home and, believe it or not, the Sheriff's repeaters will
frequently break the squelch from that far away, especially if I'm using

Yikes! I had assumed signal would fall off much quicker than that.
OTOH, I hadn't been planning on anything other than the rubber ducky
for an antenna.

an external antenna. If the signal breaks the squelch, it will tie up
the scanning until that signal goes away.

Exactly. That was my rationale behind moving the various "services"
to different groups -- so they could *easily* be disabled (turn the
group off) to keep their traffic from interfering with something
that you actively want to monitor.

The few times I have used this were to monitor "situations" that were
happening and the "other (UNRELATED) traffic" kept interfering with
the monitoring of those *conversations*.

So, I figured moving tactical frequencies to a place where they
could be isolated from "dispatch" might have some merit, etc.

I will have to look at the frequency allocations with a more critical
eye towards how to factor geography into the partition more
effectively...

 

[Don Y]

Hi Martin,

On 2/18/2012 12:39 PM, Martin Riddle wrote:

[much elided]

The Bearcat with the group buttons is meant for race team monitoring, so
1 team per group.

OK. But, I would imagine that all of the traffic on that group
at any different time is related to that "race". E.g., you
don't have the team's *accountant* chatting with the tax attorney
on a frequency in that group at the same time. If so, you would
want to be able to easily filter that out.

E.g., police dispatch and tactical frequencies both could be lumped
together as "police" and assigned to a single group. But, if you were
then interested in following what is transpiring on "TAC1", you end
up also listening to other dispatches at the same time -- as well
as TAC2, etc.

I figured assign N groups for police (since there might be several
different UNRELATED "conversations" going on at any given time
and this would allow you to *easily* drop those channels that aren't
pertinent to your interests -- *or*, leave them in play!) and
M groups for fire (same reasoning).

It just seems easier to enable or disable groups than individual
channel assignments (push button, group is disabled, push again,
group is *enabled* -- and, you can see the status at any time by
looking at the display! Not so for the individual channels in
a group)

 

[Phil Allison]

"JeffM"

A recent news item I saw said that the police in
Pasadena, California are encrypting their radio traffic.
With the Federal Gov't copiously handing out bucks
to turn local police departments into paramilitary outfits,
expect to see a lot more of that nationwide.

** All radio traffic for police, fire and ambulance in NSW Australia is
encrypted and has been so for many years - same goes for the rest of the
country AFAIK.

Why you Yanks so far behind ?

No mobile phones and very few cordless phone exist with simple FM modulation
in Australia.

My AR1000 scanner is now used purely for checking FM radio mics on VHF and
UHF.



.... Phil

 

[Phil Allison]

Installed base.

** Fucking crap.

 

[Don Y]

I rescued a handheld scanner with some battery issues.
Now that it's working, it seems an interesting "toy"
[...]
Entire groups [of channels] can be[...]disabled

Hold that thought.

I think the best approach is to group similar services[...]
E.g., fire in group 1, police in group 2

A recent news item I saw said that the police in
Pasadena, California are encrypting their radio traffic.

Old news (well, maybe not for Pasadena, but this has been
going on for a LONG time)

With the Federal Gov't copiously handing out bucks
to turn local police departments into paramilitary outfits,
expect to see a lot more of that nationwide.

Unfortunately (?), it seems that many of those grants are
going towards "toys" that will have little practical impact
in a true emergency. I know some folks who deal with this
sort of thing on the State level and they shake their heads
when they describe some of the crap ^H^H^H wonderful stuff
that goes through on these grants.

But, then again, look at the sorts of folks who are making
those "low level" decisions. Can you spell "Peter Principle"?

It is painfully obvious that you had best look to your *own*
preparations (if that wasn't intuitively obvious before!).

OTOH, you can get just as silly throwing (*your*!) money at a
problem that may never (touch wood!) materialize.

[programming a freebie scanner seems to be low hanging fruit,
IMHO. YMMV]

 

[WoolyBully]

I rescued a handheld scanner with some battery issues.
Now that it's working, it seems an interesting "toy"
[...]
Entire groups [of channels] can be[...]disabled

Hold that thought.

I think the best approach is to group similar services[...]
E.g., fire in group 1, police in group 2

A recent news item I saw said that the police in
Pasadena, California are encrypting their radio traffic.
With the Federal Gov't copiously handing out bucks
to turn local police departments into paramilitary outfits,
expect to see a lot more of that nationwide.

It is called SDR. (Software Defined Radio).

The only reason the military is involved is because the enabling
hardware already exists in that channel. Funny that it is called SDR,
but so much Hdw is Rqd to get it UAR.

It will likely require a complete switch-out of all current transceiver
gear sets.

 

[bud--]

Hi Martin,


Yes. Again, consider the application: emergencies. Presumably,
there would be an interest in disseminating information instead of
*hiding* it (though obviously there would also be interest in hiding
certain *types* of information).

Emergency responders do not design their systems to disseminate
information. They aren't hiding information. They are making maximum use
of the frequency spectrum available.

A trunked system does not have frequencies assigned to a particular
function, like "traffic". There is a control channel. Otherwise,
frequencies are assigned to "traffic" when someone needs to send
"traffic" information. The channel assigned can be any of the channels
that are available. Listening to a trunked system without a scanner made
for trunking is very problematic.

Another minor problem is, as far as I know, they are all digital. And
some are encrypted (I don't think many of the systems, like police,
encrypt much.)

http://wiki.radioreference.com/index.php/Trunking
has information on trunking

http://www.radioreference.com
probably has the best information on what systems and frequencies are
used for a particular user (like NYC police).

E.g., I also have a portable CB radio in the BoB as it would allow
contact with other folks when other means of communication are down.

How active is CB these days? I don't know.

 

[Don Y]

Hi Bud,

How active is CB these days? I don't know.

I can usually find traffic on the CB a lot more often than
something dribbling in over the scanner.

CB has lots of appeal (remember, "emergencies").

First, I *can* transmit. I can't do so on police/fire/etc.
bands. (I've also got a 2m rig but I can't *legally* key
that. It would have to be a really *personal* emergency
to go that route) A pair of handhelds (I have three units
in my BoB) allows any group I may be a part of to split
while remaining in contact. And, anyone in that group
could contact "outsiders" to request aid, information, etc.

Second, it has a reasonably large established base. And,
many of the folks using it *tend* to be active on it. I.e.,
it's not sitting in a basement "ham shack" that gets visited
"occasionally".

Third, that same community of users tend to be the sorts
who would be involved in actively encountering and then
disseminating information about an unfolding emergency
(i.e., "they've closed down highway XXX", "A national
guard caravan just passed me headed east on...", etc.).

Of course, the *quality* of that information could be
dubious (would you prefer, instead, to be constrained to
ONLY receiving information spoon fed to you over a
*controlled* medium? Recall, I have access to that just
like any other "citizen").

I've also got a pair of pocket-sized GMRS handhelds for
yet another "potential link".

The goal, of course, is to never NEED any of this! :>

 

[josephkk]

Emergency responders do not design their systems to disseminate
information. They aren't hiding information. They are making maximum use
of the frequency spectrum available.

A trunked system does not have frequencies assigned to a particular
function, like "traffic". There is a control channel. Otherwise,
frequencies are assigned to "traffic" when someone needs to send
"traffic" information. The channel assigned can be any of the channels
that are available. Listening to a trunked system without a scanner made
for trunking is very problematic.

Another minor problem is, as far as I know, they are all digital. And
some are encrypted (I don't think many of the systems, like police,
encrypt much.)

Having used a trunked radio system for some years not too long ago i can
make the following definite statements about that particular system:

Analog FM (with some GMSK control tones), some 48 frequency channels (with
some 200 logical channels) on the system.

Definite (logical and frequency) channels assigned to specific functions
and by location as well:

Functions:
Traffic management
Maintenance
Construction
Traffic response team

Locales:
LA basin
San Gabriel Valley
Coastal
Ventura County

Orange county and San Bernadino + Riverside counties had their own
subsystems. Statewide agency managed allocation.

Most individuals in had personal call signs.

 

[bud--]

Having used a trunked radio system for some years not too long ago i can
make the following definite statements about that particular system:

Analog FM (with some GMSK control tones), some 48 frequency channels (with
some 200 logical channels) on the system.

Definite (logical and frequency) channels assigned to specific functions
and by location as well:

Functions:
Traffic management
Maintenance
Construction
Traffic response team

Locales:
LA basin
San Gabriel Valley
Coastal
Ventura County

Orange county and San Bernadino + Riverside counties had their own
subsystems. Statewide agency managed allocation.

Most individuals in had personal call signs.

About a year ago I tried to figure out trunking to figure out what I
would need if I bought a scanner. I looked at my notes. It is not
simple. There are multiple basic systems that have different and
multiple features.

Looks like most communications in use now are analog. Some systems can
use digital, and some can do encrypted. My impression was that state and
local did not use encrypted much.

A function, like "traffic" (that is "Podunk traffic"), can be
permanently assigned to a particular physical channel. But a basic
feature of most trunking is assigning a physical channel to a "logical"
use on the fly so a set of "logical" uses can use a much smaller number
of physical channels.

I think that is consistent with what you wrote.

Particularly if someone is interested in listening to emergency
responder and public service communications it would be a real good idea
to find out what systems are in use. The old simple scanners work for
some, but not for others. For some others you may be able to listen, but
the conversation you listen to will constantly change. Last I read there
was one trunked system that available scanners could not follow. The
information should be available at radioreference. Also I think there
are local forums at radioreference.

 

[josephkk]

About a year ago I tried to figure out trunking to figure out what I
would need if I bought a scanner. I looked at my notes. It is not
simple. There are multiple basic systems that have different and
multiple features.

Looks like most communications in use now are analog. Some systems can
use digital, and some can do encrypted. My impression was that state and
local did not use encrypted much.

A function, like "traffic" (that is "Podunk traffic"), can be
permanently assigned to a particular physical channel. But a basic
feature of most trunking is assigning a physical channel to a "logical"
use on the fly so a set of "logical" uses can use a much smaller number
of physical channels.

I think that is consistent with what you wrote.

Particularly if someone is interested in listening to emergency
responder and public service communications it would be a real good idea
to find out what systems are in use. The old simple scanners work for
some, but not for others. For some others you may be able to listen, but
the conversation you listen to will constantly change. Last I read there
was one trunked system that available scanners could not follow. The
information should be available at radioreference. Also I think there
are local forums at radioreference.

We are coming from somewhat different experience perspectives. I do not
see any important inconsistencies. The trunked system i used was rather
old (over 40 yo) and large. It was easy to follow with simple scanners as
a result. More modern and more software defined trunked radios can be all
but impossible to follow (or even receive) with anything but system
matched equipment.

Various players are really starting to understand the tradeoff between
interoperability and privacy/security of their radio systems. Large
players with seriously old systems do not want to suddenly replace and
entire fleet worth of equipment and their systems are the easiest to
interoperate for now. Organizations with the newest systems have the most
capability but do not interoperate worth squat yet. Creates a big problem
for FEMA and the like.

 

[bud--]

We are coming from somewhat different experience perspectives. I do not
see any important inconsistencies. The trunked system i used was rather
old (over 40 yo) and large. It was easy to follow with simple scanners as
a result. More modern and more software defined trunked radios can be all
but impossible to follow (or even receive) with anything but system
matched equipment.

Various players are really starting to understand the tradeoff between
interoperability and privacy/security of their radio systems. Large
players with seriously old systems do not want to suddenly replace and
entire fleet worth of equipment and their systems are the easiest to
interoperate for now. Organizations with the newest systems have the most
capability but do not interoperate worth squat yet. Creates a big problem
for FEMA and the like.

I am surprised there were trunked systems 40 years ago, but it is
certainly not something I keep track of.

My impression is that a major push for trunked systems (actually systems
that can easily be built to interoperate) came out of 9/11 when some of
the responders to WTC couldn't talk to other responders.

After the collapse of the I35W bridge in Minneapolis a couple years ago
there were responders from mulitple police, fire and state agencies. The
report was they could talk to each other very well. I believe the
trunked system used dates to after 9/11. Some trunked systems that can
be built as very interoperable can have encryption when needed.

 

[josephkk]

I am surprised there were trunked systems 40 years ago, but it is
certainly not something I keep track of.

My impression is that a major push for trunked systems (actually systems
that can easily be built to interoperate) came out of 9/11 when some of
the responders to WTC couldn't talk to other responders.

After the collapse of the I35W bridge in Minneapolis a couple years ago
there were responders from mulitple police, fire and state agencies. The
report was they could talk to each other very well. I believe the
trunked system used dates to after 9/11. Some trunked systems that can
be built as very interoperable can have encryption when needed.

Motorola came out with trunked radio systems in the late 1970s, they were
expensive enough that only large organizations could afford them, only
partly due to FCC licensing costs. Of course public safety and similar
agencies got first pick when they could afford them.

?-)