uucp VS 4.2

[Brian Thomson]

On the Framing Errored-ness of Bit Strings, masscomp!trb has this
to say:
    atsign is has the binary value 01000000, and if if you send it too
    slowly, you'll get a cute little one bit with no stop bit.

    ^U is 00010101, which isn't pretty when you're looking for a long
    string of 0's to look like a break.

This presents me with a fine opportunity to belabour the uninteresting.
You don't need "a long string of 0's" to guarantee a framing error,
just a 0 in the correct place.

Case 1:  transmitter faster than receiver
    The intercharacter idle line looks like a giant stop bit, so
    no framing error here.  Avoid this case by starting getty at a
    high speed and stepping down.

Case 2: trasmitter 1/2 receiver speed.
    Number the data bits from right to left (this is the order in
    which they are transmitted), beginning at 0.  Each transmitter
    bit time will be received as two bits, so the receiver will
    look for a stop bit in the second half of transmitted data bit 3.
    Both ^U and @ have a 0 in this position, so both should
    cause framing errors.

Case 3: transmitter 1/4 receiver speed
    The receiver now interprets the second quarter of data bit 1
    as its stop bit.  Again, both ^U and @ win here.

Case 4: transmitter 1/8 receiver speed
    A common case, corresponding to transmission at 1200 baud and reception
    at 9600.  Here the stop bit is "seen" in transmitted data bit 0.
    This is where ^U loses.

Case 5: transmitter 1/16 or less of receiver speed
    Receiver sees only the start bit, hence is guaranteed a framing error.
-- 
		    Brian Thomson,	    CSRG Univ. of Toronto
		    {linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!uthub!thomson