Jim Brain
I realize it's extremely late and probably of no
value except for
historical purposes, but having a way to visualize the various standards
in this space with respect to duplex, baud/bps rate, etc. would be of so
I recently came across this on YouTube - it's from 13 years ago, but I
found it insightful . It's a Spectrogram of a modem dial-in connection.
I'm not sure if it's from simulation or an actual measurement - either way,
I think it's reasonably representative of the idea of tones being split
into signal, all involving FFT's.
Dial Up Modem Handshake Sound - Spectrogram - YouTube
<https://www.youtube.com/watch?v=vvr9AMWEU-c>
(the first comment on that video is helpful) And from the above video, that
led me to this:
dialup-final.png (2500×1304)
<https://oona.windytan.com/posters/dialup-final.png>
Then from the CCITT standards, I recall the verbiage of it talking
specifying "re-serializing" the signal. So in a way, these modulated
signals are another form of parallel back to the serial? Or "serial to
multi-phase back to serial" ? But - but - I thought we needed quantum
computers to represent more states than 0 and 1 at the same time? ;)
But the CCITT get dizzying to try to categorize - there seems to be a
"synchronous" and "asynchronous" version of nearly all of them, or
half vs
hull duplex variants? But one thing I did come across in exploring them:
the concept of echoing? I'm just guessing, but I recall one issue with
parallel ports is that a close enough wires and high speeds, you get
"cross-talk"? I suspect TX/RX lines of serial end up close together, is
"echoing" somehow residual of a RX echo'ing back out on the TX? (I'm
really
guessing on it, speculating before I read up more about it) In short, this
echo'ing effect I think partially explains why at high speeds they could TX
faster than RX?
Another thing I've recently read: 1200 baud v.22 isn't noted until 1980.
Maybe it was technically available a couple years earlier (you still see
that today, how WiFi vendors claim some new fast speed, chomping at the bit
to jump the market before competitors - and doing so at risk before the
standard is really ratified; that game was played also with modems --
ending up with a "mixed bag" on performance, especially when using devices
across vendors?).
Anyway, thinking on it: 1980-ish makes sense. You had 300 baud modems from
1963 to 1980, because to pull off any fancier modulation - you need a
clever FFT on a chip, a general-processor CPU (up to that point) wasn't
fast enough to pull it off. [ and I do mean in the more consumer-grade
stuff ] Is that a reasonable characterization? (on why 300 baud was "the
standard" for so long, and then suddenly the next decade after that with
incrementally better multi-phase encoding to could sustain faster
equivalent baud rates?)
-Steve
On Mon, Feb 10, 2025 at 10:46 AM Jim Brain via cctalk <cctalk(a)classiccmp.org>
wrote:
> On 2/10/2025 10:08 AM, Paul Koning wrote:
> >
> >> On Feb 10, 2025, at 3:58 AM, Jim Brain via cctalk <
> cctalk(a)classiccmp.org> wrote:
> >>
> >> On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote:
> >>> If I'm understanding it right, a "sort of" answer to my
own question
> is:
> >>> 2400 baud (v.22bis) was an "amplification" (not the right
word, but
> "phase
> >>> magic") of 600 baud. While as has been mentioned, 9600 baud
(v.32)
> was a
> >>> similar "amplification" of 2400 baud.
> >> Not sure if it's been linked, but I found a list of baud->bps
mappings
> at Wikipedia:
> >>
> >>
https://en.wikipedia.org/wiki/Modem
> >>
> >> For those who are OK using that resource to answer questions. I found
> it interesting at 1200 bps had two options (1200baud * 2 tones or 600 baud
> * 4 tones)
> > Not 4 tones; 4 modulation states per signal element, that is what QPSK
> means.
> Apologies, I was trying to use simpler terminology, given the writer's
> attempt to understand the overall relationship.
> >
> > The difference is that the 202 standard was designed to run half duplex
> over a standard phone line, or full duplex if you had a 4 wire (leased
> line) circuit. It's a very simple device that actually works at any speed
> up to 1200 bps (or a hair more, as PLATO did). The 212 modem using QPSK is
> a clocked system, but it can carry 1200 bps full duplex over a single phone
> line, with half the channel bandwidth used for one direction and half for
> the other.
I realize it's extremely late and probably of no
value except for
historical purposes, but having a way to visualize the various standards
in this space with respect to duplex, baud/bps rate, etc. would be of so
> much value. Like the poster I replied to, how a modem worked always
> seemed so oblique, especially as the speeds increased beyond 9600, even
> without the added complexity of things like MNP and the negotiation
> "dance" later modems held on the line. It was fascinating to hear about
> and use, but I always felt I should know more about it. Yet, most
> material in the day either waved a hand over the whole topic, or tried
> to regurgitate the CCITT documentation. Specifically, in your above
> statement, I'm still struggling to understand the duplex aspect of the
> various standards. As a ham operator and having went through my EE
> degree, I understand duplex, but since I always thought of the phone
> line as a full duplex medium, how it would be used as a half duplex
> channel eludes me. I'm OK with some terminology simplification, as
> shown above, if it could help show how the bandwidth of the telephone
> line was divided up in the various standards and how a 202 standard
> managed to emulate a full duplex conversation (if it actually did this)
> over the half duplex 2 wire telephone circuit. (And I use emulate in a
> loose sense, I suppose. Back in the day, when IBM and LU.2 was a thing,
> I worked at a company that created a general comms package that could
> pass data over various protocols, including TCP/IP, LU6.2, NetBIOS, IPX,
> and LU.2, which I believe was half duplex. But, the generic package
> promised full duplex comms, so we (not me, but the team) had to build a
> way to emulate a full duplex connection over that half duplex
> technology. It worked, at least well enough to support the apps used
> with it, but even it was "magic" to me, and I read all the source code)
>
>
> Jim
>
> --
> Jim Brain
> brain(a)jbrain.com
>
www.jbrain.com
>
>