Analog cards are not working and are showing "CARD TIMEOUT" on the self-test. Also shows "NV Batt Tst" failed.

[wreardon]

Analog cards are not working and are showing "CARD TIMEOUT" on the self-test. The self-test also shows "NV Batt Tst" failed. I can't seem to find trouble shooting documentation on what to do next about the cards or the battery.  This is an Atlas 550, first generation. Snap of the test results attached. Would appreciate some help. Thanks.

[Anonymous]

The "Card Timeout" is a communications issue. If the FXS ports are configured in either the DIAL PLAN or the DEDICATED MAP, remove the configuration and test the module again. If it still has a timeout, then you can try removing and re-seating the module. You may even try cleaning the contacts with rubbing alcohol. I would also configure the modules under the dial plan and see if you at least get dial tone from each port you have configured. If you do, then chances are the self-test failure is either nothing, or related to the NV BATT failure.

The NV BATT failure is a hardware failure. This is the NVRAM Battery which is part of chip U4. You can look at this discussion for more information on that. Basically with the NVRAM batter failing, the ATLAS will loose any configuration any time it looses power, is turned off, or is power cycled/rebooted.

Hope this helps SOME at least,

Patrick

[wreardon]

Patrick - Thanks for the quick reply. I set the unit back to a prior config, with a different dial plan, and ran the self-test. This time Card 0 passed and Cards 1,2 and 3 came back with the CARD TIMEOUT. I then reconfigured the modules and it made no difference. No dial tone and the card status lights are flashing green. I popped the cover off and took a look. Seems my next step is to reseat. I have to ask - would any schematics be available on pulling and reseating the cards? Thanks.

[Anonymous]

The cards are modular and held in with thumb-screws. They are accessible from the back of the chassis and the cover doesn't need to be taken off in order to remove the modules. You just unscrew the thumb-screws, pull the module out, and then slide it back in the slot and screw it back in to re-seat it. The cover only has to be removed in order to access the chip at U4 for the NVRAM battery.

[wreardon]

Patrick – No luck. I pulled and reseated each card. I ran the self-test and am getting the card timeout. Not getting a dial tone and the status lights are flashing. I changed the dial plan and rebooted. Still no dial tone and self-tests on the cards timeout. I did a shutdown, unplug, and cold boot, no change. I’ll bring in some alcohol and q-tips tomorrow and clean the contacts. Any ideas on what I should try next? Thanks, Bill

[Anonymous]

It sounds like the modules are bad, but if you have a "known good" module (of any type), I would try putting it in the chassis to verify it passes. It's strange to have all 3 modules fail in the same manner, but it could happen. So either the modules are bad, or the chassis, or perhaps a specific slot(s) is bad. If you have any spare chassis you can try putting those modules in the spare chassis.

So, in order to verify the chassis/module I suggest either testing a different module with that chassis, or testing the modules in a different chassis. Right now it sounds like either the modules have failed, or the chassis has failed, or possibly both.

[wreardon]

Patrick - I do have another 550 with 4 tested and working modules. I should be able to pull a module and do some swap tests with it the next day few days. I agree, it is odd that actually all four modules are in the same self-test timeout, no dial tone, state. I’ll keep you posted. Thanks.

[wreardon]

Patrick – I believe it is narrowed down to module 4. When module 4 is put in a working unit all analog modules fail. Replace module 4 in the bad unit all the modules work. I left module 4 out of the bad unit and that leaves us 24 lines, which is fine for now. Is it typical for one module to fail the unit, or perhaps it has to do with the slot the bad module is put in? Thanks, Bill

[Anonymous]

It is very unusual for one module to "fail the unit." Although it is still unusual, it is more likely to be a bad slot in the chassis, but I would test it to be sure. A short on the module could cause unpredictable behavior, but a short in the slot could do the same.