SocketModem query (3)

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm messing around with a SocketModem at the moment, trying to develop some
basic driver software for an AVR. Between the modem and uC is a simple RTS
flow control signal. My question is this: Assume the modem is receiving data
down the phone line and passing it to the uC (i.e. nRTS is driven low by the
uC). The receive buffer in the uC becomes too full and the nRTS signal is
set high to temporarily stop more data being sent. What happens to the flow
of data down the phone line? Will my receiving modem somehow signal up the
line to the sending modem to stop sending data? If not how is a fully
flexible link capable of handing downloads and bottlenecks at the receiving
processor implemented?



Re: SocketModem query (3)

Quoted text here. Click to load it

CTS/RTS handshaking isn't used across the PSTN boundary.  It is used between
the modem and the DTE (usually by the modem to indicate that its buffer is
temporarily full).  To tell the upstream device to stop sending in the
unlikely event that you've found a modern microcontroller that can't keep up
with a modem or are doing a shipload of processing or slow I/O on the data
received consider using XON/XOFF handshaking
l and apparently pronounced EKS-AWN EKS-AWF - possibly in some of the
hillier souther regions of the USA) or something similar.

(Good, Fast, Cheap - Pick any two).

Re: SocketModem query (3)

Quoted text here. Click to load it

That's why he asked if there was some other way the two modems
do flow control.

I'm pretty user the v.NN protocols do provide modem to modem
flow control. A few Usenet postings Google found confirm my

Quoting from

    If the modems have negotiated an error correction protocol
    (such as MNP or V.42) then the sending modem will indeed
    receive a flow control signal when the receiving computer
    tells the receiving modem to halt (whether via hardware
    flow control or software flow control).  Modem error
    correction protocols include a mechanism for flow control
    messages between the modems, and if the receiving modem's
    buffers fill up it will signal to the sending modem that
    trasmissions should stop.
    Pretty close.  All high-speed (>96%00bps) modems use
    synchronous links between the modems.  On top of this, they
    use LAP-M (which is an HDLC-based protocol) and V.42 or
    V.14 to adapt asynchronous traffic to the modem's
    synchronous interface.

    The LAP-M protocol is basically a reliable transport
    protocol which uses retransmission timers and sequence
    numbers to achieve reliability.  In this protocol, flow
    control is done by having the receiver indicate that it's
    willing to receive more data, and not necessarily by a
    "flow off" message as with XON/XOFF.  (Though, confusingly,
    V.42 does provide a way to carry RS-232 signals end-to-end.
    Yes, the modem will communicate the "halt of data" to your
    modem. How it is done (in-band or out-of-band) is part of
    the modem specs that we hear about all the time. Usually
    you don't need to worry about the specifics of how the
    modems communicate this info back and forth.

I don't have a copy of the CCITT specs, so I can't confirm the
details.  I do remember testing end-to-end flow control once
with v.92 modems, and it seemed to work fine for me.
Quoted text here. Click to load it

Avoid Xon/Xoff at all costs (even if you have to learn to
solder so you can build a cable).  Xon/Xoff is implimented very
inconsistently from one OS to the next, and your chances of
getting end-to-end Xon/Xoff to work correctly through a pair of
modems is sufficiently close to zero to be ignored.

Just use RTS/CTS hardware handshaking on both ends between the
modems and the computers, and then let the modems do their own
flow control.

Grant Edwards                   grante             Yow!  Did we bring enough
                                  at               BEEF JERKY?
We've slightly trimmed the long signature. Click to see the full one.
Re: SocketModem query (3)

Quoted text here. Click to load it =
Quoted text here. Click to load it
Quoted text here. Click to load it
Quoted text here. Click to load it

Thanks very much. This information has been very helpful.



Re: SocketModem query (3)

Quoted text here. Click to load it

This end to end flow control can be quite "elastic", especially when
XON/XOFF handshaking is used.

When the receiving DTE (uC) wants to suspend the reception by dropping
DTE or sending XOFF, the DCE (receiving modem) sooner or later stops
sending bytes to the DTE.

With XOFF, it can take a while before the XOFF has propagated through
the modem Rx FIFO and handled by the modem software and only then no
new bytes are inserted into the Tx FIFO. Thus the previous contents of
the Tx FIFO is transmitted. Thus, after the uC has sent the XOFF, a
number of characters will still be received, the number is grater than
the sum of the modem UART Rx and Tx FIFO sizes. Thus the uC ISR should
be capable of storing at least these characters.

Even if HW handshaking is used, the DCE can send at least one byte, if
it has already been transferred to the Tx shift register in the DCE
UART. Thus, the uC must still be able to receive one additional

What happens between DTE and DCE in the receiving end does not
necessary have any direct implication in the phone line communication
between the two DCEs (modems). The transmitting DCE will send frames
and the receiving DCE will acknowledge these frames until the internal
buffers are filled in the receiving DCE. At this point the receiving
DCE stops acknowledging the HDLC frames.

Since the transmitting DCE does not get acknowledges, it tries to
resend the frames. If the transmitting DTE (PC) still send bytes,
sooner or later the sending DCE buffers are filled and it requests the
sending DTE to stop sending by dropping the CTS signal or sends XOFF
to the sending DTE.

Thus, the flow control from the receiving DTE to the sending DTE can
take seconds if large buffers are used.

However, I would look at the OP's problem in a different way.

Any interrupt service routine in any current uC should be capable of
handling the data rates from any phone line modem.

In large downloads, which should include some mechanism for error
detection and recovery, the data is divided into blocks and the
receiving system acknowledges the reception of the block by sending
some kind of positive or negative acknowledge to the sender.

In the simplest case, each received block is acknowledged immediately
and only after this acknowledge, the sender resends the old block (if
negative acknowledge) or sends the next block (if positive acknowledge
from the previous block). Thus, the receiving end interrupt service
routine only needs to be able to store the full block size. In many
protocols this size can be negotiated at startup. If the normal
routines handling the received block needs more time to process it, it
simply delays the transmission of the acknowledgement.

Sending the acknowledgement after each received data block greatly
reduces the throughput, so many protocols send a few blocks before
demanding an acknowledgement. In some protocols up to 7 frames can be
sent before demanding an acknowledgment (window size 7), but multiple
blocks can acknowledged at once, so usually the data transfer is
continuous. This also means that the interrupt service routine Rx
buffer must be capable of holding all 7 blocks.

In some protocols this window size can be negotiated to a smaller
value. With window size 2, the data flow is usually continuous, but
now only two frames need to buffered. Using two separate buffers, in
which the interrupt service routine fills up one buffer, while the
other buffer containing the previous block is processed by the normal
code. For the next block, the role of these buffers are reversed. The
interrupt service routine must be capable of understanding the frame
format, so it know, when a complete frame has been received.


Site Timeline