Path: utzoo!mnetor!uunet!nbires!hao!ames!elroy!stevo From: stevo@elroy.Jpl.Nasa.Gov (Steve Groom) Newsgroups: comp.dcom.modems Subject: Getting a Trailblazer's ATtention (Was Re: Trailblazer, flow control, DMF32) Message-ID: <5445@elroy.Jpl.Nasa.Gov> Date: 15 Feb 88 17:28:46 GMT References: <272@coherent.uucp> <3249@cbmvax.UUCP> <10433@mimsy.UUCP> <14856@oliveb.olivetti.com> <3313@cbmvax.UUCP> <15547@onfcanim.UUCP> Reply-To: stevo@elroy.UUCP (Steve Groom) Distribution: comp Organization: Image Analysis Systems Grp, JPL Lines: 103 Keywords: telebit trailblazer emulex 19200 In article <15547@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: >I've written a Telebit driver for 4.3BSD uucico. After opening the line, >it does: > > for (i = 3; i > 0; i--) { > sendthem("A\\dA\\dA\\dA\\dT", dh); > if (expect("OK\r\n", dh) == 0) > break; > } > > [discussion about extra A's deleted -slg] I spent a lot of time trying to come up with a dependable way to do this, and I too decided to try putting the AT sequence into a loop of retries. However, I eventually concluded that a simple loop like this would not work reliably, no matter how many A's were in the attention string. If, for some reason, the modem becomes confused (like selecting wrong rate or something), then simply sending the AT sequence again won't help. The modem needs to be reset or otherwise kicked back into autobaud somehow before attempting the retry. In my testing, I never saw a case where the modem failed on the first try and then responded on the second or third. If it failed on the first, it *always* failed on *all* subsequent retries, until something was done to the modem (reset or cycle DTR). My solution was to cycle DTR between tries, with the modem configured to reset when it saw DTR drop (S52=2). This revealed another problem - how to cycle DTR properly. Some Hayes dialers drop DTR by changing the line speed to 0 and back again (using gtty() and stty()), and I attempted to use this method myself. What I discovered was that when DTR was re-set in this way, it didn't always come back, even after restoring the line speed. (Maybe this was just a problem in flushing output queues or something, I don't know.) In any case, this caused all kinds of problems that I won't go into here (babbling gettys, etc.), and led me to seek a better method for cycling DTR. It seems that the Hayes dialers never tried to cycle DTR except on close, and in those cases, it didn't matter much since the line was about to be closed anyway. But since I was doing this on open, things would get screwed up during the call and were much more noticeable. So, my version of getting the Trailblazer's attention looks like this: (BTW, this is also based on 4.3BSD uucico) ************************************************************* #ifdef DROPDTR /* * code to cycle DTR - clear it, pause, then set it again */ static int cycledtr(fd) int fd; { int res; DEBUG(4, "Dropping DTR\n",0); res = ioctl(fd,TIOCCDTR,0); if(res == -1){ DEBUG(4,"Error clearing DTR - errno %d\n",errno); } sleep(2); DEBUG(4, "Raising DTR\n",0); res = ioctl(fd,TIOCSDTR,0); if(res == -1){ DEBUG(4,"Error setting DTR - errno %d\n",errno); } sleep(2); } #endif DROPDTR /* get attention of Telebit modem using variable speed. * takes number of times to try, returns number of sucessful try * or 0 on failure. */ static int getattn(fd,retries) int fd; /* device to use */ int retries; /* number of times to try before giving up */ { int tries; for(tries=1;tries<=retries;tries++) { DEBUG (4, "Getting attention, try #%d\n",tries); write (fd, "A", 1); sleep(1); write (fd, "A", 1); sleep(1); write (fd, "A", 1); sleep(1); write (fd, "T\r", 2); if (expect ("0\r", fd) == 0){ DEBUG (4, "Telebit responded on try #%d\n",tries); return(tries); /* success */ } #ifdef DROPDTR if (tries