comms speed

[[e-mail]]

In the situation of a 2400 bps modem calling
a 1200 bps modem, but the caller is unaware
of what speed the remote modem is, there is a
string returned "CONNECT 1200".

Is the comms program expected to change the
UART baud rate to 1200 when it receives that
string? What happens if the CONNECT string
(received at 2400 bps) is ignored, and
processing continues at 2400 bps?

I realize that in more modern times, the baud
rate was "locked", so you could definitely
ignore the CONNECT string then.

Thanks. Paul.

[JJ]

Post by ***@gmail.com
In the situation of a 2400 bps modem calling
a 1200 bps modem, but the caller is unaware
of what speed the remote modem is, there is a
string returned "CONNECT 1200".
Is the comms program expected to change the
UART baud rate to 1200 when it receives that
string? What happens if the CONNECT string
(received at 2400 bps) is ignored, and
processing continues at 2400 bps?
I realize that in more modern times, the baud
rate was "locked", so you could definitely
ignore the CONNECT string then.
Thanks. Paul.

That "CONNECT nnn" is the comunication speed between modems. It's entirely
separate from between PC and the modem (which is the PC's COM port speed).

Communication between two devices of different speeds can only be done using
the slower speed. Because the slower device can not possibly keep up with
the faster device, the faster device will need to slow down its
communication speed so that the slower device can understand what the faster
device is saying.

It's just like communication between people, really. Some people talk fast,
and some people can't understand them unless they slow down their talking.
On the other hand, when they talking with other who can understand fast
talking, they won't slow down their talking.

[Alexei A. Frounze]

Post by ***@gmail.com
In the situation of a 2400 bps modem calling
a 1200 bps modem, but the caller is unaware
of what speed the remote modem is,

That's not what happens. Modems use so-called protocols,
which define how digital data is mapped onto analog
signals (that includes modulation like ASK, PSK, QAM,
FSK, etc) and the sequences of signals that initiate
communication.
There are also rules per which the two sides can
negotiate the common protocol and speed that both can
support.

Post by ***@gmail.com
there is a
string returned "CONNECT 1200".

When there's no agreement on the common protocol and
speed, you may never successfully establish a data
communication channel between the two sides and
therefore never see a CONNECT string.

The number in the connect string tells the speed between
the modems.

Post by ***@gmail.com
Is the comms program expected to change the
UART baud rate to 1200 when it receives that
string?

The UART speed is a separate thing, it's the speed
between a modem and its user/computer. It's usually
higher than the speed at which data flows between the
two modems. E.g. the computer can communicate with the
modem at 115200 even when the modems communicate at 14400.

What's interesting here is that many modems' UART
automatically tune their speed and character/byte size to
that of the computer by observing transitions between
zeroes and ones and the timing.
Remember that when there's no data on the UART, the rx(tx)
line is at the high level corresponding to 1. Before data
bits appear on the line there's a start bit, which is 0,
to which corresponds the low level. After the data bits
there's a stop bit, which is 1 or high level again.

Post by ***@gmail.com
What happens if the CONNECT string
(received at 2400 bps) is ignored, and
processing continues at 2400 bps?

If not just ignore the CONNECT string but actually
also try to send data before you get the string, you'll
not succeed and you'll not know why.

If your computer's and modem's UART aren't at the same
speed (and char/byte size and number of parity and stop
bits) and can't tune automatically, you'll not succeed.

Alex

[Grant Taylor]

The UART speed is a separate thing, it's the speed between a modem
and its user/computer. It's usually higher than the speed at which
data flows between the two modems. E.g. the computer can communicate
with the modem at 115200 even when the modems communicate at 14400.
What's interesting here is that many modems' UART automatically
tune their speed and character/byte size to that of the computer
by observing transitions between zeroes and ones and the timing.

Isn't this speed auto-detection? Something that almost always works?
But not guaranteed to work?

Remember that when there's no data on the UART, the rx(tx) line is
at the high level corresponding to 1. Before data bits appear on the
line there's a start bit, which is 0, to which corresponds the low
level. After the data bits there's a stop bit, which is 1 or high
level again.

Alex, you got so close to providing the answer I was hoping to see, but
you didn't quite touch on it.

Is this where the Hardware Flow Control; Clear to Send (CtS) and Ready
to Send (RtS) (respective to your "rx(tx)"?), comes in to play?

It also seems like Software Flow Control; XOn and XOff, comes into play too.

I don't know if Hardware and Software flow control are used mutually
exclusive of each other or if they can be used in combination with each
other.

Will you please elaborate on this if you are able to do so?

[Alexei A. Frounze]

Post by Grant Taylor

The UART speed is a separate thing, it's the speed between a modem
and its user/computer. It's usually higher than the speed at which
data flows between the two modems. E.g. the computer can communicate
with the modem at 115200 even when the modems communicate at 14400.
What's interesting here is that many modems' UART automatically
tune their speed and character/byte size to that of the computer
by observing transitions between zeroes and ones and the timing.

Isn't this speed auto-detection? Something that almost always works?
But not guaranteed to work?

It's not perfect.

Post by Grant Taylor

Remember that when there's no data on the UART, the rx(tx) line is
at the high level corresponding to 1. Before data bits appear on the
line there's a start bit, which is 0, to which corresponds the low
level. After the data bits there's a stop bit, which is 1 or high
level again.

Alex, you got so close to providing the answer I was hoping to see, but
you didn't quite touch on it.

Sorry, don't know what you were hoping to see. :)

Post by Grant Taylor
Is this where the Hardware Flow Control; Clear to Send (CtS) and Ready
to Send (RtS) (respective to your "rx(tx)"?), comes in to play?

Possibly, but it has even less connection to the CONNECT
message in the original post. Neither hardware nor software
flow control sets any specific stable data rate by
changing the bit duration on the UART or the aspects
of modulation/demodulation.

Post by Grant Taylor
It also seems like Software Flow Control; XOn and XOff, comes into play too.

The XON/XOFF method is very simplistic, but it can work too.

Post by Grant Taylor
I don't know if Hardware and Software flow control are used mutually
exclusive of each other or if they can be used in combination with each
other.

I've never heard of the two somehow used simultaneously.
But if you start playing Russian dolls and encapsulate
data in other data, you can find something similar happen.

Post by Grant Taylor
Will you please elaborate on this if you are able to do so?

Not sure what to elaborate here.

When you have an empty rx buffer and are ready to
receive more data, you raise your RTS. When the
rx buffer is like 3/4 full, you lower your RTS,
asking the other side to stop or slow down.
The other side sees your RTS go up and down on its
CTS. The RTS' and CTS' are cross-wired for this to
work for both sides.

Instead of raising and lowering the RTS one can send
special values (XON and XOFF) with the same meaning
and for the same purpose.

Alex

[Grant Taylor]

When you have an empty rx buffer and are ready to receive more data,
you raise your RTS. When the rx buffer is like 3/4 full, you lower
your RTS, asking the other side to stop or slow down. The other
side sees your RTS go up and down on its CTS. The RTS' and CTS'
are cross-wired for this to work for both sides.
Instead of raising and lowering the RTS one can send special values
(XON and XOFF) with the same meaning and for the same purpose.

Thank you Alex. This is more want I was missing.