Getting Junk out of Modem Speaker/Local Handset

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

On Thu, Aug 26, 1999 at 07:05:43PM +0200, Stefan Theurer wrote:
[..]
> To analyze this with a clear head I read - once again - the things they
> write in the Elite 2864 manual about flow-control.
> My result is: It doesn't matter in which mode (DATA, FAX, VOICE) you are,
> the best flow-control you can use is RTS/CTS (Elite 2864 supports this in
> every mode). And *only* RTS/CTS. Not both, RTS/CTS & XON/XOFF.

You're right.  OTOH, if mgetty/vgetty sets the modem to "something", and
the local serial port to "both", chances are better that it will work,
even if the modem doesn't do "something" but "the other thing" :-)

For example, there are lots of modems out there that won't do RTS/CTS in
fax mode, even if they are set up to do it in data mode.

> They say this not very clear. But the AT command (AT+FLO=n, n=0,1,2) to set
> flow-control is defined in Class 2 and 2.0. n=0 means no flow-control, n=1
> XON/XOFF and n=2 RTS/CTS.

The problem with that is: AT+FLO is NOT defined in class 2, only in class
2.0 - so there is no well-defined way to set flow control in class 2.  My
strategy is "use the command for data mode, but make mgetty as tolerant as
possible, if the host system supports FLOW_BOTH".

> So I can't understand why they write things like 'According to Class 2 both
> hardware-flow-control (RTS/CTS) and software-flow-control (XON/XOFF) are
> activated'. 

In *class 2*, the flow control issues are fairly undefined.  In class 2.0
and the ITU standard, things are well defined (AT+FLO).

[..]
> So, if I'm right (one can't use both properly), I found an intersting thing
> in my vm-log:
> I have set do_hard_flow true in the voice.conf vm-section (and globally), I
> type
> "vm play -v -s zyxel_2.9600.rmd" or "vm play -v -w -H zyxel_2.9600.rmd", (I
> hear garbage...),
> but vm-log reports:
> 08/26 18:02:01    vm: AT+FLO=2
> 08/26 18:02:01    ZyXEL 2864: OK
> 08/26 18:02:01   tio_set_flow_control( HARD XON_OUT )
> 08/26 18:02:01   voice command: 'AT+VTX' -> 'CONNECT'
> 08/26 18:02:02    vm: AT+VTX
> 08/26 18:02:02    ZyXEL 2864: CONNECT
> I think tio_set_flow_control should set HARD only.

I don't think that should matter here.  XON_OUT means "the modem may stop
the computer".

> The modem doesn't expect XON(ASCII 0x11h) or XOFF(ASCII 0x13h) but the
> computer may send them.

No, that would be XON_IN.  With XON_OUT, the flow control is
modem->computer (the data direction is OUT).  See the definition in
mgetty.h (tio.h in earlier versions).

[In any case, even for XON_IN, it shouldn't matter much - the computer
has no reason to send anything, as there is no "input data flow" to stop
and restart]

> But this isn't really an explanation for the garbage in the internal speaker
> / local handset, because this is done in the same way on the telco line.
> 'tio_set_flow_control' is also called with 'HARD XON_OUT' when playing and
> 'HARD XON_IN' when recording, but there is no garbage.

I feel this could be a modem bug.  If everything is the same except for
the selection of the "output sound device" (didn't test it, but I assume
it to be), and one works and the other don't, that counts as a modem bug
for me...

[..]
> Apropos the thing with the speed (now, do_hard_flow false is set for vm
> again). I don't think this is bug of the pvf-tools.
> If I play incoming messages (recorded with ZyXEL_2864 2.9600) from the telco
> line with vm play -w -H ... the message is played to slow. But if I call my
> answering machine and listen to incoming messages (with dtmf.sh) the speed
> is correct.
> To make things strange the speed is also correct when played with the
> internal speaker.

Very weird.

Roland, do you have any ideas?  Any known problems with voice on the
2864i?

Stefan, which ZyXEL software version do you use?

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert.doering@physik.tu-muenchen.de