[GreenKeys] Stop bits and TTY-Connect

Sat Feb 26 16:06:18 EST 2005

Hi

The one case that I can see where this would be a problem is on picture 
tapes. You would be running big long tapes out of the tape reader and 
printing them at full speed. The 1.42 in / 1.5 out thing would hit you 
at a rate of 0.08 UI per character. With no buffer this would mess you 
up every 13 characters. With a thousand character buffer you could run 
for 13K characters. That's still pretty easy to exceed with a "one 
hour" picture.

Obviously the tape could be controlled by a buffer check and it would 
take care of the whole problem. That's fine if the data stream is right 
in your shack. It's a bit harder if the data stream is remote. (Getting 
a bit off the TTY-Connect subject though).

	Take Care!

		Bob Camp
		KB8TQ

On Feb 26, 2005, at 2:10 PM, gil at baudot.net wrote:

> Hi Jerry:
>
> Yes, I have fifo buffers for both input and output streams, with
> intelligence (diddle filters, auto-crlf...) in the middle.  Chars are
> pulled out of the input buffer, processed as needed, and placed in the
> output buffer.  There is no uart involved, as both the input and output
> streams use an interrupt routine sampling/regenerating data at 250-us
> intervals.  The input side only requires a minimum 0.5-bit stop, but
> the output side sends a 1.5-bit stop.  It's actually a bit more
> complicated, since these ports are bi-direcional (eg: a TU-to-TTY
> stream using two buffers, and a TTY-to-TU stream also using two
> buffers).  It's not likely people will be typing on their tty
> keyboards, but the system is set up for full 2-way communication (as
> well as optional speed conversion in both directions, and optional
> baudot-to-ascii conversion in both directions).  There is a uart used
> for the pc port, but that is not related to the data streams for the TU
> or TTY ports.
>
> I am just pointing out that the data regeneration on the output side of
> things is designed for mechanical machines, and is set up to provide
> 1.5-bit stop bits.  Therefore, if the input stream has characters
> packed tightly together at 1.42-bit stops, the input buffer will
> overflow at some point.  You can make buffers bigger, but eventually
> there will be characters lost.  Now if there is some delay time added
> to the data stream (eg: dead time for a few seconds between stories),
> this will also help by allowing the buffers to empty out further.
>
> gil
>
>> -------- Original Message --------
>> Subject: Re: [GreenKeys] Stop bits and TTY-Connect
>> From: "Jerry" <gh1lockett at bak.rr.com>
>> Date: Fri, February 25, 2005 7:39 pm
>> To: gil at baudot.net
>> Cc: "John Strand" <sx43 at earthlink.net>, "Fred Caughell"
>> <fcaughell at bak.rr.com>, "GeorgeH" <w7tty at readysetsurf.com>
>>
>> Hmmm, don't you have a FIFO buffer of some sort in between the input 
>> and
>> output of the uart chip i.e. in the serial to parallel area?  I seem 
>> to
>> recall experimenting with all sorts of different chips and buffer 
>> sizes
>> to take care of things like that.  Of course its been a year or two
>> since I paid any attention to those old designs.  hi.
>>
>> I remember Irvin had software built into his rtty program whereby you
>> could speed it up to one stop pulse or slow it down to 2 or 3 or more.
>> In fact there towards the end of that development of his rtty program 
>> he
>> had it setup automatically to change the length of the stop bits
>> depending on how full the buffer got.  As it started to fill up, the
>> output would speed up, but if you were typing slowly, it would add 
>> stop
>> bits and slow the entire stream down.  Geeze, its been years since I
>> thought about this stuff.
>>
>> I originally built up a interface circuit always insured you were
>> sending letters as the fill character, even if you typed a number
>> character and then stopped typing, it would then send a letters to get
>> everything back down into normal case.  It also blocked more than one
>> letters fill character at a time, to the local computer, while sending
>> it out to the mechanical printer.  (I think, hi, would have to get out
>> my old drawings to recall exactly what it did!)   I know it evolved 
>> over
>> a period of time and made lots of changes in the logic to get it to 
>> this
>> and that... Only made one prototype and used it for several years.
>> Think its still over the drawer along with Bill's TU... hi.
>>
>> Jer
>>
>>
>> ----- Original Message -----
>> From: <gil at baudot.net>
>> To: "Jerry" <gh1lockett at bak.rr.com>
>> Cc: <greenkeys at mailman.qth.net>
>> Sent: Friday, February 25, 2005 6:14 PM
>> Subject: RE: [GreenKeys] Stop bits and TTY-Connect
>>
>>
>> : 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
>
> _______________________________________________
> GreenKeys mailing list
> GreenKeys at mailman.qth.net
> http://mailman.qth.net/mailman/listinfo/greenkeys
>