[GreenKeys] Stop bits and TTY-Connect

[gil at baudot.net]

Hi Jerry:

It's not the baudot input side of things -- actually, I am only
requiring a half stop bit on input.  But on baudot output, I use 1.5
stop bits to keep the  mechanical machines happy.  Just happens that a
half bit was easy to code.  I could add code to set it to exactly 1.42,
but it is hopefully not needed.  And I figured that 1.5-bit stops would
give the machine a little more margin to get back to an idle state.

However, when the baudot input and output are at the same speed, the
input cannot arrive faster than the output is leaving, or the input
buffer will overflow.  In this case, 2-bit stops, as George has
implemented, is great.  My current concern is reading tapes from a TD. 
I need to set one up and measure the data rate to see if the chars are
actually packed tightly enough to result in 1.42-bit (or anything less
than 1.5-bit) stops.  I also need to look at how closely they are
packed on typical rtty broadcasts.

This is not an issue when baudot is being converted from low to high
speed.  And if baudot is being converted from high to low speed, a pc
must be in the loop to provide buffering, and is throttled with
xon/xoff, so there is still no problem.  It is also not a problem when
the ascii 232 port is connected to a baudot port, since the pc is again
throttled with xon/xoff.  It is only an issue for baudot connections at
the same speed, when the input is streaming continuously, and the stop
bits are less the 1.5-bits long.  May be an issue for tape reads, I'm
not sure yet.  But most people will be outputting to page printer or
tape, from an ITTY feed or radio feed.  Not sure if anyone wants to
read/send tapes.

As Gilda Radner used to say, "It's always something."

gil


> -------- Original Message --------
> Subject: Re: [GreenKeys] Stop bits and TTY-Connect
> From: "Jerry" <gh1lockett at bak.rr.com>
> Date: Fri, February 25, 2005 4:11 pm
> To: "gil smith" <gil at vauxelectronics.com>, "George B. Hutchison"
> <w7tty at readysetsurf.com>
> Cc: greenkeys at mailman.qth.net
> 
> 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
> : 
> 
> 
> _______________________________________________
> GreenKeys mailing list
> GreenKeys at mailman.qth.net
> http://mailman.qth.net/mailman/listinfo/greenkeys