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 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.