| Bridge Talkgroup:
The "Bridge" talkgroup is up and running now with 6 c-Bridges
now. The Talkgroup ID is
3100 and all you need is a c-Bridge mapping.
Check out the Bridge talkgroup for more information.
If you have a c-Bridge and wish to join, check out
the page for more information. |
| c-Bridge Masters: (Physical
repeaters as masters are now recommended over use of
a c-Bridge manager acting as an IPSC master) We
will soon be running all 5 IPSC Managers using the
c-Bridge as the Master for each network. The
diagnostics and control is much more advanced over
that of RDAC,
that we want those advantages for the original
network. When we installed our c-Bridge in June
2011, we kept our XPR-8300 Master for 1 network
thinking that the 8300 is more dependable than this
is new product. The c-Bridge is a proven
product and there is no need for a physical Master
(our 8300 lost it's RF PA and must come down
anyway). Possible downside to this approach is
that SmartPTT requires a physical Master repeater on
the IPSC network. |
| NAT Report: Initiate a
"NAT Report" to insure that all repeaters are
affiliated correctly with the c-Bridge. The
testing forces repeaters and network to reaffiliate
and takes 10-15 seconds, quicker than a reboot and
you don't loose the logged call history.
Occasionally, repeaters loose IPSC connectivity due
to variables across the internet. Most times,
the repeaters reaffiliate correctly, but for those
times when they do not, 1 or more repeaters appear
to be connected as they appear in Net watch but
actually will have no red or green bars showing
activity. Unless you notice this on "Net
watch", those repeaters are effectively, off
network, for some indeterminate amount of time. |
*Link ID Numbers:
(this is stale info since
introduction of Super Groups) are NOT the
same nor do they mean the same thing in different
parts of the c-Bridge, for example: Link ID numbers
for talkgroup bindings (IPSC Manager link numbers)
are not the same numbers as used in Inbound or
Outbound Servers and again are different from "Cross
patch" link numbers. To reduce any confusion,
do not use the same numbers for these 3 services
We suggest 1-30 be reserved for only the IPSC
Manager links, 51-99 for Inbound and Outbound server
Link numbers and 100-200 for Cross patch link ID's.
And document EVERY assignment on a list that you can
refer to while programming your c-Bridge. This
will make life much easier when making changes later
and trying to remember out how you set-up a set of
interrelated functions. Super Groups
|
Function |
Link # |
Notes; see
more details below this table |
|
Audio
Connections |
1-30 |
1-10
generally on 5 IPSC Manager boxes times
2 for each timeslot |
|
Mappings |
51-99 |
1-99
possible for cB to cB but do not use
1-49 |
|
Cross patch |
alphas |
use
descriptive alpha-numerics or stay with
numbers 101-199 |
|
Simple
table above shows the link number
relationship |
|
| *Audio Connections:
Link Numbers for IPSC Manager bindings:
Numeric Only; 1-30 are possible choices; selects the
timeslots on each IPSC manager / most
c-Bridges only have 6 or 10 IPSC Manager timeslots,
1 and 2 for manager 1, 3 and 4 for manager 2, etc.
Reserve 1-30 for these assignments. |
| *Cross Patches:
Super Group ID's (was Link ID which was very
confusing) can be alphanumeric, at least 12
characters in length so that they can be
descriptive. A numeric list can be used also;
use sets of 3 digits (100-199 for example) so as not
confuse with link numbers for other uses. Make
any main Mapping connections and/or talkgroups a
alpha name or a link number that all others join to.
For example, your "Bridge" feed could use
"Bridge-cp" or link number 100. The downside
is that any single repeater can busy all the linked
in states so the better approach is to use the
Bridge ID (3100) and don't touch the individual
states as a collective group. |
| *Mappings: For
CC to CC connections, we suggest that a standard
naming convention be adopted so that Net watch can
show what talkgroup is used. Currently the
Group ID and it's alias are blank when traffic comes
in from another c-Bridge. The mapping name
shows in "Net watch" under "Name" in "Current
Talker" and "Voice Log" so something descriptive is
useful. Enter that description in the the
"Server Outbound" description. If you are
inbound, then ask your c-Bridge outbound partner to
do this. Give each inbound or outbound a link
number between 50-99 so that they are a different
series than IPSC Manager link numbers and Cross
patch link numbers. |
| Mapping
Suggestion: (Now
known as Conference Connections) On every "Mapping" we add a cB
to the end of bridge name so to be able to
distinguish it from a talkgroup. We then bind
the "Mapping" to the talkgroup with a "Cross patch"
and "joined" and make this link number the master
bind to the cB. This enables very quick and
simple changes of the mapping to a different
talkgroup and/or timeslot. Otherwise if you
break a mapping, you must re-configure the mapping
again and that requires more info to be re-entered
as well more chance to make mistakes.
Example: Kansas St 1 is our talkgroup
(3120) on timeslot 1, Kansas St cB is our "Mapping"
to the Kansas c-Bridge, the "Mapping" is "Cross
patched" to Link 105 and joined 7/24, Kansas St 1 is
"Cross patched" to 105 and "joined" or "unjoined" as
desired. Very easy to enable or disable. |
| Email: Email
notifications work well; 3 notifications sent out,
we recommend implementing this feature. Set-up
is very straightforward. |
| Alert on Absent:
Do not check the enabling box for this feature as it
is not designed to be used with the IPSC-3's.
This information came from Bob V. |
| TERMS: cB to cB
Connections: (Now
known as Conference Connections) Officially I think it's
called "Mapping". They is no really
consistency in the terms used by customers and the
vendor unfortunately. Some help please... |
| Documentation: (Now
Available) You are kidding right? OK tongue-in-cheek
quip, but really, it's been 15 months now but just
this month (July 2012), documentation is beginning
to be released in the form of html's built into the
c-Bridge web server. |
