[Asterisk-Users] X101P on a UK BT line ---- txgain issue

[Rich Adamson]

> > I do get echo, lots of it, I am waiting until the new patch they 
> > are all on about on the list gets into a stable release, then I 
> > will upgrade and see if that does the trick.

Not likely the patch will get applied to the Stable release since its
been stated several times that's all but dead.

> The patch didn't seem to work for me.
> 
> > I am told that some of the echo may be to do with a mismatch in the
> > impedance with the BT line.

There are at least several sources of echo, which have been noted
several times in the past six months or so:
 a. echo can in * not functioning correctly in some circumstances (patch)
 b. mismatched x100p -> pstn line
 c. pstn line problems (eg, imbalance between tip/ring and ground)
 d. 2-wire to 4-wire conversion along the end-to-end voice path

Any single pstn line could have one or more of those happening.

> Problem is do we really want BT messing with gain there end and impedance
> cos it might mess our ADSL lines up =)  I know im on the limits.

The telco isn't going to mess with changing impedance on their stuff
as that would require re-engineering their entire outside plant (cables),
line interfaces within the CO, etc. You couldn't pay them enough
money to do it. Its also highly unlikely they have any technician 
adjustable transmission level adjustments on ordinary pstn CO line 
interfaces, as those are engineered to 'standards', and manufacturing 
engineers typically don't want support technicians to muck with 
those for lots of very valid reasons.

I'm in the US and don't have any real clue what the UK standards are
for impedance, transmission levels, etc. (It would be somewhat 
interesting to here from someone who knows for sure what those are.)

The x100p card (from digium) uses the Silicon Labs ( www.silabs.com )
3012 chip to interface with the pstn line, the 3021 chip to interface
the 3012 (analog-to-digital converter) to the Tigerjet PCI controller.
The 3012 is responsible for matching pstn line impedance. The spec 
sheets at their site tend to suggest the 3012 was built to interface 
to 600 ohm pstn lines and is not adjustable/setable to other values.  
If the UK pstn lines are not 600 ohm impedance, then its unlikely the 
x100p is going to properly match up with UK lines from an impedance 
matching perspective. However, imedance mismatches have to be rather
dramatic to cause a lot of echo.

The tdm fxo module uses the 3019 and 3050 chipset, where the 3019 pstn
line interface chip has many different pstn line impedance settings
including 600, 900, 270, 220, 370, 320, 275, 120, 350, etc, ohms.
Have no clue which countries use which settings, but obviously 
Silicon Labs intended this chip set to operate in different countries,
whereas the 3012 spec sheet doesn't seem to support those objectives.

So, backing into exactly what is causing the echo in the three UK
cases noted yesterday on this list...
 - not likely to be "d" (2-wire to 4-wire conversion along the 
   end-to-end voice path) as that would impact all telco users,
   not just * users.
 - item "c" (pstn line problems) can contribute to echo depending
   upon how bad the pstn line actually happens to be. Most telco's
   have the equipment to measure line quality, however most will
   stop at the cable entrance to your home/business, leaving you to
   guess at what's happening inside.
 - item "b" (mismatched x100p -> pstn line) can contribute, but without
   knowing the exact specs (and probably more info from Silicon Labs),
   its impossible to guess at this one.
 - item "a" (echo can in *) is still a very real possibility, and Mark
   is about the only person I know of that has the knowledge of the
   spec's and * to weight in on this one. 

One of the methods that I used to help determine whether my tdm echo
was a pstn line or * issue was to eval echo on three different pstn
lines using the exact same physical * port (x100p). If the lines
are clean from an analog phone perspective (eg, no hum, no noise) and
the lines cause equal echo when used with *, then its highly likely the
issue is either "a" or "b". If the answers to "b" rule out impedance
mismatches, then "a" is likely. Why? Your not likely to have multiple
pstn lines with exactly the same fault. (Could happen but not likely.)

Second, if your pstn line is also a DSL line with appropriate filters,
the DSL line is far more critical of pstn imperfections then is the
* interface to the analog pstn line. In the majority of cases, a poor
pstn line will cause significantly more DSL problems and probably a
total DSL failure way before the pstn analog path is impacted.

Third, I obtained a Mediatrix 1204 sip gateway to displace the x100p's
to eliminate the echo. It worked fine (zero echo) on all three lines,
essentially proving the pstn lines were not the issue causing echo.
After that test, there was nothing left other then * echo can functions
(which turned out to be the case with my tdm fxo _and_ CO operation,
and resulted in this recent patch).

Given that Mark has been successful at eliminating 95%+ of the echo 
on the tdm fxo module, it proves the algorithm in use within * is
very reasonable. The algorithm is not sensitive to which "country"
it happens to be running in, but "how" that algorithm is applied to
UK pstn lines is suspicious.

I'd suggest someone in the UK with echo problem go through the
logic above to rule out as many items as possible, and then try to
coordinate some of Mark's time (in advance) to help resolve the last
item. Do that via opening a Bug report, include as much factual
detail as possible, and be ready on the IRC channel.

Rich