Just curious, but what voltage should I get out of the Smartjack?

Trying to debug a mysterious PRI that always "tests clean to the NIU".

Out I don't know as I've ever seen this. On the CO side there is a simplex current to power the repeaters. I've never heard of voltage on the drop side. I can tell you the level you should have and frequency, but that's about it. If it test clean to the NIU does it test clean to the CSU? Maybe one of the CO guy has your answer.

I'm trying to get the CO guy to call me so I can loop it up for him. Asterisk doesn't automatically loop the CSU when the CO issues a pattern test.

We used to get request all the time James to run to customer loop. So unless this is a working circuit I'd just loop it up and request they run to your loop. Most CSU's I've seen, even those built into a T-1 card have the option to loop up on the pattern commands, I said most I know there are those that don't, but you might want to see if the option is available to you. I know you know that stuff in an out, but it's possible.

Do you have capabilities of getting the T-1 status and error report?

Working on getting it out of them. This is a working circuit.

James is this a local T-1 or does it run over legacy AT&T network?

Are you able to Pull PM data out of your CSU?

Has whoever is testing your T-1 pulled the PM data from the NIU if equipped?

The AT&T switches used to store PM history.

So there should be several sources to non-intrusively pull error information.

Finally just what is the trouble?

Need to clarify something I stated about simplex current. I've been around awhile and I really don't believe there are line powered repeaters anymore. There used to be an extra charge to power the NIU via line current. I'm sure one of our CO types can verify this.

That's my big question too...

I think I should be able to find a voltage spec out of the NCTE (Network Channel Terminating Equipment; aka smart-jack) for ya if’in it would really help ya out at all. … In order to do that, I would need to have an idear on what kind it is though. Manufacture, model, type, part number, etc…

Nearly always the NCTE is line powered now days… I’m not a billing person what so ever so I’m not 100% positive on this but I’m pretty sure there’s only an additional charge if line power is REQUESTED.

Thanks Bryan. Never know in this day and age. I've been away from the hands on for awhile now.

The trouble is dropped calls and line disconnect messages. XO is swearing up and down that the problem is my system, cabling, CSU, phones, users, building, position of the moon. Reason I ask about the voltage passing out of the smart-jack is because it's just one less thing to test. I've run down everything else I could and am kind of just taking stabs in the dark here. It's kind of ridiculous the length's i'm going to but it's all in the name of good customer service I guess. Basically it's a smaller inbound call center that recieves around 300 calls per day, and they have been getting 3-5 dropped calls per day. The have also had issues with people attempting to call into the 800# from various area codes and getting call disconnect messages. They have re-broadcasted the route as it was found not all the different areas had gotten it the first time but they are still getting reports of this. Their latest stance is that it's my problem so now I am in the position of producing irrefutable evidence that their switch is A) issuing hang-up's to ME and B) that it's not even passing the call to me to decline. I do not know if I am on their Sonus soft-switch or their DMS-500, but I have another customer 30-minutes down the road with the same hardware set-up without issues. If there's any CO switch guys in the 386-676 area send me a PM, I might want to bribe you to take a peek at something

Here's what my CSU shows:
***** w1g1: T1 Alarms (Framer) *****

ALOS: OFF | LOS: OFF
RED: OFF | AIS: OFF
YEL: OFF | OOF: OFF

***** w1g1: T1 Alarms (LIU) *****

Short Circuit: OFF
Open Circuit: OFF
Loss of Signal: OFF


***** w1g1: T1 Performance Monitoring Counters *****

Line Code Violation : 3619
Bit Errors (CRC6/Ft/Fs) : 0
Out of Frame Errors : 0

Rx Level : > -2.5db


And my CSU/DSU config is as follows:
CSU/DSU w1g1 Configuration:
Media type T1
Framing ESF
Encoding B8ZS
Line Build 0db
Channel Base 1-24
Clock Mode Normal

Clock mode normal means CPE clock I.E. slave from PSTN. What I'm trying to figure out is where the line code violations are coming from. Do I think this is why someone from New Jersey cant call in? No. But it's the ONLY thing I see giving error's on my side.

Right now I've got PRI debugging enabled and am running a full D-Channel log so that way when the customer drops calls I can just send them the D-Channel log to give to XO so XO can explain why their switch issued a Cause Code 16 to mine (call-clearing/hang-up).

Looks like you can pull some pretty valuable info out of your CSU card.

How often are you getting the line code violations?

How long did it take to reach the count you're showing?

There could be a mux mis-optioned some place, but I would think you'd also get bit errors.

If there is a mux mis-optioned it should show up when Telco does an all zero's test. Bad repeater should show up on an all one's test.

Does your system allow you to clear the counters for the bipolar (line coding) violations? If so, reset the counters, and monitor how rapidly they are accumulating. If they are accumulating very rapidly, see if XO will send someone out to check their smartjack (tell them they need to check for a "dirty jack").

I've encountered bipolar errors in the past, similar to what you're experiencing, but the errors were accumulating very rapidly. It turned out to be caused by a faulty connection between a PRI card and it's smartjack/chasis. The card was simply reseated, we cleared the counters again, and no bipolar errors have been recorded eversince. The provider referred to this type of cause as "a dirty jack".

At least see if you can clear the counters to see how rapidly they are accumulating. Since this symptom is intermittent, see if the customer can provide any types of patterns whatsoever which may help out in narrowing this down.

Good point Mike. BPV's usually indicate a bad termination some place and it they aren't showing up at the Telcom equipment and just yours that will narrow it down.

Yes, I can clear stats. Those stats are from about 2am this morning. I have been trying to get the XO switch tech to call me so that I can loop the card for the reasons you mentioned bill.

Mike: I'll just try reseating the card shortly before I reset the stat's. If that's the fix then I owe you some beers.

Here's one more debug screen, but it shows no errors.
------------------------------------------------------
w1g1: AFT COMMUNICATION ERROR STATISTICS
------------------------------------------------------

RX Stats:
Number of receiver overrun errors: 0
Number of receiver CRC errors: 0
Number of receiver Abort errors: 0
Number of receiver corruption errors: 0
Number of receiver PCI errors: 0
Number of receiver DMA descriptor errors: 0
TX Stats:
Number of transmitter PCI errors: 0
Number of transmitter PCI latency warnings: 0
Number of transmitter DMA descriptor errors: 0
Number of transmitter DMA descriptor length errors: 0


You can ignore the PCI and DMA lines, as they relate to the card interfacing to the computer.

I believe my problem is the routing at XO's end, not my system, like I said. Problem is I'm just going to have to prove it the hard way I guess.

Well I did a lil’ lookin’ and I don’t think this will be much help, especially after reading your latest post. I could not find anything that states output towards the customer in the form of voltage…

There are VERY rare examples of units that can put a very small amount of voltage out to power a shelf. That was in the range of 2 v p-p.

Everything for the output of DS1 smart-jacks are really stated in the form of dB (decibels) those can range from -0.0 dB to -15 dB outputs.

I did a couple calculations to come up with:
-0.0 dB = about .77 Vrms
-7.5 dB = about .32 Vrms
-15 dB = about .13 Vrms

A VOM is really not an accurate measurement at all really to determine quality of the signal.

Thanks for the follow-up. Now I can say I know

WOW…. .This post is flying… I’s a lil’ behind (like always) with that last post.

I’m thinkin’ Mike is on to something there. With that many BPV’s in less than 24 hours something physical is junkin’ your signal.

If that turns out to be the case with the relatively small number of dropped calls I’d call that one “naughty jack” not so much dirty.

:toast:

Hello Gents.

Quick technicalnote. The Telco must remain compliant with ANSI standard T1.403 that stipulates that the network shall not place any DC voltages on the CPE side of the network interface. T1 NIU's (Smartjack) deployed since the mid 1990's no loger had the capability to support span thru powering. I worked on the Tansmission Engineering Staff at Verizon NY, and as a technical and operational member of the T1 NIU & HDSL RFP cross funtional teams, I added the ANSI requirement to remove span thru powering voltages to cross over the network interface (NI) AKS: Demarc.

Removal of span powering voltage to power customer CSU's was also mandated in the legacy FCC interconnection rules found in FCC part 68. The FCC Part 68 requirement went into effect in December 18th, 1989. ANSI T1.403 included the FCC requirement.

Regarding to the logging of incoming BPV's (CV-L), that is an indication of a physical problem at the CSU end of the DS1 circuit, and limited to the metallic T1 portion of the circuit between a LEC local MUX/ or SDL RT unit, assuming such a design, and the customer NI.

I find it interesting that no CRC-6 errors were reported by the CSU. A mis-optione MUX low speed card AMI, where it should be B8ZS, will not produce BPV's, but should register Excessive Zeros if such a PM register exists.

In all Westell T1 NIU's, and Pairgain 2W HDSL equipment, there is an option I specified to show B8ZS seconds. This is a 15 minute bucket that will indicate the presence of B8ZS from both the CPE & Network directions. It is intended to help diagnose a B8ZS/AMI line code misoption.

If there is access to the NIU or the HDSL Remote unit, a F-M DB9 cable connected to a PC serial port, withthe PC running a VT100 terminal emulation application (Procom/Hyperterm), will provide some additional clues as to where any errors may exist.

Second, insure that with a ISDN-PRI, the local PBX is taking timing from the service provider (XO), and is not in Master/Internal/Free Run clock mode.

Regards,

Field Ops
32 years & out

Well I made a big enough stink at XO that they had one of their line engineers sit down and look at the last mile. He found some issues with a repeater and they are supposively rolling a truck today (saturday) to replace the repeater at some point.

No, I did not talk to the engineer, they opted to call a customer who probably dilluted the message so much it doesn't resemble what they actually said. The "proof" in the pudding will be if I log a d-channel drop/red-alarm at some point during normal hours tomorrow. I can only assume the repeater is on the TX side as i'm not registering any errors on the RX.

Yes, is is configured for normal (CPE) timing, meaning it receives timing from the line. I plan to take a swing by their place monday, plug into the smartjack, see what I can see, reseat it, test the cable, reterminate the cable, retest the cable, and see if my BPV's go away.

If there is a regen (Repeater) on the circuit, the active side will be in the CSR to CO direction. This assumes a T1 NIU that wold be span powered from the same repeater. Of possibly HDSL.

Most tech's change out a component, and when it restores, leave without any further analysis. Unfortunately a good number of Telco tech's do not look at the performance monitoring data that has been collected on both T1 NIU-PM units, or, on HDSL equipment.

At a minimum there are seven days of PM data, plus the current 24 hour period, available to analyze. This would help determine if there were incoming T1 circuit errors based on BPV line (CV-L) or CRC6 path (CV-P) errors.

The key is being able to detect error conditions, especially those that may be transient in nature. The D channe log is helpful from the PBX end, but knowing if there is an inbound trouble helps focus resources. The LEC switch shold havethe capability to monitor the D channel status. Not very fancy, but the camp on monitor available to the %e does help. Now the task si to get the LEC to turn on the D channel monitor at the switch. Or at best, place a protoco analyzer at the CO switch DSX-1 and monitor/trap D channel messages.

If you can get them, LEC, to recognize that a trouble exists on their side ofthe NI, the circuits may get fixed.

Good luck.

Field OPS

Good luck.

James -
What's the distance between the smart jack, the CSU and your box? What kind of cables? I ran into some weird issues that seemed like timing, but turned out to be cable length, posted here:
https://www.sundance-communications.com/forum/ultimatebb.php?/ubb/get_topic/f/17/t/000208.html

I've got issues with Airespring not publishing the right routing information, but never had any issues with dropped calls. The people who can't call us say they get busies, (some report fast and some report slow) or operator intercepts. Airespring pins it on us to tell them which carriers can't call us, but that's an impossible task, of course.

Cable length from Smart Jack to Box is about 25'.

XO replaced the repeater on the line and I've been running fine since. Not 100% sure why a repeated would cause the D-Channel to hang-up either. I guess if things are working then i'm content in not knowing why, atleast this time.

I'm still getting BPV's on the line but I just haven't been in that area to reset the card and reterminate the cable.

Remember what the guy said about memory in telco smartjack. 1 week/24 hr summarys. I used to work on the cable lines outside. A quick fix was to re-seat the T1 card. If it took too many errors its buffer would fill and start dropping.Some I was back the next day or week, and others never(bad telco line or bad seat in box) . If its the D all calls would drop. Do all active callers get dropped at once? As for incoming, If it is PRI you could have colliding B channels(busy or mis-directed calls). Your switch should be on DESEND, b8zs, and have the same number of B channels turned up as telco. They will be ACSEND.(handing out B's) Calls come in on 1 out on 23, unless 2 try at once to get 1 or 23. Otherwise report to serving telco- this number cannot call your number. You need example. and make trouble report to ask for un-intrusive monitor if established calls drop. I've seen bad repeaters too.

PS-voltage in to smartjack can be 130v to ground-voltage out you may see nothing or a very small ,like 2 volts to ground. You'll think your meter is broke. Its never been of any value to find trouble to me. They become transmit and receive pairs.

Kumba:

Ifthe LEC replaced a T1 Regen, more than likely if that did clear your trouble, it is an indication of a possible fault condition in the LEC's receive into the switch. Unless a protocol analyzer were placed on the PRI circuit to monitor Q.931 call set up protocol messages between your switch, and the LEC (Call failures or link SABM message), you will more than likely not see any T1 PM events on your end.


NDT4U:

Beginning in December 1989, the FCC under part 68 ruled that LEC's (Telco) will not span power customer T1 CSU equipment from the T1 span line. The exception to this rule applies to those T1's in place prior to the FCC rule change. ANSI T1.403 incorporates this requirement.

All new T1 NIU's deployed in Bell Atlantic as of 1998, now Verizon, do not pass any t1 span voltages to the customer side of the T1 NIU. If a T1 NIU installed at your location has a DB9 serial connector, and is made by ADA, Teltrend, or Westell, then thatis a NIU.

Units made by Pairgain/ADC, and Adtran are not NIU's but HDSL Remote units or HTU-R's. Older 4W (Gray color) Adtran HTU-R remotes have a slide switch to provide T1 span power towards the CPE.

I had the span powering option removed from all new vintage T1 NIU's, and HDSL HTU-R modules deployed by Bell Atlantic/Verizon beginning in 1998 & 2000 when I was a member of the Transmission Engineering staff.


Field Ops