atcomsystems.ca/forum Forums TDM Business Telephone Systems NEC Telephones & Systems In SV8300,single line voltage is 108.8 DC Volts

System environment:
==============
Stand alone SV8300 , CPU is CP00 with R7 software (SC-4081 J1-0005.01.00)
System consists of single CPU chassis and three expansion chassis

Beginning of the issue:
==============
More than 10 single line users reported their telephones were dead (no dial tone & no ring).
Digital telephones, CO trunk lines, TIE lines with the HQ SV8500, and Operator console all were working normally.

Actions taken:
=========
replacing the faulty LC cards with new ones solve the issue and all FAULTY extensions were restored to normal operation.

Measures taken for future safety and preventive reasons:
=====================================
Testing AC voltages found in the normal range (220~225)
Testing earth connection & tightening screws. all found OK.
Measuring extension line voltages on ALL RJ45 socket located in the LC cards , we found:
ABNORMAL readings (108.8) DC Volts on all the LC cards EXCEPT the reading of the first four extensions of the LC card located in "SLOT 04" it was measuring 26.6 DC Volts

Corrective actions taken:
=========================
Removing ALL the RJ 45 connectors from the cards sockets ONE by ONE, and testing the extension voltage of the 1st four ports in SLOT 3 , same reading was noticed (108.8) DC Volts.
Removing all the cards; COT, DLC, and LC; one by one ((leaving only the LC card used for testing)) and measuring the extension voltage of the SAME 1st four ports in SLOT 3 ,same reading (108.8) was got.
Replacing the LC card used for testing with a NEW card, no reading changes were noted.
Initializing the pbx, and testing, same abnormal voltage.
Powering off two expansion chassis and disconnecting their BUSS cables, and measuring the voltage on the same card , same reading was noted.
Now , WHAT???
Should we have to replace the expansion chassis....!why not?
when the chassis #1 was replaced, voltage reading was NORMAL (26.6) DC volts,
less than 5 minutes later voltage reading was back to (108.8) volts.....!!! should we try another chassis?. we did try the new chassis but again with the same results...!
Finally we have nothing to replace BUT the CPU, and we did replace the CPU with a NEW one and loaded it with the system and office data and repeated the test, the reading was good BUT ONLY for 10 minutes this time...!
Did we forget to replace any thing else? for sure nothing was NOT replaced in the PBX....! and we still have the same abnormal voltage readings?
by the way we ALSO did not forget to use another volt
tester....!
Your help is very much appreciated.

I could not find a setting in the manual to switch over from 110v to 220v. If there is a switch setting, verify that all KSU's are set to 220v. Or, try to find a 110v source and move it over.

there is no issue with the AC source, the voltage reading here is measured on the RJ45 sockets located in the front side of the 8LCA cards it should be ~26 DC Volt but is is reading 108 DC Volts...Hope it is clear.

Have you tried cancelling message wait on all affected stations?

Hello R4+z, nice to see your post on board.
there were no waiting messages. NOT at all...!
By the way every thing is working normally EXCEPT the voltage readings, on one LC card located in slot 4, the first 4 ports measures ~26 Volt BUT the other 12 ports measure ~108 Volts...!!!!

Hi

Still lurking around but the forum seems to have shifted to SV8100s and to add insult to injury, I have not had too much exposure to SV8300s and 9x00s. Best bet would be the shelf as it would appear the shelf has a problem as you have swapped out the cards. How many shelves do you have? Can you try swapping one shelf for another and see if the problem stays with the hardware?

As said in my first post I replaced the shelf with a new one and that did not help, I have three expansion shelves and all LCs in these shelves give the same voltage reading (108.8) I do not think the three of them are faulty.

I can't see it being three faulty PSUs either but the only way I know of for the Volts to be up via software is message wait and you have excluded that. The only other thing common to the problem is the Voltmeter!

First I would check your meter to see if it's faulty. I had a Fluke go bad and it drove me nuts on a car battery once.

We didn't forget to try another voltmeter, also if it s the voltmeter why the reading of the first four circuits in the LC card located in Slot 04 is reading correctly 26 volt , please see my first post again.

Ok so when you replaced the CPU it was normal for a short period then went up, this to me indicates that the higher voltage is being switched on by software. Is there any PMS system connected? How did you check Message wait? Do you have a PMS simulator?

we do not have neither PMS, nor PMS simulator connected.

Do you have an older back up of the system, if so load it into your spare CPU and put that in and see if the voltages stay normal, If not, default the CPU and see if they stay normal.

That should prove whether it is hardware or software related.

yes I did have an older backup which is 6 months older than the current system data, and when the older backup was loaded, the voltage reading restored to normal for a few minuets only, and then it goes up to 108 Volts...and the same thing occurs when the current system data is loaded to the CPU...! if you refer to my first post you will notice the same behavior when I replaced the CPU card.

Have you tried making your own 8p8c connector and plugging in and testing them? Make sure there is not voltage being introduced in your cross connects from somewhere.

Definitely a weird one!

Ok but have you tried it with a defaulted CPU as we don't know how long the problem has existed.

If it goes up with a defaulted CPU, it basically means a hardware problem and you will probably end up having to talk to NTAC,

to oobie;
thank you for posting, the first thing we did here was taking out all the cables from their sockets on the LC cards...and testing on the sockets themselves....! of course we used a separate cable and the reading was ~(108).

any one can help on this issue? we are still facing this problem...!

The voltage number is what is getting my attention. It's almost what all 4 would produce. The only time I have seen something like that was water damage.

Still waiting to hear if it happens with a defaulted CPU?

R4+z
as said in my first post I used a NEW cpu but I loaded it with the current office data, and as I said the reading was good for about 10 minuets and then it went up to 108 DC Volts...!

Yes, I understood that! But the data that you loaded could have reintroduced the problem to the new CPU which is why I am asking if it happens with a defaulted CPU. The concept is to take it back to basics and if possible get it functioning properly then build back up from there. If it doesn't work correctly with the basics then we have to look at hardware.

That is the normal voltage for a DC message waiting lamp.

https://www.sandman.com/messwait.html

From Sandman's site:
You can measure this voltage yourself if you have a better quality DC voltmeter (that presents a high resistance). Without message waiting, you will read 24 or 48 volts (or so) on an idle line. With message waiting, you will see a constant or interrupted (if the message waiting light flashes) 90 to 140 volts. If you only see this high voltage when there's a message waiting, you should have no problem using a NEON message waiting light on your system.


~edit~ I only caught the 3rd page, if you say there are no messages I guess it's something else.

Yes, I said that in the 4th post on this thread. However that has been ruled out but not sure how it was checked. That is why I keep asking what happens with a defaulted CPU!

I personally suspect that somehow the lamps have been turned on by an MCI command (which means the Cmd 200 code probably won't turn it off) but time will tell!

ttech
Thank you for your reply.
we do not use voice mail system, how could that happen?
is there any way of turning on the MW lamp if there is no voice mail or voice message systems?
moreover, the single telephones we are using do NOT have lamps on them...!

Command 200 look for anything assigned data A040 (MW Lamp Control Set) and anything assigned data A041 (MW Lamp Control Reset) if nothing is set to A041 pick a free number and assign A041 to it then try clearing the message wait that way.

Procedure to clear is....

1. Get dial tone
2. Dial MW Cancel code
3. Dial Station Number; receive Service Set Tone
4. MW indication is cancelled
5. Hang up

I had to wait 2 days to be able to visit the site.
I do NOT remember using such codes for MW set & cancel...in any sv8300 pbx...!
Is it possible to occur on all the analog station at the same time? what about the digital telephone , they do have lamps and none of them is lit...!

The codes have been there since the SDS days although they were a digit shorter, A48 and A49 respectively. If it does turn out to be message wait, once you have them turned off use CMD 1303 to disable message wait since you don't need it. I don't know of a way to bulk turn on lamps but that doesn't mean it can't be done.

So is it resolved and what was the cause? Was it message wait and if not, what was it or is the problem still there?

yes the problem was solved by a customer engineer who tried to delete one 8LCA card and reprogram it again to see what could happen? he waited for hours and the voltage was perfect all the time, then he repeated the procedure on the other 8LCA cards and that solve the problem.
Good luck...!
with that said I could NOT follow the steps mentioned in your post, but for sure no codes were assigned for activating MW..

The steps were just about a direct copy from the manual (I simplified it to getting dial tone rather that lift the handset or press the speaker button).

That is one radical cure for a fault, deleting the cards but if that is what it takes then so be it. You could have done a list up and used that to reload everything via the script editor.

All that aside, nice work in resolving the issue.

I didn't want that to happen but I wanted to try your way to fix the problem, but after what the customer engineer has done no more can be done. Any way I thank you and all the other geeks who participated to solve this issue.
With my best wish to all of you and Happy THANKSGIVING.

The interesting thing about this is that it does actually prove that it was a software issue and not a hardware issue. Glad that the issue is resolved and happy holidays to you too (Never understood Thanksgiving being British by birth and Australian by choice for the last 26 years). Perhaps it is time to be wishing you a merry Christmas and a Happy New Year!