Protocol Definition Document - School of Engineeringeecs.vanderbilt.edu/courses/eece295/2004_2005/vumc_gcrc/... · Web viewSubnet Mask 2: 255 Subnet Mask 1: 255 Subnet Mask 0: 0 Multicast

Select and PortableNative Host

CommunicationsDefinition Document

File:document.doc

Last Edit:17Feb05

Author:C. Wells & A. Thompson

Revision:2.1

17Feb05 Native Host Comm Page 1Definition Document Revison 2.1

0 INTRODUCTIONThe current host communications protocol for the MPS PORTABLE* patient monitor emulates the host communications protocol for the DINAMAP* PLUS Monitor. This protocol will be referred to as “Plus Emulation Mode”. The new version of MPS PORTABLE* code will support, in addition to Plus Emulation Mode, a new protocol referred to as Native Mode. This document will describe the additions to Plus Emulation Mode only (to accomplish the implementation of Native Mode). As such, it is not a complete protocol definition document. Any differences between the behavior of the two modes will be noted.

There are two main design goals for the MPS PORTABLE* Native Mode protocol: 1) Don’t break the code for existing host systems; and 2) provide full numeric and waveform capabilities. The first of these is accomplished by avoiding changes to the existing host communications code (Plus Emulation Mode). This protocol (Native Mode) is specified as strict additions to the Plus Emulation Mode protocol; thus ensuring that existing Plus Emulation Mode operation will be preserved. The second of these goals can only be accomplished at the expense of increasing the host communications bit rate above 9600 bits per second for the new Native Binary Mode operation.

Native HostComm Protocol Revision supported..................................................................0Plus Emulation HostComm Protocol Revision supported....................................................0

NOTE: The Plus Emulation Mode Revision Level did NOT have to be Rev advanced for this release of code, since the basic operation of the command/response & binary data have not been modified from the previous release.

Base Document:Dinamap MPS Host Communications Reference Manual....................................Rev. 3

Operational differences with base document:1. Host Communications are NOT operational during Configuration mode.

2. The unit only recognizes documented commands and only sends the documented responses.

3. Low level errors are not reported by the unit. Only invalid command and invalid parameter identifier and, when necessary, invalid syntax are detected by the unit (i.e. extra characters in string are usually not detected).

Critikon LLC Proprietary


1 ASCII MODEASCII commands can always be transmitted to the Unit as long as it is operational. Responses, however, will not be returned if the Unit is currently sending binary data via one of the Serial ports.

Currently, the Plus Emulation Mode implements the following commands: “E”, “I”, “N”, “O”, “P”, “R”, “T”, and “*”. The following is a list of all available Native Mode commands.

B ECG-Derived Respiration RateC CO2

E ECGI Invasive Blood PressureN Non-Invasive Blood PressureO Pulse OximeterP Printer (including Central Station Printing)R Heart or Pulse RateT Temperature* DINAMAP MPS Monitor Non-Parameter Specific

There are also additional subcommands that have been added to some of the existing commands. For example, the “uEM” command reads the multiLead status for ECG.



2.0 RESPIRATION COMMANDSThe MPS PORTABLE* ECG Module has the capability to determine breath rate. The following commands are valid.

1.1.0 ECG Derived Respiration Status CommandCommand: “uBA” Read status of ECG Derived respiration

Response: “uBAabbb”

“a” Resp Status“0” - !Operate Mode“1” - Operate Mode

“bbb” Breath Rate (breaths per minute)

NOTE: A Breath Rate of 999 indicates the value is undetermined.

NOTE: When in Operate Mode the parameter is deterministic & alarms are active. The parameter will continue to indicate Operate Mode when the unit is in Standby; it is up to the Host to check for the global Standby Alarm.

1.1.1 ECG Derived Respiration Alarm Limits CommandCommand: “uBB” Read ECG Derived Alarm Limits

Response: “uBBaaabbb”

“aaa” Resp Rate Low Limit (breaths per minute)“bbb” Resp Rate High Limit (breaths per minute)

NOTE: Alarm Limits of 999 indicate the value is undetermined.



2.1 CO2 COMMANDSThe MPS PORTABLE* Monitor has a C02 module available. The following commands are valid.

1.1.2 CO2 Status CommandCommand: “uCA” Read CO2 Status

Response: “uCAabbbcccddd”

“a” CO2 Status“0” - !Operate Mode“1” - Operate Mode

“bbb” Inspired CO2 (1/2 mmHg -> 0 to 255)“ccc” End Tidal CO2 (1/2 mmHg -> 0 to 255)“ddd” Breath Rate (breaths per minute)“eee” Barometric Pressure (1/2 mmHg)

NOTE: Status values of 999 indicate the value is undetermined.


1.1.3 CO2 Alarm Limits CommandCommand: “uCB” Read CO2 Alarm Limits

Response: “uCBaaabbbcccddd”

“aaa” End Tidal Low Limit (1/2 mmHg)“bbb” End Tidal High Limit (1/2 mmHg)“ccc” Breath Rate Low Limit (breaths per minute)“ddd” Breath Rate High Limit (breaths per minute)

NOTE: Alarm Limits of 999 indicate the value is undetermined.



2.2 MULTILEAD ECG STATUS COMMANDThis command superceeds the existing ECG Status Command “EA”. The “EA” command is still valid for Plus Emulation mode, but the Multilead ECG Status Command should now be used.

The MPS PORTABLE* ECG Module has two (2) modes of operation. The first mode of operation uses 6 electrodes and can display 8 simultaneous waveforms. This is called “MultiLead Mode”. The second mode of operation uses 3 electrodes and can display 1 of 3 waveforms. This is called “SingleLead Mode”.

The 6 electrodes used in MultiLead Mode are designated LA, RA, LL, RL, Va, and Vb. RL is the reference electrode and the LA, RA, and LL electrodes produce waveforms I, II, II, aVR, aVL and aVF. Additionally, the Va and Vb electrodes can be placed in any two of the standard 6 locations.

The 3 electrodes used in SingleLead Mode are designated LA, RA, and LL. One of theses three electrodes can be the reference electrode and the remaining two will produce either Lead I, II or III.

The MPS PORTABLE* allows the user to associate a label with the Va and Vb waveforms to indicate which of the standard 6 positions that electrode occupies. This leads to the following hexadecimal numbering scheme for lead labels:

0x01 - I 0x06 - aVf 0x0b - V30x02 - II 0x07 - Va 0x0c - V40x03 - III 0x08 - Vb 0x0d - V50x04 - aVR 0x09 - V1 0x0e - V60x05 - aVL 0x0a - V2

Va (0x07) and Vb (0x08) are used to indicate that the user hasn’t specified explicit labels for those electrodes.

The following ECG commands are valid in addition to the Plus Emulation Mode commands.

Command: “uEM” Read MultiLead ECG Status

Response: “uEMabcdef”

“a” ECG Status“0” - Standby/Unplugged“1” - Operate“2” - Lead Off

“b” ECG Mode“0” - SingleLead“1” - MultiLead

“c” Adult/Neonate Flag“0” - Adult“1” - Neonate“2” - Pediatric

“d” Primary Lead Number (“1” to”E”)“e” Va Lead Number (“7” to”E”)“f” Vb Lead Number (“8” to “E”)

NOTE: Common medical use of the term ECG “Lead” is ambiguous. “Lead” can refer to either a waveform (e.g. Lead II) or a wire (e.g. a six-lead cable). Care has been taken to use the terms “waveform” and “electrode” in most instances to convey this difference and reduce ambiguity. Sometimes this substitution is awkward (e.g. MultiLead Mode); so, in these cases, the term “lead” has been left.

NOTE: In SingleLead Mode, “primary lead number” indicates which lead is being sent.



NOTE: In SingleLead Mode, the contents of fields “e” and “f” are undefined, and “d” is limited to the following 1 <= “d” <= 3.



2.3 INVASIVE PRESSURE COMMANDSThe MPS PORTABLE* Monitor Invasive Pressure module can have 2 IP modules plugged in (4 IP channels), and has the ability to take wedge pressure. The following commands are valid in addition to the existing Plus Emulation mode Invasive Pressure commands.

1.1.4 IP3 Status CommandCommand: “uIE” Read Invasive Pressure Status from the PRESS 3

channel.

Response: “uIEabbbcccdddeee”

“a” Channel Status“0” - Connected and OK“1” - Disconnected“2” - Connected but not zeroed

“bbb” Pressure Label“ccc” Systolic Pressure“ddd” Diastolic Pressure“eee” Mean Arterial Pressure

1.1.5 IP4 Status CommandCommand: “uIF” Read Invasive Pressure Status from the PRESS 4

channel.

Response: “uIFabbbcccdddeee”

“a” Channel Status“0” - Connected and OK“1” - Disconnected“2” - Connected but not zeroed

“bbb” Pressure Label“ccc” Systolic Pressure“ddd” Diastolic Pressure“eee” Mean Arterial Pressure

1.1.6 IP3 Alarm Limits CommandCommand: “uIG” Read Invasive Pressure Alarm Limits for the PRESS 3

channel.

Response: “uIGaaabbbcccdddeeefff”

“aaa” Systolic Low Limit“bbb” Systolic High Limit“ccc” Diastolic Low Limit“ddd” Diastolic High Limit“eee” Mean Low Limit“fff” Mean High Limit



1.1.7 IP4 Alarm Limits CommandCommand: “uIH” Read Invasive Pressure Alarm Limits for the PRESS 4

channel.

Response: “uIHaaabbbcccdddeeefff”

“aaa” Systolic Low Limit“bbb” Systolic High Limit“ccc” Diastolic Low Limit“ddd” Diastolic High Limit“eee” Mean Low Limit“fff” Mean High Limit

NOTE: Invasive pressure labels may change.

1.1.8 Wedge Pressure Status CommandCommand: “uIW” Read Wedge Pressure Status

Response: “uIWaaaabbbb”

“aaa” Wedge Pressure“bbbb” Time Since Wedge Pressure

(0 – 1439 minutes)

NOTE: Only an Invasive Pressure channel with the PA label can supply wedge pressure.

NOTE: A Wedge Pressure value of 999 should be interpreted as invalid.

NOTE: If a new determination is being made the new Wedge Pressure value will not be reported and the time set/reset unless the Wedge Pressure value is put into trending. If it is trended then the Pressure value will change and the Time field will be set/reset to 0 and count up; otherwise, the Wedge Pressure value and time will NOT change.



2.4 NON-INVASIVE BLOOD PRESSURE COMMANDSDue to the addition of the SuperStat NIBP module the following modifications have been made.

1.1.9 NIBP Status Command

The existing NIBP Status command will remain the same when receiving status from existing NIBP modules.

Command: “uNA” Read Non-Invasive Blood Pressure Status

Response: “uNAabcddddeeefffggg”

NOTE: If a Determination Status of ‘A’ (indicating Artifact Determination) occurs in a SuperStat module, Host Comm will return ‘3’ – Determination Failed in response to an ‘NA’ command.

NOTE: If Determination Type of ‘2’ is returned (indicating SuperStat Mode) Host Comm will return a ‘0’ – Normal Mode in response to an ‘NA’ command.

NOTE: Although the Time Since Last Determination has been increased from 90 minutes to 120 minutes in the current release of code; the ‘NA’ Status command will continue to invalidate values exceeding 90 minutes. The new ‘NF’ Status command will go until 120 minutes before the values are invalid.

1.1.10 SuperStat NIBP Status Command

The following command has been added to support the new SuperStat NIBP module. It is the same as the existing NIBP Status command, except where noted.

Command: “uNF” Read SuperStat Non-Invasive Blood Pressure Status

Response: “uNFabcddddeeefffggg”

“a” Determination Status“0” - Busy“1” - Done OK“2” - Not Used“3” - Determination Failed (N99)“4” - Pumpup Timeout (N33)“5” - Neonate Host (France Only)“6” - Total Time Timeout (N44)“7” - One-Pressure Timeout (N55)“8” - OverPressure (N00)“9” - Unknown NIBP Status“A” - Artifact Detected (SuperStat Only)

“b” Adult/Neonate Status“0” - Unknown“1” - Adult“2” - Neonate

“c” Determination Type“0” - Normal Mode“1” - Stat Mode“2” - SuperStat Mode (SuperStat Only)

“dddd” Time since last determination of Systolic, Diastolic & Mean Arterial Pressure (in seconds - 0 to 7200)



NOTE: When the timer exceeds 7200 (120 minutes) all values are invalid.

“eee” Systolic Pressure“fff” Diastolic Pressure“ggg” Mean Arterial Pressure



2.5 PULSE OXIMETRY COMMANDSAdditional values have been added to the existing SPO2 values for Native mode. These command extentions are documented below.

1.1.11 Pulse Oximetry Extended Status CommandCommand: “uOC” Read SPO2 Extended Status

Response: “uOCabbbcddeee”

“a” Pulse Ox Status“0” - Standby/Offline“1” - Operate Mode OK“2” - Operate Mode OK“3” - No Data“4” - Check Sensor (P44)“5” - Bad Sensor“6” - Sensor Unplugged

“bbb” Oxygen Saturation“c” Signal Strength (‘0’ to ‘9’)“dd” i) Averaging Interval – SensorMetric

ii) Resp Mode (1 to 3) – Nelcor“eee” Pulse Rate

1.1.12 Pulse Oximetry Extended Alarm Limits CommandCommand: “uOD” Read SPO2 Extended Alarm Limits

Response: “uODaaabbbcccddd”

“aaa” Oxygen Saturation Low Limit“bbb” Oxygen Saturation High Limit“ccc” Pulse Rate Low Limit“ddd” Pulse Rate High Limit



2.6 HEART/PULSE RATE COMMANDSThe Heart/Pulse Rate Status command/response must be extended to account for possible IP3 & IP4 rate sources.

Command: “uRC” Read Heart/Pulse Rate Extended Status

Response: “uRCabbb”

“a” Heart/Pulse Rate Extended Status“0” - No Valid Rate Source“1” - ECG“2” - Pulse Oximeter“3” - Non-Invasive Blood Pressure“4” - Invasive Pressure 1“5” - Invasive Pressure 2“6” - Invasive Pressure 3“7” - Invasive Pressure 4

“bbb” Heart/Pulse Rate



2.7 TEMPERATURE COMMANDSIn addition to the command extensions for Native Mode, the NOTE given below may be added to the Host Comm documentation to provide needed clarity.

1.1.13 Read Temperature Status CommandCommand: “uTA” Read Temperature Status (degrees C)

Response: “uTAabbb”

“a” MPS Monitor Display Format“1” - Centigrade“2” - Fahrenheit

“bbb” Temperature (in tenths of degrees Centigrade)“000” - Indicates unit is unplugged

NOTE: The Display Format value indicates the units used to display the temperature AT THE BEDSIDE ONLY. The value contained in the response to this command WILL ALWAYS respond with a value in tenths of degress Centigrade.

1.1.14 Read Temperature Extended Status CommandCommand: “uTC” Read Temperature Status (degrees F)

Response: “uTCabccccdddd”

“a” Temperature Status“0” - !Operate Mode“1” - Operate mode

“b” MPS Monitor Display Format“1” - Centigrade“2” - Fahrenheit

“cccc” Temperature (in tenths of degrees Fahrenheit)“dddd” Temperature Label

“TEMP” “SKIN”“AXIL” “NASL”“ESOP” “ORAL”“RECT” “BLAD”


1.1.15 Temperature Extended Alarm Limits CommandCommand: “uTD” Read Temperature Alarm Limits (degrees F)

Response: “uTDaaaabbbb”

“aaaa” Temp Low Limit (in tenths of degrees F)“bbbb” Temp High Limit (in tenths of degrees F)



2.8 STAR “*” COMMANDSThe following commands are valid in addition to the Plus Emulation mode Star “*” commands.

1.1.16 Identity CommandCommand: “u*?”

Response: “u*?aaabbc”

“aaaa” Model identifier (8700, 8710, 8720, etc.)“bb” The Plus Emulation Host Comm Revision

Number (current rev level is “00”).“c” Instrument Mode Flag

“0” - Service Mode“1” - Normal Operating Mode with Remote

Control Enabled“2” - Normal Operating Mode with Remote

Control Disabled

NOTE: Neither the syntax nor semantics of this command have changed. It has been added here to provide a further clarification – that the Host Comm Revision Number that is returned is for the Plus Emulation protocol. The *?? command will have to be used to obtain the Native Mode Revision Number.

1.1.17 Extended Identity CommandCommand: “u*??”

Response: “u*??aaabbccd”

“aaaa” Model identifier (8700, 8710, 8720, etc.)“bb” The Plus Emulation Host Comm Revision

Number (current rev level is “00”).“cc” The Native Mode Host Comm Revision Number

(current rev level is “00”).“d” Instrument Mode Flag

“0” - Service Mode“1” - Normal Operating Mode with Remote

Control Enabled“2” - Normal Operating Mode with Remote

Control Disabled

NOTE: This is a new command, necessitated because of the addition of a new binary protocol.

1.1.18 Change Bit RateCommand: “u*Bn”

“n” 5 - 9600 bps6 - 19,200 bps7 - 28,800 bps8 - 38,400 bps9 - 57,600 bps

Response: “u*B+” Bit Rate Change Successful



“u*B-“ Bit Rate Change Not Performed

NOTE: For a successful change in baud rate, the “*B+” response is sent at the OLD baud rate. After the “*B+” response is received by the Host, it should send a NAK with a non-specific NAK code which will cause the Monitor to resend the last valid command. When the Host receives a valid command, it will know that the bit rate has been changed.

NOTE: This command extends the “u*Bn” command already defined in Plus Emulation mode.

NOTE: The Baud Rate cannot be modified if (either) Binary Mode is currently active or if the unit is configured for Ethernet operation.



1.1.19 Read CountersCommand: “u*C”

Response: “u*Cabcc”

“a” The Good Command counter (modulo 64).“b” The Bad command counter (modulo 64).“cc” The Silence State counter (modulo 100).

NOTE: This command is added for completeness. The changes made were to the “cc” field. It was always defined as containing the Silence State count; however, the value returned was hard-coded to 00.

1.1.20 Read All CountersThis command has been added to include the Central Station Snap Shot counter is reported via as ASCII command.

Command: “u*D”

Response: “u*Dabcdd”

“a” The Good Command counter (modulo 64).“b” The Bad command counter (modulo 64).“c” The Central Station Snap Shot counter (modulo

64).“dd” The Silence State counter (modulo 100).

NOTE: The value returned for the Good Command Counter DOES NOT include the command currently being processed (*C or *D), since the command is not considered to be “good” until the task that sends the message indicates that no errors occurred in transmission.



1.1.21 Get Patient InformationCommand: “u*I”

Response: “u*Iaaaaaaaaaaaaaaaaaaaa|bbbbbb|cccc|d”

“aaaaaaaaaaaaaaaaaaaa” The Patient Name (20 chars)“|” Vertical Bar – field delimiter“bbbbbb” The Patient Unit Number (6 chars)“|” Vertical Bar – field delimiter“cccc” The Patient Bed Number (4 chars)“|” Vertical Bar – field delimiter“d” The Patient Type

0 - Adult1 - Neonate2 - Pediatric

NOTE: Encryption?

1.1.22 Set Patient InformationNOTE: This feature should be designed with HL7 compatability in mind.

1.1.22.1 Set Patient NameCommand: “u*JAaaaaaaaaaaaaaaaaaaaa”

“a … a” The Patient Name (0 to 20 ASCII characters)

Response: “u*J+” Command performed“u*J-“ Command rejected.

NOTE: If the input string exceeds 20 characters the string will be truncated to 20 characters.

1.1.22.2 Set Patient Unit Number

Command: “u*JBbbbbbb”

“b … b” The Unit Number (0 to 6 ASCII characters)



1.1.22.3 Set Patient Bed Number

Command: “u*JCcccc”

“c … c” The Bed Number (0 to 4 ASCII characters)





1.1.23 Set User ConfigurationCommand: “u*Kn”

“n” 0 - Default User Configuration 11 - Default User Configuraiton 22 - Default User Configuration 33 - Default User Configuration 44 - Default User Configuration 55 - Default User Configuration 6

Response: “u*K+” User Configuration Change Successful“u*K-“ User Configuration Change Not Performed

NOTE: This command cannot be performed unless Remote Access is enabled



1.1.24 Read Native Mode Alarm FlagsCommand: “u*Mnn”

“nn” n = ‘0’ to ‘35’; indicating Alarm Byte

Response: “u*Maaaaaaaa”

“aaaaaaaa” A series of ‘0’ and ‘1’ characters indicating if alarm bit is ON (1) or OFF (0).

“*M-” Command NAK. Command could not be performed due to improper input parameter.

1.1.25 Read Native Mode Alarm TypesCommand: “u*Nnn”

“nn” n = ‘1’ to ‘35’; indicating Alarm Byte

Response: “u*Naaaaaaaa”

“aaaaaaaa” A series of ‘0’, ‘1’, ‘2’, or ‘3’ characters indicating the alarm priority for the alarms contained in the Alarm Byte.

‘0’ - Message Alarm‘1’ - Procedural Alarm‘2’ - Warning Alarm‘3’ - Crisis Alarm

“*N-” Command NAK. Command could not be performed due to improper input parameter.

NOTE: The Alarm Byte values appear in the order as defined in the Alarm Mapping section of this document and are the same as they are reported in the OPS and LS structures.

NOTE: Command *N0 is invalid because there are no Alarm Priorities that coincide with Alarm Byte 0 – these are general alarms.



1.1.26 Get Battery MinutesThis command returns the battery time remaining (in minutes) for the Portable.

Command: “u*Q”

Response: “u*Qaaa”

“aaa” Battery time remaining, in minutes.

NOTE: This command is not valid for a Select.



1.1.27 Get System TimeCommand: “u*SA”

Response: “u*SAaaaa/bb/cc dd:ee:ff”

“aaaa” The Year (4 digits incl. century information)“bb” The Month (01 –> Jan to 12 Dec)“cc” The Day (01 to 31)“ “ Space – to delineate“dd” The Hour (military time)“ee” The Minutes (00 to 59)“ff” The Seconds (00 to 59)

1.1.28 Set System TimeCommand: “u*SB”

“”

Response: “u*SB”

“”

NOTE: FUTURE



1.1.29 Get Native Binary Mode ConfigurationCommand: “u*W”

Response: “u*Waaaaaaaaaaa”“aaaaaaaaaaa” Configuration of up to 11 waveforms

“A” - ECG Lead I“B” - ECG Lead II“C” - ECG Lead III“D” - ECG Lead aVR“E” - ECG Lead aVL“F” - ECG Lead aVF“G” - ECG Lead Va“H” - ECG Lead Vb“I” - IP1/IP2“J” - IP3/IP4“K” - Pleth/CO2/Resp.“0” to “7” - Spare 0 to Spare 7“-” - Not Used/Zero



1.1.30 Configure Native Binary ModeCommand: “u*Xaaaaaaaaaaa”

“aaaaaaaaaaa” Refer to “*W” Command

Response: “u*X+” Configuration Successfully Changed“u*X-“ Configuration Change Not Performed

NOTE: The “aaaaaaaaaaa” field must be exactly 11 characters long. If less than 11 waveforms are to be sent the field must be padded with “-“ characters. A “-“ character is not allowed to be imbedded within the waveform options.

NOTE: Duplicate non-dash characters are NOT allowed.

NOTE: The waveform characters must be in alphabethical order.

NOTE: The default configuration is “-----------“ for Serial Communications and “ABCDEFGHIJK” for Ethernet Communications.

NOTE: This command is only useful when doing Serial communications. When doing Ethernet communications, all 11 waveforms are always sent; the configuration is NOT modifiable.

NOTE: It is the responsibility of the Host to assure that the proper Baud Rate is set to accommodate the Configuration selected.

NOTE: The type of the 50 Hz waveform block is selected by counting the number of dash characters (n) at the end of the “aaaaaaaaaaa” field. “BHC2_BINARY_BLOCKx” is sent if there are (x = 11-n) trailing dash characters.

NOTE: The Native Binary Mode Configuration cannot be changed if Binary blocks are currently being sent. A *Y0 will have to be sent to stop Binary mode before the configuration change will be allowed.

NOTE: If sending IP waveforms assure that the corresponding waveforms are selected from the “Choose IPs For CS Display” menu options.



1.1.31 Send Native Binary ModeCommand: “u*Ynnnn”

“nnnn” The number of binary blocks to be sent.

“0” - Serial: Stops the current Native Mode Binary Stream.Ethernet: This command is invalid.

“9999” - Serial: The unit is put into an “continuous binary mode” (approx 2.5 years).Ethernet: This command is invalid.

<=“9998” - The new value is added to the existing Binary Count value.Ethernet: The Binary Count value is not allowed to exceed the maimum value of 9998.

Response: binaryData Native Mode binary blocks to follow.

NOTE: If the proper Bit Rate is not selected for the Waveform Configuration, the unit will not enter Native Binary mode.

NOTE: ACK’s and NAK’s are not returned in response to *Y/*Z commands (with the exception of a *Z on Ethernet; a *Z- will be returned since this is an invalid command). A valid command will result in the receipt of Binary Data. An invalid command will receive no response; a timeout should be implemented by the Host.

NOTE: The monitor returns to ASCII mode after the required number of binary blocks are sent.

NOTE: A *Y9999 command is not valid for Ethernet communications. The Host will not be allowed to place the unit in free-run binary mode for an extended period of time (*Y9998 is the maximum). Unlimited sending of data makes sense for serial communication where a point-to-point connection is established; for Ethernet the strain on the network resources would be prohibitive.

NOTE: To switch between Plus Emulation & Native Binary modes the current binary stream must first be terminated or the Binary Count must go to 0. For Serial Communication *Y0 terminates Native Binary Mode only and *Z0 terminates Plus Emulation Binary Mode only. For Ethernet Communication the Binary Count must be allowed to expire.



2 NATIVE BINARY MODEThe *Z command causes Plus Emulation Binary Mode output. The *Y command causes Native Binary Mode output. These two binary output modes are mutually exclusive.

Native Mode binary output is contained in a stream of bytes. A consecutive sequence of bytes forms a binary block. These are sent 50 times per second and are called the 50 Hz binary Block. The binary blocks are sent 4 at a time (a quad binary block). Three (3) bytes are collected from each 50 Hz Binary Block for one continuous second. These bytes form a 150 byte structure that is called the once-per-second (OPS) structure. Sixteen bytes are collected from each OPS structure in one continuous 10 second period. These bytes form a 160 byte Low Speed (LS) structure that is updated once per 10 second period. The remainder of this section describes these structures.

2.9 50 HZ BINARY BLOCKtypedef struct {

char SeqNum;char WFStat;char WFData[5][N]; /* N = number of waveforms */char NonWFData[3];char CSum[2];char ocoSeqNum;

} BinBlkNType, *BinBlkNTypePTR;

2.1.0 SeqNumThis is the block sequence number, modulo 200. The byte counts up by 1 for each consecutive binary block. When the block sequence number reaches 199, it turns back to 0. Since binary blocks arrive at a rate of 50 times per second, the (SeqNum % 50) counts from 0 to 49 and forms a one second scan index. The first byte of a one second scan has (SeqNum % 50) == 0 and the last byte of the same one second scan occurs one second later and has (SeqNum % 50) == 49.

2.1.1 WFStatThe waveform status contains real-time waveform information. Bits <3:2> are incremented for every QRS event detected. Bits <1:0> are the waveform index (0, 1, 2 or 3), indicating which of the 4 binary blocks the event occurs in (this means that the QRS event occurred in 1 of the 4 samples contained in that binary block). Bits <5:4> are incremented for every breath detected. Bit <6> is set if any warning alarm bit is set. Bit <7> is set if any crisis alarm bit is set.

NOTE: Both of the Alarm bits are latched for a minimum duration of 4 WF Stat samples.

NOTE: The QRS Event Detection is only performed on the PRIMARY lead; therefore, if the Unit is not sending the primary lead, bits 0 through 3 in the WFStat should be ignored.

NOTE: The Waveform Index field is only valid when a transition occurs in the QRS Event Detect field.

NOTE: While the QRS & Breath Event fields (bits 0 through 5) are initialized to 0’s when the unit is initially powered up this will not be the case if Native Binary Mode is stopped and restarted. The Host must check for transitions in these fields and not absolute values.



2.1.2 WFDataFor the purpose of host communications, waveform samples are packed into a 5 byte (40 bits) “packed waveform data array” (PWDA). A PWDA contains four 10 bit waveform samples which are packed, without gaps. The following C code fragment is an example of how to unpack the four waveform samples.char pwda[5]; /* packed waveform data array */short wfs[4]; /* waveform samples: bits 15 to 10 are zero. */wfs[0] = ((pwda[0] << 2) | (( pwda[1] >> 6) & 0x03)) & 0x03ff;wfs[1] = ((pwda[1] << 4) | (( pwda[2] >> 4) & 0x0f)) & 0x03ff;wfs[2] = ((pwda[2] << 6) | (( pwda[3] >> 2) & 0x3f)) & 0x03ff;wfs[3] = ((pwda[3] << 8) | (( pwda[4] >> 0) & 0xff)) & 0x03ff;

2.1.3 WFData[5][N]This is an array of PWDA arrays. The number of PWDA arrays can be from 0 to 11 and is configured by the “*X” command. There are 12 different 50 Hz binary block structures. The host must expect the appropriate structure for the configuration specified by the most recent “*X” command (defaults included). The waveform data is 4-way interleaved – same as for Plus Emulation mode.

If the host is communicating to the unit via Ethernet, then the WFData will always be the full set of 11 waveforms and the configuration specified by *X is overwritten. If the Host is utilizing Serial communications, then the configuration specified by *X is used. It is the Host’s responsibility to assure that the appropriate Bit Rate is configured for Serial operation. If the bit rate is not sufficient to support the number of waveforms selected, then binary mode will not be initiated.

# Waveforms Min Bit Rate

0 9.6 Kbps1 9.6 Kbps2 9.6 Kbps3 19.2 Kbps4 19.2 Kbps5 19.2 Kbps6 19.2 Kbps7 28.8 Kbps8 28.8 Kbps9 28.8 Kbps

10 38.4 Kbps11 38.4 Kbps

2.1.4 NonWFDataNumeric (or non-waveform) parameter data and status are available once per second. NonWFData[3] is a 3 byte array that is used to assemble a 150 byte structure called the once-per-second (OPS) structure. The following C code fragment is an example of how to fill the OPS structure. It gets executed once for every new binary block (i.e. 50 times per second).BHC2_BINARY_BLOCK0 bblk; /* binary block (no waveforms) */

union { char bytes[150]; /* individual data bytes */ BHC2_OPS_DATA opsd; /* OPS data */} uBoth;

char *ptr; /* data pointer */



. . .ptr = uBoth.bytes + (3 * (bblk.SeqNum % 50));

*(ptr + 0) = bblk.NonWFData[0];*(ptr + 1) = bblk.NonWFData[1];*(ptr + 2) = bblk.NonWFData[2];

The numeric data and status from an individual parameter cannot be used unless all bytes related to that parameter meet the following two criteria:

0. All bytes must be from the same one second scan; and1. All bytes must be from good 50 Hz binary blocks.

Note that data and status from a single parameter are not always grouped together. In particular, the error flags are not grouped with the other data and status. This must be considered when determining if the about two criteria are met.

The OPS structure contains a member called “lsData”. This is used to build a 160 byte structure called the low speed (LS) structure by a method similar to building the OPS structure itself. The complete LS structure is available once per 10 second interval.

2.1.5 CSumEach binary block has two checksums. This checksum is calculated using the standard 8-bit CRC – CCITT calculation which utilizes the generating polynomial x8 + x7 + x2 + 1. The first checksum, CSum[0], contains the checksum for the first 29 bytes of the binary block (up to 5 waveforms). The second checksum, CSum[1], contains the checksum for the remaining bytes of the binary block (up to 11 waveforms – 59 bytes total). The checksum is calculated for the WFStats, WFData, and NonWFData. The SeqNum and ocoSeqNum are not part of the checksum calculation. When 5 or less waveforms are being transmitted the second checksum byte will contain the one’s compliment of the first checksum.

2.1.6 ocoSeqNumThis member is the ones’ compliment of SeqNum. ocoSeqNum allows the host to find the start of a 50 Hz binary block as quickly as possible after loss of block synchronization.

NOTE: If a transport method is used to send binary blocks that has it’s own error checking and block framing mechanisms, then the CSum and ocoSeqNum members need not be sent. These two members can be reconstructed at the receiver.

NOTE: The data that makes up the OPS structure is captured, in its entirety, before the first byte of the next OPS structure is sent. The contents of the OPS structure should be viewed as a snapshot of the data values at the beginning of this one second interval. The LS structures are handled the same way. The selected LS structure should be viewed as a snapshot of the data values at the beginning of the 10 second interval.

2.10OPS DATA PARTICULARSThe following section gives further details to some of the OPS Data Structure Elements.

2.1.7 Waveform ConfigThe waveform config field is a short data type (16 bits) with each of the low order 11 bits corresponding to one of the 11 possible waveforms to be sent. If the prescribed bit field is SET (logical True) then that waveform is being sent;



conversely, if the bit field is CLEAR (logical False) the corresponding waveform is not being sent. The bit field to waveform mapping is given below.

X X X X X K J I H G F E D C B A---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

2.1.8 IP LabelFor Plus Emulation mode 3 characters are used to send the label of each of 2 possible IP channels. For Native Mode these 3 characters are replaced with a single unsigned character that will contain a single value that is an offset into an array that indicates which label is associated with one of 4 IP channels. The labels associated with each of the offsets is given below.

0 - ART 5 - ICP1 - PA 6 - UAC2 - CVP 7 - UVC3 - RA 8 - SP4 - LA 255 - Undefined (all spaces)

2.1.9 Temperature LabelFor Native Mode the label associated with the Temperature is also sent back. It is a value from 0 to 7. The labels associated with each value are given below.

0 - TEMP 4 - SKIN1 - AXIL 5 - NASL2 - ESOP 6 - ORAL3 - RECT 7 - BLAD

2.1.10 Temperature UnitsIn Plus Emulation mode the temperature value is given in tenths of degrees Centigrade; for Native Mode the temperature value is given in tenths of degrees Fahrenheit. The units that the temperature values are reported in DO NOT VARY; regardless of how the temperature is displayed at the bedside.

2.1.11 Binary Count ValueThe binary count value is provided as a means for the Host programmer to know when the binary data that a unit is sending is about to expire. In some instances this is the desired case; however, when the binary count is approaching a minimum value another *Yn command will have to be sent to keep Binary Mode active.

To translate the value of ‘n’ to a time value you need to know that the count is decremented for each Quad Binary Block transmitted, which occurs at a 12.5 Hz rate so 12.5 counts equal 1 second. However, that much granularity is not needed. The value 9998 needs 14 bits to be stored it in its entirety. We will only be transmitting 8 bits. The lower 4 bits (bits 0 through 3) will not be transmitted, nor will the upper 2 bits (bits 12 & 13). This leaves bits 4 through 11 as shown below. X X X X X X

---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----13 12 11 10 9 8 7 6 5 4 3 2 1 0

By losing the lower 4 bits the granularity of the value is 1 count = 1.28 seconds (a change of 1 now corresponds to 16 counts –> 16/12.5 = 1.28). By not including



the upper two bits, this means that a value of 255 can be a value from 9998 (13.33 minutes) to 3855 (5.14 minutes).

2.1.12 System Time - YearThe system time is returned in an array of 6 unsigned char’s. To obtain the current year (with century information) use the following alogrithm.

If(systime.year > 89) yearWithCentury = systime.year + 1900;else yearWithCentury = systime.year + 2000;

2.1.13 Patient TypeThe following definitions apply to the patientType field:

0 - Adult patient1 - Neonate patient2 - Pediatric patient

All other values are invalid.

2.1.14 Host Comm RevisionThere are now two (2) Host Comm Revision Numbers: one for Plus Emulation mode and one for Native Mode. For this release of code they are both at a revision level of ‘0’. To obtain the current Host Comm Revision Number of either protocol the Host may check the appropriate field in the binary data or issue a *? Command (for Plus Emulation only) or *?? command (for both Plus Emulation & Native Mode).

2.1.15 NIPB PressureThe NIBP Pressure returned for Plus Emulation is the Target Cuff Pressure. This has been changed in Native Mode to be the actual Cuff Pressure. This value will now match the values displayed by the Monitor.

2.11INVALID PARAMETER VALUESInterpretation of non-waveform data (values contained in the OPS & LS structures), must be subject to the following conditions:

0. If the status field for a particular parameter indicates that data is invalid then none of the values associated with that parameter should be considered valid.

1. Invalid values for parameters can be interpreted as the positive and/or negative maximum for the data type. Examples: char (-128 or 127); unsigned char (255); short (-32768 or 32767); and unsigned short (65535). A zero should be interpreted as a valid parameter value; except where noted otherwise.

2.12OPERATIONAL DIFFERENCES1. When the unit is in Configuration Mode, neither of the communications ports (Serial

1, Serial 2, or Ethernet) will be operational. This means that ASCII commands cannot be sent or received, nor will Binary Data (either Plus Emulation or Native modes), be sent. Host Comm will be restarted per the new configuration after Configuration Mode has been exited.



2. The first OPS structure received after HostComm has been started up will consist of all 0’s and should be discarded. This is due to the fact that we are always sending the previous second’s data and, as such, the first second after starting Binary Mode there is no valid data to send. The first LS structure received should contain correct information since it is gathered on the first second of the 10 seconds required to send it in its entirety.



3 USER VIEW MODIFICATIONSThis section deals with the modifications that will be made to any User Interface supported by the hardware.

2.13CONFIGURATION MODE – SETUP HOST COMMAll changes made to Host Comm options during Configuration mode will not take effect until after power reset. This is different from existing operation. To obtain access to these configuration options: 1) put the unit in Config Mode; and 2) select Other System Settings / Config Settings … / Setup Host Comm.

All default values are shown in BOLD.

3.1.0 StartUp ModesAll start-up modes are selectable when the unit is configured for either of the Serial ports; however, if the unit is configured for Ethernet then only Standard Mode is selectable.

Selecting either of the binary modes causes the unit to start sending the appropriate binary packets after power-up (the equivalent of issuing a *Y9999/*Z9999 command). When configured for Standard mode a *Y/*Z command is required to initiate binary mode.

NOTE: Binary is equivalent to Plus Emulation Mode and MPS Binary is equivalent to Native Mode.

Current Options: Standard New Options: StandardBinary Binary

MPS Binary

3.1.1 Communications PortThe Ethernet option will always be displayed, but it will only be selectable when the Ethernet option has been enabled via the Feature Enabler.

Note that the default value has been modified since the last release.

Current Options: Serial 1 New Options: Serial 1Serial 2 Serial 2

Ethernet

3.1.2 Bit RateFor Native Mode, assure that the Bit Rate meets or exceeds the bandwidth requirements for the number of waveforms. For Plus Emulation Mode, a minimum Bit Rate of 9600 bps is required.

NOTE: Bit Rate is not a valid option when the unit is configured for Ethernet communications.

Current Options: 9600 New Options: 960019200 19200

288003840057600



3.1.3 Waveform ConfigThe waveform configuration is a new option. It is only available when the user has selected Native Mode and one of the Serial Ports. This is because with Plus Emulation, the waveform configuration is predetermined, with Ethernet you always get all 11 waveforms, and when configured for Standard mode you can set your own configuration via the *W command or use the default.

Once the user will has selected the maximum number of waveforms for the configured baud rate, no more selections will be allowed. If more waveforms are required, the user must adjust the bit rate accordingly.

Options: EKG Lead I EKG Lead II EKG Lead III EKG Lead aVR EKG Lead aVL EKG Lead aVF EKG Lead Va EKG Lead Vb IP Channels 1&2 IP Channels 3&4 Pleth/CO2/Resp

3.1.4 Ethernet KeyThe Ethernet Key is an encoded value, tied to the unit’s Serial Number that enables the available Ethernet Features. These include: HostComm over Ethernet and Screen Prints to a Laser Printer.

The Key is generated by the genkey.exe program. The program must be supplied with the Unit’s Serial Number and the Feature Number (the Feature Number for Ethernet is 21055345). The resulting integer supplied by the program must be entered into the Ethernet Key field. Since the Key is evaluated for correctness upon entering Configuration Mode, the configuration will have to be saved and Config Mode will have to be re-entered before all Ethernet related Configuration Options will be displayed/available.

The Ethernet Key is NOT saved to E2. Therefore, if the unit suffers a memory loss the Key must be re-entered. The Key will also be lost after performing code upgrades.

The range of valid values is from 0 to 9999. The default value is 0 (zero). There is only one correct combination for each Serial Number.

3.1.5 Unit IP AddressThis option is displayed only if the Ethernet Feature is enabled.

This is the IP Address of the MPS Unit. The Unit does not support any way for automatic determination of its own IP Address (i.e. RARP or BOOTP). The IP Addresses should be obtained from the Network Administrator and should be consistent with the numbering scheme (netID & hostID) for the network to which it is attached. If the unit is moved to a different Subnet then the IP Address should be changed.

A Unit IP Address is a unique 32-bit integer value that is used in all communication with that unit. The most common way of displaying the IP Address is called dotted decimal notation, where each integer is given the value of one octet of the IP Address; thus, each octet has a minimum value of 0 and a



maximum value of 255 (0xFF). In this way the IP Address of 0x98220702 is represented as: 152.34.7.2. To enter this IP Address as the Unit’s IP Address would require the following:

IP Addr 3: 152IP Addr 2: 34IP Addr 1: 7IP Addr 0: 2

Only minor checks are performed to validate the Unit’s IP Address. None of the fields can have a value of 255. If this were done then responses sent back to the unit would be interpreted as some form of Directed Broadcast. Additionally, any IP Address that extends the upper region of Class C addresses will be rejected. Class D (multicast) addresses are NOT valid Host IP Addresses; rather they belong to a group of Hosts. If either of these two conditions are encountered, the IP Address will NOT be modified from its current value, regardless of what the Configuration shows.

3.1.6 Default Gateway IP AddressThis option is displayed only if the Ethernet Feature is enabled.

The Default Gateway performs the function of routing the packet to other networks when the packet cannot be delivered locally. Gateways (Routers) provide physical connections to other networks; by contrast, an MPS Unit (a Host) connects directly to only one physical network. Where the packet that the MPS Unit generates is sent is determined by the Configuration options and the Routing Algorithm.

The Routing Algorithm can be summarized as follows: First the unit determines whether the packet is delivered locally (on the same subnet). This is determined by a “test under mask”. Both the Source and Destination IP Addresses have the Subnet Mask applied to them (AND’d). If the result is an equivalence then the packet can be delivered locally and the destination address is the address of the recipient. Second, the Routing Table is checked for specific routes. For our applications, that table will not have a corresponding entry (except for multicast packets which must have the Host specified as a Gateway since the “test under mask” will not result in a match for Class D addresses – this is performed in software and does not required any user specification). If neither Steps 1 nor 2 are successful, then the packet is sent to the Default Gateway for routing. If the Gateway is unable to route the packet it is discarded by the Gateway; and similarly, if a Default Gateway is not specified (0.0.0.0) the packet is discarded by the Unit.

If the Default Gateway’s IP Address is 152.34.7.10 it would be entered as follows:

Gateway Addr 3: 152Gateway Addr 2: 34Gateway Addr 1: 7Gateway Addr 0: 10

Again, only minor checks are performed on the IP Address of the Default Gateway. Neither the upper nor lower octet can have a value of 0. A packet sent to 0.x.y.z would be interpreted as “Host x.y.z on THIS network”; and an address of x.y.z.0 would be interpreted as “THIS host on network x.y.z”. Neither would be valid for a Default Gateway. A check for an IP Address that exceeds the upper limit for a Class C address is performed for the same reasons as for a Unit IP Address.

This Default Gateway is also used for routing Screen Prints.



3.1.7 Subnet MaskThis option is displayed only if the Ethernet Feature is enabled.

The Subnet Mask defines which portion of the IP Address specifies the Network ID (specified by 1’s) and which part defines the Host ID (specified by 0’s). Initially, there were no constraints placed on the form of the mask – once could, for example, use the low-order bits to identify the Subnet and the middle bits to identify the host. But this liberty made the routing unnecessarily complex without much gain for network management. The specification has thus been updated such that Subnet Masks must be “contiguous”. They can have any length, provided it is larger than one. No constraints have been placed on the Subnet Mask, it is assumed that the User knows how to enter a correct value.

The mask is, ultimately, used to determine if a destination IP Address resides on the same Subnet as the Unit. In the discussion of the Routing Algorithm given above the Subnet Mask is what is used to perform the “test under mask”.

The default value is FF.FF.FF.00.

Subnet Mask 3: 255Subnet Mask 2: 255Subnet Mask 1: 255Subnet Mask 0: 0

3.1.8 Multicast TTLThis option is displayed only if the Ethernet Feature is enabled.

Valid values are 1 to 255; with 1 as the Default. Refer to subsequent sections of this document for TTL guidelines.

2.14CONFIGURATION MODE – SCREEN PRINTThis option is displayed only if the Ethernet Feature is enabled.

All changes made to Screen Print options during Configuration mode will not take effect until after power reset. To obtain access to these configuration options: 1) put the unit in Config Mode; and 2) select Other System Settings / Config Settings … / HP Laser Jet.

3.1.9 IP Address of PrinterTo enable this feature, the IP Address of an HP LaserJet printer & IP Address of the Unit (located in Host Comm Setup) must be entered correctly (refer to section on setting the Unit IP Address). No further modifications need to be made provided that the Printer is locally attached (on the same Subnet) and the correct Subnet Mask is FF.FF.FF.00.

If a Gateway must be used to correctly Route the datagrams to the Printer or if the Default Subnet Mask must be modified then those values must be modified in the Setup Host Comm section of the Configuration menu. It is NOT necessary that HostComm be set to Ethernet to use this feature; however, the Subnet Mask and Default Gateway settings apply to the Routing of both Host Comm and Printer datagrams.



2.15CONFIGURATION MODE – CHOOSE IPS FOR CS DISPLAY

The changes to this section are due to the fact that the unit now supports 2 IP modules, thus there can be a maximum of 4 IP waveforms sent via HostComm.

If the unit is configured for Plus Emulation Binary Mode only waveforms IP1 & IP2 will be sent. If configured for Native Binary Mode over Serial then the Waveform Configuration must be set appropriately for the correct number of IP waveforms to be transmitted. For Ethernet communications 4 IP waveforms are always transmitted.

The default settings remain the same. Although 4 labels may be chosen, only 2 are set for the default case.

Options: ART 1PA 2CVPRALAICPUACUVCIP



4 ALARM HANDLINGThere are over 200 different alarms in the MPS PORTABLE* monitor and several can be active at any particular time. Each possible alarm is identified by an integer value from 0 to 287. This is called the alarm number. Further, the operator can set most of these alarms to any of four severity levels.

The following discussion requires the definition of a “bit index”. An array of ‘n’ characters (char ch[n]) contains 8*n bits. Each bit can be addressed by a bit index ranging from 0 to 8*n-1 as follows.

Array Element MSB LSB

ch[0] bit index 0 bit index 7ch[1] bit index 8 bit index 15. . . . . . . . .

ch[n-1] bit index 8*n-8 bit index 8*n-1

The ON/OFF status of each alarm is conveyed by a single bit in a 36 byte array named alarmFlags in the OPS structure. Alarm number ‘m’ is active if the bit indexed by bit index ‘m’ is a 1; otherwise, alarm number ‘m’ is inactive. Not all alarm flags are used. Refer to the following section for the meaning of each alarm bit.

Each alarm can have one of 4 severity levels. The severity of each alarm is conveyed by two bit pairs in a 72 byte array named alarmType in the LS structure that contains the alarm limits. The four severity levels (0 is low, 3 is high) and their severity codes are as follows:

Alarm Level Severity Code

0 Message1 Procedural2 Warning3 Crisis

The bit in the severity level for alarm number ‘m’ that has a weight of 2 is specified by bit index 2*m in the alarmType array. The bit in the severity level for alarm number ‘m’ that has a weight of 1 is specified by bit index 2*m+1 in the alarmType array.

NOTE: The Alarm Levels contain default values unless the corresponding parameter is operational or the Alarm Level has been modified by the Host/User.

NOTE: Alarms are reported by the system and should ALWAYS be considered valid, regardless of the parameter status.

NOTE: The alarm priority of “Off” is not supported by Host Comm. It will always be reported as “Message”.



5 ETHERNET SUPPORT

2.16GENERAL MPS PORTABLE* NETWORK PROTOCOL

The MPS PORTABLE* has an RJ-45 connector on its rear panel that allows the monitor to be connected to a 10Base-T Ethernet. The MPS PORTABLE* software uses the TCP/IP protocol suite to communicate over Ethernet. Almost all commands and responses that are available for use with the RS-232 port are also available for use with the Ethernet port. Further, the formats of the commands and responses are exactly the same for all communications ports. Actual Ethernet commands and responses will, of course, include the standard headers and trailers as specified by the Ethernet and TCP/IP protocols used.

5.1.0 Network AddressingEach MPS PORTABLE* “owns” a single Ethernet (or MAC) address. The Ethernet address is configured at the factory and cannot be changed. Each MPS PORTABLE* also owns two (2) IP addresses. One of these is an IP address that is assigned at configuration time. The other IP address is a Class D multicast address. This address belongs to the Class D group 234.*.*.*, and uses the same lower 24 bits as the user assigned IP address.

It should be noted here that there is a potential problem with the translation from Multicast IP Address into Multicast Hardware (MAC) Address. The Hardware Address (or Ethernet address) is a 48-bit address that is unique for each machine; hence, there are no two hardware interfaces that share the same Ethernet address. Usually, the Ethernet address is fixed in machine readable form on the host interface hardware. Because Ethernet addresses belong to hardware devices, they are sometimes called hardware addresses or physical addresses. In addition to specifying a single destination computer, the Hardware Address can be one of three types:

The physical address of one network interface (a unicast address) The network broadcast address A multicast address

The unicast address has already been discussed, and by convention, the broadcast address (all 1’s) is reserved for sending to all stations simultaneously. The multicast address provides a limited form of broadcasting. To accommodate broadcast & multicast addressing, the Ethernet interface hardware must recognize more than its physical address. A host interface usually accepts at least two kinds of packets: those addressed to the interface’s physical (unicast) address and those addressed to the network broadcast address. The interface must be programmed to recognize the multicast hardware address (and even alternate physical addresses). When the Operating System starts, it initializes the Ethernet interface, giving it a set of addresses to recognize. The interface then examines the destination address field in each packet, passing on to the host only those transmissions designated for one of the specified addresses.

The Multicast IP Address (which is computed from the senders Host IP Address), is a 32-bit number, and Ethernet Addresses are 48-bit numbers. Ethernet uses the low-order bit of the high-order octet to distinguish conventional unicast addresses (0) from multicast addresses (1). In dotted hexadecimal notation, the multicast bit is given by: 01.00.00.00.00.00. IP Multicast uses Class D



addresses which require the first 4 bits (0 – 3) of the 32-bit integer to be: 1110. The remaining bits (3 – 31) are left to be used for identifying a particular multicast group. Thus IP addresses in the range 224.0.0.0 through 239.255.255.255 are Class D addresses.

Now, the rules for mapping an IP Multicast address to Ethernet Multicast address is as follows:

Place the low-order 23 bits of the IP Multicast address into the low-order 23 bits of the special Ethernet Multicast address 01.00.5E.00.00.00.

Applying this mapping, IP Multicast address 224.0.0.1 becomes Ethernet Multicast address 01.00.5E.00.00.01. The mapping is NOT unique because IP Multicast addresses have 28 significant bits that identify the Multicast group, and only 23 of those bits map into the Ethernet Address; the upper 5 bits of the Multicast Group ID are ignored in the mapping. Therefore, 32 different multicast group IDs map to each Ethernet Address. For example, the multicast address 224.128.64.32 (e0.80.40.20) and 224.0.64.32 (e0.00.40.20) both map into the Ethernet Address 01.00.5E.00.40.20. This should generally NOT be a problem since the 5 bits in question are usually part of the network ID portion of the IP Address and should not deviate that much in local network scenarios. However, if Hosts that are Clients of our binary data are also Clients of other multicast groups, this factor needs to be considered.

5.1.1 Message FormatTwo (2) types of Ethernet messages will be used for Host Communications:

0. ASCII command and ASCII response messages; and1. Binary response messages.

ASCII messages are sent via UDP using unicast IP. Binary responses are sent via a Raw Socket (protocol = 101) over multicast IP. When the monitor is configured for Ethernet and goes through a power-cycle, the MPS PORTABLE* opens a UDP socket bound to port number 65123 and waits to receive a datagram containing a host command.

One ASCII command message is sent from a Host to the MPS PORTABLE* in a single UDP packet. The body of the command will be identical to the packet transmitted via Serial communications.

One ASCII response message will be sent from the MPS PORTABLE* as a UDP datagram back to the Host’s source socket. The body of the command will be identical to the packet transmitted via Serial communications.

When sending ASCII commands via a Serial Port the command/response nature of the communication can be somewhat assured due to the nature of the connection; however, when sending and receiving data via the Ethernet Port greater care needs to be taken. To that end, subsequent commands should NOT be sent until a response from the previous command is received or a timeout period has expired. If this edict is deviated from the programmer should be aware of the fact that commands could be dropped by the unit and responses could be received out of order by the Host. If multiple commands are sent without waiting for responses, they should NOT be order dependent since the unit cannot assure the order in which they will be received and processed. Further, if multiple commands are received, the Unit does not assure that a response will be sent before the next command is processed.

If the *Y command is received, the monitor prepares to send binary responses in the selected format. The MPS PORTABLE* opens a Raw Socket and begins



sending Native Mode binary data to the multicast group. In order to receive the multicast datagrams, the Host must join the multicast group (via IGMP). If the datagram must be routed, the Router must have Multicast capability and the Multicast TTL field must be greater than 1. The binary block is preceded by the pseudo-UDP header shown below.

typedef struct {

USHORT HdrSrcPort; /* Some predefined number - 999 */ USHORT HdrDestPort; /* Some predefined number - 666 */ USHORT MsgLen; /* including this header */ USHORT MsgChkSum; /* not implemented – will be 0 */

} ADPHeaderType, *ADPHeaderTypePtr;

As with all connectionless data transmitted via Ethernet, the Host cannot be assured of receiving packets in the order in which they were transmitted. Therefore, it is the responsibility of the Host to assure that the incoming binary data is sequenced properly by checking the Sequence Numbers of the blocks received and implementing a queuing mechanism for out of order blocks. Similarly, duplicate and dropped packets must be accounted for.

5.1.2 Native Mode Binary Over EthernetThe Native Mode binary protocol produces 50 binary blocks per second. The network batches 4 binary blocks in one datagram; therefore, datagrams are sent at a rate of 12.5 per second. Note that datagrams sent on Raw Sockets do not have checksums. The checksums in the individual binary blocks are sufficient.

The Host needs to determine how long it wishes the MPS PORTABLE* to remain in Binary Mode. If that time value is 13.33 minutes or less, then this can be accomplished with only one *Y command. If, however, the time period exceeds this value, then the host will need to send multiple *Y commands. To better determine when to send subsequent commands the Host Comm Protocol has implemented a Binary Count value that gives insight into how much longer the unit will continue to send binary data (refer to Section 2.2.4). A comparison of this value to a minimum value could provide the impetus to sending another *Y command.

Since the *Y0 command is not valid for Ethernet communications, Native Mode binary data will continue to be sent until the Binary Count reaches 0 (a maximum of 13.3 minutes). Also, since this is not a point-to-point connection as with Serial communications, there may be more than one Host sending *Y commands to a unit. So, just blindly sending a *Y9998 command every 13 minutes is not necessarily a good idea. It should also be noted that new a *Yn value received by the unit is added to the existing count value; however, at no time does the value exceed 9998. So, if the current count value is 7500 (10 minutes) and a value of 3750 (5 minutes) is received the total is 11,250 (15 minutes), but the count will only be 9998 (13.33 minutes).

5.1.3 Multicast TTLThe Time-To-Live (TTL) value is part of the IP datagram and helps to avoid endlessly looping packets. Each Router decrements the TTL value by 1 before passing it along to the next hop. A datagram with a TTL of 0 is not forwarded. By default, IP Multicast datagrams are sent with a TTL of 1, which prevents them from being forwarded beyond a single subnet. The User can modify the TTL value from 1 to 255 in order to control the scope of the multicasts. A value of 0 is not allowed since a Multicast datagram with a TTL of 0 will not be transmitted on any subnet (it can be received only by the sender, provided Multicast Loopback



is enabled). Multicast datagrams with a TTL greater than one may be delivered to the first-hop subnet. To provide meaningful scope control, most Multicast Routers support the notion of TTL “thresholds”, which prevent datagrams with less than a certain TTL from traversing certain subnets. The thresholds enforce the following conventions:

Multicast Datagrams w/ TTL 1 are restricted to the same Subnet.Multicast Datagrams w/ TTL 32 are restricted to the same Site.Multicast Datagrams w/ TTL 64 are restricted to the same Region.Multicast Datagrams w/ TTL 128 are restricted to the same Continent.Multicast Datagrams w/ TTL 255 are unrestricted in scope.

“Sites” and “Regions” are not strictly defined, and Sites may be further subdivided into smaller administrative units, as a local matter.

2.17IP ADDRESS DETERMINATIONThe unit will NOT be able to dynamically determine its IP Address (via RARP, BOOTP, etc.). Therefore, it must be entered manually by the user during unit Configuration. In addition, the Subnet Mask and Router IP address must be specified if communications outside the scope of the local network are required.

Parameter Default Value Required for Ethernet Communications?

Unit IP Address

0.0.0.0(THIS Host on THIS

Subnet)

YesMust be modified in order to receive responses & send

binary dataDefault

Gateway IP Address

0.0.0.0(No Def Gateway)

YesIf communications outside local network are required

Subnet Mask FF.FF.FF.00 Yes

TTL Value 1Yes

If Host resides on other than the local subnet.



6 NATIVE MODE ALARM MAPPINGFor Native Mode all possible alarms will be sent, not just a group alarm. To this end, the alarms have been mapped into the bit fields of 30 Bytes as shown below. New additions will be appended to the end of the structure.

To decode the Alarm Priority’s for the associated alarm, simply treat the incoming data as unsigned shorts instead of bytes and allow 2 bits for each priority (values from 0 to 3). This way, the offsets remain the same. (e.g.: USHORT[5], bits 3*2 and (3*2) –1 yield the Priority associated with BYTE[5], bit 3).

Byte[0] 0000 0001 - Standby Alarm0000 0010 - Alarm In Progress0000 0100 - UnACKed Alarms0000 1000 - UNDEFINED0001 0000 - UNDEFINED0010 0000 - UNDEFINED0100 0000 - UNDEFINED1000 0000 - UNDEFINED

Byte[1] 0000 0001 - Alarm Fatal0000 0010 - Alarm Removed0000 0100 - Alarm Fail0000 1000 - Alarm Error0001 0000 - Alarm Too Many0010 0000 - Alarm None0100 0000 - ART Fatal1000 0000 - ART Removed

Byte[2] 0000 0001 - ART Fail0000 0010 - ART Error0000 0100 - ART Too Many0000 1000 - PA Fatal0001 0000 - PA Removed0010 0000 - PA Fail0100 0000 - PA Error1000 0000 - PA Too Many

Byte[3] 0000 0001 - CVP Fatal0000 0010 - CVP Removed0000 0100 - CVP Fail0000 1000 - CVP Error0001 0000 - CVP Too Many0010 0000 - RA Fatal0100 0000 - RA Removed1000 0000 - RA Fail



Byte[4] 0000 0001 - RA Error0000 0010 - RA Too Many0000 0100 - LA Fatal0000 1000 - LA Removed0001 0000 - LA Fail0010 0000 - LA Error0100 0000 - LA Too Many1000 0000 - ICP Fatal

Byte[5] 0000 0001 - ICP Removed0000 0010 - ICP Fail0000 0100 - ICP Error0000 1000 - ICP Too Many0001 0000 - UAC Fatal0010 0000 - UAC Removed0100 0000 - UAC Fil1000 0000 - UAC Error

Byte[6] 0000 0001 - UAC Too Many0000 0010 - UVC Fatal0000 0100 - UVC Removed0000 1000 - UVC Fail0001 0000 - UVC Error0010 0000 - UVC Too Many0100 0000 - IP Fatal1000 0000 - IP Removed

Byte[7] 0000 0001 - IP Fail0000 0010 - IP Error0000 0100 - IP Too Many0000 1000 - UNLABELED Fatal0001 0000 - UNLABELED Removed0010 0000 - UNLABELED Fail0100 0000 - UNLABELED Error1000 0000 - UNLABELED Too Many

Byte[8] 0000 0001 - Pulse Fatal0000 0010 - Pulse Removed0000 0100 - Pulse Fail0000 1000 - Pulse Error0001 0000 - Pulse Too Many0010 0000 - ECG Fatal0100 0000 - ECG Removed1000 0000 - ECG Fail

Byte[9] 0000 0001 - ECG Error0000 0010 - ECG Too Many0000 0100 - Temp Fatal0000 1000 - Temp Removed0001 0000 - Temp Fail0010 0000 - Temp Error0100 0000 - Temp Too Many1000 0000 - CO2 Fatal



Byte[10] 0000 0001 - CO2 Removed0000 0010 - CO2 Fail0000 0100 - CO2 Error0000 1000 - CO2 Too Many0001 0000 - Resp Fatal0010 0000 - Resp Removed0100 0000 - Resp Fail1000 0000 - Resp Error

Byte[11] 0000 0001 - Resp Too Many0000 0010 - SPO2 Fatal0000 0100 - SPO2 Removed0000 1000 - SPO2 Fail0001 0000 - SPO2 Error0010 0000 - SPO2 Too Many0100 0000 - NIBP Fatal1000 0000 - NIBP Removed

Byte[12] 0000 0001 - NIBP Fail0000 0010 - NIBP Error0000 0100 - NIBP Too Many0000 1000 - Recorder Fatal0001 0000 - Recorder Removed0010 0000 - Recorder Fail0100 0000 - Recorder Error1000 0000 - Recorder Too Many

Byte[13] 0000 0001 - ART Sys Hi0000 0010 - PA Sys Hi0000 0100 - CVP Sys Hi0000 1000 - RA Sys Hi0001 0000 - LA Sys Hi0010 0000 - ICP Sys Hi0100 0000 - UAC Sys Hi1000 0000 - UVC Sys Hi

Byte[14] 0000 0001 - IP Sys Hi0000 0010 - ART Sys Lo0000 0100 - PA Sys Lo0000 1000 - CVP Sys Lo0001 0000 - RA Sys Lo0010 0000 - LA Sys Lo0100 0000 - ICP Sys Lo1000 0000 - UAC Sys Lo

Byte[15] 0000 0001 - UVC Sys Lo0000 0010 - IP Sys Lo0000 0100 - ART Dias Hi0000 1000 - PA Dias Hi0001 0000 - CVP Dias Hi0010 0000 - RA Dial Hi0100 0000 - LA Dias Hi1000 0000 - ICP Dias Hi



Byte[16] 0000 0001 - UAC Dias Hi0000 0010 - UVC Dias Hi0000 0100 - IP Dias Hi0000 1000 - ART Dias Lo0001 0000 - PA Dias Lo0010 0000 - CVP Dias Lo0100 0000 - RA Dias Lo1000 0000 - LA Dias Lo

Byte[17] 0000 0001 - ICP Dias Lo0000 0010 - UAC Dias Lo0000 0100 - UVC Dias Lo0000 1000 - IP Dias Lo0001 0000 - ART Mean Hi0010 0000 - PA Mean Hi0100 0000 - CVP Mean Hi1000 0000 - RA Mean Hi

Byte[18] 0000 0001 - LA Mean Hi0000 0010 - ICP Mean Hi0000 0100 - UAC Mean Hi0000 1000 - UVC Mean Hi0001 0000 - IP Mean Hi0010 0000 - ART Mean Lo0100 0000 - PA Mean Lo1000 0000 - CVP Mean Lo

Byte[19] 0000 0001 - RA Mean Lo0000 0010 - LA Mean Lo0000 0100 - ICP Mean Lo0000 1000 - UAC Mean Lo0001 0000 - UVC Mean Lo0010 0000 - IP Mean Lo0100 0000 - ART No Signal1000 0000 - PA No Signal

Byte[20] 0000 0001 - CVP No Signal0000 0010 - RA No Signal0000 0100 - LA No Signal0000 1000 - ICP No Signal0001 0000 - UAC No Signal0010 0000 - UVC No Signal0100 0000 - IP No Signal1000 0000 - ART Not Zeroed

Byte[21] 0000 0001 - PA Not Zeroed0000 0010 - CVP Not Zeroed0000 0100 - RA Not Zeroed0000 1000 - LA Not Zeroed0001 0000 - ICP Not Zeroed0010 0000 - UAC Not Zeroed0100 0000 - UVC Not Zeroed1000 0000 - IP Not Zeroed



Byte[22] 0000 0001 - ART Disconnect0000 0010 - PA Disconnect0000 0100 - CVP Disconnect0000 1000 - RA Disconnect0001 0000 - LA Disconnect0010 0000 - ICP Disconnect0100 0000 - UAC Disconnect1000 0000 - UVC Disconnect

Byte[23] 0000 0001 - IP Disconnect0000 0010 - ECG Artifact0000 0100 - ECG Replace Electrodes0000 1000 - ECG Lead Fail0001 0000 - Asystole0010 0000 - Resp Hi0100 0000 - Resp Lo1000 0000 - Resp Artifact

Byte[24] 0000 0001 - Resp Baseline Sat0000 0010 - Resp Lead Fail0000 0100 - Resp Rate App HR0000 1000 - CO2 Resp Rate High0001 0000 - CO2 Resp Rate Low0010 0000 - CO2 High0100 0000 - CO2 Low1000 0000 - CO2 No Breath

Byte[25] 0000 0001 - CO2 Sensor Unplugged0000 0010 - CO2 Sensor Too Hot0000 0100 - CO2 Sensor Faulty0000 1000 - CO2 Sampling Line Brea0001 0000 - CO2 Sampling Line Bloc0010 0000 - CO2 Sensor Need Cal0100 0000 - CO2 Zero Cal Error1000 0000 - CO2 Check Adapter

Byte[26] 0000 0001 - CO2 Cal Cannula (OBSOLETED)0000 0010 - NIBP Sys High0000 0100 - NIBP Sys Low0000 1000 - NIBP Dias High0001 0000 - NIBP Dias Low0010 0000 - NIBP Map High0100 0000 - NIBP Map Low1000 0000 - NIBP No Det

Byte[27] 0000 0001 - NIBP Over Pressure0000 0010 - NIBP PUTO0000 0100 - NIBP TTTO0000 1000 - NIBP TOAOL0001 0000 - SPO2 Sat High0010 0000 - SPO2 Sat Low0100 0000 - SPO2 Sensor Off1000 0000 - SPO2 Lost Pulse



Byte[28] 0000 0001 - Pulse Rate High0000 0010 - Pulse Rate Low0000 0100 - Temp High0000 1000 - Temp Low0001 0000 - Temp Sensor Off0010 0000 - Recorder No Paper0100 0000 - Recorder Door Open1000 0000 - Recorder Cannot Print

Byte[29] 0000 0001 - Unknown Parameter0000 0010 - Memory Lost0000 0100 - AC Power Failed0000 1000 - Unknown Module Failed0001 0000 - SPO2 Pulse Rate High0010 0000 - SPO2 Pulse Rate Low0100 0000 - PORTABLE Fan Failed1000 0000 - PORTABLE Battery Failed

Byte[30] 0000 0001 - PORTABLE 9V Battery Fail0000 0010 - NIBP Artifact0000 0100 - Screen Print Failure0000 1000 - ECG Low Amplitude0001 0000 - UNDEFINED0010 0000 - UNDEFINED0100 0000 - UNDEFINED1000 0000 - UNDEFINED

Byte[31] 0000 0001 - UNDEFINED0000 0010 - UNDEFINED0000 0100 - UNDEFINED0000 1000 - UNDEFINED0001 0000 - UNDEFINED0010 0000 - UNDEFINED0100 0000 - UNDEFINED1000 0000 - UNDEFINED



7 OPS NATIVE MODE STRUCTURE/** ======================================================================= ** ** OPS Native Mode Structure ** ** ======================================================================= **/

typedef struct {

/******************************************** ** System & Waveform Configuration Data ** ********************************************/

UCHAR model; // Instrument model number // 16 -> SELECT, 17 -> Portable UCHAR hcpRev; // HostComm protocol revision number short config; // Waveform configuration (11-bit) // 288 1-bit alarm flags UCHAR alarmFlags[NUM_ALARM_CHARS * 1]; long lsData[4]; // Low speed data (16 bytes) UCHAR lsIndex; // Low speed data index (0 to 9) UCHAR binaryCount; // Each count corresponds to 1.3 seconds // of binary data.

/**************************** ** Patient Numeric Data ** ****************************/

/** Multilead ECG **/ UCHAR ecgStatus; // Status (same as PE) UCHAR ecgMode; // 0 -> Single Lead // 1 -> MultiLead UCHAR ecgNeonate; // False -> Adult // True -> Neonate UCHAR ecgPrimary; // Primary Lead Number UCHAR ecgVa; // Lead number for Va (0x09 to 0x0e) UCHAR ecgVb; // Lead number for Vb (0x09 to 0x0e)

/** NIBP **/ short nibpSys; // Systolic (0 to 260 mmHg) short nibpDias; // Diastolic (0 to 260 mmHg) short nibpMap; // MAP (0 to 260 mmHg) short nibpAge; // Age of last determination (0 to 5400sec) short nibpTarget; // Target cuff pressure (not used) short nibpCuffP; // Cuff Pressure UCHAR nibpStatus; // Bits<3:0> -> status // Bits<5:4> -> cuff type // Bits<7:6> -> stat mode UCHAR nibpQIndex; // FUTURE - Quality Index (0 to 100)

/** Invasive Pressure Channels 1 - 4 **/ UCHAR ip1Label; // Channel label // 0 -> ART // 1 -> PA // 2 -> CVP // 3 -> RA // 4 -> LA // 5 -> ICP // 6 -> UAC // 7 -> UVC // 8 -> SP // 255 -> No Label (all spaces) UCHAR ip1Status; // Status short ip1Sys; // Systolic (-30 to 300 mmHg) short ip1Dias; // Diastolic (-30 to 300 mmHg) short ip1Mean; // Mean Pressure (-30 to 300 mmHg)

UCHAR ip2Label; // Channel label UCHAR ip2Status; // Status short ip2Sys; // Systolic (-30 to 300 mmHg)



short ip2Dias; // Diastolic (-30 to 300 mmHg) short ip2Mean; // Mean Pressure (-30 to 300 mmHg)

UCHAR ip3Label; // Channel label UCHAR ip3Status; // Status short ip3Sys; // Systolic (-30 to 300 mmHg) short ip3Dias; // Diastolic (-30 to 300 mmHg) short ip3Mean; // Mean Pressure (-30 to 300 mmHg)

UCHAR ip4Label; // Channel label UCHAR ip4Status; // Status short ip4Sys; // Systolic (-30 to 300 mmHg) short ip4Dias; // Diastolic (-30 to 300 mmHg) short ip4Mean; // Mean Pressure (-30 to 300 mmHg)

/** Wedge Pressure **/ short wedgePressure; // Wedge pressure (LIMITS???) USHORT wedgeTime; // Time since last reading (0 - 1439)

/** Pulse Ox **/ UCHAR poStatus; // Status UCHAR poSat; // O2 saturation (0 to 100%) short poRate; // Pulse rate (0 to ??? beats per minute UCHAR poBarGraph; // Pulse bar graph (0 to 15) UCHAR poMode; // Averaging Interval for SensorMetric // Resp Mode for Nelcor

/** CO2 Status **/ UCHAR co2Status; // CO2 Status -> 0 = !Operate Mode // 1 = Operate Mode UCHAR co2Inspired; // Inspired CO2 (1/2 mmHg - 0 to 255) short co2Rate; // Breath Rate (0 - ??? breaths per min) UCHAR co2EndTidal; // End Tidal CO2 (1/2 mmHg - 0 to 255)

/** Temperature **/ UCHAR tempStatus; // Status // BIT 7: Set = degF at beside // Clear = degC at beside // 0 -> !Operate Mode // 1 -> Operate Mode short tempDDeg; // Deci-degrees in Farenheit UCHAR tempLabel; // temperature label // 0 -> TEMP // 1 -> AXIL // 2 -> ESOP // 3 -> RECT // 4 -> SKIN // 5 -> NASL // 6 -> ORAL // 7 -> BLAD

/** Heart/Pulse Rate **/ UCHAR pulseStatus; // Status & source short pulseBPM; // beats per minute (0 - 300)

/** ECG Derived Resp **/ UCHAR respStatus; // Status UCHAR respRate; // ECG Derived Breath Rate (0 to ??? bpm)

/*************************** ** MISCELLANEOUS STUFF ** ***************************/

UCHAR flags; // Bit 0 == 1 -> Service Mode // Bit 1 == 1 -> Remote Control Mode UCHAR silenceState; // Silence key pressed state UCHAR cmdOKSeqN; // Command OK Sequence Number // Host to Select UCHAR systemTime[6]; // System time ([0] = year // [1] = month // [2] = day // [3] = hours // [4] = minutes



// [5] = seconds) UCHAR cmdNGSeqN; // Command No Good Sequence Number // Host to Select UCHAR csSnapShotCnt; // Central Station Snapshot req counter UCHAR MoreSpares[5]; // Padding to make struct come out to // 150 bytes exactly.

} NMopsDataType, *NMopsDataTypePTR;



8 LS NATIVE MODE STRUCTURE/** ======================================================================= ** ** LS NM Strucutre ** ** ======================================================================= **/

typedef struct {

/****************** ** ALARM INFO ** ******************/ UCHAR alarmType[NUM_ALARM_CHARS * 2]; // 3 -> Crisis // 2 -> Warning // 1 -> Procedural // 0 -> Message /************************* ** NIBP ALARM LIMITS ** ** 0 to 240 mmHg ** *************************/

short nibpSysHi; // Systolic High short nibpSysLo; // Systolic Low short nibpDiasHi; // Diastolic High short nibpDiasLo; // Diastolic Low short nibpMapHi; // MAP High short nibpMapLo; // MAP Low

/************************ ** IP1 ALARM LIMITS ** ** -30 to 300 mmHg ** ************************/

short ip1SysHi; // Systolic High short ip1SysLo; // Systolic Low short ip1DiasHi; // Diastolic High short ip1DiasLo; // Diastolic Low short ip1MeanHi; // Mean High short ip1MeanLo; // Mean Low









/*********************** ** PULSE OX LIMITS ** ** 0 to 100% ** ***********************/

UCHAR poSatHi; // O2 Saturation High UCHAR poSatLo; // O2 Saturation Low UCHAR poRateHi; // Pulse Rate High UCHAR poRateLo; // Pulse Rate Low

/***************************************** ** CO2 LIMITS & Barometric Pressure ** ** (1/2 mmHg) (mmHg) ** *****************************************/

short co2BarPress; // Barometric Pressure measured by Co2. UCHAR co2ETHi; // End-tidal High UCHAR co2ETLo; // End-tidal Low short co2RateLo; // Resp Rate Low short co2RateHi; // Resp Rate High

/****************************** ** HEART/PULSE RATE LIMITS ** ** 0 to 300 bpm ** ******************************/ /***************************************************************** ** NOTES: ** 1) For all cardiac sourcew except PO (ECG, IP, NIBP) ** 2) We call it "heart rate", even though it's "pulse rate" *****************************************************************/

short heartRateLo; // Heart/Pulse Rate Low short heartRateHi; // Heart/Pulse Rate High

/************************************************* ** ECG DERIVED RESPIRATION RATE LIMITS (bpm) ** ** LIMITS??? ** *************************************************/

UCHAR respRateHi; // Respiration Rate High UCHAR respRateLo; // Respiration Rate Low

/************************** ** TEMPERATURE LIMITS ** ** LIMITS??? ** **************************/

short tempDDegHi; // Temperature High; short tempDDegLo; // Temperature Low;

/*********** ** ETC ** ***********/

short batMinutes; // Battery time remaining (in minutes) // ONLY VALID FOR PORTABLE! // Select will always report 0. UCHAR patientType; // 0 -> adult patient // 1 -> neonate patient // 2 -> pediatric UCHAR spares[3]; // structure must be exactly 160 bytes long

} NMlsDataType, *NMlsDataTypePTR;


Documents

Protocol Definition Document - School of Engineeringeecs.vanderbilt.edu/courses/eece295/2004_2005/vumc_gcrc/... · Web viewSubnet Mask 2: 255 Subnet Mask 1: 255 Subnet Mask 0: 0 Multicast