|
Posted by Stink on January 16, 2007, 7:34 am
If you were Registered and logged in, you could reply and use other advanced thread options
Two PRI's SLIPD counts on both increment one after the other. USLec
states there is no problem on their end. This all started after
lightning strike took out one of the PRI cards. Replaced along with
Clock Controller.
We go directly from the Smart Jack to the PRI Card (No CSU's)
Any Ideas would be greatly apprectiated.
DTA0015 Frame Slip--tracking--maintenance limit
DTA0016 Frame Slip--tracking--out-of-service limit
DTA0029 Non-tracking frame slip rate improvement criterion is met.
Trunks being returned to service.
Output from Console:
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA016 1
DCH: 21 RLS RED ALRM TIME: 6:43:56 16/01/2007
DTA029 1
DCH: 21 RLS CTS DOWN TIME: 6:45:58 16/01/2007
DTA015 1
DCH: 21 EST REMOTE TIME: 6:46:12 16/01/2007
DTC103
DTA015 1
DTA015 1
AUD000
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
TIM000 07:00 16/1/2007 CPU 0
DTA015 1
DTC103
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
DTA015 1
AUD000
DTA021 1
DCH: 21 RLS RED ALRM TIME: 7:16:52 16/01/2007
DTC103
|
  | |
Posted by John 807 on January 16, 2007, 5:13 pm
If you were Registered and logged in, you could reply and use other advanced thread options
I would put in CSU's to start (where I am telco won't even take you
seriously with out them) I would also look at whatever you are using for
the D-channel since you don't state what type of cards you are using it
might be worth trying the D-channel card first.
John 807
> Two PRI's SLIPD counts on both increment one after the other. USLec
> states there is no problem on their end. This all started after
> lightning strike took out one of the PRI cards. Replaced along with
> Clock Controller.
>
> We go directly from the Smart Jack to the PRI Card (No CSU's)
>
> Any Ideas would be greatly apprectiated.
>
> DTA0015 Frame Slip--tracking--maintenance limit
> DTA0016 Frame Slip--tracking--out-of-service limit
> DTA0029 Non-tracking frame slip rate improvement criterion is met.
> Trunks being returned to service.
>
> Output from Console:
>
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA016 1
> DCH: 21 RLS RED ALRM TIME: 6:43:56 16/01/2007
> DTA029 1
> DCH: 21 RLS CTS DOWN TIME: 6:45:58 16/01/2007
> DTA015 1
> DCH: 21 EST REMOTE TIME: 6:46:12 16/01/2007
> DTC103
> DTA015 1
> DTA015 1
> AUD000
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> TIM000 07:00 16/1/2007 CPU 0
> DTA015 1
> DTC103
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> DTA015 1
> AUD000
> DTA021 1
> DCH: 21 RLS RED ALRM TIME: 7:16:52 16/01/2007
> DTC103
>
|
|
Posted by Bob on January 17, 2007, 12:15 am
If you were Registered and logged in, you could reply and use other advanced thread options
> Two PRI's SLIPD counts on both increment one after the other. USLec
> states there is no problem on their end. This all started after
> lightning strike took out one of the PRI cards. Replaced along with
> Clock Controller.
>
> We go directly from the Smart Jack to the PRI Card (No CSU's)
>
> Any Ideas would be greatly apprectiated.
>
First, do an ssck 0 in LD 60. See if you are tracking, or free run, and if
there is tracking errors.
You might just need to do a trck pck.
Also, you might have a defective replacement clock controller, or PRI card.
Is it TMDI or regular?
Next make sure that the clock controller is on the PRI on the correct
slot..... Pref might be slot 1, while the CC is on the card in slot 2.
You should be able to swap the PRI cards, and put the CC on the older PRI
card. This would rule out (or in) the PRI card as being the source of the
problem. If the PRI card isn't providing timing to the CC, you should have
an error when you do a ssck 0. Make sure the CC is on the PRI card in the
correct slot if you swap things.
If you disable the CC (dis cc 0), does the CC status light change on the PRI
card?
Here's how things are supposed to work as a deep level: The PRI card
extracts a timing reference from the incoming T1. It provides a clock
(frequency) to the Clock controller. The clock controller uses on onboard
computer to match it's oscillator to the extracted clock (phase lock). The
clock controller takes the output of this oscillator, and provides it back
out to the backplane of the switch. The switch synchs all the codecs, and
DTI/PRI cards to this clock source that was ultimately derived from the
incoming T1. The end result should be that the transmit timing on all the
PRI cards is in synch with whatever T1 is used as the reference.....
So, the point of the problem could be no clock from the PRI card to the CC
(CC error when ssck 0'd), clock controller can't interpret the clock it's
given (CC error when ssck 0'd), CC can't control onboard oscillator
(different CC error when ssck 0'd), CC locks, but timing doesn't make it to
backplane of switch due to burned trace, line getting dragged down by
somthing else damaged by lightning, but not replaced (CC stats good, green
light on faceplate, and maybe you get DTC10x, etc) This would result in
massive timing slips, which is what might be wrong. Generally, even if a
switch is free-running, it doesn't slip so bad that it instantly kills the
T1.
As far as your NI (smartjack) PBX with no CSU arrangement goes, the CSU does
two things for you, so you should (and are legally (FCC) required to) have
one, but sometimes you can get away without one. It gives the Telco
something to loop back past their interface for testing, and subsequently
placing blame if they can loop the NI, but they can't loop a CSU. It also
provides a level of isolation (electrical) that you don't have. Depending on
the NI,and it's configuration, you may actually be connected to the incoming
cable pairs when the NI isn't looped. A CSU always has transformer isolation
from input to output. A CSU - or lack thereof (the plain-jane variety) has
nothing to do with timing slips. You might have framing hits, and BPV's, etc
if the level out of the NI isn't close enough to DSX, but it appears you
have a timing issue. Also, unless the whole CO were timing off frequency,
and you had T1's the went two different places - one on frequency, the other
not - you wouldn't see slips. If the CO was in free run, and you were
tracking properly, your switch would just blindly follow - even if they were
WAY (like 5 hz) off frequency.
Please report back.......
|
|
Posted by Stink on January 23, 2007, 9:09 am
If you were Registered and logged in, you could reply and use other advanced thread options
This all started after a lightning strike took out one of the PRI
Cards. We replaced the PRI card, Clock Controller & DChannel card.
(The PRI Cards are NOT the TMDI version) (System has two PRI Cards w/2
DChannels)
USLec came out with their test equipment and it shows the incoming
clocking frequency at 1544000 and the phone system frequency at 1543998
(2 Hz off). If the incoming frequency changes to 1544001 the phone
frequency shifts also to 1543999 again the 2 Hz off.
The CC is currently in Slot 1. During testing we moved it to slot 2,
Replaced with a different PRI card, CC card & DChannel card. We then
swapped out the cabinet and power supply. Still slipping.
The only thing left I can think of might be the ssc card. Any ideas?
Thanks,
StinkMan
|
|
Posted by Bob on January 23, 2007, 8:04 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> Bob,
>
> This all started after a lightning strike took out one of the PRI
> Cards. We replaced the PRI card, Clock Controller & DChannel card.
> (The PRI Cards are NOT the TMDI version) (System has two PRI Cards w/2
> DChannels)
>
> USLec came out with their test equipment and it shows the incoming
> clocking frequency at 1544000 and the phone system frequency at 1543998
> (2 Hz off). If the incoming frequency changes to 1544001 the phone
> frequency shifts also to 1543999 again the 2 Hz off.
>
> The CC is currently in Slot 1. During testing we moved it to slot 2,
> Replaced with a different PRI card, CC card & DChannel card. We then
> swapped out the cabinet and power supply. Still slipping.
>
> The only thing left I can think of might be the ssc card. Any ideas?
>
> Thanks,
> StinkMan
>
Regardless of what the test set shows, the frequency from telco IS 1544000.
Anything slightly different is just an inacuaracy in the test set timebase.
That's why the switch - even though it's 2 Hz low - appears to follow. When
you moved the CC to slot 2, did you change the reference data in LD 73 DDB?
Also, post the response you get when you do a ssck 0. The SSC isn't likely
to be the cause unless... But, then again, it's possible.
With no DTI (actually, no Clock Controller) in the system, the SSC generates
the timing clock used by the entire system.
The CC on the DTI/PRI card generates a more accurate (even before it is
tracking a T1) clock than the oscillator on the SSC. When a CC (and the
clock it generates) is present, the SSC is supposed to take that as an
input, and redistribute that clock. If the input to the SSC (or the
backplane is burned open) is damaged, it may never take that clock input. I
haven't seen this happen, and I have seen a fair number of lightning damaged
machines, but it's possible. One way to tell is to look at the transmit
frequency of the second PRI while you disable CC, and PRI and remove the
other card. If there isn't a significant change in frequency, and you've
swapped the CC and PRI card with a good one, you are likely dealing with a
SSC or backplane problem. The good news is, you can just move the
daughterboard, (and Ibutton) to another SSC, with no reinstall necessary.
Here's the catch though.... If you are running 25, or 3.0 (or up), make sure
that the SSC has the correct firmware on it, or it won't come up.
If you have no errors when you do a ssck 0, and if you can disable the CC
,and light the light on the DTI card, it's likely that the issue is SSC, or
backplane.
|
| Similar Threads | Posted | | Problems transfering calls to Call Pilot skillsets from internal Nortel BCMs | April 24, 2005, 11:51 pm |
| Help with PRI/DTI on Option11c | September 18, 2007, 10:55 am |
| Lost Passwords for Option11C | February 14, 2006, 10:18 pm |
| How to make Nortel Contivity Client auto reconnect on dropped connection? | March 28, 2006, 9:47 pm |
| ARN problems (rel 12.2) | September 7, 2005, 2:34 am |
| Contivity VPN Problems | May 12, 2005, 1:15 pm |
| VPN connectivity problems with Mac | June 22, 2005, 9:12 pm |
| Nortel VoIP problems | June 27, 2005, 11:20 am |
| i2004 to BCM50 Problems | August 25, 2005, 11:37 pm |
| Nortel Voicemail Problems | July 17, 2006, 4:09 pm |
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map