atcomsystems.ca/forum Forums Wiring - Telecom Carriers - Trunks & Services T1's, CSU's and DSU's Dialogic card throwing errors

That sounds more reasonable, otherwise it's a blame game of it's your equipment no it's your equipment

This is why we have our own Tbird. I got tired of the carrier or LEC telling me everything is OK when it's NOT!

On EVERY service call with Windstream, their techs show up with a pair of diagonal cutters and a VOM. I show up with the Tbird and, surprise, surprise, we ALWAYS find the fault in a matter of a few minutes. I had an issue with a Verizon circuit, about a year ago, and the "tech having a bad day" showed up with a Sidekick! DUH....what was he thinking? I already had my Tbird connected and he could see the corruption in the received pattern. I heard him say to the tester in the CO: "This guy has a Tbird and it's showing the problem is coming from the CO. What should I tell him?" Really....what should he tell me?

I had to do it. I asked to speak with his supervisor. After a few minutes of "chest pounding" we finally came to the agreement that the "multi-circuit aggregator equipment" also known as a SLiC 96 had a bad module. Sometimes I wonder, if these techs care about anything.

Rcaman

The only good way to test T-Carrier is with a BERT.

Running to a loop is fine, but for nasty problems you've got to run head-to-head.

" Sometimes I wonder, if these techs care about anything."

These days, I don't think they're trained very well and aren't given enough time to do the work properly.

Sam

I heard him say to the tester in the CO: "This guy has a Tbird and it's showing the problem is coming from the CO. What should I tell him?"

Of course the correct response from the CO would be "Must be something wrong with your PBX Tbird"

LOL....you are correct!

Years ago, while working at Bell Telephone, I was trouble shooting with a CO foreman at a CDO. After several hours of trouble shooting, he finally said: "The trouble is not in the CO, the trouble must be in the span because the trouble is leaving here OK.

DUH!

Rcaman

Of what use is a VOM meter in diagnosing a T1/PRI? I have never been able to detect any voltage, either AC or DC, on one. How do you hook up the VOM?

That's my point. They, often, either are not trained to use the proper test equipment or they just think all they have to do is show up and "talk with authority" and point to the equipment and say "there's the problem."

Friday, it happened on a job. I was doing several translations on a Mitel when in walked a Windstream tech and his helper with a VOM. I asked what he was there to do? He said the "IT Department" had called for a DSL line that was not working. Now, the facility has a communications director who is in charge of all voice and data connections and service. As usual, the IT weenies "know better" than the communications director and called the LEC to troubleshoot a non existent problem. I write non existent because that DSL circuit was disconnected several years ago and the equipment was now connected to the facility's network. There was a network problem and the brilliant IT weenies saw the old DSL modem and announced, with authority, there was a problem with the DSL! They NEVER consulted with the communications director who would have avoided a service call charge from the LEC and had them do their job and fix the network problem. More on this later.

So, the LEC tech and his hapless sidekick wonder around the telephone room looking for the non existent circuit, all the while carrying the VOM. I know it's a VOM, but they think I'm clueless. Finally, I asked where this DSL circuit was supposed to be located in the facility? The LEC tech had his work order and it said 2nd floor records room. I immediately knew there was no DSL working there as I have installed every inch of cable and wiring in the place since the mid 70s and have a detailed record of every voice and data circuit to every office and every jack in the place. I showed them the documents which are in a folder in a metal holder directly above the demarc which is a legend of every voice and data circuit provided by the LEC which terminates on a 192 port patch panel to which the LEC's copper is terminated. They scanned the documents and discovered that that circuit had been disconnected in 2008. This is kind of amusing because, as it turns out, their records indicated the circuit was still active.

There was a moment of silence and the hapless sidekick said "what are we doing here?" I chimed in, absolutely nothing especially since you came here to troubleshoot a DSL problem with a VOM. The LEC tech looked at me and said "well, we really didn't know what to expect and our only DSL tester is on the fritz."

Get it?

So, back to the "IT Weenies." It turns out that the computer that they thought was connected to the DSL had a bad patch cable. They did not think a patch cable could go bad, therefore, it had to be something more. The communications director asked me to see if I could fix the problem. In 20 seconds, with my MicroScanner2, I proved a bad patch cable.

My point is, if you want to be in this business, you MUST have some testing tools and know how to use them. If you don't, you will be spinning your wheels and wasting a lot of time.

Rcaman

Good for you!

Sam

That is why when I was still doing it, I had a truck full of test equipment including a network ip sniffer. I got tired of being blamed for a "bad connection" when it turned out the ip guy had assigned the same static ip to more than one device on the network.

You know the old adage..blame the phone guy when the Coke machine goes on the fritz.

Unfortunately, I am finding, more and more, the IT personnel are not trained nor do they have proper tools to do the job. It is so much easier for them to blame the problem on someone or something else than try and fix it. If they can't launch some whiz-bang software to fix an issue, they are clueless.

I have come to realize that, no matter what the issue, if I am called to service the problem, it will be up to me to fix it and not be concerned for the incompetence of the IT department.

Rcaman