Path: utzoo!attcan!uunet!pcrat!rick
From: rick@pcrat.UUCP (Rick Richardson)
Newsgroups: comp.dcom.modems
Subject: Re: Break definition
Message-ID: <569@pcrat.UUCP>
Date: 9 Sep 88 20:56:54 GMT
References: <402@ucrmath.UUCP> <6095@galbp.LBP.HARRIS.COM>
Reply-To: rick@pcrat.UUCP (Rick Richardson)
Distribution: na
Organization: PC Research, Inc., Tinton Falls, NJ
Lines: 35

In article <6095@galbp.LBP.HARRIS.COM> mhw@wittsend.UUCP (Michael H. Warfield) writes:
>        A break is sent on an async line by placing the  line  in
>the  "low" or "spacing" state (level, tone, what-ever) for two or
>more charracter times.  To a receiver this would  be  seen  as  a
>charracter  of  all zeros, with a framing error (no stop bit) and
>lasting at least 20 bit times (16 data bits  plus  2  start  bits
>plus  two  stop  bits total across the 2 charracter times).  Note
>that that is AT LEAST.  Some UARTS support long and short  breaks

Where did you find the citation that a break is at least 20 bit times?
The only citation I could find (in some obscure CCITT spec) defined
break as the space condition for at least 130 milliseconds.  There
was no formula based on the bps that the interface was operating at.

I'm not saying you are wrong, just that a while back I tried to
find this information and wasn't really happy with finding just
the one definition.  I'm also not saying that all devices do this.
There are definitely devices that work the way you describe.

I believe that sending break as 130 milliseconds or longer of space (0)
is a better definition, though.  No matter what the receiver
speed is set to (if greater than 110 bps), the receiver is
guaranteed to see a break.

I think the best bet is to try to detect short breaks if you
can, but always generate at least the full 130 milliseconds,
if not longer.  Then again, a modem, or other communications (DCE)
device, should attempt to reconstruct the signal at the far end
as near as possible to the way it came in at the near end.
Garbage in...garbage out!!!!  Short breaks in, short breaks out.
-- 
		Rick Richardson, PC Research, Inc.
		rick%pcrat.uucp@uunet.uu.net (INTERNET)
		   uunet!pcrat!rick (UUCP, Personal Mail)
..!pcrat!jetroff (JetRoff Info)		..!pcrat!dry2 (Dhrystone Submissions)