Do I really need to BREAK to change baud rates?

Bill Vermillion bill at bilver.uucp
Thu Dec 27 03:30:28 AEST 1990


In article <134 at mixcom.UUCP> sysop at mixcom.UUCP (System Operator) writes:
 
>SOAP BOX ON
 
>Hey UNIX vendors!  This is (almost) 1991!
>Wake up and smell the coffee!  I want a
>getty for hardwired terminals and one for
>modems that will use the modem's abilities to
>report the baud rate.  Also, the modem getty
>should have the ability to send an init string
>to the modem. In a time of smart hardware,
>why is the software so stupid?
 
>SOAP BOX OFF

Well, at one time we could detect speed change, and it was done in
hardware.

Pin 12 low was 300 and pin 12 high was 1200.  Then along came 2400, and I
saw two different implmentations arrive.   I saw two modems from AT&T and
NEC that added a second pin.  So now we could detect 4 baud rates via
hardware.

At the same time Hayes said, from now on pin 12 high shall be 2400, pin 12
low will not be 2400.    And right then and there the hardware solution
broke.  

I was using hardware detect up until that time and it worked flawlessly.

Now we do have another problem.  The v.22bis specs (2400 bps) says that if
the line gets too bad, you step back to 1200.  So the modems now move back
to 1200, while the software stays at 2400.  

So what do you get - a screen full of garbage, or a disconnect if you are
doing an error checking file protocol.  If hardware speed checking had been
continued it would have been easier.  Now the only real way to make sure
you are talking properly is with your solution to the previous questioner,
modems that used fixed dce/dte rates.  Of course that means good hardware flow
control, and a lot of systems don't handle that very gracefully.

I used Hayes products from the time Dennis was building 300 bps full size
S-100 boards in his garage.   I haven't forgiven them for breaking the
hardware speed standards.



-- 
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
                      : bill at bilver.UUCP



More information about the Comp.unix.xenix.sco mailing list