SEARCH 

4919 Cervato Way
Santa Barbara 
CA 93111 USA 

 
tel  805-680-5377 
fax  866-400-5504
info@quadron.com 
sales@quadron.com 

Copyright © 9186-2007 
Quadron Corporation 

Synchronous Communication

What is synchronous communication?
Many high speed serial communications protocols use synchronous line formats. These formats come in many varieties such as HDLC, SDLC and BISYNC, and are typically used by protocols such as X.25, LAP-B and SNA. The serial line transmitter and receiver are synchronized in such a way that as individual bits are "clocked" onto the line, the receiver reads those bits in lock-step.

Can all serial cards run synchronous communications?
No. Most serial cards found in a PC cannot be used for synchronous communications. They are designed for asynchronous operation only and lack the clock signals necessary for synchronous operation.

What is the clock?
The clock is a signal shared between the transmitter and receiver that locks the two together. With each tick of the clock (cycle), the transmitter places another bit on the data line and the receiver samples the data line. Using this shared clock, data can be reliably transferred at data rates well in excess of 1 Megabit/sec.

Where does the clock come from?
The clock can be generated at either the Data Terminal Equipment (or DTE, typically a terminal or workstation) or at the Data Communication Equipment (or DCE, typically a modem or network switch). A DCE generated clock is the most common configuration. When an ARTIC is set to generate an outbound clock, this is known as INTERNAL CLOCKING. When the ARTIC is set to receive an inbound remote clock, this is known as EXTERNAL CLOCKING. In many ARTIC documents, the term "DCE clock" means an inbound, external clock; and the term "DTE clock" refers to an outbound, internal clock.

How are clocks connected?
Only one side is allowed to generate the clock. The INTERNAL clock is sent out through one or more of the pins on the serial port connector. The other side must pick up the EXTERNAL clock from one or more pins on its serial port connector.

In the typical synchronous configuration shown above, the DCE is providing the clock to the DTE. The data rate is determined by the setting in the DCE. Most ARTICs may be used at either end. Some ARTICs require jumper settings (or Programmable Option Selects on Micro Channel cards) to select external or internal clocking.

Why are there so many clock pins?
Depending on the electrical interface in use, many different pin configurations are possible. RS-232 defines two signals to receive the EXTERNAL clock and one signal to send out the INTERNAL clock. V.35 and RS-422 define the same number of clock signals as RS-232, but use twice the number of pins. Most interfaces have provisions for a separate EXTERNAL clock for both the transmit and receive data signals although they rarely use different clocks.

Can I run synchronous communications on all ARTIC ports?
It depends on the ARTIC card. All ports on an ARTIC are not equal. Synchronous capabilities vary depending on the ARTIC and the Electrical Interface Board. Some ports have a subset of the standard electrical interface and do not carry the full complement of clock signals. Some ports support EXTERNAL clocking only, while still others have no clock signals at all.

Can I connect two ARTIC cards together via synchronous communications with a null modem?
Yes. First make sure that the ports you plan on using support the clocking signals you need and that the ports are configured correctly, one for internal and one for external. Next, ensure that the cabling carries the clock signal from the port selected as INTERNAL to the port selected as EXTERNAL. Be aware that many low-cost RS-232 Null Modem connectors are built with ASYNC in mind and they DO NOT pass the clock signal.

I'm running synchronous so all my ports can run at 64Kbps, right?
Not necessarily so. The ARTIC Portmaster, the ARTIC Multiport Model II and the ARTIC960 are built with enough Direct Memory Access (DMA) channels to run all their ports at high data rates. Other ARTICs have limited DMA capability, enough to run one full duplex high speed port. You can support a 64 Kbps data rate on that one port but don't expect to be able to run other synchronous ports at an aggregate data rate beyond 19.2 Kbps or you are likely to run into transmit and receive errors.

I'm sending but the other side isn't receiving anything.
This is probably the most common problem in setting up a synchronous connection. The side configured for INTERNAL clocking (let's assume the DCE) has a clock so it can transmit just fine. The problem is that the clock generated by the DCE is not correctly wired through to the receiver in the DTE. If the receiver doesn't see a clock, then it doesn't see the data! This is true even if you have a set of blinking lights indicating the data showing up on the receive data lines of the DTE.

I'm getting lots of CRC and ABORT errors or I'm missing the frames altogether.
The most common cause of this problem, aside from just plain bad telephone lines, is incorrect clocking setup. If both sides are set on INTERNAL clocking and their bit rates are set equal, then it is just possible that their actual clocks will be close enough to sync up every now and then. But since they are both running on their own INTERNAL clock and no two clocks are exactly alike, they will tend to run at slightly different speeds.
When this happens, the receiver may sync up at the start of a frame, but over the length of the frame, the difference between the two clocks spreads enough to cause the receiver to sample the data line at the wrong time, resulting in bit errors. These bit errors will show up as CRC or ABORT errors. The longer the frame, the greater the chance of losing sync. Make sure that one side is set to internal, and the other to external clocking.

Flow Control

What is flow control?
Flow control paces the data traffic between the sender and the receiver to keep the sender from sending data faster than the receiver can accept it.

Why do I need flow control?
When it is possible for data to be sent to a device faster than the application controlling the device can process the data, flow control must be used to prevent data from being lost. This situation is especially common using computer-to-computer communications with high speed modems.

Is there more than one type of flow control?
Yes. Asynchronous communications typically use two types of flow control: 1) Software Flow Control, commonly known as XON/XOFF Flow Control; 2) Hardware Flow Control, commonly known as RTS/CTS Flow Control. (All Quadron ASYNC device drivers support XON/XOFF, RTS/CTS, and other custom flow control options.)
Synchronous communication protocols typically rely on specific flow control or pacing indicators embedded in a message. These pacing indicators are unique to each protocol.

What type of flow control is correct for my ASYNC application?
With XON/XOFF Flow Control, unique ASCII characters tell a transmitting application to start (XON), stop (XOFF), and resume (XON). If there is a possibility that these ASCII control characters could appear as part of a BINARY data transfer, then XON/XOFF flow control cannot be used. For this situation, Hardware Flow Control is the proper selection since no flow control actions are based on the contents of the data. XON/XOFF is often used with terminal-to-computer communications.
With Hardware Flow Control, a pair of hardware handshake lines -- typically Request-To-Send (RTS) and Clear-To-Send (CTS) -- are wired together between the receiver and the transmitter. The transmitter monitors the CTS input line and stops when CTS is OFF. Transmission will resume when CTS comes back ON. When the receiver determines it is about to run out of room to store the data, it turns RTS off. When the receiving application processes the accumulated data, RTS is turned back on to indicate it is ready to take more data.

Hardware Flow Control requires more complex wiring than XON/XOFF. The two communicating devices must also have the appropriate control signals. For instance, the RS-422 ports on an ARTICm have no control signal pins and therefore cannot use Hardware Flow Control.
Just as important as the proper flow control being used for the type of data being transferred, both ends of the communication link must be configured to use the same type of flow control. For example, if your ARTIC application is configured for RTS/CTS flow control, the device connected to the ARTIC must also be configured for Hardware Flow Control and its control signal lines must be wired to the ARTIC RTS/CTS signal lines.

How do I know when I'm losing data?
To aid the ARTIC developer in determining whether or not the application requires flow control, or if flow control is working, Quadron provides device drivers with a communications monitoring utility that will let the developer know whether or not data is being lost.

Specs for a General Purpose ARTIC Cable

The wiring diagram below is for a general purpose, RS-232, 25-pin connector cable that will carry synchronous and asynchronous communications between two ARTIC cards. While you may be able to buy a cable like the one shown below, chances are you'll have to build it yourself, hence the diagram.

Go to any of these ARTIC technical topics:

About Synchronous Communications
About Flow Control
ARTIC Installation Worksheets
Memory Map to Assist in Shared Window Location
How to Select an Interrupt Level
Specs for a General Purpose ARTIC Cable
Port Configurations, Modem Status & Pin Outs

| Home | ARTIC Cards | ARTIC Software |
| Applications | About Speed & Protocols | About Quadron | Site Map |