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 <[email protected]> wrote: > On 2/10/2025 10:08 AM, Paul Koning wrote: > > > >> On Feb 10, 2025, at 3:58 AM, Jim Brain via cctalk < > [email protected]> 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 > [email protected] > www.jbrain.com > >
