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?
Essentially, yes: the problem is impossible to solve in its full
generality, so they impose a few additional conditions that turn it
into a solvable problem.
In cases such as you describe, one obvious condition is that they make
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.)
Also, note that the problem they're solving is just autobauding, not
full receiver clock recovery. Most (all?) of them used a free-running
receiver clock at some multiple of the baud rate, leading to sampling
jitter on the order of the fast clock period. Of course, this was good
enough in practice, so nobody bothered to do better for that
application.
/~\ 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
