Modem reset question
Christian Lambert
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have an easy question, whenever a modem reset, what i want is to
keep the DTR OFF during initialisation and resetting until it is
ready to receive a call. I have also removed the ATH1 and ATH0
commands, because for example when i called just hanged up, and
someone called in just after... it is answered by the ATH1 command
... and just after the ATH0 commands hang him up. So the only
problem i got left is the modem answer begin the sequence and then
hangup in the middle of the sequence probably because the netblazer
was initialising the modem and the auto-answer was on. Here is a log
: The is a DTR ON command , what modifications can i make to remove
the DTR ON command before the reseting?
Evt RING by line124, St Training -> Training\r
00:36:26.20 line124 info: Queued Evt RING by timer (St Training)\r
RING INDICATOR\r
Evt RING by line124, St Training -> Training\r
00:36:26.71 line124 got: 2\r
00:36:58.22 line124 info: Queued Evt Modem Reset by timer (St
Training)\r
Evt Modem Reset by line124, St Training -> modem-reset\r
DTR OFF\r
00:36:58.60 line124 info: DSR OFF\r
00:36:58.66 line124 info: DSR ON\r
00:36:59.66 line124 info: Queued Evt DSR ON by timer (St modem-
reset)\r
Evt DSR ON by line124, St modem-reset -> modem-reset\r
00:37:01.22 line124 info: Queued Evt Modem Reset Expired by timer (St
modem-re
set)\r
Evt Modem Reset Expired by line124, St modem-reset -> Idle\r
set line124 speed to 115200\r
DTR ON\r
~~~~~~~~ This is the one that make the modem answer while it is still
not
finished to initialise.
00:37:05.04 line124 info: set line124 speed to 115200\r
00:37:05.24 line124 sent: AT\r
00:37:05.25 line124 got: AT\r
00:37:05.40 line124 got: \r
00:37:05.40 line124 got: \nOK\r
00:37:05.40 line124 got: \n
00:37:05.97 line124 sent: AT\r
Now the initilisation is finished, now the DTR should be set to ON.
So what's my problem?
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBNKiBzbWFoHYya506EQLznQCeNgK7WcsHZ9J/p4kXurFXqCHi9D0An3Uv
GqthPC17Jqdt7xhpicODcR5O
=vj2C
-----END PGP SIGNATURE-----
*************************************************
Christian Lambert, Administrateur réseau
Les consultants Androide inc., Internet Trois-Rivieres
Partenaire Cogeco Cable / Cogeco Cable business partner
400 Williams, Trois-Rivieres, Quebec, Canada, G9A 3J2
Tel: (819) 379-2866, Fax: 379-0343, chri...@androide.com
Hal Eden
i should warn that most of what i say here is based on only snippets of
available documentation (such as the 3.0 config guide, modemcap.hlp,
applications guide, etc) and a lot of observations and testing. any
additions or corrections by other modemcappers are certainly welcome.
At 3:04 PM -0500 1/2/98, Christian Lambert wrote:
>At 16:03 97-12-31 -0700, you wrote:
>>>I have an easy question, whenever a modem reset, what i want is to
>>>keep the DTR OFF during initialisation and resetting until it is
>>>ready to receive a call.
>>
>>there is a "dtr:" tag in the modemcap that can be set to "off" to cause the
>>netblazer to keep dtr off during the autoreset time. the problem is that
>>some modems do not respond to commands if dtr is off, so i can't say
>>whether this will work in your case. what kind of modems?
>>
>
>Using USRobotics, if i look into the modemcap , they say to use DTR ON and
>the ATH1 and ATH0 commands. What i will try to do, is reduce to dtrtime to
>1 second? what time have you tried? What happen is dtrtime is set to 0?
>
Courier or Sportster? (my experience has been that they exhibit different
behavior) i don't have any around to test right now.
if whoever wrote that modemcap thought that dtr:on was necessary, there is
a strong possibility that it will not respond to commands unless dtr is on.
i don't know this for sure--just reasoned speculation. you could so some
experiments with your modem to verify this.
>Ok, i tried setting the dtr to OFF and the modem won't answer commands. So
>what i need to work is maybe the DTRTIME... any suggestion for USRobotics
>modems?
>I will also need to keep le line busy with autostart and autodone commands.
> But i still got answered when the modem do a ATH1 command.
>
a workable value for dtrtime depends on many factors. the basic common
element being how long does the modem take to "react" to DTR. this can be
affected by what the modem is configured to do when DTR drops (e.g., drop a
call, reset from pram, ...). there are also timing issues surrounding,
e.g., when the modem raises DSR (as some do after being reset by DTR going
low)--if it gets raised after the dtrtime has expired, it gets queued up
and handled as a auto-identify event, if it happens before dtrtime expires,
it is just treated as part of the modem-reset (i.e., a transition from
modem-reset->modem-reset state)
one approach is to try different values and see what works. there are
several (similar but slightly different) situations to take into account:
a) when in a connected state and the other side drops carrier
b) when in a connected state and the netblazer (on this end)
terminates the
call
c) when doing a "reset" or auto-identify on the line
d) when closing a talk session or remote telnet connection to the line
e) others???....
different modems may find one these situations to take longer than the
others. for example, in testing a multitech setup i went through several
iterations: i set it to a fairly low value (.2) to see how low it could go
and found that the modem signals were getting into strange states (such as
dropping DSR). it turned out the value was too low to give the modem a
chance to reset to PRAM, and the values were getting scrambled because i
was interrupting that process. a .5 value kept this from happening.
but then it turned out that there was another situation that imposed a
different constraint--b) above, the dtrtime would expire before the modem
had completely dropped carrier, and the first ATH1 would not be
acknowledged, leaving the modem on hook and the other window wide open.
as for the effect of setting dtrtime to 0:
----
from the manual entry for dtrtime:
> To prevent the NetBlazer from dropping DTR to reset a modem on a specified
> line, set the dtrtime value to 0.
>
> NB:Top>Configure>Line> dtrtime line01 0
> 'line01' dtr off time is 0.000 seconds
>
> Note:
>
> Setting a line's dtrtime to 0 prevents the NetBlazer from issuing AT
> commands to bring the attached modem back to a known state.
----
however, i have found the "Note:" to be bogus. true, it does not drop DTR,
but it goes right into ATH1......autospeed stuff...etc...ATH0, i.e., "to
bring the modem back into a know state." but i don't think this is what
you want, because then the netblazer cannot use DTR to drop a call
(although i s'pose you could use escape processing to hang up if you really
wanted to go this way--or if the other side always drops the line in your
situation).
of course, you can optimize some of this stuff based on how you use the
modems. if you never use a talk or remote telnet/ACS connection to the
modems, you might be able to assume that the netblazer is the only source
of commands to the modems and that resetting to pram whenever DTR drops, or
even making sure that the speeds still match, etc. is not necessary. a
bit risky, but it might work.
another approach MIGHT be to work part of the problem from the other end. i
assume that you have multiple lines coming into several modems with a "hunt
group" such that users call one number and it "roll over" to subsequent
lines. what happens with this setup is that if a call drops on one of the
lower lines in the hunt group there is a high probability that it will get
the next call, even though there may be other lines higher on the hunt
group that have been idle for a while.
i have recently found out that some CO's can implement something called UCD
(Universal Call Distribution??), which doesn't just cycle through the lines
in a fixed order, but can pick lines for the next incoming call on some
other basis (i'm still investigating it, but i think it can do something
like "least recently called," which would certainly reduce considerably the
possibility of these calls coming in right after you hang up the previous
call). of course, if all of your lines are ALWAYS full, this isn't going
to help that much.
best of luck,
hal