Medical Device Cables This document provides information on how to construct cables to connect medical monitoring devices to personal computers, with the emphasis on the Macintosh, which has special requirements because of its RS422 serial ports. Further information about computer software for anaesthesia can be found in the Virtual Anaesthesia Textbook major resources /software chapter. A companion document contains information relating to datalogging software and there is a page about James Derrick's Monitor Program. If you have useful information about connecting PC's to other devices, please e-mail me so that I can keep this list as complete as possible. To avoid ground loops, ALWAYS connect the shield to chassis ground at one end of the cable only! This document is organised into devices that require:
I have some information on the following devices:
Kimble Dunster from the Perinatal Research Unit of the University of Queensland, has a particular interest in PC to device communications. He may be able to provide specific information for the following devices:
The STA maintains a listing of shareware resources for datalogging. A useful resource is "Interfacing the IBM-PC to Medical Equipment: The Art of Serial Communication" by R.W.D. Nickalls and R. Ramasubramanian, Cambridge University Press, 1995. ISBN 0-521-46280-0 (Hardback). Besides an introduction into the basics of serial communication, the book has specific information (connectors, protocol, etc.) on the following devices:
The Mac uses RS 422 serial ports which are superior to 'standard' RS 232 serial ports. RS422 uses differential signal pairs capable of higher higher data rates (up to 256k/sec) over extended distances (several kilometers), and when using the AppleTalk software protocol provides 230k/sec 4-wire in-built networking capabilties to every Mac. Not only are the pin assignments different but the voltage levels also differ; also a low current +12V supply line is available on most Macs. Backwards compatability means that 'off the shelf' cables may work with many devices, however the differences between RS422 and RS232 often means that you have to make a custom cable. Worse still, some RS232 implementations require you to fiddle electronically to get the voltage levels right. By the way, if you do need to make a custom cable, don't try to solder the DIN-8 end at the Mac. It is way too fiddly. Instead buy a long Mac DIN-8 printer cable and cut it in the middle (though note that individual wires of the same colour will not go to the same pins at each end, because some cross over). 1. Data transfer issues. Mac data output pins are TxD- ('transmit data minus' - pin 3) and TxD+ ('transmit data plus' - pin 6). They form a pair and move in opposite directions. TxD- sits at -5V, whereas TxD+ sits at +5V. Data points are indicated by a change of state in which the signal goes to the opposite 5V rail, ie TxD- goes from -5V up to +5V, and at the same time TxD+ goes from +5V down to -5V. Thus each wire shifts 10V in opposite directions. This is in marked contrast to RS232 devices which are 'single sided'. There is only one TxD wire to send data; it sits at 0V and goes positive to about +10V to mark a data point. Despite these voltage differences, the Mac NEVER has problems reading incoming data from RS232 devices - provided that you ground RxD+ ('receive data plus' - pin 8). The Mac RxD- input (pin 5) then functions exactly as if it was a RS232 input, ie it 'reads' 0V as a data low and 10V as a data high just as any RS232 RxD pin would. On the other hand when the Mac transmits data, the usual thing to do is to use TxD- (pin3) as the output pin. As I mentioned before this sits at -5V, when transmitting data the positive peaks are at about +4.5V. These sometimes fail to reach the threshold of detection of the receiving RS232 device! It should do so, but certainly for the Graseby, and possibly other devices, +4.5V not enough and it has to be boosted somehow. When this happens it is necessary to raise the voltage that the Mac puts out, (ie the voltage that the RS232 device sees) and this can be achieved by putting a 1.5V battery (positive to the device) in series with the TxD- line. This raises the resting TxD- voltage from -5V to -3.5V and signal highs from +4.5V to +6.0V. Putting a small silver oxide button battery inside the DB9 case at the device end works well, but in practice is difficult to do. If you solder the cells the batteries eventually leak, ruining the cable; mechanical connections are fiddly; batteries get old and fail. None the less it is the most compact and simplest solution. It is the only solution if the active alternative (below) cannot be done. Note that many medical devices send data out their serial port all the time, regardless of what you do at the Mac end, so there is never a need for the Mac to talk to the device - in these, cable wiring is the only thing that can go wrong. Devices that need to hear a valid request from the Mac before they send data require both the correct cable and adequate levels on the transmit lines. 2. Handshaking issues. The Mac RS422 uses a pair 'handshaking' pins to control data flow. HSKo ('handshaking out' - pin 1) is an outuput usually set at +5V (note that until you turn the port on, it is set to -5V), and if the Mac buffer gets full, this drops to -5V. When low this line will be used to inhibit the device that is sending data to the Mac until the Mac buffer is able to take data again. HSKi ('handshaking in' - pin 2) is an input that can be used to inhibit the Mac from sending data. If hardware handshaking is enabled at the Mac end, the Mac will always send data while this pin is high (ie +5V or greater); if it goes low then data transmission will cease. In the Mac it is possible to enable or disable hardware handshaking in the dialog with the following options:
Use 'None' if handshaking is not required, or 'DTR and CTS' if you need full hardware handshaking and have an appropriate cable; if you 'fool' hardware handshaking in the cable it doesn't matter what you select. RS232 devices have two sets of handshaking pins (RTS/CTS and DTR/DSR), which are single sided. Most medical devices using handshaking on their RS232 ports use the RTS/CTS pair. RTS is held at +10V unless the buffer in the device gets full and then it drops to 0V. It is obvious that to truly implement handshaking, HsKo needs to go to CTS and RTS to HsKi, but it is equally obvious that if the voltage levels don't match up then this won't work. The solution is to either 'fool' the handshaking at each end, or use a battery in line with HSKo. 'Fooling' or 'defeating' hardware handshaking involves tying HSKo to HSKi, and separately CTS to RTS (and DTR to DSR if required). This way each device thinks that the buffer at the other end is free all the time; no actual handshaking takes place. If this is done it does not matter at the Mac end whether or not handshaking is set on or off, because it is always bypassed. The medical device will always think things are OK regardless. It is the way to go unless hardware handshaking is definitely needed. Devices requiring DB-25 Male Modem Cables A diagram of a generic macintosh DIN-8 modem cable with hardware handshaking is shown below:
Fooling handshaking involves shorting HSKo to HSKi at the mac end and CTS to RTS (and DSR to DTR if implemented) at the device end. A cable like this will work when hardware handshaking is selected in software, even if the other device doesn't support it. If the other device either provides or requires DTR and CTS then the cable should be wired as above. Typical CTS/RTS handshaking macintosh to DB25 modem cable wiring configuration: Notes:
Spacelabs PC and Express Series monitors Standard DB-25 modem cable with handshaking (Din-8 to DB-25 male) seems to work fine. Comms: 9600 baud, 8 data bits, 1 stop bit, no parity. You need to pay for a special board to get 'datalogger' data out. This is a send only system that sends page headers followed by tabular data at user-determined (and saved) intervals. James Derrick's Monitor program can only interpret data after a valid header; fortunately a new header is sent at regular intervals or whenever a new parameter is added. Generic DB-25 Male Null Modem Cables Null modem cables connect transmit to receive and vice versa. The pre-made ones that I have bought from apple dealers use DTR handshaking (DTR connected to HSKi). They hook RTS to CTS (and DSR) at the device end (and ignore the Mac HSKo line), so that the device always thinks that the Mac is able to receive data. This means that if the Mac buffer gets full it cannot stop the device from sending data. However when the device gets full of data it can stop the mac via the DTR line. The following cable 'fools' RTS/CTS and DTR/DSR hardware handshaking at both ends. This is the simplest and most reliable cable to construct:
A diagram of a cable using full CTS/RTS handshaking and 'fooled' DSR/DTR follows:
A diagram of a commercial prewired null modem cable for the Macintosh is shown below:
Standard DB-25 male null modem cable with handshaking (Din-8 to DB-25 male for Mac) seem to work fine. Comms: 9600 baud, 8bits, 1 stop bit, no parity . You have to pay extra for the RS232 board. When you turn the device on the port is off; as far as I know, you have to manually enable it each time. Go to 'monitor setup, then 'more' then you should see RS232 setup and you can enable it (assuming you have installed the board). Data is sent in a variety of formats and can be sent at fixed intervals. Hewlett-Packard 1304 Gas Analyser Standard null modem cable with handshaking (Din-8 to DB-25 for Mac). Comms: 9600 baud, 8 data bits, 1 stop bit, no parity . Dräger Cato and other Dräger DB-25 Medibus devices. Use a standard DB-25 male null modem cable (Din-8 to DB-25 male for Mac). Handshaking is not required.Use the Medibus DB25 port - marked 'Printer' or 'RS232'- each port can be configured separately, 1=shield, 2=TxD, 3=RxD, 7=GND. NB the 'Julian' Anaesthetic Machine and Vitara monitor use DB-9 cabling. If you are going to use James Derrick's 'Monitor' application, the approriate port must be set to 'Medibus' via the 'interfaces' offline menu. Default parameters are 9600, 8 data bits, 1 stop bit, even parity. Using a terminal emulator you should see a four character string (<ESC>Q6C<CR>) on the input line every two seconds (or after you press 'return' on your keyboard). This should test your cable. A more rigorous test is to send this string (binary) (binhex). See the Medibus manual for more details. Basically a null modem cable, BUT NOTE that Capnomacs and similar use pin 8 is as `test', and 20 for CO2 analogue. A non-hardware handshake null modem cable MAY be OK but only if 20 is NOT shorted to 4 and neither 20 nor 8 at the Datex end are connected to any other pins. Alistair Steyn-Ross emailed me to say that the handshaking is not required at the Datex end, and that if, as suggested in the diagram below, CTS is shorted to RTS at that end, the cable does not work. Please tell me what works for you, as I don't have a Capnomac anymore.. Capnomac comms: 1200 baud, 8bits, 1 stop bit, no parity; one string every 10 seconds. More capnomac info: www.capsuletech.com/Docs/DDIhelps/webDatexB.htm A diagram of a Mac to generic Datex Capnomac series cable with 'fooled' handshaking follows - it might work better without joining CTS to RTS at the Capnomac end:
This device uses RS422 on a DB-25 connector. It supports RS232 using a null-modem DB-25 cable but a custom RS242 cable could be made for the Macintosh and would support very long cable runs. No hardware handshaking is required or supported. Comms: 300, 1200, 2400, 4800, 9600, 19200 baud, 8 data bits, 1 stop bit, no parity. X-On X-Off flow control is implemented and may be required. Params are set by pressing and holding the ALARMS SET key, which gets you to the config screen. The ASCII PRINTER data format sends strings containing Sat, pulse, resp, CO2, O2, N20, and volatile agent. Serial intervals can be set for 1 packet per second through to 1 per 8 hours. Devices using DB9 PC-AT Null Modem Cables. A diagram of the basic Macintosh to PC-AT style DB9 null modem cable with fooled hardware handshaking follows:
Require a DB-9 null modem cable with a female plug on the cable. Only pins 2,3,5,7 and 8 are used. Every AS/3 has a functioning serial port when you buy it. With the Mac, hardware handshaking (RTS/CTS) could be fooled in the cable, but a hardwired handshaking cable is preferable at this baud rate. The AS/3 will not output any data at all unless CTS is high; the crossover point is around 2V so there is no need for any voltage augmentation in Mac cables. Note that HSKo on the mac is at -5V until the connection is opened by your comms program, so don't expect the AS/3 to open its computer interface until you open yours first! Comms: 19200 baud, 8 bits, 1 stop bit, even parity. Note 'even' parity. Nothing is sent from the AS/3 in response to incoming strings unless they are valid, so it is difficult to test the cable easily. Try sending this 52 character string (binhex) (binary) to see if you can provoke a response. If you have access to the computer interface part of the service software then you can see each string being processed as they are received. Kimble Dunster gave me this Borland C code. Female DB-9 connector required on cable like the AS3 (above). Uses the Dräger Medibus protocol (see above). Comms: 8 data bits, 1 stop bit, even parity. Female DB-9 connector required on cable like the AS3 (above). Handhaking (CTS/STR and DTR/DSR) may be fooled by linking 7 to 8 and 4 to 6 in the 9-pin D-shell. The 1050 provides ASCII data on the 'Processed EEG' port and digitsed raw EEG on the 'Raw EEG' port. Details of the ASCII protocols are not provided in the manual but are available from Aspect. Comms: 8 data bits, 1 stop bit, no parity. Male Din-9; said to be based on the PC-AT cable, but not like those above; Pins 1, 7 and 9 are unused at the device end, DTR (4) is used as a handshaking output and is high when the N-1000 input buffer is free,CTS (8) is used as a handshaking input and must be high for the N-1000 to transmit, and DSR must be high to let the N-1000 know that another device is online. A diagram of the Mac to Nellcor N-1000 cable that I use follows. Note that I use the high from DTR to enable the N-1000 CTS and DSR inputs:
Comms: 9600 baud, 8bits, 1 stop bit, no parity. The N-1000 echoes a lowercase 'e' back to you if you send it an invalid startup string so it is easy to test your cable. Valid start up strings start with the escape character and can initiate regular output of data. For example, sending <esc>N4;5;6;8;9;24va should get back a string containing RR, CO2, N2O and time. Male DB-9 PC-AT null modem handshaking cable (same as N-1000) should work. Requires CTS (pin 8) high for data transmission. Kimble Dunster has provided the following cable wiring diagram and also N-400 protocol information (26kPDF) and information on how to connect it to the Corometics 170. The Graseby needs a female DB-9 ended cable. It uses pins 2 Rx, 3 Tx, 5 ground, 6 DSR (handshake out), 7 RTS (fixed at +10V) and 8 CTS (handshaking in); I fool all handshaking in the cable by shorting pins 7 to 8 (and 4 to 6 to make it a 'universal' cable) at the Graseby end, and 1 to 2 at the Mac end. The shield pin is not connected. The Graseby 3400 will not respond to data transmitted from the Mac unless the voltage of the transmitted line is raised from from 4.5V to at least 6V. A 1.5V 'button battery' in series with the transmit line will work; it will leak later on if you use solder, instead try using heatshrink tubing or make a case out of plastic. The cable should look like this:
Comms: 9600 baud, 8 data bits, 1 stop bit, no parity. Baud rate can be altered (though I see no point at all) by getting into the setup menu (hold bolus and rightmost arrowkey together, then straight away the start key). Appropriate strings involve a command enclosed in pointy brackets, followed by the two ascii characters representing the hex checksum, then a carriage return and optionally a line feed. For example <GETR>NN<CR><LF> where NN is the checksum. An appropriate response is 'OKGETRINFS100' meaning 'OK' I understood the command, echoing the 'GETR' command, 'INFS' indicating that it is currently infusing, and '100' meaning either 100ml/hr or 10mg/kg/hr (!). If the string is malformed or the checksum wrong you get 'IVLD' back. See the manual for more details. Devices using DB9 Modem Cables. Later model German Dräger anaesthetic machines (Julian, etc) and monitors (Vitara) use female DB9 sockets on the machine, but with Pin 2 as Tx and Pin 3 as Rx (pin 5 = ground). Hence to connect these to a PC or Mac requires a modem, rather than a null-modem, cable configuration, with DB-9 male plugs on the device end. Make the cable as for a DB-9 null modem cable, but swap the Tx and Rx wires at the DB-9 end. The Julian has DB-9 male sockets, as does the Vitara. There is no need to provide handshaking in the cable and the default comms params are 9600, 8 data bits, 1 stop bit, even parity. Siemens use an 8-pin modular telephone type (SDL) connector; a custom cable is therefore required. The only way I have got anything out of the Siemens at 9600 baud is by shorting CTS to RTS at the device end. Implementing a full CTS/RTS handshaking cable has not worked. Here are basic pin connections for a 9600 cable to Mac or PC. Remember at the Mac end to join HSKi to HSKo (1 to 2) to fool hardware handshaking if the user turns it on, and join 4 to 8 as usual): Comms: 4600 or 9600 baud (9600 Baud CTS/RTS hardware handshaking lines exist but it is recommended that they be 'fooled' by connecting them together). 8 data bits, 1 start, 1 stop, even parity. Device only responds after receiving a valid request string; sends 138 data bytes with a checksum. The ABM uses a 9 pin male connector. The same cable works for the relaxograph, so they must be fairly similar, although I can't find my relaxograph sheet just at the moment. Comms: 8 data bits, 1 stop bit, no parity.
This document is by its very nature incomplete. If you know anything that I've got wrong or should be added please use this form to let me know and I'll gladly add it. Chris Thompson, RPAH, Camperdown, Australia 2050 |
||
 |
|
|
