I have two USR external modems that install correctly and pass the
diagnostic in Windows. When I try to use them I get a "no dialtone"
msg. I have what I assume is a regular phone line with Caller ID. I
mention that because I saw a post about problems with digital phone
lines.
Is this anything that might be corrected by resetting the modems with
AT commands? Neither one is flashable.

"DanceMan" <danceman@fastmail.fm> wrote in message
news:111f2689.0311302116.56780a3f@posting.google.c om...
The digital phone lines are those within a PBX system. If you are trying to
install these on home lines, you are not connecting to a digital line.

Try these steps using a terminal program:

1. init the modem using at&f1 (USR) or at&f (Rockwell or Lucent)
2. turn the volume up on the modem (a slider or wheel)
3. send the modem atd and listen. If you hear dial tone for a split second
and then the modem reports No Dial Tone, go to step 5.
4. Check which jack the phone cable is plugged into.
5. Send the modem atx3d and listen. You should hear dial tone.
6. Dial up some phone number using atx3dt<phone number> and it should go
through.

If you didn't hear dial tone at all on 3 or 5 and you've tried a different
cable, you need to make sure the wall jack is working by plugging into
that. If you jumped to step 5 from step 3, the problem is in the dial tone
itself. It is either not what the modem expects in tone level or frequency
or it is a "stutter" dial tone caused by a message waiting on a voice
mailbox provided by the telco. Step 5 used "blind dialing" which just means
the modem ignores dial tone and dials anyway.


--

Hooda Gest
"The only thing I do immediately is procrastinate."

danceman@fastmail.fm (DanceMan) wrote in message news:<111f2689.0311302116.56780a3f@posting.google. com>...
My apologies, Hooda Gest. After I posted I tried them again, after
using Hyperterminal to give AT&F commands. Both now dial out and
connect, but stop early in the handshake process. There is no problem
with the phone line -- it's working fine with various other modems,
before and after trying these.
Is my next step to try and view a window that records a log of the
connection? How would I do that?

"DanceMan" <danceman@fastmail.fm> wrote in message
news:111f2689.0312011920.5df07a8b@posting.google.c om...
Do not use AT&F with USR modems (except that new softmodem) but use AT&F1.
&F is a no flow control configuration and you do not want that.

Windows records a modem log but it won't do you much good if the connection
is not established and you indicate it isn't. Could you elaborate on what
you meant by the negotiation stopping "early in the handshake process"? The
modem will go silent at some point in that process but negotiation is
actually continuing, so that is not unexpected. Once all parameters of the
connection are "agreed upon" between the two modems, the CONNECT report will
be sent to the computer by the modem. Make sure there is plenty of time for
the modem to complete that process. The modem default is usually 60 seconds
but 45 seconds should be adequate and I would not go lower than that. If the
modem is timing out during that silent period, there may be a difficulty in
establishing error correction or data compression with the remote modem.
Disabling data compression and disabling LAPM/V.42 in favor of MNP4 are ways
to test this and get around it.


--

Hooda Gest
"The only thing I do immediately is procrastinate."

danceman@fastmail.fm (DanceMan) wrote in message news:<111f2689.0311302116.56780a3f@posting.google. com>...
My apologies, Hooda Gest. After I posted, I tried them again, after
giving them an AT&F command in Hyuperterminal. Both connected and
began the handshake process then abruptly stopped and just sat there.
What's the next step? My guess is some kind of log of the conection
but I don't know how to set that up. Before that I'll follow your
advice and try giving them the AT&F1 command in Hyperterminal. The
phone line is fine, working well with an assortment of other modems,
hard and soft.

I gave the AT&F1 command in Hyperterminal, but get the same result.
Unchecked the timeout in one of the DUN pages. Still the same result.
The modem dials (tones), then connects (white or pink noise), then
silence. I'm used to hearing the connection noises from modems, both
hardware and software. The white or pink noise should last longer. It
cuts off too soon. It will now sit there much longer after cutting
off, but eventually I'll get an error 629 message. Didn't try the
second modem again, but up to this point their behaviour has been
identical. Other USR externals checked at the same time on the same
equipment have worked. They were all later, 33.6, 56k X2, 56kV.90.
By the way I tried the 33.6 with the flash files from the Russian
"Sportster Modem Flash" site. It erased the first block then stalled.
I tried all three flasher versions and all the flash files for that
modem with the same result. The modem is toast now. And an e-mail to
the address listed on the site has infected my address with "returned
-- unedliverable" spam. A warning to others.

"DanceMan" <danceman@fastmail.fm> wrote in message
news:111f2689.0312051630.257010ed@posting.google.c om...
Did you try disabling V.42 and data compression as I suggested? I suppose
it's a moot point now, though, since you tried that Russian pirate firmware.
You had no reason to, unless you thought you could get a free upgrade that
way.



I guess that should be a lesson learned.


--
Hooda Gest
"In a New York minute, everything can change..."

danceman@fastmail.fm (DanceMan) wrote in message news:<111f2689.0311302116.56780a3f@posting.google. com>...
Both are 28.8's

The 33.6 is a different one. Nothing ventured, nothing gained.

I did disable compression or error checking or both, but not V.42. I
don't think they have V.42, just V.34 I think.

"DanceMan" <danceman@fastmail.fm> wrote in message
news:111f2689.0312070132.63a70262@posting.google.c om...

V.42 is a protocol for establishing error correction (LAPM). You can disable
it in the USR Sportsters and Faxmodems with S15=128. You will still have
error correction available but it will be MNP. Disabling all error
correction by unchecking that option will not work for you, it will just
cause other problems.

Using a terminal program for testing, try this string...

at&f1&k0s15=128

then dial the ISP's number using atdt<number>

This is the best way to test this stuff, you can change the DUN settings
later once you find out what the problem is.


--
Hooda Gest
"In a New York minute, everything can change..."

Did that, same result. Of course as I did, I realized I didn't know
how to send my username and password in a terminal program. When I say
"same result" I mean it quit the handshake early after connecting, as
it had been before.

"DanceMan" <danceman@fastmail.fm> wrote in message
news:111f2689.0312090330.3ce915cf@posting.google.c om...
Since you are not completing the negotiation process, there is no login
needed, so don't worry about that. The testing is to establish the ability
of the modem to negotiate a modem to modem connection.

Maybe we need to clarify some terminolgy...

When I say "connect", I mean complete the negotiation and report CONNECT to
the system.

The modem dialing into the remote modem and the remote picking up the
incoming call is not what I will call a connection in here.

You state that it quits the handshake early. Please explain that a little
better. All modems go through an audible and silent period during the
negotiation (handshake). The audible part establishes initial negotiation
speed and a couple of other parameters, the silent part generally is where
the error correction and any data compression is established. So I would
expect that there would be a silent period lasting a couple of seconds
before the modem reports the connection. Most of my V.34 connections were
established in about 18 seconds from beginning of dialing to connect report,
some took a little longer. When connecting through DUN, there will be an
additional period where the login to the ISP is done but you can tell where
that starts by watching the dialog box change to "Verifying username and
password". Some people do not uncheck the "Login to network" and that adds
some time to the login process.

With the USR, sometimes you can figure out a little about what is going
wrong by manually dialing (using the ATDT...), observing the actions of the
modem, and then checking the ati6 immediately after the failure to complete
the connection.


--
Hooda Gest
"In a New York minute, everything can change..."

abruptly.

Thanks for the continuing advice.