[Asterisk-Users] Major problems with TDM400 and specific telephones: suggestions?

Rich Adamson radamson at routers.com
Tue Mar 22 12:52:23 MST 2005


> Attached to the bottom of this e-mail is an edited version of an e-mail I 
> originally wrote to Digium tech support regarding Ouch and Power alarm 
> errors I have been receiving on my TDM400.  It contains a great deal of 
> detail regarding my setup.  In the end, I have found that one of the 5 
> phones I'm trying to make work with Asterisk is contributing to the 
> generation of these errors.
> 
> The phone in question is what I would consider to be a good-quality GE 
> two-line cordless telephone.  Digium's guess is that it is "putting power 
> on the telephone line and the card doesn't like that."  They have given me 
> zero solution other than to use a different telephone.
> 
> If this were a $25 garbage telephone I could understand.  Or, if *any* 
> other device had problems with it, I could understand.  But this was a 
> reasonably expensive, seemingly reasonably high quality telephone.  It is 
> also a telephone that I have used quite successfully not only on standard 
> POTS lines, but also on a variety of ISDN NT-1's with zero problems.  I 
> don't mean that I've used this model.  I've used this *phone* on at least 
> 4 different brands and models of NT-1's, several different POTS lines and 
> even an SPA-2000.  Not one bit of problem.  Yet the TDM400 card just 
> chokes itself with Power alarm and Ouch errors.
> 
> Does anyone have any idea of what I can do to try to correct this?  Is 
> there some sort of filter or adapter that I can use to condition the line 
> for the TDM400 FXS modules?  I'm handy with a soldering iron:  if you've 
> got an idea for a circuit, I'm game.  I'm going to try experimenting with 
> some caps and coils.  Anyone been down this road yet?
> 
> As an aside, why is it that just about *any* other device with an analog 
> interface you can buy today more robust than the TDM cards?  I've used 
> countless different ISDN NT-1's without problems, from $100 cheapo models 
> to $1000 high-end devices and tons in between and none have had problems 
> like this.  Now there's a ton of SIP gateway devices.  They don't seem to 
> have these issues.  Why do the TDM cards?  And most importantly, can an 
> end user do anything about this?
> 

If you draw a schematic of the fxo module on the TDM card, its almost
exactly like the tech note schematic for the Silicon Labs chipset.
First guess is that was the starting point for whoever built the
card and modules for digium.

It appears on the surface that whoever did the design and layout
is not an industry leader in professional hardware design, but there
is a lot of room for opinion in that statement. Part of that stems
from a missed circuit board trace on the E/F model, noisy reset
line between the pci controller chip (Tigerjet) and the fxo modules,
pci controller looses its ID, etc.

I've improved the stability of my card by adding a capacitor on the
reset line. Hasn't taken a hit in over two weeks.

There is also major differences when comparing external gateway
products to the TDM card, and most of those difference involve 
the controls inherient to dedicated microprocessors (or controllers)
on the gateways, verses asterisk's approach of relying on the host
processor for everything (and it's associated uncontrolled/unknown
pci motherboard structure).

On top of all that, the drivers for the card (as of right now) are
the bare minimum functions needed to make the card function. The
drivers have never been extended to preload the chipset's registers
as documented in the SI tech notes.

If you want to play around with the card, download the pdf files
from www.silabs.com for the chipset on the card. Then take a look
at zaptel/fxstest.c to dump the registers to better understand
how the chipset registers are loaded. You'll need to complile that
code as a standalone app and run it when asterisk is not loaded.

Trying to follow the code path for a functional TDM card is not
to be taken lightly. Code is scattered across multiple drivers
and buried in asterisk modules. Even those that consider themselves
good asterisk developers stay way from this one.





More information about the asterisk-users mailing list