NXP Pulse Oximeter using USB PHDC Application Note
Freescale Semiconductor
Application Note
Document Number: AN4496
Rev. 0, 03/2012
Pulse Oximeter Using USB PHDC
by:
Jose Santiago Lopez Ramirez
RTAC Américas
Contents
1 Introduction
This Application note explains the implementation of a pulse
oximeter which communicates with a computer using the USB
Personal Healthcare Device Class. Implementation is done on
the Freescale MK53N512 Kinetis microcontroller, but can be
implemented on any Freescale USB capable microcontroller.
This Application note is intended for medical solutions
developers, biomedical engineers or any person interested on
the USB personal healthcare device class. Nevertheless, some
skills in C programming and microcontrollers handling are
required.
This Application note is closely related with the application
note “AN4327 Pulse Oximeter Fundamentals and Design”. It
is recommended to read AN4327 for better understanding.
2 Personal Healthcare Device
Class Overview
Universal Serial Bus (USB) is a standard which defines
hardware and protocols for intercommunication between a
host (usually a PC) and one or more devices. Each USB
device has its own purpose, and therefore, they are divided in
different classes according to their function. One example is
the Human Interface Device (HID) class which is used in
devices like computer keyboards and mouse.
© 2012 Freescale Semiconductor, Inc.
1 Introduction................................................................1
2 Personal Healthcare Device Class
Overview...................................................................1
3 Pulse Oximeter Implementation...............................2
3.1 System Initialization......................................3
3.2 Application Initialization...............................3
3.3 Application Execution....................................3
3.3.1 ISO/IEEE 11073-20601
communication process....................3
3.3.2 Application Execution in the
Microcontroller...............................9
4 Running the Demo..................................................10
4.1 Hardware Set................................................10
4.1.1 Assembling the demo....................12
4.2 Demo Execution...........................................16
5 References...............................................................18
6 Conclusions.............................................................19
Pulse Oximeter Implementation
Personal Healthcare Device Class (PHDC) defines the requirements to establish communication and seamless interoperability
between personal USB medical devices and USB hosts, to be then processed, stored or transmitted to a doctor or relative via
internet.
USB PHDC is used by healthcare exchange protocols like ISO/IEEE 11073-20601 as the transportation method for the
communication packets between the host and the personal healthcare device. It standardizes the way in which the data and
messages are sent over USB.
3 Pulse Oximeter Implementation
Pulse Oximeter is implemented using Freescale TWR-K53N512, a tower development board including the medical oriented
microcontroller MK53N512, MED-SPO2 an analog front end board for pulse oximetry solutions development and TWRSER a tower system board for designs including serial communications. This is the same hardware used in AN4327 “Pulse
Oximeter Fundamentals and Design”. Please refer to this application note for more information about pulse oximetry
principles and the hardware used in the pulse oximeter development.
System is based on the Freescale USB stack with PHDC which is free code for developing solutions that require USB
connectivity and can be downloaded from the Freescale web page. This stack contains functions that can be used at device
level (configure clocks, initialize USB module, etc…) and the class level (send-receive packets, send descriptors, etc…).
Please refer to Freescale USB Stack with PHDC Stack Users Guide and Freescale USB Stack with PHDC Device API
Reference Manual for better understanding.
Software is basically divided in three main parts: System Initialization, Application Initialization and Application Execution.
Final application is executed in an infinite loop as shown in the following flow diagram (Figure 1).
Figure 1. Software model flow diagram
Pulse Oximeter Using USB PHDC, Rev. 0, 03/2012
2 Freescale Semiconductor, Inc.
Pulse Oximeter Implementation
For a better understanding of this chapter, it is highly recommended to open the MED-SPO2 PDHC C project and view it as
you read these lines.
3.1 System Initialization
System initialization is executed when the function Init_Sys is called at the beginning of the program. Init_Sys is a device
level function and varies upon the microcontroller. It initializes the required peripherals on the microcontroller for the stack
functionality. Init_Sys first enables the interrupts on the USB module configuring the NVICICER2 and NVICISER2
registers. Then it enables the GPIO modules required by the microcontroller calling the function GPIO_Init. Init_Sys now
calls pll_init function which configures the microcontroller for working at 50MHz using an external clock source. Once the
microcontroller’s clock has been configured, MPU_CESR register is cleared and microcontroller is configured to energize
and bring clock signal to USB module for future enumeration.
3.2 Application Initialization
Application initialization configures the previously initialized modules for use of the pulse oximetry PHDC application. This
configuration starts when the function TestApp_Init is called. TestApp_Init first calls the function PHD_Transport_Init. This
function manages the enumeration of the microcontroller’s USB module as PHDC by enabling the Pull-Up resistors and
handling the enumeration process. PHD_Transport_Init returns an error value. If error “OK” is returned it means that the
device has been already enumerated as a PHD (Personal Healthcare Device) otherwise something went wrong during the
enumeration and device might not be recognized by the host PC. At this point, the device is recognized by the host as a PHD
but it is not defined yet as a pulse oximeter device using the standard ISO/IEEE 11073-20601.
After enumeration, TWR-K53N512 on-board LEDs and push buttons are configured for future use. SwTimer_Init function is
called for initializing the software timer. More information about the software timer can be found on the application note
“AN4327 Pulse Oximeter Fundamentals and Design”: Appendix A Software Timer.
The last function called is vfnSpO2_AFE_Init. This function initializes the required peripherals (OpAmps, TRIAMPs, ADCs
and timers) required by the MED-SPO2 board.
3.3 Application Execution
Once the peripherals have been configured, a connection between the host PC and the device is established. Host PC
recognizes the device as a PHD but it is not fully functional yet. A communication protocol between the host PC and the
device is required in order to exchange the information in a standardized and reliable manner.
Several communication protocols exist, including some vendor specific protocols. Nevertheless, engineering bets on
standardized protocols that ensure same interoperability between medical devices.
Continua Health Alliance® is an organization that promotes the enhanced interoperability among medical devices. The
implementation of this demo is based on the Continua® standard for health data communication between host PC and device
which uses the standard ISO/IEEE 11073-20601 “Personal health device communication: Optimized exchange protocol” as a
base.
A brief explanation of the 11073-20601 communication protocol is shown below. For a complete explanation of the
communication protocol refer to the ISO/IEEE 11073-20601 standard.
3.3.1 ISO/IEEE 11073-20601 communication process
The standard 11073-20601 defines the communication protocol between medical devices or “Agents” and hosts or
“Managers”.
Pulse Oximeter Using USB PHDC, Rev. 0, 03/2012
Freescale Semiconductor, Inc. 3
Pulse Oximeter Implementation
The Agent can be defined as a set of objects called MDS (Medical Device System). Each MDS describes a behavior of the
agent (e.g. pulse oximeter or blood pressure monitor). Each Agent can contain one or more of these MDS objects.
In the same manner, each MDS object contains sub-objects that define its behavior (e.g. measurements to report). All this
information must be reported to the Manager so it can control the behavior of the Agent. Nevertheless only one MDS object
must be reported at a time (e.g. an Agent cannot be a pulse oximeter and a blood pressure monitor at the same time).
Following diagram represents an Agent capable of being a pulse oximeter and a blood pressure monitor).
Figure 2. Agent representation
In the case of this demo, the Agent contains only one MDS object corresponding to the pulse oximeter application. More
detailed information about the Agent representation can be found on the ISO/IEEE 11073-20601:2010 document, in the
chapter 6, Personal health device DIM.
IEEE standard defines a state machine for the Agents and other state machine for the Managers. Since our demo application
is a device, we will only explain the Agent’s state machine. Following diagram is a simplified representation of the state
machine shown in the Chapter 8, Figure 10 of the ISO/IEEE 11073-20601:2010 standard.
Pulse Oximeter Using USB PHDC, Rev. 0, 03/2012
4 Freescale Semiconductor, Inc.
Pulse Oximeter Implementation
Figure 3. Agent's state machine
At the beginning, the Agent is disconnected from the Manager. Agent must be connected to the manager in order to establish
a communication. When the connection has been established (in our case when the USB device has been enumerated as
PHDC device) the Agent passes to be in a connected state.
Once connected, the Agent is initially in an “Unassociated” state. The Agent must send an “Association Request” to start
communications. Association request is sent as an APDU (application protocol data unit), a data packet containing the
required information to start the association and it must correspond to the MDS object to associate. The association request
APDU must look like the following.
/* association request to send */
uint_8 USB_CONST PHD_OXI_ASSOC_REQ[ASSOC_REQ_SIZE] = {
0xE2, 0x00, /* APDU CHOICE Type (AarqApdu) */
0x00, 0x32, /* CHOICE.length = 50 */
0x80, 0x00, 0x00, 0x00, /* assoc-version */
0x00, 0x01, 0x00, 0x2A, /* data-proto-list.count=1 | length=42*/
0x50, 0x79, /* data-proto-id = 20601 */
0x00, 0x26, /* data-proto-info length = 38 */
0x80, 0x00, 0x00, 0x00, /* protocolVersion */
0x80, 0x00, /* encoding rules = MDER or PER */
0x80, 0x00, 0x00, 0x00, /* nomenclatureVersion */
0x00, 0x00, 0x00, 0x00, /* functionalUnits |
no test association capabilities */
0x00, 0x80, 0x00, 0x00, /* systemType = sys-type-agent */
0x00, 0x08, /* system-id length = 8 and value
, (manufacturer- and device- specific) */
0x4C, 0x4E, 0x49, 0x41, 0x47, 0x45, 0x4E, 0x54,
0x40, 0x00, /* dev-config-id | extended configuration*/
0x00, 0x01, /* data-req-mode-flags 0x00, 0x01*/
0x01, 0x00, /* data-req-init-agent-count,
Pulse Oximeter Using USB PHDC, Rev. 0, 03/2012
Freescale Semiconductor, Inc. 5
Pulse Oximeter Implementation
data-req-init-manager-count */
0x00, 0x00, 0x00, 0x00 /* Atribute list */
};
When the Agent sends the association request, it goes to the “Associating” state waiting for response from the Manager. The
Manager will process the association request and send the Association Response according with the APDU received. If the
APDU corresponds to an already known MDS, the Manager will send an “Accepted” association response indicating that the
configuration is already known, and then the Agent must transition to the Operating state. If the association request is
accepted but the Manager does not recognize the MDS, it will send back an “accepted-unknown-config” association response
asking to the Agent for the MDS configuration. If the association request is rejected, the Agent must transition to the
Unassociated state and try again. A Manager’s association response looks like the following.
0xE3 0x00 APDU CHOICE Type (AareApdu)
0x00 0x2C CHOICE.length = 44
0x00 0x03 result = accepted-unknown-config
0x50 0x79 data-proto-id = 20601
0x00 0x26 data-proto-info length = 38
0x80 0x00 0x00 0x00 protocolVersion
0x80 0x00 encoding rules = MDER
0x80 0x00 0x00 0x00 nomenclatureVersion
0x00 0x00 0x00 0x00 functionalUnits
0x80 0x00 0x00 0x00 systemType = sys-type-manager
0x00 0x08 system-id length = 8 and value
0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88
0x00 0x00 manager’s response to config-id is always 0
0x00 0x00 0x00 0x00 manager’s response to data-req-mode-capab is always 0
0x00 0x00 0x00 0x00 optionList.count = 0 | optionList.length = 0
Either if the Agent receives an accepted or accepted-unknown-config association response, the Agent must transition to the
“Associated” state. In this case, the Manager accepted the association request, but it did not recognize the MDS returning an
accepted-unknown-config association response. As a result of this, Agent must send a Configuration Report like the
following.
/* configuration event report */
uint_8 USB_CONST PHD_OXI_CNFG_EVT_RPT[PHD_OXI_CNFG_EVT_RPT_SIZE] = {
0xE7, 0x00, /* APDU CHOICE Type (PrstApdu) */
0x00, 0x70, /* CHOICE.length = 112 */
0x00, 0x6E, /* OCTET STRING.length = 110 */
0x00, 0x02, /* invoke-id (differentiates this from other
outstanding messages) */
0x01, 0x01, /* CHOICE(Remote Operation Invoke | Confirmed Event
Report) */
0x00, 0x68, /* CHOICE.length = 104 */
0x00, 0x00, /* obj-handle = 0 (MDS object) */
0xFF, 0xFF, 0xFF, 0xFF, /* event-time = 0xFFFFFFFF */
0x0D, 0x1C, /* event-type = MDC_NOTI_CONFIG */
0x00, 0x5E, /* event-info.length = 94 (start of ConfigReport) */
0x40, 0x00, /* config-report-id */
0x00, 0x02, /* config-obj-list.count = 2 Measurement objects will
be “announced” */
0x00, 0x58, /* config-obj-list.length = 88 */
0x00, 0x06, /* obj-class = MDC_MOC_VMO_METRIC_NU */
0x00, 0x01, /* obj-handle = 1 (.. 1st Measurement is SpO2) */
0x00, 0x04, /* attributes.count = 4 */
0x00, 0x24, /* attributes.length = 36 */
0x09, 0x2F, /* attribute-id = MDC_ATTR_ID_TYPE */
0x00, 0x04, /* attribute-value.length = 4 */
0x00, 0x02, 0x4B, 0xB8, /* MDC_PART_SCADA | MDC_PULS_OXIM_SAT_O2 */
0x0A, 0x46, /* attribute-id = MDC_ATTR_METRIC_SPEC_SMALL */
0x00, 0x02, /* attribute-value.length = 2 */
0x40, 0xC0, /* avail-stored-data, acc-manager-init, acc-agentinit, measured */
0x09, 0x96, /* attribute-id = MDC_ATTR_UNIT_CODE */
0x00, 0x02, /* attribute-value.length = 2 */
0x02, 0x20, /* MDC_DIM_PERCENT */
0x0A, 0x55, /* attribute-id = MDC_ATTR_ATTRIBUTE_VAL_MAP */
0x00, 0x0C, /* attribute-value.length = 12 */
Pulse Oximeter Using USB PHDC, Rev. 0, 03/2012
6 Freescale Semiconductor, Inc.
Loading...