vgetty - TAM problem

[C. D. Logan]

A site I'm servicing has had a PCtel HSP56 MicroModem installed in a Debian
(Sarge/stable 2.6.12 kernel) system for over a year. I installed Linux
drivers way back when and the modem has worked fine for dialout via cu or
minicom. They recently wanted me to investigate the possibility of using
this modem as a Telephone Answering Machine. I've found mixed reviews as to
whether this modem is compatible, but the overall consensus has been that it
*should* work.

I've installed the mgetty and mgetty-voice packages, done the configuration in
mgetty.config, and voice.conf, and recorded a greeting message and have it
converted to .rmd format.

vgetty is setup and runs from inittab apparently as it should.

Log files indicate that all is well, but when it's 'show time', it just
doesn't work. With an incoming call, the modem picks up after the 3rd ring,
but nothing else happens, no greeting message is heard by the remote caller.
The vg_modem.log indicates that the call is answered and that the greeting
message is being played, then a couple watchdog timeout messages, then vgetty
resets and goes back to 'waiting'. Using the tkvoice scripts, everything
again seems correct. A new greeting can be recorded, converted, and played
via tkvoice.

The vg_modem.log indicates that the modem is a 'Generic Rockwell Modem'.
From AT commands issued from a minicom session I assume (yeah, I know) that
the parameters for sample rate and bits should be 8000 and 4. I have noted
that when setting up an .rmd greeting that using "Rockwell 4" does not
support an 8000 sample rate, but only 7200. I don't know if this is part of
the problem, or if it's a driver issue, or the modem just won't handle the
TAM duties under Linux. (I tried this modem in a Win98 box with Winfax and
FaxTalk and it seems to function properly in voice, data, and fax modes.)

I have put copies of the mgetty.config and voice.conf files, as well as the
vg_modem.log (level 6, with a typical failed call), and a brief summary of
results returned by some AT commands on my site for perusal to eliminate
probable 'between the ears errors' on my part. They are located at:

http://bluenorthernsoftware.com/logan

Any and all help/suggestions are greatly appreciated!

Best regards,
Chuck Logan

[C. D. Logan]

But you could try to set
forceV253 TRUE
forceV253subset TRUE

I'll gve that a try... thanks for that. It's certainly not a newer modem by
any means. It's been around their office for several years.
If memory serves, we got it for them in '98 or '99, installed it in a Win
machine, then moved it over to the Linux box a year or so ago where it's been
used only for dialout data communicatons until now.

The important command AT+FCLASS=? is missing in your minicom.log

AT+FCLASS=?
0,1,8
OK

Thanks again, and I'll stop by and try enabling V253 later today or tomorrow.

Best regards,
Chuck Logan

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[C. D. Logan]

I've learned a bit more, enabling V253 did not work, didn't get a capture of
the log, but it would appear that the modem doesn't speak that language and
behaved in basically the same manner in picking up after 3 rings, but doing
nothing further.

This is an internal modem that has only the usual smaller than life on-board
speaker, and no other I/O connections other than the line and phone RJ
connectors. It doesn't seem to repsond to a connected handset, at least
nothing can be heard or recorded via the handset using vm. The phone is fully
functional as far as dialing/answering manually while hooked up through the
modem.

I tried playing the greeting message with vm. Below is the log generated from
issuing 'vm play -c4 -d6 standard.rmd'. (I tried other usable -d options,
all yield the same 'timeout while writing' message.) Using pvftools the same
file plays pefectly when directed out to the audio device. The greeting
message was created with pfvtools (wavtopfv pfvspeed pfvtormd) and using the
tkvoice frontend package it records, converts, and plays the greeting message
through the sound card.

11/29 21:45:52 vgetty: experimental test release 0.9.32 / with duplex patch
11/29 21:45:52 reading program vm configuration from config
file /etc/mgetty/voice.conf
11/29 21:45:52 opening voice modem device
11/29 21:45:52 opened voice modem device /dev/modem
11/29 21:45:52 reading port modem configuration from config
file /etc/mgetty/voice.conf
11/29 21:45:52 detecting voice modem type
11/29 21:45:53 Rockwell detected
11/29 21:45:54 initializing ROCKWELL voice modem
11/29 21:45:54 vm: Modem returned ERROR
11/29 21:45:54 can't set transmit gain
11/29 21:45:54 vm: Modem returned ERROR
11/29 21:45:54 can't set record gain
11/29 21:46:07 vm: timeout while reading character from voice modem
11/29 21:46:07 playing voice file standard.rmd
11/29 21:46:18 vm: timeout while writing buffer to voice modem
11/29 21:46:18 vm: play_file command failed
11/29 21:46:29 vm: timeout while writing buffer to voice modem
11/29 21:46:40 vm: timeout while writing buffer to voice modem
11/29 21:46:51 vm: timeout while writing buffer to voice modem
11/29 21:47:02 vm: timeout while writing buffer to voice modem
11/29 21:47:02 closing voice modem device

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Daniel Dickinson]

--=-3qBjiwV3rgwBowNq6s2g
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

This is an internal modem that has only the usual smaller than life on-bo=

ard=20

speaker, and no other I/O connections other than the line and phone RJ=20
connectors. It doesn't seem to repsond to a connected handset, at least=20
nothing can be heard or recorded via the handset using vm. The phone is f=

ully=20

functional as far as dialing/answering manually while hooked up through t=

he=20

I noticed in the snipped log that it's a Rockwell chipset. Can you see
the markings on the largest chip on the modem for it's number? Some
older rockwell chipset modems don't work with vgetty, but if you've seen
my previous message to the list I just did up a patch which may help you
too.

--=-3qBjiwV3rgwBowNq6s2g
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBFem7WhvWBpdQuHxwRAsMPAKCKf0sbrJ64oEu2yObDcunE+eiirQCfavKQ
d7v5oJogx3DvtebIDV5K9f0=
=uBWt
-----END PGP SIGNATURE-----

--=-3qBjiwV3rgwBowNq6s2g--

[C. D. Logan]

Post by C. D. Logan
The single large chip has the PCtel logo, and the numbers "PCT789T-A".
Beneath that are the numbers "9948 A003". Etched in the lower right corner
of the card is "1789 Ver2.6"

Alas, the patch didn't seem to help my particular situation, but I did learn
something new in the process. As i mentioned previously, the modem seems to
'hang' upon receiving the AT#VTX (voice transmit) command. This was true
both from a minicom session, and according to the vgetty logs, as it was
doing the various play/record functions. What I discovered, again while in a
minicom session, is that if the command "AT+FCLASS=8#CLS=8" is issued as the
entire string as it appears here, (and not a separate FCLASS and CLS command)
then the AT#VTX command is issued, the modem responds with the VCON reponse
and appears to stay 'awake'. Any additonal key strokes results in the VCON
prompt being reissued. (I do not see a "CONNECT" response with AT#VTX or
AT#VRX, but the VCON prompt does seem to be active and no longer 'hanging'
the modem. I have no idea what the next series of commands would be under
'normal operating conditions', but at least this seems to keep things going a
bit longer. I don't know if this is the magic key to the next door, and if
it's just a matter of sending a syntax and sequence of commands that this
particular modem can digest.
If I can get some free time I'll hack around a bit and see if I can make any
of that have a bearing on reality.

Regards,
Chuck



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Juergen Kosel]

Post by C. D. Logan
The vg_modem.log indicates that the modem is a 'Generic Rockwell Modem'.

Conexant has started to support the V.253 command set. I don't know, if
this is also ture for the linux driver of this modem.

But you could try to set
forceV253 TRUE
forceV253subset TRUE

in your voice.conf file. This forces vgetty to use the V.253 command set
for your modem.
(Then you need also a new greeting message.)

Post by C. D. Logan
From AT commands issued from a minicom session I assume (yeah, I know) that
the parameters for sample rate and bits should be 8000 and 4. I have noted
that when setting up an .rmd greeting that using "Rockwell 4" does not
support an 8000 sample rate, but only 7200. I don't know if this is part of
the problem, or if it's a driver issue, or the modem just won't handle the
TAM duties under Linux. (I tried this modem in a Win98 box with Winfax and
FaxTalk and it seems to function properly in voice, data, and fax modes.)
I have put copies of the mgetty.config and voice.conf files, as well as the
vg_modem.log (level 6, with a typical failed call), and a brief summary of
results returned by some AT commands on my site for perusal to eliminate
http://bluenorthernsoftware.com/logan

The important command
AT+FCLASS=?
is missing in your minicom.log


Greetings
Juergen

[C. D. Logan]

Post by Daniel Dickinson
I noticed in the snipped log that it's a Rockwell chipset. Can you see
the markings on the largest chip on the modem for it's number? Some
older rockwell chipset modems don't work with vgetty, but if you've seen
my previous message to the list I just did up a patch which may help you
too.

The single large chip has the PCtel logo, and the numbers "PCT789T-A".
Beneath that are the numbers "9948 A003". Etched in the lower right corner of
the card is "1789 Ver2.6"

Two smaller chips have been 'goobered over' at the factory preventing seeing
anything on them.

I'll also take a look at your previous messages. Thanks!

Regards,
Chuck Logan