23 Jan
2014
23 Jan
'14
1:04 a.m.
The NEC uPD7201(A) and Intel 8274 have a misfeature that makes them almost
unusable with modems that employ synchronous modulation (which is almost
all common PSTN modems at bit rates of 1200 bps or higher, except bell 202
and V.23), except when an error control (e.g. MNP or V.42) used between the
modems and flow control is used between the modem and the 7201/8274.
The problem is that due to rate mismatches between the hosts, and between
the host and the modem's sychronous modulation, the receiving end modem may
receive data at a slightly higher rate than it can be sent over the
asynchronous serial line to receiving host. In order to deal with this, the
receiving modem is allowed to send the characters to the receiving host
with a stop bit that is shorter than usual. The stop bits can be as short
as 7/8 of a bit time, or (optionally for an extended signalling range,
which I've never actually uses) as short as 3/4 of a bit time.
This stop bit shaving is part of the ITU-T V.14 standard.
Most UARTs don't have any problem with it, as they typically only sample
the start bit at the middle of the expected bit time. However, the
7201/8274 looks at at least one sample in the bit time, and will consider a
shaved stop bit to be a framing error, which IIRC causes the loss of at
least the next character and usually multiple consecutive characters.
This was a huge problem with 1200 bps and 2400 bps modems on the AT&T 7300
and 3B1 "Unix PC" before the error control protocols (MNP or V.42) became
commonly available in modems.
I learned far more than I (n)ever wanted to know about V.14 when I worked
at Telebit, especially when I was in charge of adding Appletalk Remote
Access Protocol (ARAP) support to the NetBlazer router. ARAP used MNP 3 and
V.42bis compession (a non-standard configuration) on the Macintosh, and
required that any error control (MNP or V.42) and compession be disabled in
the modem. This was done because Apple engineers found at the time that
hardware flow control between the Macintosh and commodity modems was
unreliable, due to limitations of both.
We were implementing a multiline ARAP server on the NetBlazer router and
didn't have enough CPU power to do compession for more than a few lines.
Since we only officially supported use of our own modems on the NetBlazer,
the solution was for us to implement the unusual combination of MNP 3 and
V.42bis in our modems (T1600, T3000, and WorldBlazer), and rely on reliable
flow control between the router and the modem.
Running V.42bis compression used nearly all of the available CPU cycles of
the modem. We also had to deal with another aspect of V.14, stop bit
deletion, which happens when the async data to be transmitted is overspeed
with regard to the modulation. It allows the transmiting modem to
completely discard the stop bit of up to one out of eight consecutive
characters (one of four for dxtended rate), and the receiving side has to
reinsert them. Our modem used an SCC channel of the MC68302 to send clocked
asynchronous characters to the DSP bit pump (when not using V.42 error
control, and V.42 is not used when dping MNP 3). Unfortunately the SCC
channel doesn't know about V.14 stop bit deletion (or the corresponding
reinsertion on receive), so the SCC has to be used in "raw" mode rather
than clocked asynchronous mode, which means that the control CPU has to run
a software UART to convert the character stream to a suitable raw bit
stream for the SCC.
A softwate UART is a piece of cake, you might say, and normally you'd be
right. Unfortunately the modem engineers had written the world's fanciest,
all-singing, all-dancing software UART, which took nearly all of the CPU
time of the control processor. Which was normally fine, since you never
used V.42bis compression over an asynchronous data stream over the
synchronous modulation. Except, of course, when you're running V.42bis
compression over MNP 3 error control to support ARAP.
I offered to write a more efficient software UART, using under 10% of the
CPU instead of over 70%, and the modem engineers claimed that it couldn't
be done. The fundamental problem was that their software UART was in fact
doing everything a single bit at a time. To do it efficiently, you do as
much as possible a byte at a time, using a few kilobytes of data tables to
assist.
Another problem was that the modem control code was written as a series of
tasks that all were called in round-robin sequence all of the time, whether
there was anything to do or not. There was no easy way to determine CPU
utilization because you couldn't do it as the complement of the idle time
because there was no idle time to measure. Even when it was doing nothing
it was running full-tilt.
I'm told that eventually Apple switched from their wacky proprietary ARAP
protocol to PPP, with the modem doing normal V.42 error control and V.42bis
compression, but by then I had moved on to other projects that were less
Sisyphean.
Somewhat by coincidence, before working for Telebit I worked at Apple doing
QA for (among other things) the Macintosh MNP 3 and V.42 drivers used by
Appletalk Remote Access, then known by the codename "976".
Eric
23 Jan
23 Jan
1:15 a.m.
Wikipedia claims that MNP 3 used a synchronous interface to the modem
modulation (like V.42), so either my memory is flaky and ARAP used MNP 2,
or MNP 3 still had provisions to be used over an async channel.
1:55 a.m.
On 01/22/2014 05:04 PM, Eric Smith wrote:
The NEC uPD7201(A) and Intel 8274 have a misfeature
that makes them almost
unusable with modems that employ synchronous modulation (which is almost
all common PSTN modems at bit rates of 1200 bps or higher, except bell 202
and V.23), except when an error control (e.g. MNP or V.42) used between the
modems and flow control is used between the modem and the 7201/8274.
I've put Z80 SIO/DART and 8274 chips in real production products.
They're similar, but obviously not identical. However, if you've
programmed one, you'd be right at home with the other.
That being said, I've never used one in synchronous mode. For that,
I've always used 8251A or 2651/2661 chips, with a preference for that
latter.
--Chuck
3:58 a.m.
On Jan 22, 2014 6:58 PM, "Chuck Guzis" <cclist at sydex.com> wrote:
similar, but obviously not identical. However, if you've programmed one,
you'd be right at home with the other.
On 01/22/2014 05:04 PM, Eric Smith wrote:
>
> The NEC uPD7201(A) and Intel 8274 have a misfeature that makes them
almost
> unusable with modems that employ synchronous
modulation (which is almost
> all common PSTN modems at bit rates of 1200 bps or higher, except bell
202
> and V.23), except when an error control (e.g. MNP
or V.42) used between
the
modems and
flow control is used between the modem and the 7201/8274.
I've put Z80 SIO/DART and 8274 chips in real production products. They're
That being said, I've never used one in synchronous mode. For that, I've
always used 8251A or 2651/2661 chips, with a preference for that latter.
The described problem occurs when using async mode, not sync, but when
using a modem that does synchronous modulation, which is all modems that
use modulations fancier than FSK, i.e. voice-band POTS modems at 2400 bps
and up, and full-duplex 1200 bps, and when NOT using MNP or V.42 error
control implemented in the modem. This means that it was a common
occurrence when using the uPD7201/8274 with early 212, V.22, and V.22bis
modems. It mostly was not seen with V.32 and later modems because those
almost always use V.22 error control.
I'm not sure what other common microcomputer products used the
uPD7201/8274, but this problem was very well known in the mid-1980s among
AT&T 7300 and 3B1 users. It was especially aggravating if you had spent the
money for a modem with MNP and/or V.22, but the modem bank you called into
did not support it.
The 8251A, 2651, 2661, 2681, 6551, 6850, 68681, Z80-SIO, Z8030/8530 SCC,
and almost every other UART and USART in the known universe did not have
this problem. It was a poor design choice (ay least in hindsight) by the
uPD7201 designers, in not allowing their chip to accept a slightly short
stop bit. I think everyone else accepted not due to planning for V.14, but
simply because they copied the sampling method used by the earliest UARTs,
which just happened by chance not to be affected by slightly short stop
bits.
Of course, if UARTs that couldn't tolerate short stop bits had been
commonplace, the CCITT would probably not have promulgated stop bit shaving
in V.14, and would have had to come up with a different method of rate
matching.
5:29 a.m.
On 01/22/2014 07:58 PM, Eric Smith wrote:
The described problem occurs when using async mode,
not sync, but when
using a modem that does synchronous modulation, which is all modems that
use modulations fancier than FSK, i.e. voice-band POTS modems at 2400 bps
and up, and full-duplex 1200 bps, and when NOT using MNP or V.42 error
control implemented in the modem. This means that it was a common
occurrence when using the uPD7201/8274 with early 212, V.22, and V.22bis
modems. It mostly was not seen with V.32 and later modems because those
almost always use V.22 error control.
Interesting. When I used the 8274, anything faster than 2400 would have
been a leased line or hardwired. A bit before before the Trailblazer.
Is there an app note or errata sheet from Intel on 8274 regarding this?
--Chuck
4:02 p.m.
On Jan 22, 2014 10:34 PM, "Chuck Guzis" <cclist at sydex.com> wrote:
Is there an app note or errata sheet from Intel on
8274 regarding this?
I've never seen anything from Intel or NEC about it.
On the AT&T 7300 and 3B1, the workaround was to use the dual serial
expansion board (available woth or without RAM expansiom) which used a
Z8530 rather than the uPD7201/8274.
24 Jan
24 Jan
3:23 a.m.
On 01/22/2014 07:58 PM, Eric Smith wrote:
The described problem occurs when using async mode,
not sync, but when
using a modem that does synchronous modulation, which is all modems that
use modulations fancier than FSK, i.e. voice-band POTS modems at 2400 bps
and up, and full-duplex 1200 bps, and when NOT using MNP or V.42 error
control implemented in the modem. This means that it was a common
occurrence when using the uPD7201/8274 with early 212, V.22, and V.22bis
modems. It mostly was not seen with V.32 and later modems because those
almost always use V.22 error control.
I went back to the 8274 datasheet and it seems that the designers
considered this to be a feature. In theory, one could simply start
the "hunt" for the next start bit as soon as the last data bit frame had
passed--I have no doubt that many chips actually work exactly this
way--that the "stop bit" is a simply an indeterminate marking period
until a space signals the start of the "start bit".
But Intel seems to say in its datasheet that a space during the period
of a stop bit is a framing error--and goes on to say that a half-bit
period is added in case of a framing error. Doubtless Intel considered
this a feature.
What I don't know is if the period of the mandatory space bit on receive
is also governed by the "number of stop bits" setting in the mode setup
word--or if, as in many UART chips, this controls only the length of the
stop bit on transmit.
Or, as some Intel applications engineer might have said, "That's not a
bug, that's a feature."
--Chuck
3:46 a.m.
On Jan 23, 2014, at 22:23, Chuck Guzis <cclist at sydex.com> wrote:
When I've done UARTs in FPGAS, I typically only do the
sampling in the middle of the bit period. I do check for
a stop bit in order to detect framing errors, but slicing off
the last eighth of the stop bit would probably go entirely
unnoticed by any of my implementations, which seem
to follow most "best practices" as far as efficiency goes.
- Dave
On 01/22/2014 07:58 PM, Eric Smith wrote:
The described problem occurs when using async mode, not sync, but when
using a modem that does synchronous modulation, which is all modems that
use modulations fancier than FSK, i.e. voice-band POTS modems at 2400 bps
and up, and full-duplex 1200 bps, and when NOT using MNP or V.42 error
control implemented in the modem. This means that it was a common
occurrence when using the uPD7201/8274 with early 212, V.22, and V.22bis
modems. It mostly was not seen with V.32 and later modems because those
almost always use V.22 error control.
I went back to the 8274 datasheet and it seems that the designers considered this to be a
feature. In theory, one could simply start the "hunt" for the next start bit
as soon as the last data bit frame had passed--I have no doubt that many chips actually
work exactly this way--that the "stop bit" is a simply an indeterminate marking
period until a space signals the start of the "start bit".
But Intel seems to say in its datasheet that a space during the period of a stop bit is a
framing error--and goes on to say that a half-bit period is added in case of a framing
error. Doubtless Intel considered this a feature.
What I don't know is if the period of the mandatory space bit on receive is also
governed by the "number of stop bits" setting in the mode setup word--or if, as
in many UART chips, this controls only the length of the stop bit on transmit.
4:41 a.m.
On Jan 23, 2014 8:54 PM, "David Riley" <fraveydank at gmail.com> wrote:
When I've done UARTs in FPGAS, I typically only do
the
sampling in the middle of the bit period.
I'm sure you are aware of it, but for the benefit of others, it should be
noted that this is the middle of the bit period from the receiving UART's
perspective, and may not match the transmitting UART's middle-of-stop-bit
time for two reasons:
1) There may be a timebase mismatch between the two ends. In the 1980s an
1990s, almost all async comms were locked to a crystal oscillator or at
least a ceramic resonator, so there was not much mismatch. Before that
there were mechanical async devices (e.g., Teletypes), and even some
electronic devices that used poor timebases such as RC oscillators (e.g.,
early PDP-11/05). It was considered acceptable to have a timebase error at
each end of more than +/- 1%. By the end of an 10-bit or 11-bit character,
the cumulative timebase error is significant. In recent year there are an
increasing number of async interfaces that are using various forms of
trimmed electronic oscillators, or even temperature-compensated RC
oscillators, so non-trivial rate mismatches are become more common again.
2) The receiving UART typically oversamples the receive data signal at 16x
the receive bit rate. The receiver uses the first sample that it detects a
space (vs mark) signal as the leading edge of the start bit, and samples
the bits at 8 +/- 16n clock cycles thereafter. That introduces a 1/16 bit
time uncertainty in the timing of the samples, though that is
non-cumulative and thus usually of little concern.
I do check for
a stop bit in order to detect framing errors, but slicing off
the last eighth of the stop bit would probably go entirely
unnoticed by any of my implementations, which seem
to follow most "best practices" as far as efficiency goes.
That's right. Normal UART receivers, once they've sampled the putative
middle of the stop bit, will look for a leading edge of a start bit at
every subsequent sample time, rather than delaying until the expected end
of that stop bit.
V.14 stop bit shaving aside, I suspect the uPD7201/8274 receiver would be
much less forgiving of a rate mismatch at the extreme of the normally
allowed timing tolerance than other UARTs.
The problem exists in the uPD7201/8274 and the uPD7201A. I don't know
whether NEC fixed it in the uPD72001.
3:30 p.m.
On Jan 23, 2014, at 11:41 PM, Eric Smith <spacewar at gmail.com> wrote:
Exactly. The stop bit is just the idle state of the line, and if
all is going right, it's indistinguishable from an idle line. So
as soon as I see the stop bit(s) (sometimes 2 are required), I
start hunting for a start bit at the high sample rate, which means
it could be as soon as the middle of the last stop bit.
Unless one were being particularly pedantic about framing, I can't
imagine why someone would design the chip like that, unless they
sampled at the end of the bit time (which seems like a bad idea).
I have no idea what the internal construction of the chip is, of
course, so I may be entirely off base in guessing how it's doing
the sampling. It just seems it's probably a waste of silicon to
be doing that check.
- Dave
On Jan 23, 2014 8:54 PM, "David Riley"
<fraveydank at gmail.com> wrote:
Yup. In my line of work, most serial comms are running off the clock
of the host micro, so rate mismatches aren't super uncommon. Most
users shoot for just a few percent max, because you don't want to
accumulate more than half a bit time of error by the end of 10 bits
(assuming 8N1, which is what most people use in systems I work with).
If you're shaving the end of a stop bit, you bring that tolerance in
even lower, but 1-2% shouldn't kill it.
I've had very little luck with bitrates of any significance running
off the built-in oscillators on micros, which generally have clock
tolerances in the significant single digits. I generally have OK
luck with 9600 baud, but since it's a matter of percentages more
than absolute speed, that's probably just luck. If I really NEED
it to work, a crystal (or a clock synchronous with the other end
of the line, if I were to be so lucky) is the way to go.
The 8530's digital PLL mode is quite nice, but of course it doesn't
work for async comms. Quite handy for SDLC, though (on which I've
actually had to work more than you might expect for modern devices
recently).
When I've done UARTs in FPGAS, I typically
only do the
sampling in the middle of the bit period.
I'm sure you are aware of it, but for the benefit of others, it should be
noted that this is the middle of the bit period from the receiving UART's
perspective, and may not match the transmitting UART's middle-of-stop-bit
time for two reasons:
1) There may be a timebase mismatch between the two ends. In the 1980s an
1990s, almost all async comms were locked to a crystal oscillator or at
least a ceramic resonator, so there was not much mismatch. Before that
there were mechanical async devices (e.g., Teletypes), and even some
electronic devices that used poor timebases such as RC oscillators (e.g.,
early PDP-11/05). It was considered acceptable to have a timebase error at
each end of more than +/- 1%. By the end of an 10-bit or 11-bit character,
the cumulative timebase error is significant. In recent year there are an
increasing number of async interfaces that are using various forms of
trimmed electronic oscillators, or even temperature-compensated RC
oscillators, so non-trivial rate mismatches are become more common again. 2) The receiving UART typically oversamples the
receive data signal at 16x
the receive bit rate. The receiver uses the first sample that it detects a
space (vs mark) signal as the leading edge of the start bit, and samples
the bits at 8 +/- 16n clock cycles thereafter. That introduces a 1/16 bit
time uncertainty in the timing of the samples, though that is
non-cumulative and thus usually of little concern.
Indeed, though it factors into the overall margin for byte time.
I do check
for
a stop bit in order to detect framing errors, but slicing off
the last eighth of the stop bit would probably go entirely
unnoticed by any of my implementations, which seem
to follow most "best practices" as far as efficiency goes.
That's right. Normal UART receivers, once they've sampled the putative
middle of the stop bit, will look for a leading edge of a start bit at
every subsequent sample time, rather than delaying until the expected end
of that stop bit. 
25 Jan
25 Jan
12:26 a.m.
On 01/24/2014 10:30 AM, David Riley wrote:
The total error for a 10 bit char has to be less
than 8/160 clock times
or less than a few percent.
Exactly. The stop bit is just the idle state of the line, and
if
all is going right, it's indistinguishable from an idle line. So
as soon as I see the stop bit(s) (sometimes 2 are required), I
start hunting for a start bit at the high sample rate, which means
it could be as soon as the middle of the last stop bit. The edge of the start bit
starts the half bit counter then every center
is expected to be 16 bit times later.
On Jan 23, 2014, at 11:41 PM, Eric Smith <spacewar
at gmail.com> wrote:
> On Jan 23, 2014 8:54 PM, "David Riley" <fraveydank at gmail.com>
wrote:
>> When I've done UARTs in FPGAS, I typically only do the
>> sampling in the middle of the bit period.
> I'm sure you are aware of it, but for the benefit of others, it should be
> noted that this is the middle of the bit period from the receiving UART's
> perspective, and may not match the transmitting UART's middle-of-stop-bit
> time for two reasons:
>
> 1) There may be a timebase mismatch between the two ends. In the 1980s an
> 1990s, almost all async comms were locked to a crystal oscillator or at
> least a ceramic resonator, so there was not much mismatch. Before that
> there were mechanical async devices (e.g., Teletypes), and even some
> electronic devices that used poor timebases such as RC oscillators (e.g.,
> early PDP-11/05). It was considered acceptable to have a timebase error at
> each end of more than +/- 1%. By the end of an 10-bit or 11-bit character,
> the cumulative timebase error is significant. In recent year there are an
> increasing number of async interfaces that are using various forms of
> trimmed electronic oscillators, or even temperature-compensated RC
> oscillators, so non-trivial rate mismatches are become more common again.
Actually the TTY was locked to the power line and that was at laest .02%
over time and because of inertia that had a a long term effect only.
Yup. In my line of work, most serial comms are
running off the clock
of the host micro, so rate mismatches aren't super uncommon. Most
users shoot for just a few percent max, because you don't want to
accumulate more than half a bit time of error by the end of 10 bits
(assuming 8N1, which is what most people use in systems I work with).
If you're shaving the end of a stop bit, you bring that tolerance in
even lower, but 1-2% shouldn't kill it.
Depends of if your shaving the sent
stop bit or the received version of it.
All parts sampled in the middle of the bit determined by the start bit.
Usually the clock was 16X that so in 10 bit times (one transmitted
character)
you had to be well off to miss by a half bit.
I've had very little luck with bitrates of any
significance running
off the built-in oscillators on micros, which generally have clock
tolerances in the significant single digits. I generally have OK
luck with 9600 baud, but since it's a matter of percentages more
than absolute speed, that's probably just luck. If I really NEED
it to work, a crystal (or a clock synchronous with the other end
of the line, if I were to be so lucky) is the way to go.
I ran up to 115300 with no issues other than could the system keep up with
a character rate of 11530 bytes/sec. Most could but not all.
The 8530's digital PLL mode is quite nice, but of
course it doesn't
work for async comms. Quite handy for SDLC, though (on which I've
actually had to work more than you might expect for modern devices
recently).
Note that the 8530 was the SIO with DPLL and DMA so if you had those
things in the system you had a SIO. The 8530 could go faster, and the
DMA lighted the processor load some. Though the CPU still had to mange
buffers and keep up with status and errors.
2) The
receiving UART typically oversamples the receive data signal at 16x
the receive bit rate. The receiver uses the first sample that it detects a
space (vs mark) signal as the leading edge of the start bit, and samples
the bits at 8 +/- 16n clock cycles thereafter. That introduces a 1/16 bit
time uncertainty in the timing of the samples, though that is
non-cumulative and thus usually of little concern.
Indeed, though it factors into
the overall margin for byte time. I do check for
a stop bit in order to detect framing errors, but slicing off
the last eighth of the stop bit would probably go entirely
unnoticed by any of my implementations, which seem
to follow most "best practices" as far as efficiency goes.
That's
right. Normal UART receivers, once they've sampled the putative
middle of the stop bit, will look for a leading edge of a start bit at
every subsequent sample time, rather than delaying until the expected end
of that stop bit. Unless one were being particularly pedantic about
framing, I can't
imagine why someone would design the chip like that, unless they
sampled at the end of the bit time (which seems like a bad idea).
I have no idea what the internal construction of the chip is, of
course, so I may be entirely off base in guessing how it's doing
the sampling. It just seems it's probably a waste of silicon to
be doing that check.
What if they sampled the falling end and then center insure that the
start bit
wasn't a false transistion (noise)? Same with stop bits, if you expect
2 stops and
you see a transistion before the end of the second there is an error
there that might
be worth flagging in some system.
Allison
24 Jan
24 Jan
4:58 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/23/2014 07:46 PM, David Riley wrote:
When I've done UARTs in FPGAS, I typically only do
the
sampling in the middle of the bit period. I do check for
a stop bit in order to detect framing errors, but slicing off
the last eighth of the stop bit would probably go entirely
unnoticed by any of my implementations, which seem
to follow most "best practices" as far as efficiency goes.
I've always detested the term "stop bit"--this should have been called
"inter-character time" or some such thing. It's not a bit; it carries
no information and talking about 1.5 "bits" in the case of 75 bps
5-level transmission is just plain insanity.
Back to Eric's observation--does anyone with a mechanical terminal (e.g.
ASR 33, Flexowriter, 2741, etc.) accommodate shortening the "stop bit"
interval? In particular, those devices requiring only 1 "stop bit"...
--Chuck
5:47 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
I've always detested the term "stop
bit"--this should have been
called "inter-character time" or some such thing. It's not a bit; it
carries no information
It carries just as much information as the start bit. Bits do not
necessarily carry information in the sense of anti-redundancy; for
example, the high bits in the octets making up this email carry
little-to-no information, since they're all the same, but they're still
real bits just the same.
and talking about 1.5 "bits" in the case of
75 bps 5-level
transmission is just plain insanity.
I'm not sure what's "5-level" about it, but I think "just plain
insanity" is overstating the case; it seems fair to me to consider it a
kind of shorthand for "1.5 bit times".
Back to Eric's observation--does anyone with a
mechanical terminal
(e.g. ASR 33, Flexowriter, 2741, etc.) accommodate shortening the
"stop bit" interval? In particular, those devices requiring only 1
"stop bit"...
For reliable operation, receiving devices must accommodate a slightly
short stop bit; otherwise, if the sender's clock is slightly faster
than the receiver's, streaming characters back-to-back will produce
phase drift and eventually a framing error.
I don't know enough about most UARTs to comment on them in this regard,
but I think I once saw documentation on one which implied that it was
willing to tolerate receiving a character that was only (what the
receiver's clock says is) only a little over 9.5 bit times long,
because it samples in the middle of (its idea of) each bit time,
starting half a bit time from the beginning of the start bit, and,
provided the stop-bit's sample shows the correct level, it is
immediately ready to accept a new start bit's beginning after that
sample.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
6:12 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Fri, Jan 24, 2014 at 12:47:08AM -0500, Mouse wrote:
Assuming this refers to a Model 15 etc. (e.g. 45 BPS Baudot with 5 bits
per character but they weren't really thinking of them as "bits" so it
was commonly called the "5-level" code), it's actually more like
1.4something
stop bits, since it's just the amount of time it takes the mechanism to finish
its rotation and go back to being stopped against the friction clutch.
It's all analog mechanical stuff (the sampling times are chosen by pegs on
a shaft, like a music box) so there's no reason why the stop period has
to be an exact multiple (or fraction) of anything else.
John Wilson (KC1P)
D Bit
and talking
about 1.5 "bits" in the case of 75 bps 5-level
transmission is just plain insanity.
I'm not sure what's "5-level" about it, but I think "just plain
insanity" is overstating the case; it seems fair to me to consider it a
kind of shorthand for "1.5 bit times".
6:56 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/23/2014 09:47 PM, Mouse wrote:
It carries just as much information as the start bit.
Bits do not
necessarily carry information in the sense of anti-redundancy; for
example, the high bits in the octets making up this email carry
little-to-no information, since they're all the same, but they're still
real bits just the same.
No, stop bits are nothing more than a break in the bit stream that
allows the "start bit" to be synchronized upon--in fact, while there may
be a minimum length for them, there's no practical maximum length.
Synchronous transmission has neither start nor stop bits--after
synchronization with the transmitter is achieved, any gaps in the
transmission are filled with "idle" characters, whose sole purpose is to
mark time (just like the "stop bit")--they're discarded by the receiver.
I'm not sure what's "5-level" about
it, but I think "just plain
insanity" is overstating the case; it seems fair to me to consider it a
kind of shorthand for "1.5 bit times".
Used with older Baudot/Murray teletype gear. But nobody (read your
datasheets) ever calls them anything but "stop bits", not "stop bit
time".
For reliable operation, receiving devices must
accommodate a slightly
short stop bit; otherwise, if the sender's clock is slightly faster
than the receiver's, streaming characters back-to-back will produce
phase drift and eventually a framing error.
A history question--was asynchronous comm ever intended at the outset to
be used for long (i.e. multi-kilobyte) messages? I seem to recall that
most high-speed leased lines used a synchronous link.
I don't know enough about most UARTs to comment on
them in this regard,
but I think I once saw documentation on one which implied that it was
willing to tolerate receiving a character that was only (what the
receiver's clock says is) only a little over 9.5 bit times long,
because it samples in the middle of (its idea of) each bit time,
starting half a bit time from the beginning of the start bit, and,
provided the stop-bit's sample shows the correct level, it is
immediately ready to accept a new start bit's beginning after that
sample.
But is there any point to that in modern gear? In fact, why not a PLL
to synchronize the receiving clock? Return to mark level by the center
of the bit cell should be more than adequate for most applications.
--Chuck
3:35 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 24, 2014, at 1:56 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 01/23/2014 09:47 PM, Mouse wrote:
That's great (and frequently done) if there are enough transitions at
the start to get some sort of PLL lock, but that is typically not the
case with asynchronous comms... you get the start bit, and then you
have data (which could be all zeros). Synchronous protocols like SDLC
have the flag bytes before the transmission, which forms an effective
preamble; most implementations I've seen (granted, not many) often
send two or three flags before the data just to make sure the PLLs
have time to lock before the data starts. SDLC also has fun things
like zero stuffing to ensure that there are enough transitions in
the data to keep the PLL on target.
- Dave
I don't know enough about most UARTs to
comment on them in this regard,
but I think I once saw documentation on one which implied that it was
willing to tolerate receiving a character that was only (what the
receiver's clock says is) only a little over 9.5 bit times long,
because it samples in the middle of (its idea of) each bit time,
starting half a bit time from the beginning of the start bit, and,
provided the stop-bit's sample shows the correct level, it is
immediately ready to accept a new start bit's beginning after that
sample.
But is there any point to that in modern gear? In fact, why not a PLL to synchronize the
receiving clock? Return to mark level by the center of the bit cell should be more than
adequate for most applications.
28 Jan
28 Jan
5:24 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
But is there
any point to that in modern gear? In fact, why not a PLL to s$
That's great
(and frequently done) if there are enough transitions
[...], but that is typically not the case with asynchronous comms...
you get the start bit, and then you have data (which could be all
zeros).
7:24 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/27/2014 09:24 PM, Mouse wrote:
Indeed. Consider a wire which is in the marking
state, then goes to
the spacing state for 312.5 microseconds, returning to mark and staying
there for, say, several milliseconds. (I _think_ I'm using `mark' and
`space' correctly here; they might need switching. By `mark' I mean
the idle state and `space' the other state.) Is that a start bit and
two spacing data bits at 9600 baud (with the rest of the character
being mark bits) or is it a start bit and five spacing data bits (plus
ditto) at 19200 baud? Or is it a framing error at 38400 baud? Or
perhaps just a start bit, with all the data being mark bits, at 3200
baud? Or an entire (8-bit) character of spacing bits at 28800 baud?
Answer: without more information than just the signal on the wire,
there is absolutely no way to tell.
So, is that why one had to hit CR a few times on the old dialup BBS to
get it to determine your modem speed? Because it was impossible?
--Chuck
7:49 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
Indeed.
Consider [...example of particularly ambiguous serial-line
behaviour...]
Answer: without more information than just the signal on the wire,
there is absolutely no way to tell.
So, is that why one had to hit CR a few times
on the old dialup BBS
to get it to determine your modem speed? Because it was impossible?
5:37 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 28, 2014 12:59 AM, "Mouse" <mouse at rodents-montreal.org> wrote:
assumptions about the data - that it's a 0x0d
octet - and that the
speed is one of a handful of relatively standard speeds. (The latter
was generally not in question because the modem you called typically
was not willing to speak more than a handful of speeds out its serial
port in any case.)
Before "Smartmodems", and PSK or QAM modulation, modems were generally
perfectly happy with any data rate you cared to use, up to a limit. Bell
103, for instance, would work perfectly well at 217 bps.
The serial ports and both ends tended to be a lot more picky.
7:30 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 28, 2014, at 12:37 PM, Eric Smith <spacewar at gmail.com> wrote:
On Jan 28, 2014 12:59 AM, "Mouse" <mouse
at rodents-montreal.org> wrote:
Similarly, they would not care about sync vs. async. PLATO used Bell 202 modems for 1260
bps 21 bit sync one way, slow speed (50-100 bps?) 10 bit plus parity async the other way,
on a standard 2 wire phone link.
paul
assumptions about the data - that it's a 0x0d
octet - and that the
speed is one of a handful of relatively standard speeds. (The latter
was generally not in question because the modem you called typically
was not willing to speak more than a handful of speeds out its serial
port in any case.)
Before "Smartmodems", and PSK or QAM modulation, modems were generally
perfectly happy with any data rate you cared to use, up to a limit. Bell
103, for instance, would work perfectly well at 217 bps.
8:37 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 28, 2014 12:53 PM, "Paul Koning" <paulkoning at comcast.net>
wrote:
Similarly, they would not care about sync vs. async.
PLATO used Bell 202
modems for 1260 bps 21 bit sync one way, slow speed (50-100
bps?) 10 bit
plus parity async the other way, on a standard 2 wire phone link.
Bell 202 was asymmetric with provision for line turnaround. 1200/75 was
common. I doubt 1260 would pose any problem, but I'm not sure how much you
could push the slow direction. What could be achieved in practice with 202
(or any FSK modem) was more limited by the performance of the specific
modems than the theoretical limit of the FSK modulation, bandwidth, and
channel SNR.
9 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Tue, 28 Jan 2014, Eric Smith wrote:
On Jan 28, 2014 12:53 PM, "Paul Koning"
<paulkoning at comcast.net> wrote:
I have a hazy memory of the PMMI S-100 modem being able to do 600 baud if
it was talking to another PMMI S-100 modem...
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
Similarly, they would not care about sync vs.
async. PLATO used Bell 202
modems for 1260 bps 21 bit sync one way, slow speed
(50-100 bps?) 10 bit
plus parity async the other way, on a standard 2 wire phone link.
Bell 202 was asymmetric with provision for line turnaround. 1200/75 was
common. I doubt 1260 would pose any problem, but I'm not sure how much you
could push the slow direction. What could be achieved in practice with 202
(or any FSK modem) was more limited by the performance of the specific
modems than the theoretical limit of the FSK modulation, bandwidth, and
channel SNR.
10:17 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 28, 2014, at 3:37 PM, Eric Smith <spacewar at gmail.com> wrote:
On Jan 28, 2014 12:53 PM, "Paul Koning"
<paulkoning at comcast.net> wrote:
Asymmetric, or full duplex four wire. The PLATO case was two wire, with the ?secondary?
reverse channel on the same wire at slow speed. 75 bps sounds plausible.
paul
Similarly, they would not care about sync vs.
async. PLATO used Bell 202
modems for 1260 bps 21 bit sync one way, slow speed
(50-100 bps?) 10 bit
plus parity async the other way, on a standard 2 wire phone link.
Bell 202 was asymmetric with provision for line turnaround. 1200/75 was
common. I doubt 1260 would pose any problem, but I'm not sure how much you
could push the slow direction. What could be achieved in practice with 202
(or any FSK modem) was more limited by the performance of the specific
modems than the theoretical limit of the FSK modulation, bandwidth, and
channel SNR.
9:47 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/28/2014 11:30 AM, Paul Koning wrote:
Similarly, they would not care about sync vs. async.
PLATO used Bell
202 modems for 1260 bps 21 bit sync one way, slow speed (50-100 bps?)
10 bit plus parity async the other way, on a standard 2 wire phone
link.
When did using async parity go out of style? It seems to have slowly
been disappeared from the scene, but I think that some MCUs with
serial-interface bootloaders (e.g. STM32) still require parity of one
sort or another (could be mark or space).
This goes back to the question about not having any additional
information to determine async bit rate.
--Chuck
11:30 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Tue, Jan 28, 2014 at 01:47:18PM -0800, Chuck Guzis wrote:
When did using async parity go out of style?
I certainly don't mind, because it seemed as if it was annoying (inadvertant
mismatch => systems stubbornly refuse to communicate) more often than it was
helpful (tells you about a transmission error so minor that you wouldn't have
noticed otherwise). Protocols already do their own error detection, and for
plain text the problems are usually obvious}i
John Wilson
D Bit
29 Jan
29 Jan
12:43 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/28/2014 03:30 PM, John Wilson wrote:
On Tue, Jan 28, 2014 at 01:47:18PM -0800, Chuck Guzis
wrote:
Seems to me that E71 was pretty much a given in the ASR 33 heyday.
Getting a telegram with garbled characters was probably a very big deal
to WU.
Might as well get rid of magtape parity...
--Chuck
When did using async parity go out of style?
I certainly don't mind, because it seemed as if it was annoying (inadvertant
mismatch => systems stubbornly refuse to communicate) more often than it was
helpful (tells you about a transmission error so minor that you wouldn't have
noticed otherwise). Protocols already do their own error detection, and for
plain text the problems are usually obvious}i
1:40 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 28, 2014, at 7:43 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 01/28/2014 03:30 PM, John Wilson wrote:
I don?t remember ever seeing a Model 33 with parity. And weren?t telegrams sent in 5
level code? If not at the end, then surely before ASCII appeared. And of course before
either, there was Morse code, which doesn?t come with parity either.
All parity can do is convert garbled characters into missing characters. Neither is good.
Telegraph operators probably relied on having good signal quality, ensuring adequate bit
error rate values, at which point parity is not particularly needed. And with Morse,
you?re probably relying on skilled operators ? ECC performed by trained brain cells.
paul
On Tue, Jan 28, 2014 at 01:47:18PM -0800, Chuck
Guzis wrote:
Seems to me that E71 was pretty much a given in the ASR 33 heyday. Getting a telegram
with garbled characters was probably a very big deal to WU. When did using async parity go out of style?
I certainly don't mind, because it seemed as if it was annoying (inadvertant
mismatch => systems stubbornly refuse to communicate) more often than it was
helpful (tells you about a transmission error so minor that you wouldn't have
noticed otherwise). Protocols already do their own error detection, and for
plain text the problems are usually obvious}i 
2:03 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Tue, Jan 28, 2014 at 7:40 PM, Paul Koning <paulkoning at comcast.net> wrote:
I don't remember ever seeing a Model 33 with parity. And weren't
telegrams sent in 5 level code? If not at the end, then surely before
ASCII appeared. And of course before either, there was Morse code, which
doesn't come with parity either.
All parity can do is convert garbled characters into missing characters.
Neither is good. Telegraph operators probably relied on having good
signal quality, ensuring adequate bit error rate values, at which point
parity is not particularly needed. And with Morse, you're probably relying
on skilled operators -- ECC performed by trained brain cells.
Wikipedia seems to indicate that the Model 33 ASR sent 7-bit ASCII with
even parity. I've found that in many of the programs on my PDP-8/E, even
parity is required, which I presume stems from the Model 33 ASR days.
Kyle
7:17 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
I don?t remember ever seeing a Model 33 with parity.
And weren?t
They exist, sort of. From what I've seen and read :
All Model 33 'Typing Uniuts' -- the printer -- expect 8 bits, of which
the high bit is ignored. so you can send them 7 bits with an odd or even
parity bit and they will work. Pairty is not checked.
The punch and reader of the ASR33 handle all 8 bits. That is, the
incoming parity bit will be punched on the tape (it is not checked) and
the parity bit punched on the tape will be read and transmitted. In a
sense they are '8 bit clean'
The keyboard exists in 2 versions. One always sens a '0' for the parity
bit. The other one, which can be recognised by an extra switch contact
block, sends even parity.
I think one of my Model 33s does have the 'parity keyboard'.
-tony
28 Jan
28 Jan
3:53 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 28, 2014, at 2:24 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 01/27/2014 09:24 PM, Mouse wrote:
Yes. There are a few modern micros that have this as an autobaud
option, actually, and they usually expect a CR or three to get
the speed right. It's sort of more handy than having a fixed
console rate, unless you forget and type a few characters at the
beginning of a session and screw up the baud rate until reset.
- Dave
Indeed. Consider a wire which is in the marking
state, then goes to
the spacing state for 312.5 microseconds, returning to mark and staying
there for, say, several milliseconds. (I _think_ I'm using `mark' and
`space' correctly here; they might need switching. By `mark' I mean
the idle state and `space' the other state.) Is that a start bit and
two spacing data bits at 9600 baud (with the rest of the character
being mark bits) or is it a start bit and five spacing data bits (plus
ditto) at 19200 baud? Or is it a framing error at 38400 baud? Or
perhaps just a start bit, with all the data being mark bits, at 3200
baud? Or an entire (8-bit) character of spacing bits at 28800 baud?
Answer: without more information than just the signal on the wire,
there is absolutely no way to tell.
So, is that why one had to hit CR a few times on the old dialup BBS to get it to
determine your modem speed? Because it was impossible?
4:50 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/28/2014 07:53 AM, David Riley wrote:
Yes. There are a few modern micros that have this as
an autobaud
option, actually, and they usually expect a CR or three to get
the speed right. It's sort of more handy than having a fixed
console rate, unless you forget and type a few characters at the
beginning of a session and screw up the baud rate until reset.
Sorry, Dave. My question was rhetorical. I've programmed this myself
back in the dark ages.
--Chuck
24 Jan
24 Jan
4:03 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 24, 2014, at 1:56 AM, Chuck Guzis <cclist at sydex.com> wrote:
...
Synchronous transmission has neither start nor stop bits--after synchronization with the
transmitter is achieved, any gaps in the transmission are filled with "idle"
characters, whose sole purpose is to mark time (just like the "stop
bit")--they're discarded by the receiver.
Almost always that is true. There is at least one oddball exception: the 21-bit
synchronous output stream for the PLATO terminals. That consists of a start bit, 19 data
bits, and a parity bit. Idling is done by sending NOP commands, which have all zero in
the data bits (but the standard start and parity bits).
I suspect this was done to provide one?s density for the receiver to lock onto. The
standard way to achieve that in sync communication is with non-zero idle characters (DDCMP
and Bisync) or bit stuffing (SDLC, HDLC). Or if you view things like Ethernet as sync
communication, which would make sense, there is also encoding that always has transitions
(Manchester in 10 Mb/s Ethernet), coding with guaranteed one?s density (4b/5b in FDDI and
100 Mb/s Ethernet), or coding with that plus DC balance (8b/10b in Fibre Channel and 1Gb/s
Ethernet).
paul
5:14 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/24/2014 08:03 AM, Paul Koning wrote:
Almost always that is true. There is at least one
oddball exception:
the 21-bit synchronous output stream for the PLATO terminals. That
consists of a start bit, 19 data bits, and a parity bit. Idling is
done by sending NOP commands, which have all zero in the data bits
(but the standard start and parity bits).
Heh, CDC could be very strange at times. Around 1975, I was assigned
the job of project manager for the STAR-100 remote operator's console.
My job was mostly administrative; I did none of the programming or
design--just made sure that the project came in on time and attended the
(ugh) status meetings.
I remember asking the engineer about using an (at that time) commodity
LSI UART to handle data, but his boss nixed the idea, so the add-on to
the MCU was designed using SSI chips. I never understood why, but it
worked. It also used an oddball data rate--1800 bps., but that was
probably just a compromise based on how much leased-line bandwidth was
considered expendable.
--Chuck
5:50 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 24, 2014, at 12:14 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 01/24/2014 08:03 AM, Paul Koning wrote:
True, but this particular system wasn?t a CDC invention. It was created at the University
of Illinois, the inventors of PLATO. It?s part of the amazingly clever I/O setup that
connected to 1008 terminals via a single multiplexer device (TDM, one bit to each terminal
every 1/60th second). It uses a microwave TV link to broadcast terminal output around the
campus; the mux output was cleverly encoded to look enough like a standard (analog, US
standard b/w) TV signal that a stock transmitter would happily transmit it.
Details are in CERL technical report X-26, available on Bitsavers (under
pdf/univOfIllinoisUrbana/plato/X-20_The_Plato_IV_Architecture_May72.pdf)
paul
Almost always that is true. There is at least
one oddball exception:
the 21-bit synchronous output stream for the PLATO terminals. That
consists of a start bit, 19 data bits, and a parity bit. Idling is
done by sending NOP commands, which have all zero in the data bits
(but the standard start and parity bits).
Heh, CDC could be very strange at times.
6:39 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
True, but this particular system wasn?t a CDC
invention. It was
created at the University of Illinois, the inventors of PLATO. It?s
part of the amazingly clever I/O setup that connected to 1008
terminals via a single multiplexer device (TDM, one bit to each
terminal every 1/60th second). It uses a microwave TV link to
broadcast terminal output around the campus; the mux output was
cleverly encoded to look enough like a standard (analog, US standard
b/w) TV signal that a stock transmitter would happily transmit it.
I'm familiar with PLATO (at least the plasma display types; CRT versions
were after my time). The Sunnyvale PLATO contingent were just down the
hall--and numerous PLATO courses were offered in-company. I wasted lots
of company time playing AIRFIGHT myself and managed to gather a crowd
playing it in the CDC booth at (IIRC) the 1978 NCC, even though I wasn't
working for CDC at the time.
But even the old INTERCOM linkup used oddball data rates (2000 bps seems
to stick in my mind). Display code, not ASCII , of course.
--Chuck
5:36 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Fri, Jan 24, 2014 at 11:03:36AM -0500, Paul Koning wrote:
I suspect this was done to provide one?s density for
the receiver to lock
onto. The standard way to achieve that in sync communication is with non-zero
idle characters (DDCMP and Bisync) or bit stuffing (SDLC, HDLC).
Almost definitely showing my own ignorance (I'm very new to serial comms),
but my impression is that in the old days, synchronous ports *always* used
a modem-supplied (etc.) external clock signal, and it's only newer fancy-pants
ports like the Zilog Z85(2)30 that try to be cute about using a PLL to derive
a clock from transitions in the bit stream.
So my understanding (correct me!) was that sync characters exist for, well,
sync (i.e. byte framing -- getting to a character boundary for sure, when
it's possible the receiver wasn't listening or just started up), and idle
characters are to maintain that byte framing when you don't have anything
else to send, i.e. TX underrun (because if you just sent a variable amount
of "mark" like an async line, you'd lose your byte framing when you started
sending valid data again).
And bit-stuffing in SDLC is just there to make sure that the 01111110 flag
character that begins/ends packets can't possibly occur anywhere except in
those places (this is a huge bug in DDCMP -- if a header gets garbled, the
receiver can be fooled by a fake packet contained entirely within the data
field, which is delimited only by a byte count in the header).
But through all of this there's a 1x clock coming in the RxC/TxC pins on
the DB25, either from the modem, or on a local connection, from a 1x BRG
in one of the ports that has been strapped to drive it onto the connector.
ANYWAY so the point of the SYN character is not to have a certain # of
guaranteed transitions, but to be intentionally lopsided so that no rotation
of it can be mistaken for valid (e.g. 55h would be useless as a sync char),
so that a receiver in "sync search" mode can click into position and be
ready for the LSB of the real data.
OK rip me to pieces.
John Wilson
D Bit
6:14 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 1/24/14 9:36 AM, John Wilson wrote:
Almost definitely showing my own ignorance (I'm
very new to serial comms),
but my impression is that in the old days, synchronous ports *always* used
a modem-supplied (etc.) external clock signal, and it's only newer fancy-pants
ports like the Zilog Z85(2)30 that try to be cute about using a PLL to derive
a clock from transitions in the bit stream.
Manchester-encoded transmission schemes have embedded clocking. These go back well
before the days of the SCC. The on-wire encoding was normally hidden by whatever
modem was handling what was on the wire, so all you would see would be clock and
data. Think of the distinction today between the PHY and MAC in an Ethernet interface.
There is also the notion of a 'modem eliminator' which is a box that will
generate
a clock for you in environments where you don't need physical modems.
6:33 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 24, 2014, at 1:14 PM, Al Kossow <aek at bitsavers.org> wrote:
On 1/24/14 9:36 AM, John Wilson wrote:
Manchester encoding is an excellent example of a modulation scheme that provides bit clock
as part of the demodulation process. Given the required bandwidth, it?s a good LAN (or
tape, e.g., DECtape) scheme, not so much for long distance connections.
Some other simple modulation schemes are not clocked; FSK is a good example (110 baud, 300
baud, and Bell 202 modems). But many others, and in particular any of the faster phone
modem schemes (1200 bps and up) use modulation where the demodulator recovers the bit
clock as part of (or in order to do) the demodulation. PSK is an example, and certainly
anything harder like QAM inherently depends on having a good receiver clock.
paul
Almost definitely showing my own ignorance
(I'm very new to serial comms),
but my impression is that in the old days, synchronous ports *always* used
a modem-supplied (etc.) external clock signal, and it's only newer fancy-pants
ports like the Zilog Z85(2)30 that try to be cute about using a PLL to derive
a clock from transitions in the bit stream.
Manchester-encoded transmission schemes have embedded clocking. These go back well
before the days of the SCC. The on-wire encoding was normally hidden by whatever
modem was handling what was on the wire, so all you would see would be clock and
data. Think of the distinction today between the PHY and MAC in an Ethernet interface.
11:55 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/24/2014 01:33 PM, Paul Koning wrote:
On Jan 24, 2014, at 1:14 PM, Al Kossow <aek at
bitsavers.org> wrote:
Manchester was only one of many. People believed that NZRI could not
extract clock data at one time.
On 1/24/14 9:36 AM, John Wilson wrote:
Manchester encoding is an excellent example of a modulation scheme that provides
bit clock as part of the demodulation process. Given the required bandwidth, it?s a good
LAN (or tape, e.g., DECtape) scheme, not so much for long distance connections. Almost definitely showing my own ignorance
(I'm very new to serial comms),
but my impression is that in the old days, synchronous ports *always* used
a modem-supplied (etc.) external clock signal, and it's only newer fancy-pants
ports like the Zilog Z85(2)30 that try to be cute about using a PLL to derive
a clock from transitions in the bit stream.
Manchester-encoded transmission schemes have embedded clocking. These go back
well
before the days of the SCC. The on-wire encoding was normally hidden by whatever
modem was handling what was on the wire, so all you would see would be clock and
data. Think of the distinction today between the PHY and MAC in an Ethernet interface.
Some other simple modulation schemes are not clocked;
FSK is a good example (110 baud, 300 baud, and Bell 202 modems). But
Generally
they didn't provide clocking but micros and cassette tape
forced people to recognize that it can self clock
if your willing to do the work.
many others, and in particular any of the faster phone
modem schemes (1200 bps and up) use modulation where the demodulator recovers the bit
clock as part of (or in order to do) the demodulation. PSK is an example, and certainly
anything harder like QAM inherently depends on having a good receiver clock.
Most
techniques required a known starting point and then worked out how
or around how to get back to that point.
Allison
7:46 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Fri, Jan 24, 2014 at 1:14 PM, Al Kossow <aek at bitsavers.org> wrote:
There is also the notion of a 'modem
eliminator' which is a box that
will generate a clock for you in environments where you don't need
physical modems.
I used those everyday for in-room, box-to-box HASP and 3780 links
for development and testing (and file transfer when it was easier than
cutting a tape or provisioning a DDCMP connection).
We even made our own modem eliminators, on a 3"x3" board, out
of TTL chips, a fistful of 1488/1489 EIA drivers, and a COM8146
baud rate generator chip. Our own MEs had a pair of 40-pin
"DL-11"-type interface connectors so you could hook two
COMBOARDs together with a board and a pair of what were
indistinguishable from ISA-era IDE cables.
I still have a stack of them in my tub of old COMBOARDs. Some
of them might even work. If people still used Sync Serial, they
might even be useful.
-ethan
11:48 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Fri, Jan 24, 2014 at 10:14:39AM -0800, Al Kossow wrote:
Manchester-encoded transmission schemes have embedded
clocking. These go back
well before the days of the SCC. The on-wire encoding was normally hidden by
whatever modem was handling what was on the wire, so all you would see would
be clock and data.
Well, exactly. So clock insertion/recovery is the modem's business, and has
already happened by the time you get out to the computer's serial port and
are dealing with things like sync and idle characters. So I still claim
that sync/idle chars have to do with byte framing, and SDLC bit-stuffing is
for packet framing, and neither one has anything directly to do with PLL sync.
Once you establish byte framing with a couple of SYN characters, you can
send NULs all day long w/o losing your place, and they'll all be dutifully
clocked into the receiving port...
John Wilson
D Bit
25 Jan
25 Jan
12:50 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 24, 2014, at 6:48 PM, John Wilson wrote:
On Fri, Jan 24, 2014 at 10:14:39AM -0800, Al Kossow
wrote:
It's dual purpose. Believe me, you need guaranteed transitions to keep
your PLL synced; PLLs have MUCH more drift than crystals, and you
couldn't use a crystal to send NULs all day long either. The fact that
it allows you to send special out-of-band symbols like the flag and
abort sequences is a nice side effect of the zero-stuff regime, similar
to the break sequence in async comms (which is otherwise a framing
error).
- Dave
Manchester-encoded transmission schemes have
embedded clocking. These go back
well before the days of the SCC. The on-wire encoding was normally hidden by
whatever modem was handling what was on the wire, so all you would see would
be clock and data.
Well, exactly. So clock insertion/recovery is the modem's business, and has
already happened by the time you get out to the computer's serial port and
are dealing with things like sync and idle characters. So I still claim
that sync/idle chars have to do with byte framing, and SDLC bit-stuffing is
for packet framing, and neither one has anything directly to do with PLL sync.
Once you establish byte framing with a couple of SYN characters, you can
send NULs all day long w/o losing your place, and they'll all be dutifully
clocked into the receiving port...
24 Jan
24 Jan
6:26 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 24, 2014, at 12:36 PM, John Wilson <wilson at dbit.com> wrote:
On Fri, Jan 24, 2014 at 11:03:36AM -0500, Paul Koning
wrote:
Yes, the modem would supply the clock, but the modem has to get that clock from somewhere.
It might be from the modulation, but for simple modulation schemes about all you have is
the bit transitions of the data stream.
An extreme example is the Bell 202 modem: 1200 baud one way (or duplex only if you have
four wires). It uses simple FSK modulation 1200 Hz and 2200 Hz to encode the bit values
if I remember right. No clock. To send sync data over such a modem, you need to build
your own PLL. I?ve done exactly that, for amateur packet radio (the original AX.25
connection oriented flavor, 1200 baud AFSK on a 2 meter FM radio).
I suspect this was done to provide one?s density
for the receiver to lock
onto. The standard way to achieve that in sync communication is with non-zero
idle characters (DDCMP and Bisync) or bit stuffing (SDLC, HDLC).
Almost definitely showing my own ignorance (I'm very new to serial comms),
but my impression is that in the old days, synchronous ports *always* used
a modem-supplied (etc.) external clock signal, and it's only newer fancy-pants
ports like the Zilog Z85(2)30 that try to be cute about using a PLL to derive
a clock from transitions in the bit stream.
So my understanding (correct me!) was that sync characters exist for, well,
sync (i.e. byte framing -- getting to a character boundary for sure, when
it's possible the receiver wasn't listening or just started up), and idle
characters are to maintain that byte framing when you don't have anything
else to send, i.e. TX underrun (because if you just sent a variable amount
of "mark" like an async line, you'd lose your byte framing when you
started
sending valid data again).
Sync characters certainly are for byte framing, but (again, unless the modulation itself
provides bit clocking) they may also be needed to help with bit framing.
And bit-stuffing in SDLC is just there to make sure that the 01111110 flag
character that begins/ends packets can't possibly occur anywhere except in
those places (this is a huge bug in DDCMP -- if a header gets garbled, the
receiver can be fooled by a fake packet contained entirely within the data
field, which is delimited only by a byte count in the header).
DDCMP doesn?t have that bug, because DDCMP headers have CRC. The only thing that comes
close is that you can get false framing if you construct a fake whole packet inside the
payload, but ONLY if the receiver has lost packet framing and is in frame search mode.
BTW, SDLC flag is not a character though it is often wrongly described that way. It?s a
pattern on the encoded bit stream. It ties to the original encoding for SDLC, which is
NRZI ? invert the current polarity if sending a zero bit, leave it alone if sending a 1
bit. Bit stuffing was done to ensure transition density: at least one per 6 bitclocks.
So the flag is a code stream pattern that doesn?t appear in data: transition, 6 clocks
without transition, transition.
By the way, SDLC/HDLC allow frames that are any number of bits in length (not necessarily
a multiple of 8), and USARTS typically support that. (The NEC chip where this thread
started does, for example.) I?ve never run into any network protocols that used this
fact, though. Perhaps CDC did to send data encoded in 6 bit characters?
But through all of this there's a 1x clock coming in the RxC/TxC pins on
the DB25, either from the modem, or on a local connection, from a 1x BRG
in one of the ports that has been strapped to drive it onto the connector.
ANYWAY so the point of the SYN character is not to have a certain # of
guaranteed transitions, but to be intentionally lopsided so that no rotation
of it can be mistaken for valid (e.g. 55h would be useless as a sync char),
so that a receiver in "sync search" mode can click into position and be
ready for the LSB of the real data.
That ?no rotation? property is true for Bisync, which relies purely on the sync character
for framing as far as I know. But for DDCMP, it?s helpful but by no means required; the
main framing mechanism is sync character search combined with header CRC validation.
The ?no rotation? property does come back in later protocols; the JK character pair in the
4b/5b code of FDDI and 100 Mb/s Ethernet has this property (indeed, it?s sometimes
referred to as the ?JK property?). Similarly, the start of packet character in the 8b/10b
code of Fibre Channel and 1Gb/s Ethernet has this property. This is used in receiver
circuitry to do code word alignment ? there?s a shift register that accepts the incoming
bitstream and delivers it word-wide to the remaining logic so it doesn?t have to run at
extreme speeds. For that alignment to be practical, it has to be very easy to recognize
the first bit of a packet, and these codes were designed to do that.
paul
11:51 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/24/2014 01:26 PM, Paul Koning wrote:
On Jan 24, 2014, at 12:36 PM, John Wilson <wilson
at dbit.com> wrote:
SDLC was a BOP (bit oriented protocol) and BiSynce and other tended to
be COP (character oriented protocol).
at the physical level then there were other layers of what to do...
On Fri, Jan 24, 2014 at 11:03:36AM -0500, Paul
Koning wrote:
Yes, the modem would supply the clock,
but the modem has to get that clock from somewhere. It might be from the modulation, but
for simple modulation schemes about all you have is the bit transitions of the data
stream.
An extreme example is the Bell 202 modem: 1200 baud one way (or duplex only if you have
four wires). It uses simple FSK modulation 1200 Hz and 2200 Hz to encode the bit values
if I remember right. No clock. To send sync data over such a modem, you need to build
your own PLL. I?ve done exactly that, for amateur packet radio (the original AX.25
connection oriented flavor, 1200 baud AFSK on a 2 meter FM radio).
I suspect this was done to provide one?s density
for the receiver to lock
onto. The standard way to achieve that in sync communication is with non-zero
idle characters (DDCMP and Bisync) or bit stuffing (SDLC, HDLC).
Almost definitely
showing my own ignorance (I'm very new to serial comms),
but my impression is that in the old days, synchronous ports *always* used
a modem-supplied (etc.) external clock signal, and it's only newer fancy-pants
ports like the Zilog Z85(2)30 that try to be cute about using a PLL to derive
a clock from transitions in the bit stream. So my understanding (correct me!) was that sync
characters exist for, well,
sync (i.e. byte framing -- getting to a character boundary for sure, when
it's possible the receiver wasn't listening or just started up), and idle
characters are to maintain that byte framing when you don't have anything
else to send, i.e. TX underrun (because if you just sent a variable amount
of "mark" like an async line, you'd lose your byte framing when you
started
sending valid data again).
Sync characters certainly are for byte framing, but
(again, unless the modulation itself provides bit clocking) they may also be needed to
help with bit framing.
And bit-stuffing in SDLC is just there to make
sure that the 01111110 flag
character that begins/ends packets can't possibly occur anywhere except in
those places (this is a huge bug in DDCMP -- if a header gets garbled, the
receiver can be fooled by a fake packet contained entirely within the data
field, which is delimited only by a byte count in the header).
DDCMP doesn?t have
that bug, because DDCMP headers have CRC. The only thing that comes close is that you can
get false framing if you construct a fake whole packet inside the payload, but ONLY if the
receiver has lost packet framing and is in frame search mode.
BTW, SDLC flag is not a character though it is often wrongly described that way. It?s a
pattern on the encoded bit stream. It ties to the original encoding for SDLC, which is
NRZI ? invert the current polarity if sending a zero bit, leave it alone if sending a 1
bit. Bit stuffing was done to ensure transition density: at least one per 6 bitclocks.
So the flag is a code stream pattern that doesn?t appear in data: transition, 6 clocks
without transition, transition. By the way, SDLC/HDLC allow frames that are any number
of bits in length (not necessarily a multiple of 8), and USARTS typically support that.
(The NEC chip where this thread started does, for example.) I?ve never run into any
network protocols that used this fact, though. Perhaps CDC did to send data encoded in 6
bit characters?
Therin lies the key, there were codes, physical protocols, and packet
level protocols in the sync world.
Allison
But through all of this there's a 1x clock
coming in the RxC/TxC pins on
the DB25, either from the modem, or on a local connection, from a 1x BRG
in one of the ports that has been strapped to drive it onto the connector.
ANYWAY so the point of the SYN character is not to have a certain # of
guaranteed transitions, but to be intentionally lopsided so that no rotation
of it can be mistaken for valid (e.g. 55h would be useless as a sync char),
so that a receiver in "sync search" mode can click into position and be
ready for the LSB of the real data.
That ?no rotation? property is true for
Bisync, which relies purely on the sync character for framing as far as I know. But for
DDCMP, it?s helpful but by no means required; the main framing mechanism is sync character
search combined with header CRC validation.
The ?no rotation? property does come back in later protocols; the JK character pair in
the 4b/5b code of FDDI and 100 Mb/s Ethernet has this property (indeed, it?s sometimes
referred to as the ?JK property?). Similarly, the start of packet character in the 8b/10b
code of Fibre Channel and 1Gb/s Ethernet has this property. This is used in receiver
circuitry to do code word alignment ? there?s a shift register that accepts the incoming
bitstream and delivers it word-wide to the remaining logic so it doesn?t have to run at
extreme speeds. For that alignment to be practical, it has to be very easy to recognize
the first bit of a packet, and these codes were designed to do that.
paul
11:46 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/24/2014 12:36 PM, John Wilson wrote:
On Fri, Jan 24, 2014 at 11:03:36AM -0500, Paul Koning
wrote:
It was a matter of necessity. Its very
hard to generate long bit
streams without
clock regeneration or resynchronization. it only takes a minute with a
calculator
to see that is the clocks both crystal controlled are apart by +50ppm
and -50ppm
(decent crystals) that over time they will drift apart.
I suspect this was done to provide one?s density
for the receiver to lock
onto. The standard way to achieve that in sync communication is with non-zero
idle characters (DDCMP and Bisync) or bit stuffing (SDLC, HDLC).
Almost definitely
showing my own ignorance (I'm very new to serial comms),
but my impression is that in the old days, synchronous ports *always* used
a modem-supplied (etc.) external clock signal, and it's only newer fancy-pants
ports like the Zilog Z85(2)30 that try to be cute about using a PLL to derive
a clock from transitions in the bit stream.
So my understanding (correct me!) was that sync characters exist for, well,
sync (i.e. byte framing -- getting to a character boundary for sure, when
it's possible the receiver wasn't listening or just started up), and idle
characters are to maintain that byte framing when you don't have anything
else to send, i.e. TX underrun (because if you just sent a variable amount
of "mark" like an async line, you'd lose your byte framing when you
started
sending valid data again).
Several function including padding between packets as
most all Sync
protocols
are packet oriented rather than character oriented.
So the sync and fill chars serve to allow time for PLLS to sync, or fill
dead time
in transmission beteen packets (and keep the pll locked). Income case
the fill
pattern (byte?) was used when the cpu could not get to the task fast enough.
And bit-stuffing in SDLC is just there to make sure
that the 01111110 flag
character that begins/ends packets can't possibly occur anywhere except in
those places (this is a huge bug in DDCMP -- if a header gets garbled, the
receiver can be fooled by a fake packet contained entirely within the data
field, which is delimited only by a byte count in the header).
It's important to be aware of the standards evolving and what they were
then
as compared to even a few months or a year later.
But through all of this there's a 1x clock coming
in the RxC/TxC pins on
the DB25, either from the modem, or on a local connection, from a 1x BRG
in one of the ports that has been strapped to drive it onto the connector.
ANYWAY so the point of the SYN character is not to have a certain # of
guaranteed transitions, but to be intentionally lopsided so that no rotation
of it can be mistaken for valid (e.g. 55h would be useless as a sync char),
so that a receiver in "sync search" mode can click into position and be
ready for the LSB of the real data.
OK rip me to pieces.
That last paragraph was part of the standards and how protocols evolved.
Drove me and others nuts at NEC back then as what the part could do vs
what the
moving target of standard sis were very fluid.
One of the big things emerging but far from there yet is that systems
were only
starting to talk to other systems and that there as many ways to do it
was carter
had liver pills.
Allison
5:06 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 24, 2014 12:03 AM, "Chuck Guzis" <cclist at sydex.com> wrote:
But is there any point to that in modern gear? In
fact, why not a PLL to
synchronize the receiving clock? Return to mark level by the
center of the
bit cell should be more than adequate for most applications.
Because async has no defined timing relationship between characters. The
PLL would have to reacquire lock for every character, which generally can't
be done quickly enough., since characters don't individually have suitable
preambles.
25 Jan
25 Jan
12:14 a.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/24/2014 12:06 PM, Eric Smith wrote:
On Jan 24, 2014 12:03 AM, "Chuck Guzis"
<cclist at sydex.com> wrote:
It was demonstrated using a pseudo-DPLL running at 16x data rate and
lacking
edges to sync on it would "center" itself. It only needed one edge to
determine
early or late and the next edge was enough to correct it if wrong.
Since async
always has at least one transition (start bit) thats enough to assure
the mid bit
sample was correctly timed.
Generally Async ran at 16, 32, or 64X baud clock and the logic would sample
at the numerical halfway mark. Since the source clock and destination
clocks
were guaranteed (by convention and spec) to be within a fraction of a
percent this
worked well as you resynchronized every character time during the stop
bit "time"
A common trick was to send two stop bits and receiver using only one
stop bit
as this assured one bit time to resync. Further the half way point was
a very wide
target and the two clocks (TX and RX) would have to be far apart to fail
in a
character. To fail you have to be more than half a bit time off at the
end of 10
bit times or about 2% clock error. Crystals used for clocks then were
typically
50 to 100 ppM over temperature range and at room temp less.
Async to async was fairly bullet proof for most mediums that didn't exhibit
time shift.
FYI: the mits ACR used a async and tolerated a fair mismatch in rate but
was very intolerent of short term jitter as could be cause by irregular
tape
speed occurring at a fast (1/15 to 1/30th of a second) rate. Reason is
it was
FSK without clock recovery or sychronization and drove a simple UART.
Allison
But is there any point to that in modern gear?
In fact, why not a PLL to
synchronize the receiving clock? Return to mark level by
the center of the
bit cell should be more than adequate for most applications.
Because async has no defined timing relationship between characters. The
PLL would have to reacquire lock for every character, which generally can't
be done quickly enough., since characters don't individually have suitable
preambles.
29 Jan
29 Jan
12:40 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
But nobody (read your datasheets) ever calls them
anything but "stop
bits", not "stop bit time".
Nobody ever calls them DE9, either, always DB9. Doesn't make it
correct. (Doesn't make it wrong, either, of course; just pointing out
that popularity isn't that reliable a guide.)
[...] I think
I once saw documentation on one [UART] which implied
that it was willing to tolerate receiving a character that was only
(what the receiver's clock says is) only a little over 9.5 bit times
long, [...]
But is there any point to that in modern gear? In fact, why not a
PLL to synchronize the receiving clock?
5:56 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On 01/29/2014 04:40 AM, Mouse wrote:
Nobody ever calls them DE9, either, always DB9.
Doesn't make it
correct. (Doesn't make it wrong, either, of course; just pointing out
that popularity isn't that reliable a guide.)
"Nobody"? "NOBODY?" There are some of us who are aware that
"DB9",
which, although possible, is most decidedly NOT the same as "DE9".
There's really no excuse for such nonsense. I see people using "Watts"
do describe energy, not power also. that doesn't make it correct.
--Chuck
6:16 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 29, 2014, at 12:56 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 01/29/2014 04:40 AM, Mouse wrote:
Or ?pounds? for mass. Or ?kilograms? for force. :-)
paul
Nobody ever calls them DE9, either, always DB9.
Doesn't make it
correct. (Doesn't make it wrong, either, of course; just pointing out
that popularity isn't that reliable a guide.)
"Nobody"? "NOBODY?" There are some of us who are aware that
"DB9", which, although possible, is most decidedly NOT the same as
"DE9".
There's really no excuse for such nonsense. I see people using "Watts" do
describe energy, not power also. that doesn't make it correct.
7:45 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
There's
really no excuse for such nonsense. I see people using "Watts" do describe
energy, not power also. that doesn't make it correct.
Or ?pounds? for mass. Or ?kilograms? for force. :-)
6:27 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
Nobody ever
calls them DE9, either, always DB9. Doesn't make it
correct.
"Nobody"? "NOBODY?" There are some of us who are aware that
"DB9", which, although
possible, is most decidedly NOT the same as "DE9".
Certainly. And there are those for whom "bit" is a slightly more
flexible word than the one you seem to take it as, one for which "1.5
stop bits" actually makes sense.
There's really no excuse for such nonsense. I see
people using
"Watts" do describe energy, not power also. that doesn't make it
correct.
My point exactly: "nobody does it" doesn't mean "it's wrong".
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
6:30 p.m.
New subject: "stop bits"; was: NEC uPD7201 misfeature
On Jan 29, 2014 11:15 AM, "Chuck Guzis" <cclist at sydex.com> wrote:
There's really no excuse for such nonsense. I see
people using "Watts"
do describe energy, not power also. that doesn't
make it correct.
I was extremely aggravated about that very issue recently when I saw an
article about a new energy storage system. The article gave a number
claimed to be how many watts it could store. That makes the same amount of
sense as claiming that it stored a certain number of millimeters.
24 Jan
24 Jan
4:52 a.m.
On Jan 23, 2014 8:34 PM, "Chuck Guzis" <cclist at sydex.com> wrote:
In theory, one could simply start the "hunt"
for the next start bit as
soon as the last data bit frame had passed--I have no
doubt that many chips
actually work exactly this way--that the "stop bit" is a simply an
indeterminate marking period until a space signals the start of the "start
bit".
Actually standard practice did not ignore the received stop bit entirely.
The stop bit was sampled at the time the receiver considered to be the
nominal middle of the bit time, and if it wasn't in mark state, signalled a
framing error. However, the leading edge of a start bit could be recognized
on the very next sample, typically 1/16 bit time later. Rate mismatch
aside, this means that the transmitted stop bit only has to be 9/16 of a
bit time (1/2, plus the 1/16 sampling uncertainty).
When you consider rate mismatch, it becomes worse. However, V.14 stop bit
shaving is only done in modems that retime the bits delivered to the DTE
locked to a quartz crystal, so the 12.5% (or 25%) V.14 "error" in the stop
bit timing is never on top of more than another 0.02% of timebase error.
What I don't know is if the period of the
mandatory space bit on receive
is also governed by the "number of stop
bits" setting in the mode setup
word--or if, as in many UART chips, this controls only the length of the
stop bit on transmit.
Interesting question. I suspect that ot doesn't validate the second rx stop
bit (or the extra half when 1 1/2 is specified), nor delay start bit
sampling for it, but I haven't tried it.
3765
days inactive
3771
days old
55 comments
12 participants
participants (12)
-
aek＠bitsavers.org -
ajp166＠verizon.net -
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
geneb＠deltasoft.com -
kylevowen＠gmail.com -
mouse＠Rodents-Montreal.ORG -
paulkoning＠comcast.net -
spacewar＠gmail.com -
wilson＠dbit.com