Aadiron.112
net.periph
utcsrgv!utzoo!decvax!duke!adiron!bob
Wed Mar 10 19:59:50 1982
problems using ventel 212+
Here are some of my findings and recommendations for the
Ventel 212+ auto-dial/answer modem running on VAX/UNIX 4.1BSD.
We have a ROLM CBX phone system. For a while we could communicate
at 1200 baud only if we originated a call. We switched some of
the phone lines around and found one that worked with 1200 baud in
both directions. It is not clear where the noise or attenuation was -
NY TELL or our CBX. If this had not worked we were going
to scope things and run power transmission tests.
If you use your 212+ as an autodialer and auto answer port you
may have this problem:
The 212+ might fail to answer a call if it had not been reset
very recently (about a minute). You can reset the 212+ by
pushing the AL button or dropping DTR (Data Terminal Ready).
What was happening was UNIX was deciding that it should try to
log someone into that port (even when there was no call).
The DZ's scanning probably saw CF (carrier detect) being asserted by the 212+.
Then UNIX sends out its welcome and as an unfortunate side effect
wakes up the ventel (into AUTO DIAL MODE).
The ventel responds with a messages like "error or invalid..." because most
characters are not valid ventel commands.
Then UNIX takes this "error or invalid..." stuff as a user name.
UNIX then asks for a password to which the ventel responds "error ....".
This bounces back and fourth many times - hence the mysterious
transmissions and receptions as seen on the REC and SEND indicators.
When in autodial mode, the 212+ will not answer and there is no
way to get out of autodial mode short of pushing the AL button or
cycling DTR in software from the DZ.
The ventel designers chose to assert CF (data carrier detect - pin 8)
when the modem was idle so that certain terminals would be happy.
Those terminals need CF to operate and the terminal must be operating
in order to auto-dial. THIS IS NOT THE PROPER INTERPRETATION OF CF.
CF SHOULD BE ASSERTED WHEN THE MODEM DETECTS A SIGNAL FROM ANOTHER
MODEM THAT IS SUITABLE FOR COMMUNICATIONS.
So just disconnecting pin 8 won't work - the modem will reliably
answer, but the computer will never know that the port came alive
since the computer waits for CF on pin 8.
Defeating the carrier detect scan in software brings you back to the
original problem where the computer sends out a welcome and
the ventel thinks the computer is trying to auto-dial and back and fourth.
Now if the message sent out by the computer told the ventel to
go to into idle mode (QUIT command) things might be OK. I added two
new entries to the getty program that are similar to the of
3 or 5. The new entries are the same as 3 and 5 but the login message
skips the "Welcome to Berkeley .......\r\r\r\n\n" and just puts out
"loginq". The trailing q is the command to tell the 212+ to QUIT and
go into IDLE mode.
This seems to work. It is a KLUGE but seems better than spending the
time on the next option:
Modify the dz driver so:
The dz scans for Phone RINGS (pin 22). When pin 22 is
asserted by the modem the computer will turn on DTR (pin 20).
When the modem sees DTR it will answer the call and Carrier will
be asserted by the modem. The computer sees carrier and then
continues with the logging in.
-bob gray
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
