On 3/12/2010 1:03 PM, nj902 wrote:
Answers to most of the Mototrbo questions can be found in the Mototrbo
System Planner.
Here is some information on color codes and groups copied from that
document:
Color codes are defined by the Digital Mobile Radio (DMR) standard and
can be used to separate two or more MOTOTRBO digital radio systems
which operate on common frequencies.
The total number of available color codes per frequency is 16. From a
radio user's perspective the color code is similar in nature to a
Group ID. However, it should not be used for this purpose. Just as
Groups are intended to separate users into groups, the color code is
intended to uniquely identify systems or channels which operate on
common frequencies.
In MOTOTRBO systems, capabilities for Group Calls are configured with
the portable and mobile radio CPS. The repeater does not require any
specific configuration for groups. Radios can be configured to enable
the user to select among multiple groups using the radio channel
selector knob or buttons, or using the radio menu contacts list. Which
group a radio user hears on a given channel depends on a configurable
parameter called the RX Group List.
Very succinct answer, thanks. That all matches what I suspected.
Someone else had forwarded me a copy of the system planner document just
this morning, but I hadn't had any time to read/review it.
Quickie question (that'll be answered when I get around to reading it,
but I suspect the answer is "no")... does the System Planner document
cover the new(er) trunking functionality at all? (Not that I can afford
two or more repeaters, nor need them, nor even a TRBO radio right now...
ha... just curious more than anything.)
Comparing all these similar-but-different digital systems keeps the
brain sharp... digging through their specs looking for something REALLY
innovative, is always fun. Nothing in TRBO is all that innovative, so
far in my reading.
It's well-implemented, and as one local pointed out... it behaves like I
expect a commercial radio system to... he was comparing to D-STAR where
you *have* to fidget and mess with callsigns, etc... to really utilize
all the features... in TRBO, he switches the rig to "Channel 1" to talk
locally, and "Channel 2" to talk to a pre-defined group of IP-linked
repeaters... obviously, this is dirt-simple, and keeps the complexity
for the user away, and places the complexity choices on the system
operator/administrator. Not as "flexible" by any means, but sometimes
you're just looking for it to "just work".
I'm SERIOUSLY curious to find out how it behaves with "collisions" in
the IP routed world. And their announcement that they have
"transmission interrupt" functionality is fascinating. There's a couple
ways they could implement that, but I assume it's a "priority" decision
made by the repeater... one station talking on a particular TG, another
keys up (on second channel) on same TG, repeater sees they're a higher
priority user, and stops passing the first user's transmission and
switches to the second user's... could get very confusing in practice,
if the rigs don't have a good way to signal the stop of one transmission
and the beginning of the next, but if they higher-priority traffic gets
through -- okay, that's good.
Now start mixing the collision problem in the IP-linking and the new
"priority" feature. Ahh, a system's integrator/systems testers dream
Excel spreadsheet of possible tests comes out of that... would be fun to
document it all. Well, if I were getting PAID to do it, it would,
anyway. LOL! That testing would be time-consuming, but fun.
I bet a few sure-fire examples of "unintended consequences" would come
out of that testing. Then add trunking. The matrix of required tests
to document all the scenarios is almost already out of control, mixing
all of those features together. They keep adding stuff, they'll hit the
"too complex to test" point, pretty soon.
Thanks for the info.
Nate WY0X
