stevo@elroy.Jpl.Nasa.Gov (Steve Groom) (02/16/88)
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<retries){ cycledtr(fd); /* cycle DTR before trying again */ } #endif DROPDTR } DEBUG (4, "Telebit no response after %d tries\n",tries-1); return(0); /* failed */ } ***************************************************** -- /* Steve Groom, MS 168-522, Jet Propulsion Laboratory, Pasadena, CA 91109 * Internet: stevo@elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo * Disclaimer: (thick German accent) "I know noothingg! Noothingg!" */
dave@onfcanim.UUCP (Dave Martindale) (02/18/88)
In article <5445@elroy.Jpl.Nasa.Gov> stevo@elroy.UUCP (Steve Groom) writes: > >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). My Trailblazer is also configured to reset on DTR drop. It seems that DTR drops reliably at the end of a call, so the modem is always in a known state when the next try begins, so the autobaud sequence I posted always works for me. The one that didn't work reliably apparently just had too few A's in it. However, whether your serial port drops DTR reliably when it is supposed to is a function of both the hardware and software. If they aren't working correctly (and Steve talks about DTR not always coming back up after using 0 baud), then you may have to use whatever you can get to work. Dave Martindale
andy@rbdc.UUCP (Andy Pitts) (02/18/88)
In article <5445@elroy.Jpl.Nasa.Gov>, stevo@elroy.Jpl.Nasa.Gov (Steve Groom) writes: > 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. [...] Getting the Telebit to autobaud is easy. I think this has been discussed here before, but let me quote a section of the manual: _____________________________________________________________________ "When S51 = 255, the modem will try different transfer rates until it receives an upper or lower case "A". It then selects a transfer rate and begins to echo characters. [Stuff deleted]. The modem will go into speed select mode in the following situations: 1. If the value of S51 in the non-volatile memory is 255 and the modem is powered up or reset (ATZ). 2. If S51 is changed to 255 while in Command Mode. 3. If S51 is 255 and a break is sent to the modem from the local DTE ^^^^^ while the modem is not connected to another modem." _______________________^^^____________________________________________ I have found the following code reliable for getting the Telebit's attention: { . . . (void) ioctl(fd, TCSBRK, 0); /* send a break to the modem */ (void) sleep(1); for(i = 0; i < 7; i++) /* send some A's with a 1 sec pause */ { (void) write(fd, "A", 1); (void) sleep(1); } . . . } This sends a break, and a string of "A"'s (with a pause between them). It works every time, and you don't have to muck with DTR. Andy Pitts {gladys, bakerst}!rbdc!andy
nerd@percival.UUCP (Michael Galassi) (02/20/88)
In article <5445@elroy.Jpl.Nasa.Gov> stevo@elroy.UUCP (Steve Groom) writes: >... 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). What I did to circumvent the autobauding problem was to always talk to the modem at 19.2 KBpS, then I switch baudrate based on the result code returned by the modem. About a week ago I added code to togle dtr before talking to the modem so I would be guaranteed that it is already at the baudrate I expect it to be and all its internal buffers would be flushed. I posted the dialer (along with a USR Courier dialer) about a month ago. If anyone is using it and would like an updated version I will be happy to send it along, just drop me a line. If there is enough responce I will re-post it. Note: The way I have set things up works in an environment where I have to disable dialin on the port everytime I want to dialout and then re- enable dialin when I'm done, it works smoothly this way but there is no reason for which it should not work on a dialin only line. -michael -- Michael Galassi | If my opinions happen to be the same as ...!tektronix!tessi!percival!nerd | my employer's it is ONLY a coincidence, ...!uunet!littlei!percival!nerd | of cource coincidences DO happen.