How Fast Can Instruments send data over RS232?
RS stands for recommended standard. In the 60's a standards committee now known as the Electronic Industries Association developed an interface to connect computer terminals to modems. Over the years this has been updated: the most commonly used version of the standard is RS232C (sometimes known as EIA232); the most recent is RS232E. The standard defines the electrical and mechanical characteristics of the connection - including the function of the signals and handshake pins, the voltage levels and maximum bit rate.
If RS232 is a standard why can't I just use a standard lead to connect together two RS232 ports and expect them to talk to one another? That's a good question. The answer is that the RS232 standard was created for just one specific situation and the difficulties come when it is used for something else. The standard was defined to connect computers to modems. Any other use is outside of the standard. The authors of the standard had in mind the situation below:
The standard defines how computers (it calls them Data Terminal Equipment or DTEs) connect to modems (it calls them Data Communication Equipment or DCEs). The standard says that computers should be fitted with a 25 way plug whilst modems should have a 25 way D socket. The interconnecting lead between a computer and a modem should be simply pin1-pin1, pin2-pin2, etc. The main signals and their direction of flow are described below. It is important to note that a signal which is an output from a computer is an input to a modem and vice versa. This means that you can never tell from the signal name alone whether it is an input or an output from a particular piece of equipment. Also, instead of being a DCE device, a data acquisition device might be configured as DTE. In this case you need an adaptor or the RS232 cable wired differently to normal. When the PC is connected to a DTE instrument - called a null modem arrangement - some of the cable wires must cross over.
TXD Transmitted Data, Pin 2 of 25 way D
This is the serial encoded data sent from a computer to a modem to be transmitted over the telephone line.
RXD Received Data, Pin 3 of 25 way D
This is the serial encoded data received by a computer from a modem which has in turn received it over the telephone line.
DSR Data Set Ready, Pin 6 of 25 way D
This should be set true by a modem whenever it is powered on. It can be read by the computer to determine that the modem is on line.
DTR Data Terminal Ready, Pin 20 of 25 way D
This should be set true by a computer whenever it is powered on. It can be read by the modem to determine that the computer is on line.
RTS Request to Send, Pin 4 of 25 way D
This is set true by a computer when it wishes to transmit data.
CTS Clear To Send, Pin 5 of 25 Way D
This is set true by a modem to allow the computer to transmit data. The standard envisaged that when a computer wished to transmit data it would set its RTS. The local modem would then arbitrate with the distant modem for use of the telephone line. If it succeeded it would set CTS and the computer would transmit data. The distant modem would use its CTS to prevent any transmission by the distant computer.
DCD Data Carrier Detect, Pin 8 of 25 Way D
This is set true by a modem when it detects the data carrier signal on the telephone line..
PC Serial Ports
A nine pin D plug has become the standard fitting for the serial ports of PCs, although it's nothing to do with the RS232 standard. The pin connections used are:
Pin Direction Signal
1 Input DCD Data Carrier Detect
2 Input RXD Received Data
3 Output TXD Transmitted Data
4 Output DTR Data Terminal Ready
5 Signal Ground
6 Input DSR Data Set Ready
7 Output RTS Request To Send
8 Input CTS Clear To Send
9 Input RI Ring Indicator
You've plugged your instrument into your computer's COM
port, installed your data acquisition software, but no
data appears. You suspect it is a problem with your
RS232 communications. What do you do?
Download the free comDebug serial trouble-shooting software. This provides many features which let you detect, and correct, communication errors. If you can't immediately obtain data with comDebug, follow these steps.
- Find Communication Details: Baud Rate etc.
Obtain all the information available about your instrument or device. You will need to know the baud rate, number of bits in the data byte and parity. If you have information about the Stop Bits then use it, otherwise set them to 2. This will at worse slow the message down slightly.
- Send a message
If you can persuade your device to send a message, perhaps a power on message or a message that can be initiated by a button press, then do so. This will verify your signal connections. At this stage you should select the no handshake option when setting up the COM Port. If you still can't receive any data, you may have a wiring error. Use the COM Port Status window to check the state of the lines to and from the computer, and see points 3, 4 and 5 below.
- Check the COM port is Working Correctly
This tip works if your instrument is a DTE computer
type with a 9-pin connector. (See above for more on
DTE type instruments).
- Disconnect the RS232 cable from
your instrument and check it has a socket on the free
end.
- Unravel a paperclip, insert one end into the
pin 1 hole on the cable socket and the other into the
pin 2 hole. (Pin 1 is to the right of the long edge,
pin 2 is next to it.)
- Send a message. It
should echo back to the computer and let you confirm
that messages are arriving at your instrument.
- Check the Cabling
If you suspect a wiring error, you could try contacting
the manufacturer of your instrument to see if they sell
the correct cable. Sartorius devices, for example,
won't work with a standard RS232 cable and you need to
either purchase a cable from the company or re-wire the
connections. If your instrument is a DTE computer type,
you may need a Null Modem adaptor. Alternatively, you may want to try rewiring the
cable connector yourself.
When wiring the cable yourself, The first signals to connect are the ground, RXD and TXD. Try to establish, from your device's documentation, which signal wire carries its output data - connect this to the computer's RXD. The signal which inputs data to your device should be connected to the computer's TXD. Don't rely on the signal names, remember the signals can be either inputs or outputs depending on whether your device is a computer or modem type. It's not unusual for Instrument Manuals to neglect this vital information, but you may be able to get a clue from other signals. For instance if the manual says that DTR is an output then the instrument should be a computer type. If on the other hand it says that DSR is an output then it should be a modem type. In fact if you know the direction of any one of the signals you should be able to deduce the rest. Be careful when doing this: we have encountered manufacturers who change the names of the data signals when dealing with modem types - after all it must be confusing to tell a user that Transmitted Data is an input.
If the signals are correctly named then a computer to modem link connects TXD to TXD and RXD to RXD. A computer to computer link (more common when dealing with instruments) connects TXD to RXD and RXD to TXD. This crossed arrangement is sometimes called a Null Modem connection, and buying an adaptor may solve your wiring problems.
If all else fails you can determine which data signal is the output by measuring the unconnected data lines with a voltmeter or using one of the plugs with built in LED indicators which show the line state. The output signal will be at a definite negative voltage, properly -12 Volts or more. The input line will be close to 0V. The only time this strategy will fail is if your device is of the multidrop variety. These only drive the output line for the duration of the transmitted message.
- Set Hardware Handshaking or Flow Control
If you are confident that the signal wires are properly connected, but you still can't retrieve a message from your instrument, you may need to tie the handshake lines.
Handshake arrangements can be used for 2 purposes. Firstly the computer can prevent the device from sending data when it is not able to receive it. Secondly the device can prevent the computer from sending data when it is not ready for it. The fact that your device comes equipped with inputs and outputs that can be used for handshaking is no guarantee that handshaking is needed. The signals are often provided simply because the processor used in the device provides them, so the manufacturer feels he may as well put them on the plug. It is usually best to start with the intention of tieing any potential handshake lines to fixed voltages so that they do not affect operation. In fact many manufacturers add tieing resistors to handshake lines so that if you do not want to use them you simply make no connection.
If you start with no handshaking what symptoms might indicate that it really is needed ?. Well one possibility is that the computer misses part of a message because its input buffer overflows. In COMIML the buffers are 3000 bytes long so you are unlikely to be bothered by this problem. The other possibility is that the device misses part of a message sent by the computer. This will presumably cause the device not to operate as desired. If you do decide that handshaking must be used then COMIML uses DTR / CTS handshaking. This means that the computer uses its DTR output to indicate when it is able to receive data and its CTS input can be controlled by the device to prevent transmission of data from the computer. Once you select the hardware handshake option the state of the CTS input to the computer becomes important. When hardware handshake is not selected the CTS line state is ignored, the DTR output however is maintained permanently high so you can use it to tie unused inputs on your device.
- Set Software Handshaking or Flow Control
Xon \ Xoff Handshaking is a software protocol that is often used to control data flow. Supposing that the computer were sending data to a device which could accept no more data for the time being - the device would send the single Xoff character to the computer which would stop sending data until it received an Xon character to restart transmission. The same arrangements would apply for the reverse direction of data flow. If your device requires this type of handshaking then simply select it in comDebug.
The speed of RS232 communications is expressed in Baud. The unit is named after Jean Maurice-Emile Baudot (1845-1903), a French telegraph engineer and the inventor of the first teleprinter. It was proposed at the International Telegraph Conference of 1927. The maximum speed, according to the standard, is 20000 Baud. However, modern equipment can operate much faster than this. No matter how fast (or slow) your connection - the maximum number of readings per second you can take from your instrument depends on the software. For example, with Windmill software, speeds of up to 35 readings per second are achievable whilst with Streamer software this rises to 700 readings per second.
The length of the cable also plays a part in maximum speed. The longer the cable, the greater the cable's capacitance and the slower the speed at which you can obtain accurate results. A large capacitance means voltage changes on one signal wire may be transmitted to an adjacent signal wire. Fifty feet is commonly quoted as the maximum distance, but this is not specified in the standard. We generally recommend a maximum distance of 50 metres, but this depends on the type of hardware you are connecting and characteristics of the cable.
Related Topics:
Free measurement news feed...