DEVON@Mit-Mc (12/15/82)
From: Devon S McCullough <DEVON@Mit-Mc> I'm surprised you think the SmartModem is well-designed. Although adequate for some unsophisticated uses, it is poorly programmed and crashes when left unattended. You can't control it without sending trash (+++) down the data link, you can't transmit arbitrary data over it without losing control of the modem, you can't uncrash it except by manually power-cycling, and it drops incoming characters whenever you issue any control commands.
rconn@BRL (12/15/82)
From: Rick Conn <rconn@BRL> Odd. What you report is quite a contradiction to my own experiences. I use TERM II (my own design) to talk thru my Smartmodem, and have never had any problems. It has run attended for hours without crashing, it is used in a Remote CP/M System mode from time to time and as an outgoing (to ARPA Net et al) communication link the rest of the time. I have transferred TONS of both binary and ASCII data using two different byte (8 sig bits) - oriented protocols on it and again have experienced no problems at all. TERM II does all of the control of the Smartmodem thru its (TERM II's) support package, and I have another version running under the PMMI and DCH modem cards with the same type of reliability. A lot of my lack of problem comes from the lack of control instructions issued by TERM II. This only happens on init and hangup. Data is sent the rest of the time. So, in a nutshell, I suggest that your problems may be caused in part by (1) not using software that controls the Smartmodem in a reasonable way and (2) trying to do things with the Smartmodem at odd times. By the latter, I refer to the fact that TERM II can do everything in the way of control to the Smartmodem at init and hangup. There is no need to issue further commands in between, and, consequently, the +++ sequence is never sent down the line. Rick
DEVON@Mit-Mc (12/16/82)
From: Devon S McCullough <DEVON@Mit-Mc> The SmartModem works fine under manual control and supervision, and my software for originate mode dials out and transfers with no glitches, connected to TWX and not DDD by the way, but incoming calls can wedge the modem with all the LED's lit, and only power-cycling will revive it. If you've been able to reliably control this guy by software alone, I'd sure like to see what magic tricks you used to bypass Hayes' misfeatures.
rconn@BRL@sri-unix (12/16/82)
From: Rick Conn <rconn@BRL>
I have had no experience at all with what you describe as
being a problem, and I use no magic at all in employing the
Smartmodem. It DID take a while to figure out exactly what to
send to the Smartmodem in order to run under software control,
but, once I did, no problems.
Let me outline the telephone interface section of the
TERM II support package for the Smartmodem for you.
First, there is a routine which issues a Smartmodem 1-
char command. This routine does the following: (1) delay just
over 1 sec before sending the first char, (2) send A and wait for
its echo, (3) set T and wait for its echo, and (4) send the char-
acter and wait for its echo. Do not check to see that this echo
is the same character sent, altho I don't see why it would hurt.
Also, immediately after the 1 sec delay timesout, flush any
current char from the modem before proceeding to step (2).
Second, there is a routine which waits for a response to
a Smartmodem command. It enters a large delay loop, polling the
status all the time. If the status does not show an incoming
char by the time the loop finishes, return an error code. If
status shows a char, get it, check for a numeric code (>'0'), and
go back into looping if not the case or exit if the case.
Third, there is an attention routine. It checks the car-
rier detect line from the Smartmodem and returns if no carrier.
If a carrier, I flush the UART, output a NULL (at least one char-
acter has to be output before the Smartmodem will work with +++),
and then I output the three +'s in rapid succession. No echo is
checked in sending the NULL or the +'s. I then call the response
routine.
Finally, a Flush routine simply checks status and grabs
the character if one is available. It is thrown away. The 1-sec
timeout routine delays over 1 sec and then calls the Flush rou-
tine.
Now we are ready to begin. The following modules perform
all the telephone interface functions necessary:
1. Init -- call Attention, send the Z command, send a
<CR> with echo (a simple command end routine). Then enter the
loop: flush, send a V command and end it, wait response, and
keep on doing this until a '0' received.
2. Goto Originate Mode -- do nothing
3. Prepare to Answer the Phone -- Hang up phone, send
"S0=1" command, flush response, send H command, and flush
response. By flushing response, I don't check for validity, but
just get it.
4. Answer phone -- do nothing except return OK code
5. Pick Up phone -- do nothing except return OK code
6. Hang up phone -- check carrier; if carrier present,
call ATTENTION routine and send H command, awaiting any response;
then, with or without carrier, send "S0=0" command and flush
response
7. Wait for Dial Tone -- do nothing except return OK
code
8. Wait for Answer of Phone (after dialing) -- wait for
response, check for connected code ('1'), and return code saying
if connected or not; here I allow the Smartmodem to time out
9. Ring Status Detect -- do nothing except return car-
rier detect status
10. Dial Tone Status Detect -- do nothing except return
OK code
11. Carrier Status Detect -- return carrier status code
12. Start Dialing -- flush character, send "DT" but DO
NOT terminate command
13. Dial Digit -- Send Digit passed in A (ASCII Char)
14. Stop Dialing -- terminate command via <CR> and enter
a loop which (1) waits for a '1' (OK) response from Smartmodem or
(2) waits for a keypress from the user to abort as failure
And that's all there was to it! Very simple and logical.
The same set of routines apply in general to the Smartmodem,
PMMI, DCH, Novation AUTOCAT, and acoustic couplers to perform any
telephone system interface necessary for TERM II. The calling
sequence of these routines is important, of course, but I imagine
you could logically piece them together (think of them like
SYSLIB's process box concept). In applying these routines to
modems other than the Smartmodem, the commands are different, of
course, but the ideas are the same.
Rickrconn@BRL (12/17/82)
From: Rick Conn <rconn@BRL> Happy to have helped. It DID take some time to figure out what was going on with the Smartmodem and how to program it. Most of the problems revolved around its human-interface design. It runs at human speeds, being designed to be spoken to very slowly. If you try to run at computer speeds, such as a true 300 baud, this is much too fast for it. Especially if you send a character before the previous echo comes back ... it almost acts like it runs half duplex in command mode. Rick
martin (12/29/82)
Devon S McCullough, said a few things about Smaartmodems that i can not agree on. I'm surprised you think the SmartModem is well-designed. Although adequate for some unsophisticated uses, it is poorly programmed and crashes when left unattended. I connected a Smartmodem 300 to our 'lime' unix system about 10months ago, went home and wrote the changes to run uucp thru the unit. I went back to the machine room the next day and set the option switches to it's silent mode (easier to use from a machine), i only changed the software once since then (i forgot to do a close). The unit has been working every day since then, the machine only goes down when there is no power in the room, about 4 times this year. You can't control it without sending trash (+++) down the data link, you can't transmit arbitrary data over it without losing control of the modem, you can't uncrash it except by manually power-cycling, and it drops incoming characters whenever you issue any control commands. The modem has been used for uucp transfer (mail + lots of news), so i can say that i'v send every character sequence thru that device known to man (or machine). i use the command sequence 'ATDT<number>\n' to do the dial and wait for a responce '3\r' or '1\r'. I set the switch setting to give DTR action, NOECHO and NUMBER respone. Last week i connected a Smartmodem 1200 to the same machine. i just copied the switch settings from one to the other and it started working. the great thing is that the 1200 works at 300 (does speed selection on the AT) so i now have 3 devices in the L.devices file:- ACU /dev/cul0 hayes 300 ACU /dev/cul1 hayes 300 ACU /dev/cul1 hayes 1200 I have seen no problems with the 1200 yet. martin levy. harpo!ariel!martin