[GreenKeys] Stop bits and TTY-Connect

[Jerry]

If you stop and think about this a bit, just set your 'TTY-Connect 
system' to operate at 1.0 length stop bit, and it should just sit there 
and 'hang' waiting for the next available 'start' transition.  That 
could be 1, 1.42, 1.5 or 2.0 or more, as it would be 'ready' at 'one' 
and not miss a thing, while it was waiting for the next negative 
transition or start bit...

Thats how all the old time UART setups were setup ala the UT-4 etc that 
Irv introduced way back when...Worked just fine.  You could copy 
whatever stop bit length the other guy was sending with no problems...

Jer -n6jp-

----- Original Message ----- 
From: "gil smith" <gil at vauxelectronics.com>
To: "George B. Hutchison" <w7tty at readysetsurf.com>
Cc: <greenkeys at mailman.qth.net>
Sent: Friday, February 25, 2005 2:07 PM
Subject: Re: [GreenKeys] Stop bits and TTY-Connect


: At 08:16 AM 2/25/2005, George Hutchison wrote:
: >The extended stop bit was implimented because, back in them greasy,
: >smelly days, the U.S. power grid was not a locked-in...
:
: At 08:20 AM 2/25/2005, Bob Camp wrote:
: >My biggest concern is that if somebody *is* using a computer to 
generate a
: >signal that they do it in a fashion that does not mess up a 
mechanical
: >machine....
:
:
: Hi George and gang:
:
: Yes indeed, we need to make this internet system work for both 
computer and
: mechanical machines.  Let me make a quick point on stop bits and 
throughput:
:
: By making stop bits longer, you effectively insert a delay between
: characters, since the stop bit is mark, which is the same state as 
line
: idle.  Using 1.42 bits for stop is the fastest that chars should be
: streaming to your typical baudot tty.  Pushing the envelope (eg: 
western
: union) by shortening stop bits can improve throughput a bit, but 
throughput
: should not be of concern to us today.  We just want to get our 
machines
: printing properly.
:
: I'd rather see longer stop bits than shorter, since there is a 
practical
: implication with my TTY-Connect system, as I regenerate the data with 
a
: 1.5-bit stop.  So a constant stream of packed 1.42-stop-bit baudot 
text
: will overflow my input buffer at some point.  I have not looked at 
stop
: bits on M14 or M28 TDs -- anyone know whether the chars are packed 
that
: closely when reading a tape?
:
: This does not seem to be an issue with ITTY, as I measured 2-stop-bits 
on
: George's stream.  A 2-bit stop is good --  the absolute minimum 
TTY-Connect
: can tolerate is a 1.5-bit stop, without the input buffer creeping
: full.  Could likely tweak this to 1.42, but I'd rather not.
:
: So if the incoming stream is packed and constant with 1.5-bit or 
greater
: stop, the system will keep up.  But there is also the issue of
: automatically inserting a CRLF string when line length is exceeded. 
In
: TTY-Connect, you can configure it to insert up to an 8-character 
string
: when you hit a certain number of chars (after the previous CR) on a
: line.  The default  string is CR CR LF LTRS LTRS sent at 72 chars. 
Now
: this will prevent overprinting at the end of the line, but it still 
takes
: time to send these chars, and they get inserted into the output buffer 
to
: do this.  If the incoming stream is at a constant 1.5-bit stop, 
repeated
: auto-CRLF action will overflow the output buffer at some point.
:
: Delays between text bursts are needed to allow auto-CRLF insertions 
(and
: the resulting lengthened text block), to empty from the output buffer.
:
: Of course this is not an issue with George's feed, which includes a 
proper
: end-of-line sequence, but I mention it here since it is related to
: throughput.  So George, if you keep the line lengths under 72, and use
: 2-bit stop pulses, as you are currently, TTY-Connect will be happy.
:
: gil
:
:
:
:
: Vaux Electronics, Inc.
: 480-354-5556
: (fax: 480-354-5558)
: www.vauxelectronics.com
:
:
:
: _______________________________________________
: GreenKeys mailing list
: GreenKeys at mailman.qth.net
: http://mailman.qth.net/mailman/listinfo/greenkeys
: