Article View: demon.ip.support.pc
Article #707Re: Modem INIT strings affecting success rate with Ascends
From: David English
Date: Fri, 05 Jan 1996 00:00
Date: Fri, 05 Jan 1996 00:00
158 lines
7587 bytes
7587 bytes
In article <820792146snx@holly.demon.co.uk>, Mark Rogers
<mcr@holly.demon.co.uk> writes
>In article <vZAAwiA+v96woA0r@turnpike.com>
> David English <DavidE@turnpike.com> writes:
>> >
>> >AT&F (set factory defaults) expands to:
>> > AT B1E1F0L1M1N1Q0V1W0X4Y0 &C0&D0&G0&K3&P&Q5&S0&T4&Y0 %C3%E0 \A1\G0\L0
>
>> Could you please post the output of say AT&F0&V. Thanks.
>
>AT&F0&V
>
>ACTIVE PROFILE:
>B1 E1 L1 M1 N1 Q0 T V1 W0 X4 Y0 &C0 &D0 &G0 &J0 &K3 &Q5 &R1 &S0 &T4 &X0 &Y0
>S00:000 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:050 S08:002 S09:006
>S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S36:007 S37:000 S38:020 S44:020
>S46:138 S48:007 S95:000
To reprise:
The init strings were as follows:
FAILED: AT&F0E1N0Q0X3Y0&C0&D2&G2&J0&K3&R1&S1&T4S37=11\r
WORKED: AT&F0W1&C1&D2%C2\r
>However, the fact remains that both the working and failing INIT strings
>included &F0, so any paramaters previously excluded from the analysis
>were the same in both working and failing cases (although the additional
>information may help others trying to get a non-Zoom modem into the same
>state as my working Zoom).
>
>Both "working" and "failing" connections connect, go through the login
>procedure, display motd, etc. The dialer "window" then closes and I'm
>returned to the KA9Q net> prompt. The difference is that the working
>string then allows me to continue from here (the time connection is made,
>then mail is sent, news collected, etc) whereas the other doesn't budge
>from here, and "ppp sl0" indicates that PPP hasn't started properly.
>
>Because of the differences in the two init strings, I don't get
>sufficient information back to to confirm the V.42bis (etc) state; I'll
>try modifying the init strings to report as much info as possible and try
>again, on the assumption (which should be quickly confirmed) that the
>difference in reporting won't affect the connection itself in any way.
>
>Unfortunately, the problems last night (continual CBNL's, presumably as a
>result of the Raduis problems?) meant that doing any experiments last
>night was out of the question. Indeed, I may well leave the tests until
Yes, I understand it was quite cloudy last night and not suitable for
observations :-^)
>the weekend when the lines are less busy anyway. (I would try now (ie
>during the daytime), but I *should* be working.)
yes, I do understand. I do this for a living, though of course I have
to justify time spent. I work all day, but not at the weekend, if I can
help it.
>What is the Turnpike recommended string for the Zoom V.32? What about for
>the USR which someone else is struggling with?
The relevant parts from the zoom Turnpike .mdm file is:
IDENT Zoom VFX V.32bis external fax modem
SEND 'AT&FW1&C1&D3&K3S95=46\r'
WAIT 3 "OK"
;
; Sent:
; &F - Restore factory configuration
; W1 - Report line speed, EC protocol and DTE speed
; &C1 - Allow RLSD to follow the carrier state
; &D3 - On DTR on-to-off transition the modem performs a soft
; reset
; &K3 - Enable RTS/CTS DTE/DCE flow control
; S95=46 - Add /ARQ, CARRIER, PROTOCOL & COMPRESSION message
; options
;
; Assumed:
; &G - Guard tone
; &P - Pulse dial make / break ratio
; \\T - Inactivity timer
; E1 - Turn on command echo
; L2 - Set medium speaker volume
; M1 - Turn on speaker during handshaking and turn off speaker
; while receiving carrier
; N1 - Turn on automode detection
; Q0 - Allow result codes to DTE
; V1 - Report long form (verbose) result codes
; X4 - Report all call progress result codes and connection
; rate
; Y0 - Disable long space disconnect before on-hook
; &Q5 - Modem negotiates an error corrected link
; &S0 - DSR is always active
; %C1 - Enable V.42bis/MNP Class 5 data compression
; %D2 - Set dictionary size 2048 (V.42 bis)
; %M3 - Set two-way compression mode (V.42 bis)
; \\A3 - Set maximum block size in MNP to 256
; \\G0 - Disable modem to modem flow control
; \\L0 - Use stream mode for MNP connection
; S0=0 - Disable auto-answer
;
; You could add any of:
; M3 - Turn off speaker during dialing and receiving carrier
; and turn speaker on during answering
; N0 - Turn off automode detection, connect at speed according
; to S37
; &G0 - Disables guard tone (US)
; &G2 - Selects 1800Hz guard tone (UK and Europe)
; &P0 - 39%/61% make/break ratio at 10 pulses per second
; (US/Canada)
; &P1 - 33%/67% make/break ratio at 10 pulses per second
; (UK/Hong Kong)
; &P2 - 39%/61% make/break ratio at 20 pulses per second
; &Q6 - Asynchronous normal mode (speed-buffering, no error
; correction)
; S37=9 - Attempt to connect at V.32bis/V.32 9600bps
; S37=10 - Attempt to connect at V.32bis 12000bps
; S37=11 - Attempt to connect at V.32bis 14400bps
; S37=12 - Attempt to connect at V.32bis 7200bps
I don't think the USR settings are very relevant here. The kind of
settings they are altering are either changing subtle V.34 behaviour
such as signal shaping, V.8 call tones and ITU V.34 versus Rockwell V.FC
modulation. Also, I don't think the problems they have are of quite the
same kind.
You probably ought to try using ATW1S95=46 to tell you as much as
possible about the connections.
I think what you should be trying to do here is to refine out the
essence of the difference between the two sets of settings, in order
that we can all know what is needed for a good connection.
The most obvious way to refine the difference is to try to make the two
sets of settings more closely similar, while retaining their different
outcomes.
Another approach would also help though. Change settings in both sets
identically to restrict the behaviour of the modem, so as to eliminate
other sources of variability. You might like to try adding to both
strings some of:
S36=3 - eliminate MNP4 connections
S36=0 - allow only V.42 connections
%C0 - disable data compression, V.42bis
S48=0 - bypass v.42 negotiation
%E0 - disable quality monitor and auto-retrain
( you cannot be sure from the above that this is actually the
&F0 default, I would not trust a manual on this particular
point as far as I could kick it )
Hope this helps
Dave
--
Dave English, T U R N P I K E Ltd
250/256 High Street, DORKING, Surrey, UK. RH4 1QT
My other computer's a brain
Technical Details
Message-ID:
<VatmcBAC9P7woAa+@turnpike.com>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<820709627snx@holly.demon.co.uk> <vZAAwiA+v96woA0r@turnpike.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 102a94,ae57d9c38dda272f X-Google-Attributes: gid102a94,public X-Google-Thread: fb525,ae57d9c38dda272f X-Google-Attributes: gidfb525,public X-Google-Thread: 1004db,ae57d9c38dda272f X-Google-Attributes: gid1004db,public From: David English <DavidE@turnpike.com> Subject: Re: Modem INIT strings affecting success rate with Ascends Date: 1996/01/05 Message-ID: <VatmcBAC9P7woAa+@turnpike.com> X-Deja-AN: 134088155 distribution: world x-nntp-posting-host: pillar.turnpike.com references: <820709627snx@holly.demon.co.uk> <vZAAwiA+v96woA0r@turnpike.com> organization: Turnpike Ltd mime-version: 1.0 newsgroups: demon.ip.support.pc,demon.ip.support,demon.tech.modems