Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watmath.UUCP Path: utzoo!watmath!idallen From: idallen@watmath.UUCP Newsgroups: net.dcom Subject: Description and Review of USR Courier 2400 bps modem Message-ID: <16670@watmath.UUCP> Date: Wed, 2-Oct-85 01:03:34 EDT Article-I.D.: watmath.16670 Posted: Wed Oct 2 01:03:34 1985 Date-Received: Wed, 2-Oct-85 07:51:53 EDT Distribution: net Organization: U of Waterloo, Ontario Lines: 281 Subject: Description and Review of USR Courier 2400 modem Newsgroups: net.dcom Distribution: net Product description, evaluation, and bug report: US Robotics Modem Courier 2400 (FCC CJE794) Ser. #30-05816 ROM set #242 Bell 103/113 Bell 212-A CCITT V.22bis compatible (300/1200/2400 bps) Approved by DOC Communications Canada 550 1169 A Ringer Equivalence: 0.4 Canadian Modem Load Number 36B Warranty: Two years. Description: - plastic case; help summary printed on the bottom; connections via rear - on-line help screens for everything (AT$ ATS$ ATD$) - all current modem settings displayable in an on-line table - internal speaker; slide volume-control on right side of unit - records duration of call, or use timer as real-time clock - detailed call progress result codes (e.g. BUSY, RINGING, VOICE) - automatically repeat-dial a busy line up to 10 times - ability to dial alphabetic phone numbers, e.g. 1-800-DIAL USR - outgoing baud rate set automatically according to terminal baud rate - automatic switch from 2400 to 1200 if called modem is 1200 - optional adaptive DTMF (Touch Tone) dialling - optionally uses DTMF if line can handle it, otherwise uses pulse - two RJ11C jacks; one for wall and one for phone - can dial-out with Answer instead of Originate tones - can toggle switch hook, e.g. to transfer a call - can wait for second dial tone - can wait for "answer" - silence after a ring - optional fast dial-tone detect - Morse Code capability - 1270Hz tone 62ms dot 186ms dash Result Codes: OK CONNECT CONNECT 1200 CONNECT 2400 RING RINGING BUSY VOICE ERROR NO CARRIER NO ANSWER NO DIAL TONE 'AT' Command set: $ HELP Command Reference Screen (this list) S$ HELP S-register Reference Screen D$ HELP Dial Reference Screen A Force answer mode A/ Repeat last command AT Prefix Cn n=0 Transmitter OFF (modem becomes receive-only) n=1 Transmitter ON (normal operation) Ds Dial telephone number s=0..9#* @WTPR,;"! En n=0 No echo of commands n=1 Echo commands to screen Fn n=0 Half Duplex-local echo n=1 Full Duplex-no local echo Hn n=0 Hang up n=1 Go off-hook In n=0 Show product code n=1 Do checksum n=2 RAM test n=3 Call duration/Clock I3=s Set Clock s=Hours:Min:Sec n=4 Show current modem settings Kn n=0 Call Duration mode n=1 Real Time Clock mode Mn n=0 Speaker OFF n=1 Speaker ON until Carrier n=2 Speaker always ON n=3 Speaker OFF during Dial O Return on-line after command Qn n=0 Show result codes n=1 Suppress result codes Sr=n Set register "r" to "n" Sr? Query register "r" (see also I4) Vn n=0 Numeric result codes n=1 Verbal result codes Xn n=0 Standard result codes set (Hayes X0) n=1 Extended (1200) result code set (Hayes X1) n=2..6 Advanced result code sets Z Software reset and reading of DIP switches > Repeat command until cancelled; repeat Dial at most 10 times S-Register Functions (can be set to 1..255): S0 Number of rings before answering S1 Counts number of rings S2 Set Escape-Code character S3 Set Carriage-Return character S4 Set Line-Feed character S5 Set Backspace character S6 Set Dial Tone wait time (seconds) S7 Set Carrier wait time (seconds) S8 Set Comma and Repeat pause time (seconds) S9 Set Carrier Detect recognition time (1/10 seconds) S10 Set Carrier Loss/Hang-up time (1/10 seconds) S11 Set Touch-Tone spacing (milliseconds) S12 Set Escape-Code guard time (1/50 seconds) S14 Smartcom 2.0 kludge to pretend modem is 1200 bps S16 0 = Data Mode 1 = Analog Loopback 2 = Dial Test 4 = Test Pattern 4 = Analog Loopback and Test Pattern Dip Switches: - DTR (pin 20) normal / DTR always on - Verbal result codes / Numeric result codes - Suppress result codes / Display result codes - Echo off-line commands / Don't echo off-line commands - Auto-answer on Ring / Suppress auto-answer - Normal Carrier-Detect (pin 8) / Carrier-Detect always ON - Single phone connection RJ11 / Multiple phone connection RJ12/RJ13 - Disable AT command set / Enable AT command set - Disconnect with +++ / Can go back on-line after +++ - Reserved - Pins 2 and 3 standard / Reverse pins 2 and 3 LED front-panel: - High Speed (2400 bps communication) - Auto Answer; Answer mode - Carrier Detect - Off Hook - Receive Data - Send Data - Terminal Ready (DTR from terminal or with DTR over-ride ON) - Modem Ready; Power - Analog Loopback (self-test mode) Initial Performance: No errors during 10 hours at 2400 bps from home (1 crow mile from UofW) into some 2400 bps modem (make unknown) attached to Sytek network at UofW. No errors when using the Courier to dial out from MATH into the Sytek at 2400bps and then logging back into MATH again. Many errors on MATH end during two of several 1200 bps calls into WATMATH ttyd0 (Gandalf/Cermetek SAM 212A modem). The errors were always BREAK followed by a "{". Unlike the Hayes 1200 modem I normally use, taking an extension phone off the hook at 1200bps made the MATH errors much worse rather than better. (The Hayes 1200 is virtually error-free with the phone off the hook at 1200bps.) Calling in to MATH and ROSE modems (Gandalf/Cermetek SAM 212A modems) produced lots and lots of noise when I tried calling out and back in using the Courier at 1200bps. Using the Courier to call in to WATCGL, WATDAISY, and WATMUM (Vadic 3451 modems) showed no noise. As I said, at 2400bps, calling out from MATH into the unknown 2400 bps modem using the Courier showed no noise at all. UUCP Our byte rate to ihnp4 in Chigago is usually about 70-90 bytes/sec at 1200 bps; using the 2400 bps Courier changed that up to about 145 bytes/sec. Looking at the amount of illumination of the send/receive data LEDs, I get the feeling that the limiting factor is still the load on ihnp4, not the speed or quality of the line or modem. ihnp4 would not respond for long periods of time; this would often cause our end to time out. I babysat the modem and kept calling back whenever this happened. ihnp4 has an ARK 2400 bps modem inbound, and uses a Concord outbound. In town here, we do a maximum of 110 bytes/sec at 1200 bps; using the Courier upped that to about 215 bytes/sec. If they ever start charging for local calls, the higher speed will be useful. Calling utzoo in Toronto, our 1200 bps byte rate is about 109 bytes/sec. I tried to use the Courier into their 2400 bps modems (they have a Racal-Vadic 2400PA), but the noise on the line usually prevented the login from succeeding. In the rare cases where it did succeed, the error rate was so high that the byte rate was only 24 bytes/sec, with so many timeouts that the overall rate was less than half that. 1200 bps on the same line, a UofW FX Toronto line, worked just fine. I tried avoiding the FX line and just dialling long distance and got about the same error rate, so I don't think it's the FX line that's awful. (After all, we call ihnp4 at 1200 and 2400 bps using the same set-up with much better results.) I put the Courier onto its own dedicated phone line, getting it off the UofW SL-1 extension altogether, and called utzoo again. Byte rate went up to 150 bytes/sec, provided I could get logged in. Still lots of noise on the line. I called linus (Boston), who have Concord Data 2400 bps modems, and noticed no noise on the line during the brief call there. I sent them /etc/termcap (74355 bytes) and got a byte rate of 210 bytes/sec. (Very Nice!) I called utai (Toronto) briefly, and noticed no noise there either. (No uucp account, so I couldn't send anything.) To sum up: it seems the University's SL-1 switch might be damaging communications a bit. Regardless of that, the Courier just doesn't like talking to the Vadic at utzoo at 2400 bps no matter what line I use. The Courier calls all four other 2400 bps modems I know of okay. henry@utzoo says their 2400 bps calls to linus average over 200 bytes/sec both ways; we seem to do the same to linus, but can't talk to utzoo. Just shows that things that can talk to the same thing can't necessarily talk to each other! Observed Quirks with this modem: If you are connected to something at 2400bps, you use +++ to get back to the command mode, you display and *interrupt* a HELP menu, then go back on line, you get lots of repeating junk on your screen. You have to use +++ to go off-line again, display a HELP menu *without interruption*, then go back on line. If you try the same thing at 1200bps, you get *no* junk if you interrupt the HELP menu and go back on line, and you get the repeating junk if you let it finish and go back on line! At 1200 bps, I had the modem hang three times when this junk started appearing. When the junk is printing, the Receive Data light is flashing madly and pulling out the phone cord gives an immediate NO CARRIER. When the modem hung, the RD light went out, the SD light would flash when characters were typed, but nothing appeared on the screen and +++ and AT had no effect. Pulling out the phone cord did not affect the hung modem; it just did not respond to anything and I had to power down every time. Looks like you'd better not need any on-line help screens in the middle of a session. We took the modem to a country exchange, long distance to UofW, and saw the same sort of junk appear when we tried calling the unknown 2400 bps modem at UofW. The 2400 would answer, signal 2400 bps, and the Courier would respond with CONNECT 1200 (!?) and then lots of incessant junk. We usually had to power off the modem to get it back. The incessant junk looked the same as the junk that kept spewing out in the above-mentioned help-menu bug. It's almost as if the answering modem were sending a 2400 bps carrier that the Courier was mis-interpreting at 1200 bps, resulting in a continuous stream of junk. Actually using the Courier to call out at 1200 bps on the same country line worked just fine. Nothing I tried could get the modem to recognize my VOICE in the extended result code set. I set parameter X6 and phoned from my home line to my data line and answered the phone myself - the Courier said RINGING and then eventually NO CARRIER, no matter what I said into the phone. A friend tried the same thing and yelled a few times into the phone, and it recognized his voice as VOICE. I picked up my extension phone, dialed a '5' to get rid of the dial tone, and then told the Courier to dial a number on the same line. If I said nothing, it would correctly detect NO DIAL TONE. If I talked while it came off-hook, it would usually mistake my voice for a dial tone, dial the number into my voice, and then say either BUSY or RINGING followed eventually by NO CARRIER. Register S10 (timer for loss of carrier) claims to be scaled in tenth-seconds, but setting it to 254 and unplugging the telephone cable causes carrier loss after only a second or two, not 25 seconds. Setting S10 to 255 and unplugging the cable hangs the modem. It gets stuck off-hook with the CD light on, and refuses to respond to anything except power-off, even with the cable plugged in again. The manual says you can type the command set in upper or lower case. What it doesn't say is that both letters of the AT prefix must be the *same* case -- "AT" and "at" work; "aT" and "At" do not. "A/" repeats the last command, and the last command is cleared the instant the letters AT appear, so if you intended to repeat the last command but type AT followed by backspace followed by /, it's too late. Backspace only deletes command chars, not the prefix itself. This is a "feature" of Hayes modems, too. The "guard band" register (S12) behaves a bit non-intuitively when set to small values. Not only does the guard band decrease, but the length of time in which you have to type all three "+"s goes down too! At small settings, you have to use the repeat key to get it fast enough. At the smallest settings, I think you're required to type the "+"s faster than the baud rate will allow... Summary: I could have put up with the help-menu problem if I hadn't also tripped over similar junk when using the modem in the country. Looks like the modem's state transition diagram has a loophole. UofW needs a modem that can talk 2400 bps to utzoo in Toronto, ideally using the cheap FX line through the UofW SL-1 exchange, and this one can't do that very well. (In fact the ratio of line costs, FX versus using DDD on a private line, is almost exactly the ratio of byte rates, meaning we save no money going to 2400 bps on the DDD line instead of using 1200 bps on the FX line.) -- -IAN! (Ian! D. Allen) University of Waterloo Brought to you by Super Global Mega Corp .com