[Asterisk-Users] How to read dbm or voltage via ztmonitor ?

[Rich Adamson]

> > Yes, I've read that. Ztmonitor is simply a very _basic_ tool that provides
> > you with a little bit of feedback to adjust the rxgain and txgain
> > settings to something relatively close to what the human ear considers
> > reasonable audio levels.
> >
> > The tool cannot detect or determine what settings are reasonable for
> > echo. Therefore, the end result is you need to listen to a conversation
> 
> Isn't getting your transmit and receive levels to 0dBm considered THE #1 STEP 
> in combating echo?  The echo cancellers all assume that the audio will be at 
> a given level and thus it's crucial to make sure this adjustment is fine.

Sort of. Essentially the problem goes something like this...

Audio transmitted from the CO incurres an unknown loss due to the length
of the copper pstn lines between the CO and *. The longer the copper pairs,
the greater the loss. If you're 15k feet from the CO, the loss is roughly
7db (the exact loss is dependent upon the gauge of the copper wires). So
to get close to what another sip phone would sound like, one would need
to crank rxgain=7.0. If you want the remote pstn party to hear properly,
then txgain=7.0 is required as well. Setting both to that level causes
echo as the levels are way outside what the * canceller can handle.

Using that same example, "if" one could follow transmission engineering
practices in use since the dark ages, the correct way to handle the loss
would be to adjust the transmit level "at the CO" to be roughly 7db higher
then normal so as deliver an audio signal to * that is roughly 0db (after
the cable loss). And, then adjust * to transmit audio 7db greater then
normal towards to CO. (In actual transmission engineering practice, the
gains would typically be specified about 1 or 2db less then the cable 
loss.) However, I don't know of any telco that wouild do that even if 
they could, and I don't know of any current CO switch that has that 
capability on an ordinary pstn line-interface basis.

If one think's about setting rxgain and txgain to values like 7db, think
also about the noise, hum, and other imperfections that will also be
amplified by the same 7db. Amplifying that crap also has a serious
negative impact on how well the existing * canceller functions.

So, essentially one can truly say "the further * is from the CO, the 
greater the audio problems will be".

In the olden days of US analog pbx trunking, the above example would be 
handled by the telco by using 4-wire analog circuits, and typically
those circuits were engineered with the capability to adjust "transmit"
levels at "both" ends of the circuit. Not so today with ordinary pstn
lines. In this 4-wire approach, the echo canceller has much less work
to do as the reflected energy that it has to deal with is much much less
regardless of where it originates from.

It would be very consistent with historic transmission engineering
practices to essentially say "use a TDM card if * is located within 3db
of the CO, or use a digital (eg, pri/bri) line if beyond 3db". But,
digium does not suggest/specify parameters like that and as a result we
get lots of * implementors trying to use the TDM card in situations that
are almost impossible to address. (Plus, as we've all seen over the last
couple of years, the majority of * implementors don't have a clue what
their pstn line loss happens to be or even how to measure it. Even those
that represent themselves as professional pbx vendors don't typically 
own a transmission test set or know how to use a CO milliwatt generator.)

> Perhaps I have just been lucky but after adjusting the levels such that 
> they're at 0dBm my echo problems are largely gone.

Don't know if that's luck or just implementing asterisk with pstn lines
that don't have relatively high cable losses. The US telco's have 
deployed a ton of digital remote line units (or cabinets) in our 
neighborhoods that effectively moves the CO line interface closer to our 
businesses and homes (less pstn loss). In those cases, we might think
we're some hugh distance from the CO, but the remote line cabinets place
the interface much closer to us then one might think. The average telco
employee that rolls around in a truck and visits customer locations
doesn't have a clue why those cabinets are out there.
  
> If I crank up the gain to compensate for a 7dB loss would the far end not get 
> audio at correct levels?  The 15kft isn't a moving target so that loss should 
> be constant.  Now if the hybrid on the TDM card is causing such jacked-up 
> audio to be crossed over to the rx side you would *still* only see it as a 
> sidetone since it's occurring right on the card and your only delays would be 
> the digitization and PCI transfer delays.

Your analogy with sidetone is correct, except with the TDM card there is
an internal delay associated with transmitting data from asterisk (as an
application) across the pci bus, queued on the TDM card, hybrid, receiving
queue, pci bus, back into asterisk, and into * echo canceller. That delay
is not at all constant (very high jitter) and when the "missed frames" are
added into the picture, expecting the existing * echo canceller to work
in some reasonable way is not going to happen. Spandsp with the TDM or
x100p card not working correctly is a perfect example of why the 
software-based echo canceller can't handle reasonable pstn audio in
some pstn cases. We all get around that with pure audio by reducing 
rxgain and txgain settings. (That's addressing the sympton and not the
root cause.)
  
> I agree with the second part of this, but as I said I've had very good luck 
> with MEC2, MMX "optimizations" and adjusting CFLAGS and KFLAGS for your true 
> processor for the zaptel driver.  Once ztmonitor's saying you're tx and rx 
> levels are at 0dBm everything just seems to work.  No echotraining even.  
> Just an echocancel setting (usually 64, but 128 and 32 have been used too).

As mentioned above, those optimizations are 100% dependent on the exact
pstn implementation that you've had to deal with, and don't necessarily
apply to the next location. Dependencies actually include the use of
a solid mobo, how clean the pstn lines are (eg, noise, hum), proper
impedence matching, distance from the pstn line interface (eg, CO), and
many other things that you've learned from practical experience. If
you deployed a system in rural Des Moines, I'd bet that experience
becomes somewhat different. ;)

I'm not at all disagreeing with anything that you're stated, we just
have to be careful suggesting something that works in one case may
not work in the next case. (If I recall correctly, the OP for this
thread is in France and I'm not even sure where he stands with 
config'ing the TDM card for proper impedence matching, etc.)

Rich