Home    PNW-DMR    News    Netwatch    Dash    Repeaters    Talkgroups    c-Bridge    Linking    Open IPSC    MTUSA

Site Map

c-Bridge Tips, Hints, Gotchas and other such

Remembering what works and doesn't work is problematic.  So here are some of our  trial and error findings and/or suggestions, in no particular order.
Your mileage may vary...and your tips or feedback is welcome.

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.

We welcome your tips, input, corrections or suggestions, just write: c-Bridge-Tips@trbo.org

Revised: 07/16/2017 00:37

Webmaster

pgp