Acest post si continutul lui este scris in engleza, google translate dar si termenii tehnici, deoarece nu se adreseaza numai radioamatorilor romani, ci si celor din afara tarii. Pana la aparitia unui al 2-lea EBTS in Romania, din nou, zic... "sunt tatal acestui rahat" :))) Cu alte cuvinte, "I am the father of this shit."
Din nou readuc in discutie faptul ca tot ceea ce am reusit sa diagnostichez si sa repar, am facut cu capul meu, neajutat de nimeni. Pentru ca nimeni nu stie ce probleme ai, chiar daca le explici cumva. :)
Sa purcedem la scris. Mai jos este varianta text, aproape inutila tehnic, mai mult ca lectura foarte lunga, de asemenea inutila. Dar pentru "robots.txt" conteaza la indexare.
Linkurile pentru descarcarea fisierelor pdf , .MD si scripturilor , sunt mai jos. Retineti, pdf-ul are poze si e cel mai cuprinzator.
ATENTIONARE: LUCRATI CU BAGARE DE SEAMA! UN FIRMWARE CORUPT, UN SCURT CIRCUIT UNDE NU TREBUIE, SI SE POATE ALEGE PRAFUL DE TOT ! ASADAR MARE ATENTIE CE MODIFICATI SI CUM. EVIDENT CA NU POT FI FACUT RESPONSABIL DACA CEVA MERGE EXTREM DE PROST SI APAR FLACARI GALBENE SI TOTUL ARDE CU FUM NEGRU !!
WARNING: WORK CAREFULLY! A CORRUPT FIRMWARE, A SHORT CIRCUIT WHERE IT'S NOT NEEDED, AND YOU CAN BURN EVERYTHING! SO BE VERY CAREFUL WHAT YOU MODIFY AND HOW. I CANNOT BE HELD RESPONSIBLE IF SOMETHING GOES EXTREMELY WRONG AND YELLOW FLAMES APPEAR AND EVERYTHING BURNS WITH BLACK SMOKE!!
ENGLISH VERSION:
This post is written in English, google translate but also the technical terms, because it is not addressed only to Romanian radio amateurs, but also to those outside the country. Until the appearance of a 2nd EBTS in Romania, again, I say... "sunt tatal acestui rahat" :))) In other words, "I am the father of this shit."
Again I bring up the fact that everything I managed to diagnose and fix, I did with my own head, unaided by anyone. Because no one knows what problems you have, even if you explain them somehow. :)
Let's get to writing. Below is the text version, almost technically useless, more like very long reading, also useless. But for "robots.txt" it matters for indexing.
The links for downloading the pdf files, .MD and scripts, are below. Remember, the pdf has pictures and is the most comprehensive.
If the EBTS is physically moved to another location, with different GPS coordinates, it will be necessary to reallocate the new position in the TSC memory.
below are the download links.
aici sunt fiserele https://dash.radiofarafiltru.ro/doc/
aici este doar pdf-ul https://dash.radiofarafiltru.ro/doc/EBTS_TetraPack_Integration_Guide.pdf
urmeaza textul gigant. Pentru analiza si debuging recomand pdf-ul si fisierul .MD care permite copierea comenzilor bash de linux.
the giant text follows. For analysis and debugging I recommend the pdf and the .MD file which allows copying of linux bash commands.
CONNECTING A MOTOROLA DIMETRA EBTS TO AN AMATEUR TETRA CORE
A Complete, Field-Tested Integration Guide
Version 1.1 - August 2026
All credentials, network identifiers and personal names in this document
have been redacted or replaced with placeholders. Substitute your own
values where marked.
================================================================================
THIS IS THE PLAIN-TEXT EDITION.
It carries the complete text of the illustrated PDF, but not the 38
photographs and schematics. Where a figure carried information, its caption
appears in place as [ FIGURE n ] so you know what you are missing.
For the TESS screenshots, the board photographs and the Motorola schematic
extracts, use the PDF edition - EBTS_TetraPack_Integration_Guide.pdf - which
also has a clickable table of contents and PDF bookmarks for every chapter.
================================================================================
==========================================================================
READ THIS FIRST - THE ONE THING THAT WILL WASTE WEEKS OF YOUR LIFE
==========================================================================
| ### R5.x FIRMWARE WILL NOT WORK WITH THE CORE.
|
| Your site will link. It will reach Wide Trunking. The E1 will be
| clean, both PVCs will be ACTIVE, GPS will phase-lock, the Base Radio
| will transmit, and radios will register and attach to talkgroups.
|
| And every single PTT will fail.
|
| The Call Log will show S: 4 C:255 - status 4, cause 255 - meaning the Zone
| Controller never allocated a traffic resource. Radios display
| "unit not attached" or "PTT denied". In Local Site Trunking (LST) the very
| same radios, on the very same talkgroup, work perfectly - which makes you
| certain the problem is on the network side and sends you chasing IP addresses
| for weeks.
|
| It is not an IP problem. It is a firmware protocol incompatibility.
| You need R8.x on both the TSC and the BRC.
This was confirmed by an experienced operator (referred to below as K.) who
stated plainly: *"you need version R8 to be compatible with the core. R5 is not
compatible."* It took a full re-verification of every addressing parameter in
the site before that advice was finally acted upon - and it was correct.
Everything else in this guide matters too. But if you only fix one thing, fix
this one.
---
==========================================================================
TABLE OF CONTENTS
==========================================================================
1. Scope and Assumptions
2. Hardware You Need
3. Network Architecture
4. Step 1 - The E1 Crossover Cable
5. Step 2 - The ZeroTier Bridge (Raspberry Pi / Orange Pi)
6. Step 3 - Cisco Router Configuration
7. Step 4 - TESS Basics and Personality Selection
8. Step 5 - Site Controller Configuration, Tab by Tab
9. Step 6 - The Firmware Upgrade to R8 (the critical step)
10. Step 7 - Patching the BRC Firmware (PA scaling and power deviation)
11. Step 8 - Sending the Configuration
12. Step 9 - Verification Commands
13. Error Reference - What Each Symptom Actually Means
14. Optional - NTP Client (R8 only)
15. Optional - Packet Data / WAP
16. "DO NOT DO THIS" - Mistakes We Actually Made
17. Hardware-Level Fault Diagnosis - including the metering chain traced on the factory schematics
18. E1, Frame Relay and PIM Fault Decoder - reading the link from both ends
19. Diagnostic Scripts (ready to copy and run)
20. Appendix A - MMI Command Reference
21. Appendix B - Known-Good Parameter Table
---
==========================================================================
1. SCOPE AND ASSUMPTIONS
==========================================================================
This guide covers connecting a Motorola Dimetra EBTS (PR3.0 generation) -
a separate 1U Site Controller (TSC) plus one or more Base Radios (BR/BRC) - to
an amateur TETRA virtual core over the internet, using a Cisco router with an
E1 card and a ZeroTier Layer-2 bridge.
It assumes:
* You have a working EBTS in Local Site Trunking (LST) mode before you start.
If your BR does not transmit and your radios do not register locally, fix
that first. Connecting to a core will not fix a broken site.
* You have basic Cisco IOS knowledge and basic Linux console knowledge.
* You have obtained a site allocation from the core network team: a Site ID,
a Zone ID, PVC subnets, and permission to join their overlay network.
* You are legally licensed to transmit on the frequencies you intend to use.
Throughout this document:
* <SITE_ID> - your allocated site number (examples use 35)
* <ZONE_ID> - your allocated zone (examples use 1)
* xxxxxxxxxxxxxxxx - redacted ZeroTier network identifier
* <PASSWORD> - a credential you must obtain or set yourself
* People are referenced by initial only: E., S., K., M., L.
| Warning. This is experimental. You can render an expensive TSC unbootable
| if you are careless with firmware slots. Read Section 9 completely before you
| touch anything. Keep the fallback slot intact at all times.
---
==========================================================================
2. HARDWARE YOU NEED
==========================================================================
[ FIGURE 1 - see the PDF edition ]
Site Controller main board. The large central IC is the PowerPC host
processor; the DIMM sockets and debug headers are clearly visible.
Useful for identifying board generation.
| Item | Notes |
|---|---|
| EBTS Site Controller (TSC) | 1U or 4U. Must boot and reach LST. |
| Base Radio (BR) with BRC | Must key up and be RF-aligned for your band. |
| GPS antenna + cable | Mandatory for frequency stability. Free-running OCXOs drift far outside the +/-100 Hz that EN 300 392-2 sect.7.8 allows - one operator measured +331 Hz without GPS. |
| Cisco 1900 or 2600 series router | With a 1-port or 2-port E1 WIC/VWIC. Note: E1 cards differ between the 1900 and 2600 series - they are not interchangeable. You also need an IOS image that carries Frame Relay and IP multicast - see Section 6.1. |
| Raspberry Pi (or Orange Pi) | Runs the ZeroTier client and the Layer-2 bridge. |
| USB Ethernet dongle for the Pi | You need a second Ethernet port. |
| E1 crossover cable (RJ45) | See Section 4. You will almost certainly have to make this yourself. |
| Cisco console cable | For the router. |
| USB-to-RS232 adapter(s) | For the TSC and BRC service ports. |
| A duplexer (if single antenna) | Minimum 60 dB TX->RX isolation. 67 dB measured on a well-tuned unit. |
A note on the 2600 series: it is old and they do fail. Reported failures
include flash errors and blown capacitors. The 1900 series is more recent and a
safer purchase if you are buying now.
---
==========================================================================
3. NETWORK ARCHITECTURE
==========================================================================
--------------------------------------------------------------------
[ Radios ]
| (air interface)
[ Base Radio / BRC ]
| (internal site bus)
[ Site Controller / TSC ]
| E1 crossover cable, 31 timeslots, 1984 kbps
[ Cisco router, E1 WIC ]
| Frame Relay DCE, DLCI 16 (primary) + DLCI 17 (backup)
| Fa0/0 = 192.168.250.<SITE_ID>
[ Ethernet ]
|
[ USB Ethernet dongle on Pi ] <--+
| | br0 - a pure L2 bridge, NO IP address
[ ZeroTier interface on Pi ] <--+
|
[ ZeroTier overlay 192.168.250.0/24 ]
|
[ Core network - Zone Controller, Network Manager, NTP ]
--------------------------------------------------------------------
The single most important architectural point
---------------------------------------------
**The Raspberry Pi is a transparent Layer-2 bridge. It does not own the site's
IP address. The Cisco router does.**
The Pi joins the ZeroTier network but must be configured not to accept
managed IP addresses. Its bridge interface br0 has no IP at all. The
192.168.250.<SITE_ID> address lives on the Cisco's FastEthernet0/0.
If you let ZeroTier assign an address to the Pi, you will have two devices
fighting over one address and your PIM neighbours will flap.
---
==========================================================================
4. STEP 1 - THE E1 CROSSOVER CABLE
==========================================================================
E1 over RJ45 uses two pairs: one for transmit, one for receive. A crossover
cable swaps them so that each end's transmitter feeds the other end's receiver.
Pinout (RJ45 to RJ45):
| End A pin | End B pin | Function |
|---|---|---|
| 1 | 4 | TX ring -> RX ring |
| 2 | 5 | TX tip -> RX tip |
| 4 | 1 | RX ring -> TX ring |
| 5 | 2 | RX tip -> TX tip |
Pins 3, 6, 7, 8 are unused. Use a proper twisted pair for 1/2 and another for
4/5 - do not split pairs, E1 is a 120 ohm balanced interface and split pairs will
give you bit errors that are maddening to diagnose.
Symptoms of a bad E1 cable: LOS detected on the Cisco, Line Loss and
Frame alignment Loss counters climbing on the TSC, Site Link flapping between
UP and DOWN.
| Important caveat learned the hard way: a TSC reset also produces LOS
| detected on the Cisco, because the TSC stops driving the line while it
| reinitialises its framer. Two LOS events fifteen seconds apart, immediately
| after a reset, are normal. Persistent LOS with no reset is a cable fault.
|
| Distinguish them by looking at the bit-error counters (CRC4 errors, bipolar
| violations). A bad cable produces bit errors. A rebooting TSC produces clean
| signal loss with zero bit errors.
---
==========================================================================
5. STEP 2 - THE ZEROTIER BRIDGE
==========================================================================
5.1 Do not trust the automated installer
----------------------------------------
The core network's wiki offers a one-line installer. As published, the command
is broken:
--------------------------------------------------------------------
# WRONG - this does not work
wget https://<core-domain>/install/tools/EBTS/CiscoBridge.sh | sudo bash
--------------------------------------------------------------------
wget without -O - writes the script to a file and sends its *progress
output* to stderr. bash receives nothing. The script downloads but never runs.
The syntactically correct form is:
--------------------------------------------------------------------
wget -O - https://<core-domain>/install/tools/EBTS/CiscoBridge.sh | bash
--------------------------------------------------------------------
However - even when run correctly, the script has been observed to **stop
silently part-way through**, after apt update but before configuring ZeroTier.
Assume it did not work and verify manually. The instructions below build the
bridge by hand, which is what actually ended up running in production.
5.2 Install ZeroTier and join
-----------------------------
--------------------------------------------------------------------
curl -s https://install.zerotier.com | sudo bash
sudo zerotier-cli join xxxxxxxxxxxxxxxx
--------------------------------------------------------------------
Then ask the core network administrators to authorise your node. Send them your
node ID:
--------------------------------------------------------------------
sudo zerotier-cli info
# 200 info xxxxxxxxxx 1.16.2 ONLINE
--------------------------------------------------------------------
Be patient here. Authorisation is a manual step performed by a human
volunteer. It can take days.
5.3 Critical: disable managed addresses
---------------------------------------
--------------------------------------------------------------------
sudo zerotier-cli set xxxxxxxxxxxxxxxx allowManaged=0
--------------------------------------------------------------------
This is what stops ZeroTier from putting an IP on the Pi. Verify:
--------------------------------------------------------------------
sudo zerotier-cli listnetworks
# 200 listnetworks xxxxxxxxxxxxxxxx <name> <mac> OK PRIVATE ztXXXXXXXX
--------------------------------------------------------------------
Note the interface name (ztXXXXXXXX) - you need it for the bridge.
5.4 Build the bridge
--------------------
Identify your USB Ethernet dongle:
--------------------------------------------------------------------
ip link show
# e.g. enxXXXXXXXXXXXX
--------------------------------------------------------------------
Create the bridge script /usr/local/bin/zt-bridge-up.sh:
--------------------------------------------------------------------
#!/bin/bash
ZT_IF="ztXXXXXXXX"
ETH_IF="enxXXXXXXXXXXXX"
# Wait for the ZeroTier interface to appear
for i in $(seq 1 60); do
ip link show "$ZT_IF" >/dev/null 2>&1 && break
sleep 2
done
brctl addbr br0 2>/dev/null
brctl addif br0 "$ETH_IF" 2>/dev/null
brctl addif br0 "$ZT_IF" 2>/dev/null
ip link set "$ETH_IF" up
ip link set "$ZT_IF" up
ip link set br0 up
# br0 deliberately has NO IP address
# Disable multicast snooping so PIM/IGMP flood correctly
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping 2>/dev/null
exit 0
--------------------------------------------------------------------
--------------------------------------------------------------------
sudo chmod +x /usr/local/bin/zt-bridge-up.sh
--------------------------------------------------------------------
Create /etc/systemd/system/zt-bridge.service:
--------------------------------------------------------------------
[Unit]
Description=Attach the ZeroTier interface to br0
After=zerotier-one.service network-online.target
Wants=zerotier-one.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/zt-bridge-up.sh
[Install]
WantedBy=multi-user.target
--------------------------------------------------------------------
--------------------------------------------------------------------
sudo systemctl daemon-reload
sudo systemctl enable --now zt-bridge.service
--------------------------------------------------------------------
5.5 Verify
----------
--------------------------------------------------------------------
brctl show br0
--------------------------------------------------------------------
Expected - both interfaces present, and no IP on br0:
--------------------------------------------------------------------
bridge name bridge id STP enabled interfaces
br0 8000.xxxxxxxxxxxx no enxXXXXXXXXXXXX
ztXXXXXXXX
--------------------------------------------------------------------
--------------------------------------------------------------------
systemctl is-enabled zt-bridge.service
# enabled
--------------------------------------------------------------------
That last check matters. A Pi that rebuilds its bridge automatically after a
reboot is the difference between a two-minute outage and a dead site.
| Real incident. During this project the Orange Pi rebooted itself
| unattended (an automatic security update). The L2 bridge went down for
| roughly two minutes. On the Cisco, **all twenty PIM neighbours dropped
| simultaneously** and the DR election moved to the local router. Everything
| recovered by itself once the Pi came back, with no manual intervention -
| precisely because zt-bridge.service was enabled.
|
| If you see every PIM neighbour disappear at once, suspect your own bridge,
| not the network.
To prevent surprise reboots on a production node:
--------------------------------------------------------------------
grep -A2 Automatic-Reboot /etc/apt/apt.conf.d/50unattended-upgrades
--------------------------------------------------------------------
---
5.6 Troubleshooting the bridge
------------------------------
| Symptom | Likely cause | Check |
|---|---|---|
| listnetworks shows ACCESS_DENIED | Node not yet authorised | Ask the core team; nothing local will fix it |
| An IP appears on br0 or on the Pi | allowManaged is still 1 | zerotier-cli get <NETWORK_ID> allowManaged |
| Cisco cannot reach the overlay gateway | Bridge not built, or wrong interface enslaved | brctl show br0 |
| Bridge looks fine, still no multicast | multicast_snooping is 1 | cat /sys/devices/virtual/net/br0/bridge/multicast_snooping |
| Works until the next reboot | Service not enabled | systemctl is-enabled zt-bridge.service |
| All PIM neighbours drop at once | Pi rebooted, or ZeroTier restarted | uptime, systemctl status zerotier-one |
| ONLINE but everything is slow | UDP 9993 blocked, or CGNAT - traffic is relayed | zerotier-cli peers, look for RELAY on the planet roots |
Section 19.1 gives a script that tests every one of these in a single command.
5.7 Things not to do with the bridge
------------------------------------
* Do not put an IP on br0, or let ZeroTier put one on the Pi.
* Do not enslave the onboard Ethernet port you manage the Pi through. Give
the Pi a static address on that port before you start, or you will discover
that your only way in was the interface you just bridged.
* Do not enable STP on br0. There is no loop, and the forwarding delay
costs you thirty seconds on every restart.
* Do not leave multicast snooping on.
* Do not run the wiki installer and assume it worked.
* Do not leave unattended reboots enabled on a node that carries a site.
==========================================================================
6. STEP 3 - CISCO ROUTER CONFIGURATION
==========================================================================
6.1 The IOS image - check this before you configure anything
------------------------------------------------------------
The configuration below needs three things at once: **Frame Relay with
fragmentation, IP multicast routing with PIM**, and an image small enough to
fit the flash and DRAM you actually have. Plain IP-only IOS images will accept
some of the commands and silently lack the rest.
Two images are known to work on a 2600XM chassis:
| Image | Train | Notes |
|---|---|---|
| c2600-adventerprisek9-mz.124-25d.bin | 12.4 mainline, final maintenance release | This is what the reference site runs. Recommended - mainline, end of a very long maintenance cycle, no T-train regressions. |
| c2600-advsecurityk9-mz.124-15.t14.bin | 12.4(15)T14 | Also carries Frame Relay and PIM. Smaller; useful if you are short of flash or DRAM. |
Confirm what is actually running before you blame the configuration:
--------------------------------------------------------------------
show version | include IOS|System image|bytes of memory
dir flash:
--------------------------------------------------------------------
The reference site reports:
--------------------------------------------------------------------
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(25d)
--------------------------------------------------------------------
which is exactly the c2600-adventerprisek9-mz.124-25d.bin image above.
| Do not copy a new image over the running one. The advanced-enterprise
| 12.4(25d) image is large. A 2600XM fitted with the minimum flash and DRAM will
| not boot it, and you will find that out only after the old image is gone.
| Check free flash and installed DRAM first, keep the working image in place
| until the new one has verified, and set boot system flash:<file> explicitly
| rather than relying on the first-file-in-flash default.
6.2 Complete working configuration
----------------------------------
Replace <SITE_ID> and the PVC addresses with values issued to you by the core
team. Values shown are for site 35.
--------------------------------------------------------------------
hostname BTS_CORE_ROUTER_SITE_35
!
enable secret <SET_YOUR_OWN_ENABLE_PASSWORD>
!
ip multicast-routing
!
card type e1 0 0
!
controller E1 0/0
clock source internal
framing CRC4
linecode HDB3
channel-group 0 timeslots 1-31
!
interface FastEthernet0/0
ip address 192.168.250.35 255.255.255.0
ip pim dense-mode
duplex auto
speed auto
!
interface Serial0/0:0
no ip address
encapsulation frame-relay IETF
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay fragment 100 end-to-end
!
interface Serial0/0:0.101 point-to-point
ip address 172.24.16.141 255.255.255.252
ip pim dense-mode
frame-relay interface-dlci 16
!
interface Serial0/0:0.201 point-to-point
ip address 172.24.20.141 255.255.255.252
ip pim dense-mode
frame-relay interface-dlci 17
!
ip route 10.0.0.0 255.0.0.0 192.168.250.254
ip route 10.128.35.0 255.255.255.0 172.24.16.142
ip route 172.24.0.0 255.255.0.0 192.168.250.254
!
line con 0
line vty 0 4
password <SET_YOUR_OWN_VTY_PASSWORD>
login
--------------------------------------------------------------------
6.3 The two bugs in the published example configuration
-------------------------------------------------------
Both of these were present in the example config handed out to new operators,
and both silently break the site.
Bug 1 - wrong BTS subnet.
The example used 10.128.10.0/24 regardless of site number. The scheme is
actually 10.128.<SITE_ID>.0/24. For site 35 the BTS IP is 10.128.35.1, not
10.128.10.1. Fix both the TESS parameter and the Cisco static route.
Bug 2 - wrong PIM mode.
The example used ip pim sparse-dense-mode together with an ip pim rp-address
statement. The overlay network runs dense mode and has no rendezvous point.
With sparse-dense-mode configured and no reachable RP, **all core multicast is
blocked** and the site never gets its traffic streams.
--------------------------------------------------------------------
! WRONG
ip pim sparse-dense-mode
ip pim rp-address 192.168.250.254
! CORRECT
ip pim dense-mode
! (no rp-address statement at all)
--------------------------------------------------------------------
You will still see log messages like:
--------------------------------------------------------------------
%PIM-6-INVALID_RP_JOIN: Received (*, 228.4.0.14) Join from 192.168.250.13
for invalid RP 192.168.250.254
--------------------------------------------------------------------
These come from other sites that still have the wrong configuration. They are
severity 6 (informational) and harmless to you. You cannot fix them from your
end - but it is worth telling the core team which site IDs are generating them.
6.4 Cisco verification
----------------------
--------------------------------------------------------------------
show controllers e1
show frame-relay pvc
show ip pim neighbor
show interfaces serial0/0:0
--------------------------------------------------------------------
Healthy output looks like:
* E1 0/0 is up, No alarms detected, zero Line Code Violations in the current interval
* Both DLCI = 16 and DLCI = 17 with PVC STATUS = ACTIVE
* A full list of PIM neighbours with the DR on the core gateway (.254)
* Serial0/0:0 is up, line protocol is up, DCE LMI up
To reset counters for a clean measurement you need privileged mode:
--------------------------------------------------------------------
enable
clear counters Serial0/0:0
clear controller e1 0/0
--------------------------------------------------------------------
---
==========================================================================
7. STEP 4 - TESS BASICS AND PERSONALITY SELECTION
==========================================================================
[ FIGURE 2 - see the PDF edition ]
A community-built EBTS status dashboard, assembled purely from the
serial MMI commands documented in this guide.
TESS (TETRA BTS Service Software, also called BTS Service Software) is the
Motorola tool used for all configuration. There is no web interface. CLI
configuration on the TSC exists but is not persistent - TESS is the only
supported way to configure a site permanently.
7.1 Launching
-------------
1. Connect a USB/RS232 adapter to the TSC service port.
2. Open TESS and select the personality Dimetra R8.
The application password is a fixed string published on the core wiki; treat
it as <TESS_APP_PASSWORD> here.
3. Configuration -> Direct Settings - select the correct COM port.
| Keep a written note of which COM port is which. On the reference system:
| COM7 = BRC, COM12 = TSC, COM31 = Cisco console. Mixing them up wastes a
| surprising amount of time, because get info on a TSC prompt just returns
| "Invalid command" with no hint that you are on the wrong device.
7.2 Personality version - an important subtlety
-----------------------------------------------
The personality you select in TESS is a configuration template, not the
firmware. TESS will happily let you open an R8 personality while the TSC is
running R5 firmware, and vice versa.
* Older wiki revisions instructed operators to select Dimetra 5.2.
* The current revision instructs Dimetra R8.
This change is not cosmetic. Select Dimetra R8.
Interestingly, a configuration file generated on an R5.1 personality was parsed
by R8 firmware without a single error during this project. The parameter
sets overlap enough that it works. But new features (notably the NTP tab) exist
only in the R8 personality.
7.3 Connecting
--------------
--------------------------------------------------------------------
Connection -> Connect Direct
--------------------------------------------------------------------
Press Enter. Log in with the factory service credentials - the defaults are
documented in the Motorola manuals as <user> / <password>, and Motorola
explicitly recommends changing them once the equipment is verified. Note that
the TSC and BRC use different default accounts.
7.4 Pull the existing configuration first
-----------------------------------------
--------------------------------------------------------------------
Upload Configuration
--------------------------------------------------------------------
Select the tsc.cf file marked + under Current. TESS automatically pulls
the matching Base Radio files (brc01.cf etc.) with the same version label.
Save it. Always do this before you change anything. It is your rollback.
---
==========================================================================
8. STEP 5 - SITE CONTROLLER CONFIGURATION, TAB BY TAB
==========================================================================
Personality -> Modify -> Edit Site Controller
The core team will have given you: **Site ID, BTS IP Address, PVC Primary, PVC
Backup, Network Manager IP Address**. Everything else below is either fixed or
derived.
General
-------
[ FIGURE 3 - see the PDF edition ]
Site Controller, General tab. Only Site ID and Zone ID are site-
specific; the rest of the values shown are the reference set.
| Field | Value |
|---|---|
| BTS Site ID | <SITE_ID> |
| BTS Zone ID | <ZONE_ID> |
| LST Enable | checked |
| TSC Temperature Threshold (C) | 70 |
| EAS Poll Timer (secs) | 5 |
| Site Trunking Hold off Time | 0 sec |
| Site Link Debounce Time | 2 |
| No Trunking BS Service Details | All services |
| Adjacent Site Broadcast Update | checked |
Master Site
-----------
[ FIGURE 4 - see the PDF edition ]
Site Controller, Master Site tab. Note the Zone Controller addresses
ending in .1, NOT .255. Greyed fields are not used.
| Field | Value |
|---|---|
| Link Recovery Timer (secs) | 5 |
| Primary ZC IP Address | 10.1.231.1 |
| Secondary ZC IP Address | 10.1.232.1 |
| BTS IP Address | 10.128.<SITE_ID>.1 |
| BTS IP Network Mask | 255.255.255.0 |
| Trap. The R5.1 / R5.2 / R5.5 firmware defaults for the ZC addresses are
| 10.1.231.255 and 10.1.232.255. The R5.0 defaults are .1. Templates
| circulating among operators contain the .255 values. **The live core uses
| .1** - this was confirmed both by packet capture (responses arrive from
| 10.1.231.1) and by the official provisioning script. Use .1.
Network Management
------------------
[ FIGURE 5 - see the PDF edition ]
Site Controller, Network Management tab. The Network Manager address
is .101; .88 is the NTP server and belongs elsewhere.
| Field | Value |
|---|---|
| Network Mgr IP Address | 10.1.233.101 |
| Network Manager Port Number | 162 |
| Zone Manager Port Number | 161 |
| Primary ZC Subnet Mask | 255.255.255.0 |
| Secondary ZC Subnet Mask | 255.255.255.0 |
| Trap. 10.1.233.88 is the NTP server, not the Network Manager.
| Putting .88 in the Network Manager field is a common copy-paste error.
| The Network Manager is .101.
Site Link
---------
[ FIGURE 6 - see the PDF edition ]
Site Controller, Site Link tab. DLCI 16 primary, DLCI 17 secondary,
/30 masks, Netcom UDP ports 1050 and 1051.
| Field | Value |
|---|---|
| Primary PVC DLCI | 16 |
| Secondary PVC DLCI | 17 |
| Primary PVC BTS IP Address | 172.24.<x>.142 (issued to you) |
| Primary PVC IP Network Mask | 255.255.255.252 |
| Secondary PVC BTS IP Address | 172.24.<y>.142 (issued to you) |
| Secondary PVC IP Network Mask | 255.255.255.252 |
| Primary PVC Recovery Timer | 30 |
| Netcom Outbound UDP Port | 1050 |
| Netcom Inbound UDP Port | 1051 |
| Trap seen on another site. The official provisioning script generated the
| wrong /30 subnet for operator M. - it produced the subnet belonging to
| site 36 while generating a config for site 37. Always check that the /30 you
| were given is arithmetically consistent with your site number, and query it if
| it is not. That site never reached Wide Trunking until it was corrected.
Site Router
-----------
[ FIGURE 7 - see the PDF edition ]
Site Controller, Site Router tab. CRTP is shown unchecked in the
reference configuration.
| Field | Value |
|---|---|
| CRTP Enable | unchecked (per reference screenshots) |
| LMI Enable | checked |
| LMI LIV Time (ms) | 300 |
| LMI Error Threshold | 3 |
| Full Status Polling Counter | 6 |
| Monitored Events Count | 4 |
| Type Of Service Latency Time (ms) | 5000 |
| Frame Relay Fragmentation Size | 100 |
| CRTP (Compressed RTP) is enabled by default in firmware. The reference
| screenshots show it disabled. Our production site currently runs with it
| enabled and works fine, but if you experience audio problems on wide-area
| calls, this is the first thing to try turning off.
Packet Data
-----------
[ FIGURE 8 - see the PDF edition ]
Site Controller, Packet Data tab. BTS PD and PD Gateway addresses are
greyed out; those live on the core side.
| Field | Value |
|---|---|
| Data Tx Request Transmissions | 4 |
| End of Data Transmissions | 4 |
| Initial Transmissions on PDCH | 4 |
| PD Port Number | 10130 |
| RNG IP Address | 10.128.105.15 |
| Trap. The RNG address is 10.128.105.15 - note 128, not 129. A
| transposed digit here is easy to make and hard to spot.
|
| BTS PD IP Address and PD Gateway IP Address are greyed out. That is normal;
| those are core-side values.
SDTS
----
[ FIGURE 9 - see the PDF edition ]
Site Controller, SDTS tab.
| Field | Value |
|---|---|
| SDR TCP Port Number | 4176 |
| Max Number of Short Data Repeats | 4 |
| Max Number of Short Data Retries | 5 |
| Max TCP Segment Size (Bytes) | 512 |
| TCP Socket Buffer Size (Bytes) | 8192 |
Voice
-----
[ FIGURE 10 - see the PDF edition ]
Site Controller, Voice tab.
| Field | Value |
|---|---|
| Receive voice | 2 Interfaces |
| Voice Port Number | 10120 |
Serving Cell (a different dialog - Edit Serving Cell)
-----------------------------------------------------
| Field | Value |
|---|---|
| Colour Code | 1 |
| Mobile Country Code | as issued (e.g. 901) |
| Mobile Network Code | as issued (e.g. 9999) |
| System Code | 1 |
---
==========================================================================
9. STEP 6 - THE FIRMWARE UPGRADE TO R8
==========================================================================
9.1 Understand the slot system before you touch anything
--------------------------------------------------------
The TSC stores two copies of every component. Each has three flags:
| Flag | Meaning |
|---|---|
| c - current | The version running right now. |
| n - use next | The version that will load at the next boot. |
| fallback | Used automatically if the "use next" image fails to boot. |
Displayed by attrib as a six-character field, e.g. cn--ra:
--------------------------------------------------------------------
SC: attrib
ATTRIB NAME VERSION DATE
------------------------------------------------------
----ra brc.code.1 <label> ...
cn--ra brc.code.2 <label> ...
----r- tsc.cf.1 48 ...
cn--r- tsc.cf.2 49 ...
----ra tsc.code.1 r8 ...
cn--ra tsc.code.2 25 ...
--------------------------------------------------------------------
Reading that: tsc.code.2 is current and will be used next (it is R5);
tsc.code.1 holds an R8 image but is inactive.
The golden rule: never overwrite the slot that is currently c. Always send
new files into the slot showing all dashes. That way, if the new firmware does
not boot, the old one is still there.
9.2 Take stock of what is already in flash
------------------------------------------
[ FIGURE 11 - see the PDF edition ]
Keeping firmware images organised pays off: the R8 BRC image (1.86 MB)
is visibly larger than the R5 images (1.60 MB), which makes
identifying what is in a flash slot trivial.
--------------------------------------------------------------------
SC: dir -all
--------------------------------------------------------------------
Compare the byte sizes in flash with your local files. This is how we
discovered that the R8 TSC image was already present in slot 1 from an
abandoned attempt years earlier:
| Slot | Size in flash | Matching local file |
|---|---|---|
| tsc.code.1 | 5,275,517 | R080229.tsc - exact match |
| tsc.code.2 | 4,126,029 | R053258.tsc - exact match |
| brc.code.1 | 1,679,328 | R5 BRC image |
| brc.code.2 | 1,679,328 | R5 BRC image |
If your sizes match a file you already have, you do not need to transfer it
again - you only need to flip the flag.
9.3 Transfer the BRC firmware
-----------------------------
[ FIGURE 12 - see the PDF edition ]
File download properties. A version label has been entered and Use
Next ticked, but the entry at the top still reads '- - -' because
'Update selected items' has not been clicked yet. Clicking OK now
would transfer the file with no flags set.
[ FIGURE 13 - see the PDF edition ]
Selecting the file to overwrite. tsc.cf.1 carries '+' under Current
and Use Next, so it must NOT be touched; the highlighted tsc.cf.2
shows only dashes and is the safe target.
TESS: Connection -> Send Files -> Application Files, select your .brc file.
In the File download properties dialog:
1. Enter a Version Label - 1 to 12 characters, letters/digits/underscore/dot
only, no spaces, and it must be unique.
2. Tick Use Next. Leave Current and Fallback unticked.
3. Click "Update selected items". This step is easy to miss. Until you click
it, the flags in the list still show - - - and your label is not applied.
4. Click OK.
5. When prompted to select the file to be replaced, **choose the entry showing
all minus signs**.
Transfer runs over ZMODEM at serial speed. A 1.9 MB image takes several minutes.
Watch the Errors: field - it must stay at 0.
9.4 Set the flags
-----------------
[ FIGURE 14 - see the PDF edition ]
ZMODEM transfer in progress. Destination brc.code.1 is the inactive
slot; Errors must remain at 0 throughout.
[ FIGURE 15 - see the PDF edition ]
Successful completion. 'sent and configured' means both the transfer
and the flag update succeeded.
Alternatively - or to correct flags afterwards - use the MMI directly:
--------------------------------------------------------------------
attrib -v <version_label> brc.code.1
attrib -n brc.code.1
attrib -n tsc.code.1
--------------------------------------------------------------------
Verify before rebooting:
--------------------------------------------------------------------
attrib
--------------------------------------------------------------------
You want to see n on both R8 slots and the R5 slots without n:
--------------------------------------------------------------------
-n--ra brc.code.1 <r8_label>
c---ra brc.code.2 <r5_label>
-n--ra tsc.code.1 r8
c---ra tsc.code.2 25
--------------------------------------------------------------------
9.5 Reset and what to expect
----------------------------
Enable session logging in your terminal before you do this. If the boot
fails, the log is your only diagnostic.
--------------------------------------------------------------------
reset
--------------------------------------------------------------------
The first boot after switching to R8 does something alarming but normal:
--------------------------------------------------------------------
Verifying Configuration Image in Flash...
Verify failed first attempt. Retrying ...Failed after 15 secs
Configuration image in FLASH differs from current - Upgrading...
Configuration Program - Flasher Build
Verifying hardware configuration word....OK
1 block needs programming...
Block 1 Load Map 0xfff00000..0xffffffff, Size 0x100000
Erasing block...
Programming block...
Flash memory programmed OK
TSC Reset by FLASHER code...
--------------------------------------------------------------------
The TSC reprograms its own boot block. Do not interrupt this. Do not power
cycle. After it completes you will notice:
* The monitor version changes (e.g. TSC_PR3_MON-R03.35.07 -> PR3_TSC_MON-R01.30.00)
* The prompt changes from SC: to SC#
* Access is now reported as "Engineering access"
At SC# you are in the monitor, not the application. It has a much shorter
command set. In our case the application then started on its own - the
prompt returned to SC: and ver reported the R8 application. If it does not
start by itself, the monitor command is:
--------------------------------------------------------------------
run
--------------------------------------------------------------------
Confirm:
--------------------------------------------------------------------
SC: ver
Dimetra Site Controller
Application Version : PR3_TSC_APP-R08.02.29
Release date : Jan 12 2017 09:54:13
--------------------------------------------------------------------
On the BRC console you will see the BR fetch its new code from the TSC:
--------------------------------------------------------------------
Waiting for Registration
Waiting for Code Download
Code Download in progress
Code Download completed OK
...
Version: R08.02.15 BRC_APP
Board configuration: 25MHz / 16MByte
BRC-Board type: PR20
...
BRC Software runs in Rel 8.2 configuration
--------------------------------------------------------------------
9.6 If the site does not come back
----------------------------------
Your fallback slots are untouched. From the monitor prompt:
--------------------------------------------------------------------
attrib -n tsc.code.2
attrib -n brc.code.2
reset
--------------------------------------------------------------------
That returns you to the previous firmware.
---
==========================================================================
10. STEP 7 - PATCHING THE BRC FIRMWARE
==========================================================================
10.1 Why this is necessary
--------------------------
This is the second reason an R8 attempt fails, and it is almost invisible.
The BRC firmware contains hard-coded calibration tables. On every boot, the
routine load_cnfg_parms_to_eeprom overwrites the EEPROM from those tables.
This means:
* Changes made with set pa_scaling_factor or set max_pwr_deviation from the
MMI persist only until the next reset (unless you are logged in with Factory
permissions, which writes EEPROM as well - but a firmware reload will still
overwrite it).
* A fresh firmware image ships with factory defaults, which are almost
certainly wrong for an amateur-converted radio.
The factory defaults in an unmodified image are:
| Parameter | Factory value |
|---|---|
| PA_PORT0 (forward power A/D scaling) | 1.0 |
| PA_PORT1 (reflected power A/D scaling) | 1.0 |
| max_pwr_deviation | 0.15 dB |
A 0.15 dB power-levelling tolerance is far too tight. Power levelling fails, the
BR cannot reach its target, and the site misbehaves in ways that look like a
network problem. **This is the most likely reason an earlier R8 attempt "did not
work" and was rolled back.**
10.2 Background - how these offsets were originally found, on R5
----------------------------------------------------------------
This is not new territory. The same three parameters were tracked down and
patched on the R5 firmware long before the R8 migration, and that earlier
work is what made the R8 patch a twenty-minute job instead of another
multi-night investigation.
The story is worth knowing because the reasoning transfers directly:
* The operator had been setting pa_scaling_factor 0, pa_scaling_factor 1 and
max_pwr_deviation by hand after every single boot, because they always
reverted to factory values.
Experienced engineers consulted at the time all gave the same answer: those
are Motorola factory values written in EEPROM, they cannot be changed.*
* That answer was half right and completely misleading. The values really do
live in EEPROM - but they are not put there by the factory. They are written
there by the firmware itself, at every boot, from hard-coded tables. The
EEPROM is a mirror, not the source of truth.
* The MMI confirms this if you read the response carefully:
set POWER AMPLIFIER SCALING FACTOR 1 to 1.000000 in RAM - the words in RAM
are the whole story. Compare with set brc_scratch, which really is
persistent.
* Several dead ends were explored first: editing brc01.cf, editing the
uploaded .CFG, and hunting for the parameters over SNMP. None of them
contain pa_scaling_factor at all. brc01.cf holds only integers - the
scaling factors are floats and simply are not there. A configuration file you
cannot find a parameter in is a strong hint that the parameter is not
configuration.
* The breakthrough was to stop treating the firmware as opaque and search the
binary for the float tables directly, cross-referenced against the board
revisions reported by get pa_rev_no and get brc_rev_no.
That is exactly the method reused in Section 10.4 for R8: the tables are laid
out identically, only relocated.
The original R5 session - including the wrong turns, the .cf and .CFG
analysis that led nowhere, and the moment the hard-coded tables were located -
is documented publicly here:
--------------------------------------------------------------------
https://radiofarafiltru.blogspot.com/2026/03/
sa-antrenam-ai-ul-la-ceas-de-seara-mai.html
--------------------------------------------------------------------
| The transferable lesson. If a parameter reverts on every boot and you
| cannot find it in any configuration file, stop looking in configuration files.
| Check whether the firmware writes it. get <module>_rev_no tells you which
| table entry applies to your hardware; the binary tells you the rest.
|
| And note what this means for any firmware change: the moment you load a new
| image, your calibration is silently replaced by that image's hard-coded
| defaults. Read your values out before you flash, every time.
10.3 Read your working values first
-----------------------------------
On the BRC, with the old firmware still running:
--------------------------------------------------------------------
BRC> get pa_scaling_factor 0
POWER AMPLIFIER SCALING FACTOR 0 is 4.00
BRC> get pa_scaling_factor 1
POWER AMPLIFIER SCALING FACTOR 1 is -9.00
BRC> get max_pwr_deviation
MAXIMUM POWER DEVIATION ( db before adjustment ): 3.000000
--------------------------------------------------------------------
Write these down. They are specific to your PA and coupler.
Do not be alarmed that PA_PORT0 and PA_PORT1 look nothing like each other.
The forward and reflected detector chains on the MPM have deliberately different
component values, and the two op-amp stages that scale them on the Exciter have
different gain networks. Section 17.3 traces both chains on the factory
schematics. The two numbers are not supposed to match.
10.4 Locating the parameters in the binary
------------------------------------------
The tables have an identical structure in R5 and R8, which makes them findable:
* 18 tables of 12 float32 slots each (6 parameters x 3 hardware revisions)
* Tables are spaced exactly 0x58 bytes apart
* The PA scaling table is the 11th table (index 10)
* The distance from the max_pwr_deviation table to the PA table is **exactly
0x1000** in both versions
Find them by scanning for runs of twelve consecutive 3f800000 (float 1.0)
values, four-byte aligned:
--------------------------------------------------------------------
def find_runs(data, pattern=b"\x3f\x80\x00\x00", min_run=6):
runs, i, n = [], 0, len(data)
while i < n - 4:
if data[i:i+4] == pattern:
start, count, j = i, 0, i
while j < n - 4 and data[j:j+4] == pattern:
count += 1; j += 4
if count >= min_run:
runs.append((start, count))
i = j
else:
i += 4
return runs
--------------------------------------------------------------------
Known offsets:
| Firmware | PA_PORT0 | PA_PORT1 | max_pwr_deviation (3 copies) |
|---|---|---|---|
| R05.02.57 (R050257x.brc) | 0x16d5bc | 0x16d5c0 | 0x16c5bc, 0x16c5e0, 0x16c604 |
| R08.02.15 (R080215_440MHz.brc) | 0x1c38dc | 0x1c38e0 | 0x1c28dc, 0x1c2900, 0x1c2924 |
Values are big-endian IEEE-754 float32. Write max_pwr_deviation to all
three copies - they correspond to hardware revisions R03.00, R03.01 and R03.02,
and writing all three removes any doubt about which revision your board is.
10.5 Patching script
--------------------
--------------------------------------------------------------------
import struct
SRC = "R080215_440MHz.brc"
DST = "R080215_440MHz_patched.brc"
PA0, PA1, MPD = 4.0, -9.0, 3.0 # <-- YOUR measured values
OFF = {0x1c38dc: PA0, 0x1c38e0: PA1,
0x1c28dc: MPD, 0x1c2900: MPD, 0x1c2924: MPD}
data = bytearray(open(SRC, "rb").read())
for off, val in OFF.items():
print(f"{off:#x}: {struct.unpack('>f', bytes(data[off:off+4]))[0]} -> {val}")
data[off:off+4] = struct.pack(">f", val)
open(DST, "wb").write(data)
--------------------------------------------------------------------
Sanity checks after patching:
* File size must be unchanged
* Fewer than 20 bytes should differ from the original
* Reading back the offsets must return your intended values
10.6 Verify after the upgrade
-----------------------------
--------------------------------------------------------------------
BRC> get pa_scaling_factor 0
POWER AMPLIFIER SCALING FACTOR 0 is 4.00
BRC> get pa_scaling_factor 1
POWER AMPLIFIER SCALING FACTOR 1 is -9.00
BRC> get max_pwr_deviation
MAXIMUM POWER DEVIATION ( db before adjustment ): 3.000000
--------------------------------------------------------------------
If those survived the boot, the patch is correctly baked into the firmware and
will survive every future reset.
10.7 Uploading a patched image
------------------------------
Connection -> Send Files -> Application Files, then exactly as in Section 9.3.
Use a clear version label so you can tell patched images apart later.
---
==========================================================================
11. STEP 8 - SENDING THE CONFIGURATION
==========================================================================
1. Connection -> Connect Direct
2. Connection -> Send Files -> Configuration Files
3. Select your saved .cfg
4. Version label: something unique, e.g. v50
5. Tick Use Next
6. Click "Update selected items"
7. OK
8. Choose the target file with all minus signs - never the one marked +
TESS compiles the .cfg into a .sc1 (site controller) plus .b01, .b02, ...
(base radios) and translates the names during transfer:
--------------------------------------------------------------------
*.sc1 -> tsc.cf
*.b0? -> brc0?.cf
*.tsc -> tsc.code
*.brc -> brc.code
*.x21 -> x21.code
--------------------------------------------------------------------
Then:
--------------------------------------------------------------------
reset
--------------------------------------------------------------------
And, if your site link needs to be re-declared:
--------------------------------------------------------------------
.sitelink -e1
.e1config -crc on -crdStart 1 -crd 31 -ts16Skip off -portNo 1
reset
--------------------------------------------------------------------
| If your E1 is already working, you do not need those two commands. They set
| exactly the parameters a working site already has.
| Documented behaviour to be aware of: parameters set locally can be
| overwritten by the network management terminal when the site connects to the
| master site, and the value received from the network only takes effect after
| a subsequent reset. If a value you set does not stick, reset again and
| re-check before assuming you made a mistake.
---
==========================================================================
12. STEP 9 - VERIFICATION COMMANDS
==========================================================================
On the TSC
----------
--------------------------------------------------------------------
ver
status sc -all
status bts
status bsl -r
status fr -r
status lmi -r
status sri
status sri -gps
status br
display config -ip
display config -quick
status ntp
ping 10.1.231.1
ping 10.1.232.1
--------------------------------------------------------------------
A fully healthy site:
--------------------------------------------------------------------
Overall Status: Active - ENABLED_SYNC / NO_REASON
BTS type: EBTS
Site Status: Wide Trunking(SecurityClass1)
Internal State: AS_U_E_A
Site Link State: UP
Netcom Primary: ACTIVE_S
Netcom Secondary: STANDBY_S
Cell 01 State: CS_U_E_A
BRC 01 (cab=1,pos=1) State: BS_U_E_A DCKs Downloaded and Class Set
--------------------------------------------------------------------
On the BRC
----------
--------------------------------------------------------------------
get info
get config
get alarms
get fwd_pwr
get ref_pwr
get vswr
get rssi 1 100
get hw_config
--------------------------------------------------------------------
Healthy example:
--------------------------------------------------------------------
BRC Code Version : R08.02.15 BRC_APP
Receive Freq : 432.55000 MHz
Transmit Freq : 439.55000 MHz
Power Levelling Enabled. [300 Seconds].
Maximum VSWR : 4.00:1
Forward Power : 36.48 watts [45.62 dbm]
Reflected Power : 0.67 watts [28.26 dbm]
VSWR is 1.31:1
NO ALARM CONDITIONS DETECTED
--------------------------------------------------------------------
The Call Log - the definitive PTT test
--------------------------------------
--------------------------------------------------------------------
diag
4 (Call Logging)
3 (Route to Display - live)
--------------------------------------------------------------------
Then key a radio. Entries look like:
--------------------------------------------------------------------
GRP <start> <end> A:<caller_hex> B:<group_hex> I:<idx> P:<pri> S:<status> C:<cause> D:<dur>
REG <time> <time> A:<issi_hex> G:<gssi_hex> L:<n>
--------------------------------------------------------------------
Exit with 0 then 0.
Reading the result:
| Log line | Meaning |
|---|---|
| S: 4 C:255 with zero duration | Resource never allocated. On R5, this is the firmware incompatibility. |
| S: 4 C:02 with a real duration | Success. The call was set up and carried audio. |
| Timestamps in impossible years (2044, 2065, 2076) | Symptom of the same broken-call condition; sane timestamps appear once calls work. |
| REG lines appearing | Radios are registering correctly. |
| Caller ISSIs you do not recognise | Wide-area traffic from other sites - proof the core link works. |
Convert hex to decimal to identify radios: 0x22883A = 2263098,
0x0375D9 = 226777.
---
==========================================================================
13. ERROR REFERENCE - WHAT EACH SYMPTOM ACTUALLY MEANS
==========================================================================
| Symptom | Real cause | Fix |
|---|---|---|
| S:4 C:255, "unit not attached", "PTT denied", works in LST | R5.x firmware is not compatible with the core | Upgrade TSC and BRC to R8 (Section 9) |
| Site never reaches Wide Trunking | Wrong PVC /30 subnet, or wrong BTS IP | Verify the /30 matches your site; BTS IP is 10.128.<SITE_ID>.1 |
| Wide Trunking reached, but no core multicast / no wide-area audio | PIM in sparse-dense-mode with unreachable RP | ip pim dense-mode, remove ip pim rp-address |
| All PIM neighbours drop at once, DR moves to your router | Your ZeroTier bridge went down (Pi rebooted or ZeroTier restarted) | Ensure zt-bridge.service is enabled; check Pi uptime |
| %CONTROLLER-5-UPDOWN: E1 0/0 changed state to down (LOS detected) right after a TSC reset | Normal - the TSC stops driving the line while reinitialising | Ignore; confirm bit-error counters stay at zero |
| Persistent LOS with no reset, climbing Line Code Violations | Genuine cable/connector fault | Reseat both RJ45 ends; check pair integrity |
| Netcom Primary: GRANT_S, Secondary: ACTIVE_S | Failover to the backup PVC after a primary interruption | Usually self-heals; recheck in a few minutes |
| %PIM-6-INVALID_RP_JOIN ... for invalid RP | Another site has the sparse-dense misconfiguration | Not your problem; inform the core team |
| BRC MAJOR alarms 118/119 (RX2/RX3 delta out of range) | Receiver delta values stored in the receiver module EEPROM | These disappeared entirely after the R8 upgrade in our case |
| Radio shows "no service" while another radio on the same site works | Codeplug issue - most often a missing frequency in the Frequency List, or damaged tuning data | Compare codeplugs; check the frequency list first |
| Antenna icon flashing on the radio | The site has lost its link to the core and dropped to Local Site Trunking | Check Site Link State on the TSC |
| Power levelling fails after a firmware upgrade | max_pwr_deviation reverted to the 0.15 dB factory default | Patch the firmware (Section 10) |
| get info returns "Invalid command" on the TSC | You are on the wrong serial port - that is a BRC command | Check your COM port assignments |
| Radio registers and attaches but the core dashboard shows 0 connected radios | Core has not fully provisioned the site | Raise it with the core team |
---
==========================================================================
14. OPTIONAL - NTP CLIENT (R8 ONLY)
==========================================================================
[ FIGURE 16 - see the PDF edition ]
The NTP tab, available only on the R8 personality (note the 'Mode:
EBTS R8.2' indicator). Frequency locking stays unchecked when GPS is
present.
R5.32.58 has no NTP support at all - the tab does not exist. R8 adds it.
Edit Site Controller -> NTP:
| Field | Value |
|---|---|
| Primary NTS IP Address | 10.1.233.88 |
| Secondary NTS IP Address | 0.0.0.0 |
| Allow NTS For Frequency Locking | unchecked |
Leave frequency locking off. Your GPS discipline is far better than NTP over the
public internet; NTP here is only for log timestamps and UTD.
Verify:
--------------------------------------------------------------------
SC: status ntp
Primary NTS server status: 10.1.233.88, peer
peer.stratum = 1
peer.reference id = PHC0
sys.offset = 94.932 ms
synchronization distance = 19.105 ms
frequency lock validity: NO
--------------------------------------------------------------------
frequency lock validity: NO is the correct result when the checkbox is
unticked.
When GPS is available, status sri will report Time source: GPS. If GPS is
lost, it falls back to Time source: NTS.
---
==========================================================================
15. OPTIONAL - PACKET DATA / WAP
==========================================================================
15.1 What actually works
------------------------
Older documentation states that EBTS supports only simplex group calls with no
SDS, status calls or packet data. That is out of date with respect to packet
data. The current position from the core administrators is:
* Rohill - no central PD support
* CTS - the base station must be specially preconfigured
* EBTS / MTS - should work; nothing special is needed in the Dimetra radio
profiles, the provisioning importer handles it
* PD works out of the box on Dimetra **if the base station is properly
configured and the ISSI is authorised**
15.2 What you must request
--------------------------
[ FIGURE 17 - see the PDF edition ]
The published WAP / mobile IP data settings. CHAP, the BrandMeister
SelfCare hotspot password, and per-ISSI enablement by the
administrators.
[ FIGURE 18 - see the PDF edition ]
The core network's affiliation dashboard. A site can show as
'Connected' while reporting zero attached radios, which is a useful
cross-check against what your own TSC believes.
Packet data must be enabled per ISSI by the core administrators. Post in the
core support group:
--------------------------------------------------------------------
Hi, could you please enable Packet Data / WAP for the following ISSIs:
<ISSI_1>, <ISSI_2>, <ISSI_3>
I would like full AMPR/HAMNET access if possible.
Also, could you confirm that Site <SITE_ID> has a dynamic PD slot allocated?
--------------------------------------------------------------------
Two notes:
* You will be asked whether you want WAP only or **full AMPR/HAMNET
routing**. AMPR (also called 44Net) is the 44.0.0.0/8 IPv4 block allocated
to amateur radio. The routable address space mapped to AMPR/HAMNET is limited,
so if WAP is enough, they prefer to allocate from non-routable space.
* Ask them to confirm your site has a dynamic PD slot allocated - this is
visible only from the core side and is a genuine prerequisite.
15.3 Radio CPS settings
-----------------------
[ FIGURE 19 - see the PDF edition ]
Radio CPS packet data settings. Proxy 10.10.10.2 (not .0), port 9201,
CHAP, Authenticator Name DIMETRA_P. Credentials redacted.
[ FIGURE 20 - see the PDF edition ]
The proxy address detail. A single wrong digit here costs an evening
of debugging.
| Field | Value |
|---|---|
| Proxy IP Address | 10.10.10.2 |
| Remote Port | 9201 |
| Force SAR | checked |
| SAR Group Size | 3 |
| Bearer Index | 0 |
| Protocol Type | CHAP |
| User Name | the radio's own ISSI |
| Password | <BM_HOTSPOT_PASSWORD> |
| User Authentication | checked |
| Authenticator Name | DIMETRA_P |
| Data Only / Voice&Data / Voice Only | all checked |
| Default Packet Data Mode | Voice&Data |
| PD Page Period Updates | 1000 ms |
| IP Queue Timeout | unchecked |
| IP Maximum Queuing Time | 5 s |
| Request a Dynamic IP Address | checked |
| Static IP Address | 0.0.0.0 |
| The single most common mistake: 10.10.10.0 instead of
| 10.10.10.2 for the proxy address. One operator lost an evening to this.
The password is the hotspot / repeater password from your BrandMeister
SelfCare page. It is one password per callsign, used with a different username
(ISSI) on each radio. The same password is also used when a node (mini base
station, RoIP gateway) authenticates to the core - username is the node's ID,
password is the same BM hotspot password.
The EBTS never sees this password. CHAP authentication happens between the
radio and the core's packet data gateway. The base station is a transparent
transport. Do not go looking for a place to enter it in TESS.
15.4 Manage your expectations
-----------------------------
[ FIGURE 21 - see the PDF edition ]
The failure mode most operators see on older handsets: 'Data Not
Connected' despite a correct configuration and an authorised ISSI.
Multiple operators have reported that packet data **does not work on MTH800 or
MTP6650**, while working on MXP600. Several people followed the documented
procedure exactly and still got "Network unavailable" or *"Data Not
Connected"*. One core administrator's honest assessment is that PD adds close to
zero practical value and that most enabled IDs are used for an hour of testing
and then forgotten.
It is worth trying. Do not be surprised if it does not work on older handsets.
---
==========================================================================
16. "DO NOT DO THIS" - MISTAKES WE ACTUALLY MADE
==========================================================================
Do not overwrite the currently active slot.
Always target the entry showing all minus signs. Losing your fallback while
experimenting with firmware is how a TSC becomes a paperweight.
Do not forget to click "Update selected items".
The version label and the Use Next flag are not applied until you do. The file
transfers, the flags do not.
Do not copy the ZC addresses from an old template.
.255 is a firmware default that does not match the live core. Use .1.
Do not put the NTP server address in the Network Manager field.
.88 is NTP. .101 is the Network Manager.
Do not use sparse-dense-mode on the serial subinterfaces.
It silently blocks all core multicast when there is no reachable RP.
Do not let ZeroTier manage an address on the Pi.
allowManaged=0. The Cisco owns the site address, not the bridge.
Do not assume a failed transfer means a broken cable.
Check whether a TSC reset happened at the same moment.
Do not skip reading the current BRC calibration values before flashing.
Once the new firmware overwrites the EEPROM, they are gone. Write them down
first.
Do not run the wiki installer as published.
The wget | bash line lacks -O - and does nothing. Even corrected, verify by
hand.
Do not blindly trust the example configuration you were given.
Two of its values were wrong for every site that used it.
Do not chase network problems for weeks before checking firmware versions.
Ask early: "what firmware is everyone else running?"
---
==========================================================================
17. HARDWARE-LEVEL FAULT DIAGNOSIS
==========================================================================
Everything up to this point assumed your Base Radio is electrically healthy and
the problem is integration. This section covers the opposite case: faults inside
the BR itself. They matter here because **several of them present as "calls do
not work"** and can easily be mistaken for the core-side rejection described in
the opening warning.
| Tell the two apart immediately. A core-side rejection gives you a *fully
| healthy site* - Wide Trunking, NO ALARM CONDITIONS DETECTED, BR keyed - and
| failure appears only in the Call Log as S:4 C:255. A hardware fault gives you
| alarms, a BR that will not key, or status bts reporting a subsystem as Major
| or Critical. If get alarms is clean and the BR is transmitting, stop looking
| at hardware.
17.1 The PA power control loop - how it works
---------------------------------------------
[ FIGURE 22 - see the PDF edition ]
Base Radio transmit chain and power control loop. RF from the Exciter
passes through LDM and the two LFM stages; the Feedback Coupler on the
MPM samples the output into the LPF and Power Detector, whose forward
and reflected outputs, together with the thermistor, reach the A/D and
then the SPI interface. This is the loop that pa_scaling_factor
calibrates.
Understanding the loop makes every power-related fault self-explanatory. The
chain is:
1. BRC hands baseband data to the Exciter, which generates the modulated
RF at low level.
2. The Exciter output (PA_IN) is amplified through LDM -> LFM -> MPM; the
final stage output (PA OUT) is the transmitted RF.
3. A directional coupler taps a sample of the output - RF FEEDBACK FROM PA
MODULE / PA_FEEDBACK.
4. On the MPM module, diodes, resistors, capacitors and inductors form a
detector plus low-pass filter, producing the analogue levels FW_DET and
REV_DET (forward and reflected).
5. An A/D converter digitises them into FWD_PWR / REV_PWR
(as EXTW_VFWD / EXTW_VREF).
6. The digital values travel to the BRC over SPI (SPI_CLK, SPI_MISO,
SPI_MOSI) across the backplane.
7. The BRC compares measured power against target and adjusts drive.
This is exactly the loop that pa_scaling_factor 0 and pa_scaling_factor 1
calibrate - they are the multipliers applied at step 5 to convert raw A/D counts
into watts. max_pwr_deviation is the tolerance the BRC allows at step 7 before
it declares the loop unable to converge. That is why the firmware patch in
Section 10 is not cosmetic: **wrong scaling factors make the BRC believe the PA
is producing the wrong power, and a too-tight deviation makes it give up.**
17.2 Power control loop and LPF detector faults
-----------------------------------------------
[ FIGURE 23 - see the PDF edition ]
Detector and levelling detail. The RF line is sampled by Schottky
diodes, filtered, then scaled by MC3303-class op-amp stages before
reaching the converter; the thermistor sits in the same block.
[ FIGURE 24 - see the PDF edition ]
The same circuit drawn out by hand while tracing the board: RF line at
the bottom, coupler and detector diodes, then a non-inverting op-amp
stage feeding the A/D input. Redrawing a circuit from the PCB is often
the fastest way to understand it.
A power-loop or detector fault can originate at any step above:
| Failure point | Typical cause | What you observe |
|---|---|---|
| PA module | Internal fault, rollback condition | PA LED steady red or blinking; minor alarm; reduced performance |
| RF feedback path | Defective or disconnected coupler, damaged straps (including Omega straps), bad coax | Power reads implausibly low or zero while RF is actually present |
| Detector / LPF on MPM | Burnt diodes, open resistors or inductors, shorted capacitors | FW_DET / REV_DET wrong or absent |
| A/D converter | Fault on the DC board or Exciter/MPM | Readings frozen, nonsensical, or not updating |
| SPI bus | Bad backplane contacts, corrupted signalling | BRC cannot read power at all |
| Supply rails | +5.1 V, +14.2 V, +28.6 V out of tolerance from the DC board | Multiple unrelated measurements drift together |
| Physical damage | MPM, DC board or backplane | Any of the above, often intermittent |
Diagnostic sequence:
--------------------------------------------------------------------
get alarms
get fwd_pwr
get ref_pwr
get vswr
--------------------------------------------------------------------
Reference limits: forward power above 36 W (or 38.20-41.89 W for a 40 W PA),
reflected power below 4.0 W, VSWR below 2:1. A bad VSWR reported alarm points
outward - antenna, lead-in, or surge arrestor - not at the PA.
Note the diagnostic value of the scaling factors being stored per module: the
kit number, revision number and module-specific scaling and correction factors
all live in that module's own EEPROM. When you swap a FRU, its factory
calibration comes with it. That is also why scratch fields exist per module
(brc_scratch, ex_scratch, pa_scratch, rx1..3_scratch) - 40 characters of
free text in EEPROM, genuinely persistent, ideal for recording replacement dates
or which site a module came from.
17.3 The metering chain, traced on the factory schematics
---------------------------------------------------------
Everything above is the functional description. This section is the same chain
read off the manufacturer's drawings, component by component, because it settles
a question that costs people a lot of time: *where is the comparator that decides
pa_scaling_factor 0 and pa_scaling_factor 1?*
Sources. Booklet 4-4 Base Radio (68P02500U48-O): MPM module CTX5081A at
page 8-6, parts list at 8-2; Exciter CTX5086A at page 5-26 and its block diagram
at 5-9; DC board CLN7494A block diagram at 13-6, parts list at 13-3.
Where FW_DET and REV_DET are born - the MPM (CTX5081A)
[ FIGURE 25 - see the PDF edition ]
The complete MPM sheet (68P02500U48-O, page 8-6). RF enters at
ISOLATOR_IN on the left, passes the two 26 dB directional couplers and
the low-pass filter, and leaves at RF_OUT. The 18.5 dB coupler at the
top feeds EXCITER_FB and has nothing to do with power metering.
[ FIGURE 26 - see the PDF edition ]
The two detector chains, enlarged and stacked. Top: the forward chain
- D2 into R9, filtered by C4 and C2, with D4 as the compensation
diode, out to FW_DET at M4. Bottom: the reflected chain - D1 into R8,
C3 and C1, D3 compensating, out to REV_DET at M3. Note that D1 to D4
are each drawn as a box containing two diodes: that is the dual-diode
three-pad package which reads as a short when you probe it in circuit.
Two 26 dB directional couplers in series sit in the output line, upstream of
the low-pass filter (L1-L4 24 nH with C7-C12) and the RF_OUT connector.
Each coupler feeds one identical detector chain:
| Stage | Forward chain | Reflected chain |
|---|---|---|
| Coupler | 26 dB directional | 26 dB directional |
| Matching, isolated-port termination | C6 27 pF, L7 6.8 nH, L10 100 nH, R6 100 ohm | C5 27 pF, L8 6.8 nH, L9 100 nH, R5 100 ohm |
| Detector diode | D2 | D1 |
| Temperature-compensation diode | D4 to ground | D3 to ground |
| Shunt filter at the diode | C4 82 pF, R4 220 ohm | C3 82 pF, R3 220 ohm |
| Series inductor | L6 0.18 uH | L5 0.18 uH |
| Series output resistor | R9 17.8 kohm | R8 17.8 kohm |
| Output shunt | R2 15 kohm, C2 200 pF | R1 15 kohm, C1 200 pF |
| Output pin | FW_DET (M4) | REV_DET (M3) |
Three things in that table are worth pausing on.
D1 through D4 are all the same part - Motorola 4882290T04, described in
the parts list only as "Diode; hot carrier". Not one of them is a transistor.
And look at how they are drawn: each is a box containing two diodes, i.e. a
dual diode in a three-pad package. D4 and D3 sit directly across their
detector outputs to ground. That is the exact origin of the measurement trap
described in Section 17.4 - in circuit they read as a short across two of their
pads, and they are supposed to.
**The parts list and the schematic sheet disagree, and you should know which to
trust.** The drawing shows both chains symmetric: R8 = R9 = 17.8 kohm, R1 =
R2 = 15 kohm. The parts list at 8-2 gives R1 17.8 kohm, R2 16.9 kohm, R8 15 kohm,
R9 17.8 kohm. That is a revision difference, not a typo on your part. Treat the
parts list as the authority for ordering and the **board in front of you as
the authority for what is fitted** - measure before you replace. Either way the
two chains are not guaranteed to be identical, which is part of why PA_PORT0
and PA_PORT1 are nowhere near each other numerically (4.0 and -9.0 on the
reference site). Do not "correct" one to match the other.
EXCITER_FB is not power metering. A separate 18.5 dB coupler on the PA
input side feeds EXCITER_FB through a resistive pad (R11-R14 1.5 kohm,
R15/R16 18 ohm, R10 51 ohm terminating). That signal goes back to the Exciter
for linearisation, not to the power loop. Chasing it when you meant to chase
forward power is an easy and expensive mistake. RT1, a 100 kohm thermistor,
provides THERMAL_SENSE from the same module.
Where they are scaled and digitised - the Exciter (CTX5086A)
[ FIGURE 27 - see the PDF edition ]
The Exciter metering sheet (68P02500U48-O, page 5-26). EXTW_VFWD
enters at the lower left, EXTW_VREF at the lower right; both are
scaled by MC3303 sections and land on U3100, the TLC542 converter, in
the middle.
[ FIGURE 28 - see the PDF edition ]
Detail: U3100 TLC542, an 11-channel serial A/D, with the EXTW_VREF
scaling stage below it. The two remaining MC3303 sections are marked
UNUSED GATES on the original sheet, because exactly two channels exist
for exactly two measurements.
FW_DET and REV_DET cross the backplane and arrive at the Exciter as
EXTW_VFWD and EXTW_VREF:
| | Forward | Reflected |
|---|---|---|
| Input network | C3100 0.1 uF, R3100 1 Mohm | R3126 1 Mohm, C3110 4.7 uF, C3112 0.1 uF |
| Series input resistor | R3101 20 kohm | R3122 20 kohm |
| Amplifier | U3101 MC3303, pins 12/13/14 | U3101 MC3303, pins 5/6/7 |
| Gain network | R3102 100 kohm, R3105 11 kohm | R3118 10 kohm, R3121 10 kohm |
| Output clamp | CR3100, R3111 100 kohm | CR3103, R3115 100 kohm |
The sheet marks the other two MC3303 sections UNUSED GATES - a quad op-amp
of which exactly two sections are used, for exactly two measurements. Both
outputs land on U3100, a TLC542: an 11-channel 8-bit serial A/D, addressed
on A0...A10, clocked over IOCLK / DATAOUT / ADDRESSIN with A_D_CS*, and
wired out to SCK / MISO / MOSI. That is the same converter family as the
TI TLC542I visible in the photographs earlier in this section. Other channels
on the same converter carry SYNTH_VSL, LO2_LOCK and the A+ rail through
R3124 27 kohm.
The conclusion: there is no comparator in this path
This is worth stating plainly, because it is what people go looking for and never
find:
| Nothing between the PA output and the BRC compares anything. The detector
| diodes rectify, two MC3303 sections scale, the TLC542 digitises, and the result
| goes to the BRC as a number over SPI. Every decision - is the power right, is
| it too far off, should the drive go up - is taken in software.
That is precisely why pa_scaling_factor 0 and 1 are IEEE-754 floats in a
firmware table rather than trimmer pots, why max_pwr_deviation is a value in dB
rather than a resistor ratio, and why the whole problem in Section 10 is solved
by editing a binary and never by touching the hardware.
Where the real comparators are - the DC board (CLN7494A)
[ FIGURE 29 - see the PDF edition ]
DC board diagnostics (68P02500U48-O, page 13-6). Every triangle with a
REF input is a comparator: HI-TEMP DETECT, FAN FAULT DETECT, BULK
DETECT, the rail diagnostics. These decide in hardware and hand the
result to the A/D converter and the SPI bus. Nothing in the RF power
path works this way.
The comparators do exist, but they measure something else. The DC board block
diagram at 13-6 shows a row of DETECT blocks, each with its own REF input -
those are the analogue comparators:
| Block | What it compares | Result |
|---|---|---|
| BULK DETECT, MOD FAIL, DC FAIL | Inverter and bulk supply | Front-panel MODULE FAIL (red) / DC (green) |
| HEATSINK STATUS DETECT | Heatsink diagnostics | HEATSINK DIAG |
| HI-TEMP DETECT | Heatsink thermistor against reference | HI-TEMP DETECT alarm |
| FAN FAULT DETECT | Fan current sense against reference | FAN FAIL, FAN ON |
| +5.1 V / +14.2 V / +28.6 V DIAG DETECT | Each supply rail against reference | Rail diagnostics |
The board also carries its own A/D converter, address-decode circuitry and the
SPI bus to the Station Control Module. So: **rails, temperature and fans are
compared in hardware and cross the SPI as decided alarm bits. RF power is not
compared in hardware at all.** Two different philosophies on two different
boards, and knowing which is which tells you immediately whether a symptom can
possibly be fixed in firmware.
Identifying the screened sub-board in your own radio
Both the Exciter and the DC board carry a TLC542-class converter and MC3303 op
amps, so the converter alone does not tell you which board you are holding. The
DC board parts list (13-3) is the fingerprint:
| Ref | Part | Marking you will read on the chip |
|---|---|---|
| U5000 | Dual 1-of-4 decoder / demultiplexer | AC139 |
| U5001 | 8-bit A/D converter | TLC542 |
| U5003 | Octal 3-state non-inverting line driver | AC244 |
| U5004 | 2 kbit serial EEPROM, 8-pin SOIC | X25C02 / X25020 |
| U5102, U5310 | Quad operational amplifier | MC3303 |
| U5311 | Precision voltage reference | |
| D5310-D5312 | HP PIN diode | |
| RT5310 | 100 kohm thermistor | |
**If the module carries an AC139, an AC244, an X25-series EEPROM and a
TLC542 together, it is the DC board diagnostics block.** The reference
photographs bear this out: read the silkscreen. Figures 30 to 34 all carry
5xxx designators - U5001, U5004, U5102, R5007-R5012, C5001,
D5103-D5108 - so they are the DC board. Figure 36 carries 3xxx
designators and sits next to U3100, so it is the Exciter. Two boards, two
TLC542-class converters, and the reference designator block is the fastest way
to tell them apart in a photograph taken months earlier. The Exciter has an
EEPROM too - U5001, an X25020 - but pairs it with MC74ACT125 buffers and a
MAX512 DAC generating VBLIN, which the DC board does not have.
This also answers "which EEPROM holds my calibration": each FRU has its own.
pa_scratch, ex_scratch, brc_scratch and rx1..3_scratch are separate
memories on separate boards, which is why swapping a module carries its
calibration with it.
What this means when you are probing
- Measure forward and reflected as analogue voltages at the MPM outputs **M4
(FW_DET) and M3 (REV_DET)**, keyed into a known dummy load. TP1-
TP6 are on the same module.
- One reading wrong, the other tracking -> that chain's detector diode,
filter or series resistor. The two chains share nothing downstream of the
couplers.
- Both wrong or frozen -> the shared path: the coupler section, the
backplane connection, the MC3303 stage, or the TLC542 itself.
- Both plausible but the power is wrong anyway -> nothing is broken. You have
a scaling problem, and it lives in firmware. Go to Section 10.
17.4 Where the calibration actually lives, in hardware
------------------------------------------------------
It is worth seeing the physical circuit, because it makes Section 10 concrete.
[ FIGURE 30 - see the PDF edition ]
The metering sub-board itself, screened and mounted on the main board:
ADC, bus buffer, decoder, glue logic and the serial EEPROM.
[ FIGURE 31 - see the PDF edition ]
The same module in place, with the functional blocks identified.
Annotations translated from the original working notes.
The metering module is a small screened sub-board carrying, typically: an
A/D converter (e.g. a TI TLC542 series 11-channel serial ADC), a **bus
buffer/driver (AC244), decoders/demultiplexers** (AC139) that select which
analogue channel is sampled, a small amount of CMOS glue logic (HC11, HC14),
and - critically - a serial EEPROM (X25C02 class).
[ FIGURE 32 - see the PDF edition ]
The A/D converter, a TI TLC542-series serial ADC. Every power, voltage
and temperature reading the BRC acts on passes through this device.
[ FIGURE 33 - see the PDF edition ]
The serial EEPROM (X25C02 class) that holds the module's kit and
revision numbers, its scaling and correction factors, and the scratch
pad. This is the memory the firmware overwrites at every boot, which
is the reason Chapter 10 exists.
That EEPROM is the one referenced throughout this guide: it stores the module's
kit number, revision number, module-specific scaling and correction factors,
and the free-form scratch pad. It is also the memory that
load_cnfg_parms_to_eeprom rewrites from the firmware's hard-coded tables on
every boot - which is exactly why MMI changes do not survive a reset and why the
firmware itself has to be patched.
The analogue front end feeding that ADC is a straightforward detector plus
op-amp chain: the coupler sample is rectified by Schottky diodes, filtered, and
scaled by a non-inverting op-amp stage (MC3303-class quad op-amps are used) whose
output swings into the ADC input range. Forward and reflected each get their own
identical chain; further inputs on the same ADC carry supply rails and the
thermistor.
[ FIGURE 34 - see the PDF edition ]
Analogue inputs arriving at the converter: the forward/reflected pair
from the internal reflectometer, plus supply-rail and temperature
channels from the final stage.
[ FIGURE 35 - see the PDF edition ]
The Base Radio Controller board. The circled areas are the small
three-pad networks in the analogue metering path.
A word of caution when probing this area with a multimeter. Several of the
small three-pad SOT-23 devices in the bias network around the detector chain
read as a short across two of their pads when measured in circuit. A normal
NPN or PNP does not do that. **Do not condemn them on the strength of that
reading** - more than one person has replaced perfectly good components after
misreading a part of this kind.
[ FIGURE 36 - see the PDF edition ]
A measurement trap, not a fault. This is the Exciter board, not the
metering sub-board of the previous figures - note the 3xxx reference
designators and U3100, the TLC542 converter from the schematic at page
5-26. The circled three-pad parts read as a short across two of their
pads in circuit. That reading on its own does not condemn them: see
the analysis below.
What can and cannot be proved here is worth stating exactly, because the
documentation runs out at this point:
* The board silkscreen gives these parts a Q prefix - on the reference
Exciter, Q3206, Q3207, Q3209, Q3210, Q3211 (Figure 36).
* The Exciter parts list in Booklet 4-4 contains Q3206 (a PNP) and then jumps
straight to Q3300. Q3207, Q3209, Q3210 and Q3211 are not in it at
all, and neither are R3240, R3242, R3244, C3500 or C3630, all of
which are printed on the board. U3100, U3200, CR3200 and C3600 are
listed - so this is the right book and the right board, just an earlier
revision of it.
* The 2001 manuals do not fully describe later board revisions. That is the
real lesson. The designator exists on your board and not in your book, so the
book cannot tell you what the part is, and an in-circuit measurement of a
three-pad device inside a bias network is not conclusive on its own.
Dual diodes in a transistor footprint is the usual explanation for this reading,
and it remains the most likely one - but on this board it is an inference, not
something taken from the parts list. Either way the practical rule is unchanged.
Before condemning anything in this path, confirm the part type from the board
markings and from the service documentation for your revision, rather than
from the footprint or from an in-circuit resistance reading. A genuine
detector-path fault shows up as a reading that is wrong - for example
forward power plausible while reflected sits at zero or full scale regardless of
load - not as a part measuring oddly on a meter.
17.5 What METERING_DIAGNOSTICS monitors
---------------------------------------
The station's internal metering covers more than RF power:
* RF power - FWD_PWR / REV_PWR, via FW_DET / REV_DET
Temperature - PA_TEMP, THERMISTOR_IN; triggers HI-TEMP DETECT*
* Supply rails - +14.2_VOLTS, plus diagnostics for +5.1 V, +14.2 V,
+28.6 V and VBAT
* Fans - FAN_ALARM, FAN_I_SENSE, FAN_FAIL, FAN ON, FAN_SENSE;
triggers FAN FAULT DETECT
Module health - MOD FAIL, DC FAIL, front-panel INPUT GOOD (green)* and
MODULE FAIL (red), startup detect and inverter status
All analogue values are digitised and reported to the BRC over SPI. The circuitry
is spread across the DC board, the Exciter and the MPM - which is why a fault on
the DC board can produce symptoms that look like an RF problem.
17.6 "Unable to sync" and EXTERNAL REFERENCE is UNDEFINED
---------------------------------------------------------
[ FIGURE 37 - see the PDF edition ]
GPS clock acquisition in progress. Until the receiver settles, the
site reference stays in UN-SYNC FREE RUN and the time source falls
back to NTS.
[ FIGURE 38 - see the PDF edition ]
A healthy site reference: MAINTAIN FREQ LOCK, 1 PPS VALID,
Synchronised YES, time source GPS.
Synchronisation failures are the other large family of local faults, and they
do stop calls.
The site's timing comes from GPS via the Site Controller, which distributes
5 MHz and 1 PPS to every Base Radio. Break that chain and the BR cannot key.
Main causes:
GPS reception or receiver failure. GPS Problem - 0 Tracked Satellites is a
Major alarm: the controller goes to Impaired, the high-stability oscillator
enters free run, and after a four-hour timer every BR dekeys and call service
is lost. Causes range from antenna, cabling and surge arrestors to RF
interference, site shadowing, or a failed GPS receiver. Diagnose with:
--------------------------------------------------------------------
status sri
status sri -gps
--------------------------------------------------------------------
Look for satellites tracked, C/N ratios, and PDOP. Be patient - **GPS
acquisition and oscillator lock can take 30 minutes, occasionally up to two
hours**, after a cold start or reset. A site showing UN-SYNC FREE RUN and
Time source: NTS ten minutes after boot is not necessarily faulty.
Oscillator faults. HSO Failed is Critical and means hardware replacement.
Related alarms: HSO 1PPS Missing, HSO Phase Not Locked (1 PPS phase off by
more than 30 ms), HSO Frequency Not Locked.
5 MHz / 1 PPS distribution problems. Degraded or missing reference produces
1 PPS out of window or External reference failure, which resets BRs and drops
active calls. A specific and easily-made mistake is **5 MHz/1 PPS loop
overload** - installing more BRs on the loop than it supports. The affected BRs
simply cannot sync. The fix is to reduce the number of BRs on the indicated line.
get ext_ref returning UNDEFINED. The expected answer is ENABLED.
UNDEFINED means the BRC's phase-lock circuit is in neither state - it is not
detecting or interpreting the external reference correctly. Given the section
above, this almost always points back to the 5 MHz/1 PPS feed on the backplane
connector (P13 or P24 depending on BR type) or to the reference source itself.
Treat it as an underlying cause, not a curiosity.
17.7 Reading status bts -l - the "No voice channel" trap
--------------------------------------------------------
--------------------------------------------------------------------
SC: status bts -l
Subsystem : EBTS
Trap State : (51) Site Trunking
Probable Cause : ( 3) No voice channel
Severity : Major
--------------------------------------------------------------------
Decoded:
* Site Trunking - the site is operating standalone, not connected to the core
* No voice channel - no traffic channels (TCH) are available
* Major - severe degradation of capability, urgent corrective action required
This is not the same failure as S:4 C:255. Here the site genuinely has no
usable traffic channels, almost always because the BR is not in service. Causes,
in rough order of likelihood:
1. Synchronisation - everything in 17.5. A BR that cannot sync cannot key,
and a BR that cannot key provides no channels.
2. BR faults or initialisation failures - TX initialisation and diagnostic
test failures. One documented specific cause is the **exciter Q offset not
being programmed to non-zero values**. Check get alarms on the BRC and the
front-panel LEDs.
3. Configuration or software download problems - newly installed BRs that
never enter service, local Ethernet loop misconfiguration, failed BR
application download.
4. Connectivity - the controller-to-BRC link. Internal site Ethernet
problems break BR management even when the RF side is fine.
Diagnostic order:
--------------------------------------------------------------------
status bts -l
status br
get alarms (on the BRC)
status sri
--------------------------------------------------------------------
The public write-up of this hardware-fault analysis, covering the power control
loop, the LPF detector, METERING_DIAGNOSTICS and the sync failures above, is
here:
--------------------------------------------------------------------
https://radiofarafiltru.blogspot.com/2026/01/
conversatie-cu-ai-notebook-lm-despre.html
--------------------------------------------------------------------
| **Summary of the distinction, because it is the single most useful thing in
| this section:**
|
| * get alarms clean + BR keyed + Wide Trunking + S:4 C:255 -> **core / firmware
| compatibility.** Go to Section 9.
| * Alarms present, or BR not keying, or status bts showing Major/Critical
| -> local hardware or synchronisation. Stay in this section.
---
==========================================================================
18. E1, FRAME RELAY AND PIM FAULT DECODER
==========================================================================
The value of this chapter is that it reads the same link from both ends.
Almost every wasted evening on an EBTS site link comes from looking at one end
only and guessing about the other. Every symptom below tells you what the other
end should be showing at the same moment. Chapters 4 and 6 told you how to build
the link; this one tells you how to read it when it misbehaves.
18.1 The thirty-second triage
-----------------------------
Run these four, in this order, and stop at the first one that is wrong:
| # | Where | Command | Must say |
|---|---|---|---|
| 1 | Cisco | show controllers e1 0/0 | No alarms detected |
| 2 | Cisco | show interfaces serial0/0:0 | up, line protocol is up |
| 3 | Cisco | show frame-relay pvc | DLCI 16 and 17, both ACTIVE |
| 4 | TSC | status sc -all | Site Link State: UP, Netcom Primary: ACTIVE_S |
If all four are clean, the transport is fine. Anything still broken above this
layer is not an E1 problem, and no amount of re-cabling will help.
---
18.2 Which end owns what
------------------------
This table exists because getting it backwards produces slips, and slips look
like a cable fault.
| Parameter | Cisco (router) | TSC (site controller) |
|---|---|---|
| Clock | clock source internal - the router is the master | External / recovered from line |
| Framing | framing CRC4 | crc4 on |
| Line code | linecode HDB3 | HDB3 (fixed in normal operation) |
| Timeslots | channel-group 0 timeslots 1-31 | crdStart 1, crd 31, ts16Skip off |
| Frame Relay role | frame-relay intf-type dce | DTE |
| LMI | frame-relay lmi-type ansi | ANSI, LMI Enable checked |
| Fragmentation | frame-relay fragment 100 end-to-end | Frame Relay Fragmentation Size 100 |
| Line rate | 1984000 bps (31 x 64k) | 1984000 bps |
| Exactly one end supplies the clock. If both do, you get slip seconds. If
| neither does, you get loss of frame. On this link it is always the router.
---
18.3 Physical layer - decoding show controllers e1
--------------------------------------------------
18.3.1 The alarm words
| Cisco reports | What it means | What the TSC shows at the same time | Cause and action |
|---|---|---|---|
| No alarms detected | Healthy | Site Link State: UP | - |
| Receiver has loss of signal (LOS) | No electrical signal arriving | TSC is resetting, or its port is dead | First ask: did the TSC just reset? A TSC reset produces LOS while it reinitialises its framer, with zero bit errors. Two LOS events ~15 s apart right after a reset are normal. Persistent LOS with no reset is a cable or connector fault. |
| Receiver has loss of frame (LOF) | Signal present, framing cannot be found | Frame alignment loss counters climbing | Framing mismatch - one end CRC4, the other not. Or the timeslot map differs. |
| Receiver has remote alarm (RAI / yellow) | The far end is telling you it cannot frame on what we send | TSC reports its own receive problem | The fault is in our transmit pair, or in the TSC's receiver. Do not chase our receive side. |
| Transmitter is sending remote alarm | We cannot frame, so we are telling them | - | Mirror of LOF; fix our receive path. |
| AIS (all ones / blue) | Far end sending unframed all-ones | - | Usually an intermediate device in maintenance, or a TSC in an odd state. |
18.3.2 The counters - and why you must clear them first
Counters accumulate from boot. A router that has been up for two years will show
frightening numbers that mean nothing. Always:
--------------------------------------------------------------------
enable
clear counters Serial0/0:0
clear controller e1 0/0
--------------------------------------------------------------------
then wait at least 60 seconds before reading. A clean link accumulates zero
of everything in that minute.
| Counter | Zero expected? | If not zero |
|---|---|---|
| Line Code Violations (LCV) | Yes, absolutely | Genuine bit errors. Bad cable, split pair, bad connector, or wrong line code. This is the counter that distinguishes a broken cable from a rebooting TSC - a rebooting TSC gives you clean signal loss with zero LCV. |
| Path Code Violations (PCV) | Yes | CRC4 errors. Marginal cable, or a CRC4 mismatch between ends. |
| Slip Secs | Yes | Clocking. Two masters, or neither. Check clock source on both ends. |
| Fr Loss Secs | Yes | Framing instability, usually together with LOF. |
| Unavail Secs | Yes | Accumulates while the link is down. Non-zero after a clear means a real outage happened during your measurement. |
| Degraded Mins | Yes | Sustained low-level error rate - the classic signature of a split pair. |
| The single most useful diagnostic sentence in this chapter:
| *A bad cable produces bit errors. A rebooting TSC produces clean signal loss
| with zero bit errors.* Decide which one you have before touching anything.
18.3.3 The crossover cable
Repeated here from Chapter 4 so that this chapter stands on its own at the rack.
E1 over RJ45 uses two pairs. The cable must swap them.
| End A pin | End B pin | Function |
|---|---|---|
| 1 | 4 | TX ring -> RX ring |
| 2 | 5 | TX tip -> RX tip |
| 4 | 1 | RX ring -> TX ring |
| 5 | 2 | RX tip -> TX tip |
Pins 3, 6, 7, 8 unused. Keep 1/2 on one twisted pair and 4/5 on another. E1
is a 120 ohm balanced interface; a split pair still passes traffic and gives you an
error rate that drifts with temperature and cable movement, which is the most
frustrating fault in this entire document to track down.
---
18.4 Layer 2 - the serial interface and LMI
-------------------------------------------
18.4.1 The four states of show interfaces serial0/0:0
| State | Meaning | Where to look |
|---|---|---|
| up, line protocol is up | Healthy | - |
| up, line protocol is down | Layer 1 is fine, LMI is failing | Section 18.4.2. Do not go back to the cable. |
| down, line protocol is down | Layer 1 problem | Section 18.3 |
| administratively down | Someone shut it | no shutdown |
That second row is the important one. It tells you the electrical link is good
and the two ends simply are not agreeing on Frame Relay signalling. Cable
swapping at this point is wasted effort.
18.4.2 LMI decoding
--------------------------------------------------------------------
show frame-relay lmi
--------------------------------------------------------------------
| Reading | Meaning | Action |
|---|---|---|
| LMI enq sent rising, Num Status msgs Rcvd 0 | We are asking, nobody answers | Check frame-relay intf-type dce on the router and DTE on the TSC. Check lmi-type ansi on both. |
| Both rising together | Healthy | - |
| Num Status Timeouts rising | Intermittent - usually errors on the E1 | Go back to Section 18.3.2 |
| Both zero | LMI disabled somewhere | LMI Enable on the Site Router tab of TESS; frame-relay lmi-type on the router |
TSC-side equivalents:
--------------------------------------------------------------------
status lmi -r
status fr -r
status bsl -r
--------------------------------------------------------------------
Matching LMI timers, for reference: LMI LIV Time (t391) 300, error threshold
(n392) 3, full status polling counter (n391) 6, monitored events (n393) 4.
18.4.3 PVC status
--------------------------------------------------------------------
show frame-relay pvc
--------------------------------------------------------------------
| PVC STATUS | Meaning | Action |
|---|---|---|
| ACTIVE | The far end knows this DLCI and it is usable | - |
| INACTIVE | We know the DLCI, the far end is not answering on it | The TSC has the wrong DLCI configured, or has not finished booting |
| DELETED | The far end does not know this DLCI exists | DLCI mismatch. Primary must be 16, secondary 17 |
| DLCI missing entirely | Not configured on the router | Check the subinterfaces |
Both 16 and 17 must be ACTIVE. A site can run on the primary alone and look
almost healthy - until the primary hiccups and the failover has nowhere to go.
The TSC's own view:
--------------------------------------------------------------------
status fr -r
--------------------------------------------------------------------
should show the primary PVC ACTIVE and the secondary ACTIVE, and
status sc -all should show Netcom Primary: ACTIVE_S, Netcom Secondary:
STANDBY_S.
If you see Netcom Primary: GRANT_S with Secondary: ACTIVE_S, the site has
failed over to the backup PVC after an interruption on the primary. It usually
self-heals; recheck in a few minutes before intervening.
---
18.5 Layer 3 - addressing and PIM
---------------------------------
18.5.1 The addressing traps
Three of these have bitten real sites. All three produce a link that comes up
and a site that does not work.
| Parameter | Correct | Wrong value seen in the wild |
|---|---|---|
| BTS IP | 10.128.<SITE_ID>.1 | 10.128.10.1 copied verbatim from the example config for every site |
| PVC /30 | arithmetically consistent with your site number | a provisioning script generated site 36's subnet for site 37 |
| ZC primary / secondary | 10.1.231.1 / 10.1.232.1 | .255 - a firmware default that circulates in shared templates |
| Network Manager | 10.1.233.101 | 10.1.233.88 - that is the NTP server |
| RNG | 10.128.105.15 | 10.129.105.15 - transposed digit |
Verify from the TSC, not from your notes:
--------------------------------------------------------------------
display config -ip
--------------------------------------------------------------------
18.5.2 PIM
The overlay runs dense mode and has no rendezvous point.
--------------------------------------------------------------------
! CORRECT
ip pim dense-mode
! WRONG - silently blocks all core multicast
ip pim sparse-dense-mode
ip pim rp-address 192.168.250.254
--------------------------------------------------------------------
sparse-dense-mode with an unreachable RP is the worst kind of fault: nothing
logs an error, the link is up, the PVCs are active, and no traffic streams ever
arrive.
| Symptom | Meaning |
|---|---|
| show ip pim neighbor lists many neighbours, DR on the core gateway .254 | Healthy |
| All neighbours disappear at once | Your own bridge went down. Twenty independent sites do not fail in the same second. Check the Pi's uptime. |
| DR moves to your own router | Same event, seen from a different angle |
| %PIM-6-INVALID_RP_JOIN ... for invalid RP | Another operator still has rp-address configured. Severity 6, informational, harmless to you. Tell the core team which source IP it is coming from. |
| No neighbours ever appeared | Bridge never worked, or multicast snooping is on |
---
18.6 Cross-referenced symptom table
-----------------------------------
| Cisco says | TSC says | Diagnosis |
|---|---|---|
| No alarms, S0/0:0 up/up, both PVCs ACTIVE | Site Link UP, Wide Trunking | Transport perfect. Any remaining fault is above this layer. |
| LOS, zero LCV, two events 15 s apart | just rebooted | Normal. Ignore. |
| LOS, LCV climbing | Line Loss / Frame alignment loss climbing | Cable, connector, or split pair |
| up / line protocol down | Site Link DOWN | LMI mismatch - DCE/DTE or lmi-type |
| PVC 16 ACTIVE, 17 INACTIVE | secondary PVC down | Secondary DLCI or /30 wrong; site runs but has no redundancy |
| Both PVCs ACTIVE | Netcom Primary ACTIVE_S | Netcom is talking |
| Both PVCs ACTIVE, PIM neighbours present | Wide Trunking reached, but PTT gives S:4 C:255 | Not a transport problem. On this core that signature means R5.x firmware on the TSC/BRC. Upgrade to R8. |
| Slip seconds accumulating | intermittent link errors | Two clock masters, or none |
| Everything clean, no PIM neighbours | Site Link UP but no wide-area traffic | Bridge, or sparse-dense-mode |
---
18.7 Command quick sheet
------------------------
Cisco (privileged mode)
--------------------------------------------------------------------
show controllers e1
show controllers e1 0/0
show interfaces serial0/0:0
show frame-relay lmi
show frame-relay pvc
show frame-relay map
show frame-relay fragment
show ip interface brief
show ip pim interface
show ip pim neighbor
show ip mroute count
show logging | include CONTROLLER|LINK|LINEPROTO|PIM
show version | include IOS|System image
!
clear counters Serial0/0:0
clear controller e1 0/0
--------------------------------------------------------------------
TSC (SC: prompt)
--------------------------------------------------------------------
status sc -all
status bts
status bsl -r
status fr -r
status lmi -r
status sri
status sri -gps
status br
display config -ip
display config -quick
ping 10.1.231.1
ping 10.1.232.1
--------------------------------------------------------------------
Re-declaring the E1, only if it is genuinely misconfigured - these commands set
exactly what a working site already has, so do not run them to "make sure":
--------------------------------------------------------------------
.sitelink -e1
.e1config -crc on -crdStart 1 -crd 31 -ts16Skip off -portNo 1
reset
--------------------------------------------------------------------
IOS image - see also Section 6.1
Frame Relay with fragmentation plus IP multicast means you need an advanced
feature set. Two known-good images for a 2600XM chassis:
| Image | Notes |
|---|---|
| c2600-adventerprisek9-mz.124-25d.bin | 12.4 mainline, final maintenance release. This is the reference build - show version reports C2600-ADVENTERPRISEK9-M ... Version 12.4(25d). |
| c2600-advsecurityk9-mz.124-15.t14.bin | 12.4(15)T14, also carries Frame Relay and PIM. Smaller, useful if flash or DRAM is tight. |
Check what is actually running before blaming anything else:
--------------------------------------------------------------------
show version | include IOS|System image|bytes of memory
dir flash:
--------------------------------------------------------------------
Confirm free flash and installed DRAM before copying a new image, and never
erase the running one until the replacement has verified.
---
18.8 The three sentences worth memorising
-----------------------------------------
1. **A bad cable produces bit errors; a rebooting TSC produces clean signal loss
with zero bit errors.**
2. **up / line protocol down means layer 1 is fine - go and look at LMI, not
at the cable.**
3. **If every PIM neighbour vanishes in the same second, the fault is at your
end of the bridge, not theirs.**
==========================================================================
19. DIAGNOSTIC SCRIPTS (READY TO COPY AND RUN)
==========================================================================
Two scripts, reproduced here in full so that this document is the only thing you
need to keep. Both are read-only: neither one configures anything. Copy the
code out of this chapter into a file, chmod +x it, edit the handful of marked
lines at the top, and run it.
They exist because the two most common site faults - a bridge that quietly died
and an E1 whose counters nobody has ever cleared - are both tedious to check by
hand and trivial to check by script.
19.1 zt-bridge-check.sh - is the ZeroTier bridge actually working?
------------------------------------------------------------------
Run this on the Pi, as root. It walks the whole chain in Chapter 5: the daemon,
network membership and authorisation, the allowManaged=0 rule, the bridge
members, the absence of an IP on br0, multicast snooping, whether the service
will survive a reboot, and whether frames are crossing at all. It also warns you
if unattended-upgrades is allowed to reboot the node, which is how one site in
this guide lost its bridge without anybody touching it.
--------------------------------------------------------------------
sudo ./zt-bridge-check.sh # full report
sudo ./zt-bridge-check.sh -q # only problems
sudo ./zt-bridge-check.sh -c 5 # also sample 5 s of live traffic
--------------------------------------------------------------------
Exit code 0 means healthy, 1 means warnings, 2 means broken - so it drops
straight into a cron job or a monitoring check.
Edit the four variables in the header block before first use.
--------------------------------------------------------------------
#!/bin/bash
#
# zt-bridge-check.sh - health check for a ZeroTier Layer-2 bridge fronting an
# EBTS site router.
#
# Verifies the whole chain: ZeroTier daemon, network membership, the
# allowManaged=0 rule, the bridge itself, multicast snooping, persistence
# across reboot, and whether frames are actually crossing.
#
# Usage: sudo ./zt-bridge-check.sh
# sudo ./zt-bridge-check.sh -q # only show problems
# sudo ./zt-bridge-check.sh -c 5 # capture 5 s of traffic
#
# Exit code 0 = all good, 1 = warnings, 2 = something is broken.
#
# ---------------------------------------------------------------------------
# EDIT THESE THREE LINES FOR YOUR SITE
# ---------------------------------------------------------------------------
BRIDGE="br0" # bridge interface name
ETH_IF="" # USB Ethernet dongle, e.g. enx00e04c361049
# leave empty to auto-detect from the bridge
CISCO_IP="" # site router IP on the overlay, e.g. 192.168.250.35
# leave empty to skip reachability tests
GATEWAY_IP="" # overlay gateway, e.g. 192.168.250.254
# ---------------------------------------------------------------------------
QUIET=0
CAPTURE=0
while getopts "qc:h" o; do
case "$o" in
q) QUIET=1 ;;
c) CAPTURE="$OPTARG" ;;
h) sed -n '2,20p' "$0"; exit 0 ;;
esac
done
RC=0
if [ -t 1 ]; then
G=$'\e[32m'; Y=$'\e[33m'; R=$'\e[31m'; B=$'\e[1m'; N=$'\e[0m'
else
G=; Y=; R=; B=; N=
fi
ok() { [ "$QUIET" -eq 1 ] || printf ' %sOK %s %s\n' "$G" "$N" "$1"; }
warn() { printf ' %sWARN%s %s\n' "$Y" "$N" "$1"; [ $RC -lt 1 ] && RC=1; }
bad() { printf ' %sFAIL%s %s\n' "$R" "$N" "$1"; RC=2; }
info() { [ "$QUIET" -eq 1 ] || printf ' %s\n' "$1"; }
head_() { [ "$QUIET" -eq 1 ] || printf '\n%s== %s ==%s\n' "$B" "$1" "$N"; }
if [ "$(id -u)" -ne 0 ]; then
echo "Run this with sudo - zerotier-cli and the bridge sysfs need root." >&2
exit 2
fi
printf '%sZeroTier L2 bridge check - %s on %s%s\n' \
"$B" "$(date '+%Y-%m-%d %H:%M:%S')" "$(hostname)" "$N"
# --------------------------------------------------------------- 1. the host
head_ "Host"
UP=$(cut -d. -f1 /proc/uptime)
info "uptime: $((UP/86400))d $(((UP%86400)/3600))h $(((UP%3600)/60))m"
if [ "$UP" -lt 600 ]; then
warn "this node rebooted less than 10 minutes ago"
info "a recent reboot explains PIM neighbours dropping on the router"
fi
if [ -f /etc/apt/apt.conf.d/50unattended-upgrades ]; then
if grep -Eq '^[^/]*Unattended-Upgrade::Automatic-Reboot[[:space:]]+"true"' \
/etc/apt/apt.conf.d/50unattended-upgrades; then
warn "unattended-upgrades may reboot this node automatically"
info "that is how a site loses its bridge at 06:00 with no warning"
else
ok "automatic reboot not enabled"
fi
fi
# ---------------------------------------------------------- 2. the ZT daemon
head_ "ZeroTier"
if ! command -v zerotier-cli >/dev/null 2>&1; then
bad "zerotier-cli not installed"
else
if systemctl is-active --quiet zerotier-one; then
ok "zerotier-one is running"
else
bad "zerotier-one is NOT running"
fi
systemctl is-enabled --quiet zerotier-one \
&& ok "zerotier-one enabled at boot" \
|| warn "zerotier-one is not enabled at boot"
ZINFO=$(zerotier-cli info 2>/dev/null)
info "$ZINFO"
case "$ZINFO" in
*ONLINE*) ok "node is ONLINE" ;;
*) bad "node is not ONLINE - check UDP 9993 outbound" ;;
esac
NETS=$(zerotier-cli listnetworks 2>/dev/null | tail -n +2)
if [ -z "$NETS" ]; then
bad "not joined to any network"
else
echo "$NETS" | while read -r _ _ NID NAME MAC STATUS TYPE DEV REST; do
[ -z "$NID" ] && continue
info "network $NID ($NAME) status=$STATUS dev=$DEV"
case "$STATUS" in
OK) ;;
ACCESS_DENIED)
printf ' %sFAIL%s network %s: ACCESS_DENIED - node not authorised yet\n' "$R" "$N" "$NID" ;;
*) printf ' %sWARN%s network %s: status %s\n' "$Y" "$N" "$NID" "$STATUS" ;;
esac
AM=$(zerotier-cli get "$NID" allowManaged 2>/dev/null)
if [ "$AM" = "0" ]; then
printf ' %sOK %s allowManaged=0 on %s (correct - the Cisco owns the IP)\n' "$G" "$N" "$NID"
else
printf ' %sFAIL%s allowManaged=%s on %s - run: zerotier-cli set %s allowManaged=0\n' \
"$R" "$N" "$AM" "$NID" "$NID"
fi
done
# re-evaluate RC after the subshell
echo "$NETS" | grep -q " OK " || RC=2
for NID in $(echo "$NETS" | awk '{print $3}'); do
[ "$(zerotier-cli get "$NID" allowManaged 2>/dev/null)" = "0" ] || RC=2
done
fi
RELAYED=$(zerotier-cli peers 2>/dev/null | awk '$5=="RELAY" && $6=="PLANET"' | wc -l)
DIRECT=$(zerotier-cli peers 2>/dev/null | awk '$5=="DIRECT"' | wc -l)
info "peers: $DIRECT direct, $RELAYED relayed via planet roots"
[ "$DIRECT" -eq 0 ] && warn "no direct peers - all traffic is relayed, expect latency"
fi
# ------------------------------------------------------------- 3. the bridge
head_ "Bridge $BRIDGE"
if [ ! -d "/sys/class/net/$BRIDGE" ]; then
bad "$BRIDGE does not exist"
else
MEMBERS=$(ls "/sys/class/net/$BRIDGE/brif/" 2>/dev/null)
info "members: $(echo $MEMBERS | tr '\n' ' ')"
ZT_MEMBER=$(echo "$MEMBERS" | grep -c '^zt')
[ "$ZT_MEMBER" -ge 1 ] \
&& ok "a ZeroTier interface is enslaved" \
|| bad "no zt* interface in the bridge - the overlay is not connected"
if [ -n "$ETH_IF" ]; then
echo "$MEMBERS" | grep -qx "$ETH_IF" \
&& ok "$ETH_IF is enslaved" \
|| bad "$ETH_IF is NOT in the bridge"
else
ETH_IF=$(echo "$MEMBERS" | grep -v '^zt' | head -1)
[ -n "$ETH_IF" ] \
&& ok "physical member detected: $ETH_IF" \
|| bad "no physical interface in the bridge"
fi
[ "$(cat /sys/class/net/$BRIDGE/operstate)" = "up" ] \
&& ok "$BRIDGE is up" \
|| bad "$BRIDGE is not up"
ADDRS=$(ip -o -4 addr show dev "$BRIDGE" | awk '{print $4}')
if [ -z "$ADDRS" ]; then
ok "$BRIDGE has no IPv4 address (correct)"
else
bad "$BRIDGE has an IP: $ADDRS - remove it, the Cisco owns the address"
fi
SNOOP="/sys/devices/virtual/net/$BRIDGE/bridge/multicast_snooping"
[ -f "$SNOOP" ] || SNOOP="/sys/class/net/$BRIDGE/bridge/multicast_snooping"
if [ -f "$SNOOP" ]; then
if [ "$(cat $SNOOP)" = "0" ]; then
ok "multicast snooping disabled (correct for PIM dense-mode)"
else
bad "multicast snooping is ON - core multicast will be filtered"
info "fix: echo 0 > $SNOOP (and add it to your bridge script)"
fi
fi
STP="/sys/class/net/$BRIDGE/bridge/stp_state"
[ -f "$STP" ] && [ "$(cat $STP)" != "0" ] && \
warn "STP is enabled on $BRIDGE - 30 s forwarding delay on every restart"
for IF in $MEMBERS; do
[ "$(cat /sys/class/net/$IF/operstate)" = "up" ] \
|| bad "member $IF is not up"
done
if command -v bridge >/dev/null 2>&1; then
FDB=$(bridge fdb show br "$BRIDGE" 2>/dev/null | grep -vc permanent)
info "learned MAC entries in the forwarding database: $FDB"
[ "$FDB" -lt 2 ] && warn "almost nothing learned - is the Cisco plugged in and up?"
fi
fi
# --------------------------------------------------------- 4. persistence
head_ "Persistence"
if systemctl list-unit-files 2>/dev/null | grep -q '^zt-bridge.service'; then
systemctl is-enabled --quiet zt-bridge.service \
&& ok "zt-bridge.service is enabled - the bridge survives a reboot" \
|| bad "zt-bridge.service exists but is NOT enabled"
systemctl is-active --quiet zt-bridge.service \
|| warn "zt-bridge.service is not active (oneshot units may show inactive; check RemainAfterExit=yes)"
else
warn "no zt-bridge.service found"
info "without it the bridge is gone after the next power cut"
fi
# ------------------------------------------------------- 5. reachability
head_ "Reachability"
if [ -n "$CISCO_IP" ]; then
if command -v arping >/dev/null 2>&1; then
if arping -c 2 -w 3 -I "$BRIDGE" "$CISCO_IP" >/dev/null 2>&1; then
ok "$CISCO_IP answers ARP across the bridge"
else
warn "no ARP reply from $CISCO_IP on $BRIDGE"
info "the Pi has no IP here, so a silent ARP probe is the only test available"
fi
else
info "install arping (apt install iputils-arping) for an L2 reachability test"
fi
if command -v bridge >/dev/null 2>&1 && [ -n "$ETH_IF" ]; then
bridge fdb show br "$BRIDGE" 2>/dev/null | grep -q "dev $ETH_IF" \
&& ok "MACs learned on $ETH_IF - the router side is alive" \
|| warn "nothing learned on $ETH_IF"
fi
else
info "CISCO_IP not set, skipping"
fi
# --------------------------------------------------------- 6. live traffic
if [ "$CAPTURE" -gt 0 ]; then
head_ "Traffic (${CAPTURE}s)"
if command -v tcpdump >/dev/null 2>&1; then
OUT=$(timeout "$CAPTURE" tcpdump -i "$BRIDGE" -n -c 200 2>/dev/null)
TOTAL=$(echo "$OUT" | grep -c .)
PIM=$(echo "$OUT" | grep -ci 'PIMv2\|proto 103')
info "frames seen: $TOTAL PIM: $PIM"
[ "$TOTAL" -eq 0 ] && bad "no traffic at all on $BRIDGE"
[ "$PIM" -eq 0 ] && [ "$TOTAL" -gt 0 ] && \
warn "traffic present but no PIM - check dense-mode on the router subinterfaces"
else
info "tcpdump not installed"
fi
fi
# -------------------------------------------------------------- verdict
printf '\n'
case $RC in
0) printf '%sBridge healthy.%s\n' "$G" "$N" ;;
1) printf '%sBridge working, with warnings above.%s\n' "$Y" "$N" ;;
2) printf '%sBridge is broken - see FAIL lines above.%s\n' "$R" "$N" ;;
esac
exit $RC
--------------------------------------------------------------------
19.2 cisco-e1-diag.exp - a full E1 / Frame Relay / PIM snapshot
---------------------------------------------------------------
Run this from any machine that can reach the router. It logs in, collects
everything in Section 18.7 into a timestamped transcript, and then reads that
transcript back and tells you what is wrong in plain language: line code
violations, slip seconds, PVC states, sparse-dense-mode, missing PIM
neighbours, and whether the controller-down events in the log look like a
rebooting TSC or a failing cable.
--------------------------------------------------------------------
apt install expect
./cisco-e1-diag.exp -host 192.168.88.10 -pass VTYPASS -en ENABLEPASS
./cisco-e1-diag.exp -serial /dev/ttyUSB2 -en ENABLEPASS
./cisco-e1-diag.exp -host 192.168.88.10 -pass VTYPASS -en ENABLEPASS -clear
--------------------------------------------------------------------
-clear resets the E1 and serial counters, waits sixty seconds, and only then
samples. Use it. Without it you are reading counters that may have been
accumulating since the router was first switched on, and they will tell you
nothing about today.
The only writes it performs are those optional counter clears, which affect
statistics and nothing else.
--------------------------------------------------------------------
#!/usr/bin/expect -f
#
# cisco-e1-diag.exp - collect a full E1 / Frame Relay / PIM health snapshot
# from an EBTS site router and flag the obvious faults.
#
# Requires: expect (apt install expect)
# telnet for VTY access
# cu only if you use the serial console (apt install cu)
#
# Usage:
# ./cisco-e1-diag.exp -host 192.168.88.10 -pass VTYPASS -en ENABLEPASS
# ./cisco-e1-diag.exp -serial /dev/ttyUSB2 -en ENABLEPASS
# ./cisco-e1-diag.exp -host 192.168.88.10 -pass VTYPASS -en ENABLEPASS -clear
#
# -clear resets the E1 and serial counters first, waits 60 s, then samples.
# This is the only way to get a meaningful error rate. Without it you
# are reading counters that may have been accumulating since 2019.
#
# Output: ./cisco-e1-diag-YYYYmmdd-HHMMSS.log (full transcript)
# plus a short verdict on stdout.
#
# Nothing is configured. Every command below is read-only except the optional
# counter clears, which affect statistics only.
#
set host ""
set serial ""
set baud 9600
set vtypass ""
set enpass ""
set doclear 0
set timeout 30
for {set i 0} {$i < [llength $argv]} {incr i} {
set a [lindex $argv $i]
switch -- $a {
-host { incr i; set host [lindex $argv $i] }
-serial { incr i; set serial [lindex $argv $i] }
-baud { incr i; set baud [lindex $argv $i] }
-pass { incr i; set vtypass [lindex $argv $i] }
-en { incr i; set enpass [lindex $argv $i] }
-clear { set doclear 1 }
-h -
-help { send_user "see the header of this file for usage\n"; exit 0 }
}
}
if {$host eq "" && $serial eq ""} {
send_user "ERROR: give either -host <ip> or -serial <device>\n"
exit 2
}
set stamp [clock format [clock seconds] -format "%Y%m%d-%H%M%S"]
set logfile "cisco-e1-diag-$stamp.log"
log_file -noappend $logfile
send_user "Logging to $logfile\n\n"
# ---------------------------------------------------------------- connect
if {$serial ne ""} {
spawn cu -l $serial -s $baud
expect {
"Connected" {}
"Line in use" { send_user "\nERROR: $serial is busy - close your terminal program\n"; exit 2 }
timeout {}
}
send "\r"
} else {
spawn telnet $host
expect {
"Password:" { send "$vtypass\r" }
"Username:" { send_user "\nERROR: this router wants a username; edit the script\n"; exit 2 }
"refused" { send_user "\nERROR: connection refused - is telnet enabled on the vty lines?\n"; exit 2 }
timeout { send_user "\nERROR: no response from $host\n"; exit 2 }
}
}
# ------------------------------------------------------------ get enable
expect {
-re {[\r\n][^\r\n]*>$} { send "enable\r"; exp_continue }
"Password:" { send "$enpass\r"; exp_continue }
-re {[\r\n][^\r\n]*#$} { }
"Access denied" { send_user "\nERROR: wrong enable password\n"; exit 2 }
timeout { send_user "\nERROR: never reached the enable prompt\n"; exit 2 }
}
# stop the pager, or every command stops at --More--
send "terminal length 0\r"
expect -re {#$}
proc run {cmd} {
send "$cmd\r"
expect -re {#$}
}
# ------------------------------------------------------------ identity
run "show clock"
run "show version | include IOS|System image|uptime|bytes of memory|Configuration register"
run "show inventory"
# ---------------------------------------------- optional counter reset
if {$doclear} {
send_user "\n--- clearing counters, sampling in 60 s ---\n"
run "clear counters"
expect {
-re {confirm} { send "\r"; expect -re {#$} }
-re {#$} {}
}
run "clear controller e1 0/0"
send_user "waiting 60 s so the error rate means something...\n"
sleep 60
}
# ------------------------------------------------------------ layer 1
run "show controllers e1"
run "show controllers e1 0/0"
# ------------------------------------------------------------ layer 2
run "show interfaces serial0/0:0"
run "show frame-relay lmi"
run "show frame-relay pvc"
run "show frame-relay map"
run "show frame-relay fragment"
# ------------------------------------------------------------ layer 3
run "show ip interface brief"
run "show ip route"
run "show ip pim interface"
run "show ip pim neighbor"
run "show ip mroute count"
run "show ip mroute"
# ------------------------------------------------------------ history
run "show logging | include CONTROLLER|LINK|LINEPROTO|PIM|FR"
run "show processes cpu | include CPU utilization"
send "exit\r"
expect eof
log_file
# ============================================================== analysis
send_user "\n"
send_user "==========================================================\n"
send_user " Verdict\n"
send_user "==========================================================\n"
set fh [open $logfile r]
set t [read $fh]
close $fh
set problems 0
proc bad {m} { global problems; incr problems; send_user " \[FAIL\] $m\n" }
proc warn {m} { send_user " \[WARN\] $m\n" }
proc good {m} { send_user " \[ OK \] $m\n" }
# --- E1 physical -------------------------------------------------------
if {[regexp {No alarms detected} $t]} {
good "E1: no alarms detected"
} else {
foreach {pat msg} {
{Receiver has loss of signal} "E1 LOS - no signal from the TSC. Cable, or the TSC is resetting."
{Receiver has loss of frame} "E1 LOF - signal present but framing wrong. Check CRC4 on both ends."
{Receiver has remote alarm} "E1 RAI - the far end cannot see us. Check our transmit pair."
{Transmitter is sending remote alarm} "E1 sending RAI - we cannot frame on the received signal."
{AIS} "E1 AIS - all-ones from the far end."
} {
if {[regexp $pat $t]} { bad $msg }
}
if {$problems == 0} { warn "E1: could not confirm 'No alarms detected' - read the log" }
}
if {[regexp {Line Code Violations,\s*(\d+)} $t -> lcv]} {
if {$lcv > 0} {
bad "E1: $lcv line code violations - genuine bit errors, suspect the cable or a split pair"
} else {
good "E1: zero line code violations"
}
}
if {[regexp {Path Code Violations,\s*(\d+)} $t -> pcv]} {
if {$pcv > 0} { warn "E1: $pcv path code violations (CRC4 errors)" }
}
if {[regexp {(\d+) Slip Secs} $t -> slip]} {
if {$slip > 0} { bad "E1: $slip slip seconds - a clocking problem. Exactly one end must be 'clock source internal'." }
}
if {[regexp {clock source is internal} $t] || [regexp {Clock Source is Internal} $t]} {
good "E1: this router provides the clock (correct - the TSC should be External)"
}
# --- serial / frame relay ---------------------------------------------
if {[regexp {Serial0/0:0 is up, line protocol is up} $t]} {
good "Serial0/0:0 up/up"
} elseif {[regexp {Serial0/0:0 is up, line protocol is down} $t]} {
bad "Serial0/0:0 up but line protocol DOWN - LMI is failing, layer 1 is fine"
} elseif {[regexp {Serial0/0:0 is down} $t]} {
bad "Serial0/0:0 is down - fix layer 1 first"
}
if {[regexp {LMI enq sent\s+(\d+)} $t -> sent] && [regexp {Num Status msgs Rcvd\s+(\d+)} $t -> rcvd]} {
if {$rcvd == 0} {
bad "LMI: $sent enquiries sent, none answered - check 'frame-relay intf-type dce' and lmi-type ansi"
} else {
good "LMI exchanging ($sent sent / $rcvd received)"
}
}
if {[regexp {Num Status Timeouts\s+(\d+)} $t -> to]} {
if {$to > 0} { warn "LMI: $to status timeouts recorded" }
}
set nactive 0
foreach m [regexp -all -inline {PVC STATUS = (\w+)} $t] {
if {$m eq "ACTIVE"} { incr nactive }
}
foreach dlci {16 17} {
if {[regexp "DLCI = $dlci," $t]} {
good "DLCI $dlci present"
} else {
bad "DLCI $dlci missing from the PVC table"
}
}
if {[regexp {PVC STATUS = INACTIVE} $t]} {
bad "at least one PVC is INACTIVE - the TSC is not answering on that DLCI"
}
if {[regexp {PVC STATUS = DELETED} $t]} {
bad "a PVC is DELETED - the far end does not know about that DLCI at all"
}
# --- PIM ---------------------------------------------------------------
if {[regexp {sparse-dense-mode} $t]} {
bad "PIM sparse-dense-mode found - this network is DENSE mode. Core multicast will be blocked."
} elseif {[regexp {[Dd]ense} $t]} {
good "PIM dense-mode"
}
if {[regexp {rp-address} $t]} {
bad "an ip pim rp-address statement is present - remove it, there is no RP"
}
set nbrs [llength [regexp -all -inline {\n\S+\s+Serial|\n\S+\s+FastEthernet} $t]]
set nbrcount 0
foreach line [split $t "\n"] {
if {[regexp {^\s*\d+\.\d+\.\d+\.\d+\s+(FastEthernet|Serial)} $line]} { incr nbrcount }
}
if {$nbrcount == 0} {
bad "no PIM neighbours at all - suspect your own ZeroTier bridge before the network"
} elseif {$nbrcount < 3} {
warn "only $nbrcount PIM neighbour(s) visible"
} else {
good "$nbrcount PIM neighbours"
}
if {[regexp {INVALID_RP_JOIN} $t]} {
warn "%PIM-6-INVALID_RP_JOIN messages present - other sites are still misconfigured. Informational, not yours to fix."
}
# --- log history -------------------------------------------------------
set losn 0
foreach line [split $t "\n"] {
if {[regexp {CONTROLLER-5-UPDOWN.*down} $line]} { incr losn }
}
if {$losn > 0} {
warn "$losn controller down events in the log"
send_user " two events ~15 s apart right after a TSC reset are normal;\n"
send_user " persistent flapping with rising LCV is a cable fault\n"
}
send_user "\n"
if {$problems == 0} {
send_user " Nothing broken found on the router side.\n"
send_user " If PTT still fails with S:4 C:255, the transport is fine and the\n"
send_user " problem is above it - check TSC/BRC firmware (R5.x is not compatible).\n"
exit 0
} else {
send_user " $problems problem(s) found. Full transcript in $logfile\n"
exit 1
}
--------------------------------------------------------------------
19.3 What a clean run looks like
--------------------------------
The router script ends with either
--------------------------------------------------------------------
Nothing broken found on the router side.
If PTT still fails with S:4 C:255, the transport is fine and the
problem is above it - check TSC/BRC firmware (R5.x is not compatible).
--------------------------------------------------------------------
or a list of [FAIL] lines and a pointer to the transcript. That first message
is the useful one: it is the script telling you to stop working on the network
and go and read Chapter 9.
==========================================================================
20. APPENDIX A - MMI COMMAND REFERENCE
==========================================================================
TSC - application mode (SC:)
----------------------------
| Command | Purpose |
|---|---|
| ver / ver -h / ver -all | Software and hardware version |
| attrib | Show component flags |
| attrib -n <file> | Mark a file "use next" |
| attrib -v <label> <file> | Set a version label |
| attrib -bare | Same, without paging |
| dir / dir -all | Flash file system listing |
| display config -ip | All IP parameters |
| display config -quick | Summary configuration |
| status sc -all | Site controller and site link state |
| status bts | Subsystem state table |
| status bsl -r | Base site link (E1) statistics |
| status fr -r | Frame relay PVC status |
| status lmi -r | LMI status |
| status sri / status sri -gps | Site reference and GPS detail |
| status br | Base radio summary |
| status ntp | NTP client state (R8) |
| diag | Enter diagnostics menu |
| ping <ip> | ICMP test |
| reset | Reset the site controller |
| reset -ebts | Reset the whole EBTS |
| invalidate <file> | Invalidate a stored file |
| bts_type | Show BTS type |
| lock / unlock | Lock or unlock the site |
TSC - monitor mode (SC#)
------------------------
| Command | Purpose |
|---|---|
| run | Leave the monitor and start the application |
| attrib | Same flag management as above |
| dir | Flash listing |
| sitelink -x21 \| -e1 | Select the site link type |
| e1config ... | Configure the E1 port |
| test -all | Peripheral self-tests |
| load / go | Load and execute an image over Ethernet |
| ver -all | Monitor and platform version |
BRC (BRC>)
----------
| Command | Purpose |
|---|---|
| get info | Firmware, revisions, frequencies, power |
| get config | Cell configuration |
| get hw_config | Board type and memory |
| get alarms | Active alarms |
| get fwd_pwr / get ref_pwr / get vswr | RF measurements |
| get rssi <rx> <n> | Receive level and BER |
| get pa_scaling_factor <0-11> | PA A/D scaling |
| set pa_scaling_factor <port> <value> | Change it (RAM, or EEPROM with Factory access) |
| get max_pwr_deviation | Power levelling tolerance |
| get tx_freq / get rx_freq | Frequencies |
| chanstat | Live TDMA slot state |
| cs | Channel setup / timeslot occupancy |
| dekey | Stop transmitting |
| reset | Reset the base radio |
---
==========================================================================
21. APPENDIX B - KNOWN-GOOD PARAMETER TABLE
==========================================================================
Reference values from a fully working site. Substitute your own where marked.
--------------------------------------------------------------------
--- Identity ---------------------------------------------------------------
BTS Site ID <SITE_ID>
BTS Zone ID <ZONE_ID>
Mobile Country Code as issued
Mobile Network Code as issued
Colour Code 1
System Code 1
--- Master Site ------------------------------------------------------------
Link Recovery Timer 5 s
Primary PVC DLCI 16
Secondary PVC DLCI 17
ZC primary IP 10.1.231.1 / 255.255.255.0
ZC secondary IP 10.1.232.1 / 255.255.255.0
BTS primary IP 10.128.<SITE_ID>.1 / 255.255.255.0
--- Network Management -----------------------------------------------------
Network Manager IP 10.1.233.101
Network Manager Port 162
Zone Manager Port 161
--- Site Link --------------------------------------------------------------
Primary PVC BTS IP 172.24.<x>.142 / 255.255.255.252
Secondary PVC BTS IP 172.24.<y>.142 / 255.255.255.252
Netcom Outbound UDP Port 1050
Netcom Inbound UDP Port 1051
Primary PVC Recovery Timer 30 s
--- Packet Data ------------------------------------------------------------
PD Port Number 10130
RNG IP Address 10.128.105.15
--- SDTS -------------------------------------------------------------------
SDR TCP Port 4176
Max Segment Size 512
TCP Socket Buffer 8192
--- Voice ------------------------------------------------------------------
Voice Port Number 10120
Receive voice 2 Interfaces
--- NTP (R8 only) ----------------------------------------------------------
Primary NTS IP 10.1.233.88
Secondary NTS IP 0.0.0.0
Frequency lock allowed No
--- Site Router ------------------------------------------------------------
LMI enable Enabled
LMI LIV time (t391) 300
LMI error threshold (n392) 3
LMI full status polling (n391) 6
LMI monitored events (n393) 4
ToS Latency Time 5000
FR fragmentation size 100
--- E1 ---------------------------------------------------------------------
crc4 on
crdStart 1
crd 31
ts16Skip off
Port 1
Clock (TSC side) External
Clock (Cisco side) Internal
Speed 1984000 bps
--- Firmware ---------------------------------------------------------------
TSC application PR3_TSC_APP-R08.02.29
TSC monitor PR3_TSC_MON-R01.30.00
BRC application R08.02.15 BRC_APP
BRC ROM R07.00.18
BRC board PR20, 25 MHz / 16 MByte
--- BRC calibration (patched into firmware) --------------------------------
PA_PORT0 site-specific (4.0 in our case)
PA_PORT1 site-specific (-9.0 in our case)
max_pwr_deviation 3.0 dB
--------------------------------------------------------------------
---
==========================================================================
CLOSING NOTE
==========================================================================
The difficult part of this project was not any single step. It was that the
system fails in a way that looks like a configuration problem: the link comes
up, the radios register, everything reports healthy, and only the final resource
allocation quietly refuses. Every instinct says to check addressing again.
Check the firmware version first.
73
Niciun comentariu:
Trimiteți un comentariu