I recently had an FXT 112 that all of a sudden got static on some extensions. Interestingly enough, whatever extensions had static on one station board, I could go to the same position on the next station board and also find static.

Okay, typical problem for a bad FXSRV-2 board. Whether it's a DXP or FX, when there's system-wide static that's not specific to a line or station, it's often caused by a bad FXSRV-2 board.

I happened to have a couple spare, used FXSRV-2 boards. I replaced the board, and then noticed while still onsite that my database backups were not consistently finishing. I could get it to go okay once every couple times, and then the other times I got failures. I just figured I'd keep an eye on it, and then proceed from there, if necessary.

Customer calls stating that the serial link is down ("voicemail is down, and keeps going down").

I go back onsite and switch to another one of my spare boards. Now, I can't even get a backup to complete without the failure. It didn't matter whether I was on Com 1, 2, 3, etc. (CPU or MAUX), or whether baud rate was 9600 or 19200. I could no longer get the backup to complete.

I changed out the CPU, and the problem seemed to be remedied.

Now it makes me wonder whether it was BOTH the FXSRV-2 or ONLY the FXCPU-2. I'm guessing that whatever caused the problem on the services board also caused problems on the CPU. I'm also wondering whether draining the cap on the CPU, and then reloading software (if I even can) will do me any good.

One thing I have not tried since I got the other CPU to work is to put the FXMEM/FXRAMUP-2 board back on the CPU. So far, I suppose it's possible it could have been the cause of the Com port problem, since I haven't reintroduced it into the system. I'll update once I do.

Any thoughts?

Thanks!

Justin

Update:

After putting the FXMEM/FXRAMUP-2 on the replacement CPU/SRV combo, I was able to get 4 or 5 consecutive backups done without a problem. Somewhere around the 4th or 5th I did get a failure, followed by 2 more where I had no problems. Interestingly enough, I threw the original CPU (on the first replacement SRV), and ran a couple backups without problem.

Very strange. I think I'll let it run on the 2nd replacement SRV and replacement CPU for a while, and see if I get any more complaints of "voicemail down".

Another thing I did before leaving was disconnect the mods from the relay ports on the SRV, since they weren't being used. Not sure why, but at this point, why not?

Okay, the problem didn't go away. Customer just called stating that the VMAIL option just went away again. Another thing they're saying is occurring is that when a call is transferred from the receptionist's phone (8412S-FB with IB48X) to another phone (8324S-FB, in most cases), the recipient will get the call, then the buttons on the IB48X will light up, then after a little while, the receptionist hears what would amount to a hold recall or transfer recall ringing; nobody there when answered; then once the recipient hangs up from the call THEY get the same recall ringing, again with nobody there. I asked if this was with one specific station or multiple. They said it was multiple, making me think this isn't Camp On (which is disabled in programming).

Any input? I'm thinking some other hardware is the culprit, or a corrupt database.

I believe they also mentioned the recall thing before the swap-out of the CPU. The replacement CPU had license for feature set 17, so when I swapped out, I also upgraded them from feature set 15C to 17F.

I'm currently not coming up with anything on this one, so any input would be greatly appreciated (as always).

Thanks!

Justin

bump

it's a thought pulled from way in the back of my head, haven't worked on a DXP/FX/FX-II in a while, but I do recall something about the rom memory upgrade to have the added serial ports function.

dunno if it will help, but it does sound like you have touched EVERYTHING I would check.

On the problem with the recall ringing and no one there it sounds like a possible user error. Could the receptionist somehow be putting the call in a 3 way conference mode? It sounds suspicious since this problem was reported before swapping CPU

This system has been in since 1999, and that particular problem didn't get reported until they had the initial problem with static and such, but AFTER I swapped out the services board. I have my doubts on the user error, but since I haven't duplicated it or seen it duplicated yet, I can't say that I know that's 100% accurate.