[Asterisk-Users] Will Echo problems EVER be solved, I'm scared

[Bruce Ferrell]

I'll do my comments in line and hope I don't offend.

Rich Adamson wrote:
>>First off, thank you *very* much for this unbelievably informative post!  I've 
>>got it saved away now along with Kris Boutilier's adjusting rxgain/txgain 
>>post.
>>
>>On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote:
>>
>>>At the point where the phone line get's to your demarc the is supposed
>>>to ba a -2 to 3db reference point, sometimes called a -2 or -3 test
>>>level point (TLP).  So that milliwatt tone at that point should read in
>>>the range of -2 to -3 dbm.
> 
> 
> If I read the above words exactly as written, the above is not true. Maybe
> there was a different intent that I'm missing, or, maybe words left out?

I'm a lousy typist :)

> I'm reading the words to say "if I put a transmission test set on the 
> cable pair just before the pair leaves the central office, the reading
> should be in the -2 to -3 dbm range." If that is what you meant, then 
> its incorrect. Even the old analog step-by-step switch specs called 
> for no more then .5db loss from the milliwatt generator to the cable 
> pair (CO distribution frame).

> If you mean placing a transmission test set at the customer's demarc (at
> the customer's site), the -2 to -3 db is still incorrect for "analog"
> pstn circuits. That level _will be_ the 0db generator tone minus the cable 
> loss from the CO to the customer's demarc. That cable loss is 100% 
> predictable if you know the length and gauge of the copper wires between
> the central office and the customer's site. (That "is" exactly how the
> engineering spec is set for the less technical telephone installers
> to measure after installing a new pstn facility to a customer site.)

at the last point leaving the CO, the tone level should be a nominal 
0dbm.  By the time it get's to the customer demarc, -2 to -3 dbm.  The 
loops are "suppposed" to be engineered that way.  On a brand spanky new 
loop, yes 100% predictable.  Over time, all sorts of oddities 
(corrosion, half taps, loading coils, and just general funkieness) are 
introduced in the real world.

> If you are referring to a Remote Line Module (where CO lines are extended
> into a neighborhood using fiber, T1's, or whatever) and placing a transmission
> test set on the customer's cable pair as it leaves that remote module,
> then the -2 to -3 dbm range is correct "at the remote module". It is not
> correct at the customer's demarc as you still have the physical copper
> loss from the module to the customer's site. That loss is still 100%
> dependent on the length and gauge of the copper cable to the customer's
> demarc.
 >
> If you are referring to a customer site that is 100% digital (eg, T1, 
> fiber) from the CO to the customer site demarc, then your words
> are correct. But, the customer probably wouldn't be using an analog
> asterisk interface if they had a clue.

Can't argue that.


> FWIW, the majority of the larger telco's now store a variable in the
> customer's online record that represents the length of copper cable
> from the customer's physical address to the CO (or remote line module).
> That length is used by less technical types to predict whether DSL can
> be supported, and, is translated into an "expected loss" value that is
> given to the installer (on their service order). That expected loss
> value becomes the boggy for the installer to determine whether the
> completed installation meets company standards. Any deviation of that
> value is suppose to be reported as trouble and resolved before the
> service order is completed.

We were supposed to too back when I did this, but if it meant delaying 
an order... we tended to just take the pair and note it.

>>Ok so since -3dB is 1/2 power we should be expecting a reading of 7422 in 
>>ztmonitor if it's a linear reading of the signal.
>>
>>
>>>If the milliwatt is arriving at the demarc at the nominal -2 to -3dbm
>>>and getting into the asterisk to be measured at 8dBm (+8dbm0), I'd say
>>>something is grossly mal-adjusted.  You're seeing 8db of gain!
> 
> 
> Agreed, regardless of what type of facility exists between the CO and
> the customer's site.
>  
> 
>>No, he was saying he had to set his rxgain to 8 in order to get a level of 
>>14844 (0dBm) in ztmonitor.

Ahhh.... OK a dimensionless number 8. not a reading of 8dbm.

> Right, and if we knew the gauge of copper used to that customer's site,
> we could calculate exactly how many feet of copper exists between the
> customer and the CO (or remote module). An 8db loss is very very common,
> and even 12 db of loss is acceptable by some telco's to distant customers.
> 
> FWIW, those individuals that are responsible for planning the location
> of a new central office or remote line module use programs that calculate
> the copper loss from several potential sites to each potential customer.
> Sort of like drawing a circle around a potential module location and
> asking the question "how many customer sites can be reached that are
> within 12 dbm of that module location?" (Substitute some realistic 
> engineering value for the 12db.) Part of that planning process actually
> involves playing what-if games with things like: 1) if I use 26 gauge
> cable to every customer from that potential site, what is the total
> cost of deploying a remote module? 2) if I use 19 gauge copper, what's
> the total cost?  (19 gauge copper has a much lower transmission
> loss then does 26 gauge, and can reach more customers. However, the
> cost of 19 gauge copper is much greater then 26 gauge so some sort of
> economic trade off is obvious.)
> 
> I fully understand the TLP point referenced in the post, but the words
> that were used is going to lead other readers to an incorrect conclusion.

Again, I'm a lousy typist.  I do my best... and know I'll get soundly 
flamed if it get's too bad :)

> The echo cancellation problem with the x100p and TDM cards are very
> much related to the narrow operating range that the existing echo 
> cancellation software can operate within.  In the above 8 db loss
> example (assuming there is an actual 8 db of copper loss between the
> CO and the customer's site), the _correct_ rxgain and txgain settings
> would be to provide approximately +6 dbm of gain within asterisk/zaptel.
> Those gain settings would fall within the stated -2 to -3 db TLP range.
> However, that 6db of gain (in both directions) will fall outside the
> operating range of the existing echo canceller, therefore smaller
> gain values are almost always required in asterisk. It doesn't make
> any difference whether the transmission level is measured with 
> ztmonitor or a $10k transmission test set. Neither will make it work
> right.

Actually, the test sets I used to use can be had these days for about 
$400.  $10K? please!

> I think it was Steve Underwood that commented on the echo cancel
> routines some time ago (and if you look in zaptel code you'll see
> where he attempted to provide another alternative). The issue of
> recognizing reflected energy (eg, echo) and providing some sort of
> subtractive routine to remove that energy is very complex. Its very
> easy if the routine only has to deal with a single tone (eg 1000 hz),
> but is very difficult and processor intensive to deal with harmonics,
> male vs female voices, soft vs loud speakers, local vs distant sources
> of reflected energy (latency), etc. The companies that engineer dedicated
> echo cancellers can throw processing power at the problem or use
> dedicated chips (DSP's) to do that function. Not likely asterisk's
> canceller will ever be equivalent to dedicated hardware cancellers.
> (And, why does the new digium T1 card have it on board?)
> 
> One other point that may not be obvious from previous echo postings.
> Those asterisk users that are physically located a greater distance
> from the CO _always_ have greater echo issues. Those that are relatively
> close don't have as big an issue. That _is_ due to the small operating 
> range of asterisk's echo canceller. And, that is _one_ of the reasons 
> why one implementor's settings don't work at another implementor's 
> location. (Not to mention differences in motherboards, etc, etc.)
> 
> Rich