Document Sample
final_cdr Powered By Docstoc
					Critical Design Report for the
Universal Internet Interface


Eric Pettersen
Etana Elegbe
Jared Gillis
Shamit Patel
Shari McNamara

February 16 2005
Version 1
                                                                                      Page 1 of 52


1         Introduction
2         Recognition and Evaluation of Need
    2.1         Comparison with Previous Work
    2.2         Contrast with Previous Work
    2.3         Split Team Design
3         Concept Development
    3.1         UII Communications Protocol
    3.2         Zigbee for all Wireless Communication
    3.3         ECG/EMG Peripheral
    3.4         PDA User Interface
    3.5         USB for AHMD
    3.6         Internet Connectivity
          3.6.1        Ethernet Connection to Internet
4         Feasibility Assessment
    4.1         PDA Electrical Interface
    4.2         Translator
    4.3         Zigbee
          4.3.1        Bluetooth vs. Zigbee
    4.4         ECG/EMG Front-end
5         Functional Specifications
    5.1         Wireless Communication Link
          5.1.1        Zigbee Board User Interface
          5.1.2        Verification of Transmission
    5.2         Fifth Element
    5.3         Overall Functionality
          5.3.1        Physician’s Perspective
    5.4         AHMD Interface
    5.5         Failure Conditions and Modes
          5.5.1        Scenarios of User Mistakes
          5.5.2        Ways Zigbee can Fail
          5.5.3        Ways Translators can Fail
          5.5.4        Ways UII can Fail
          5.5.5        Ways ECG can Fail
6         Regulatory Requirments
    6.1         Food and Drug Administration
          6.1.1        Determining if the Device Meets the Definition of a Medical Device
          6.1.2        Pre-market Review of Telemedicine Devices
                     Device Determination
                     Software Policy Development
                     The Pre-market Notification [510(k)]
                     Selecting the Appropriate Marketing Application
          6.1.3        Other Requirements
                     Pre-market Requirements: Labeling, Registration, Listing
                                                                                  Page 2 of 52

                   Post-market Requirements: Quality System, Medical Device
  6.2        Federal Communications Commission
      6.2.1         Zigbee
      6.2.2         Modems
      6.2.3         Ethernet
  6.3        IEEE
      6.3.1         Medical Device Communications Standard
      6.3.2         Zigbee
  6.4        Patents
      6.4.1         Integrated Medical Information Management and Medical Device Control
                    System and Method (US Patent Application #20040215490)
      6.4.2         Physician information System and Software with Automated Data Capture
                    Feature (US Patent Application #20040220830)
      6.4.3         Pharmaceutical Patient Information System (US Patent Application
      6.4.4         Distributed System and Method for Managing Communication Among
                    Healthcare Provider, Patients and Third Party (US Patent Application
7     Synthesis of Design
  7.1        Hardware
      7.1.1         UII
      7.1.2         Translator
                 Freescale Development Board as Translator
                 Freescale Development Board
      7.1.3         5th Element
       The ECG-EMG signal properties
       The ECG-EMG design
        Basic components of a typical ECG and EMG
        The Power Supply and Isolation Circuit
  7.2        Software
      7.2.1         UII Communications Protocol
      7.2.2         UII Architecture
                 User Interface Architecture
                 Medical Database Architecture
                 AHMD Implementation
                 Web Server Implementation
      7.2.3         Translator Architecture
8          Software Architecture
     8.1          Programming the HC(S)08
     8.2          The Medical Instrument Data Output
     8.3          Software Organization
9          Bill of Materials
10         Citations
                                                                                               Page 3 of 52


The Universal Internet Interface (UII) is a smart communications hub that serves as a medium for bi-
directional data flow between various physical health monitoring devices at a patient‟s home and a
physician at a remote location over the Internet. The advent of home medical monitoring devices has
given the patient the freedom to stay at home and perform a number of medical tests; however, the
utility of these home medical devices has been curtained by the lack of simultaneous professional
analysis of the gathered data. While improving technology has provided fascinating facilities to the
patient at home and to the physician at the hospital, there exists no link connecting the patient and the
physician. The UII is being developed to form the physical connection between the physician and the
patient and their medical technologies. The UII and its included software shall have the ability to
communicate with various commercially available medical devices through a wireless connection, store
retrieved data in a structured database, and act as a communications interface between the physician and
the user. [1]

The goals of the UII are to improve the following situations.

   1. While the patient may be able to identify extreme deviations of medical results from normal
      readings, they still have to physically convey these readings to a physician for medical analysis.
      Furthermore subtle changes in readings, which might be critical to the patient‟s health, may be
      overlooked if the patient is the only person interpreting the data.
   2. The readings from a monitoring device could be critical in an early diagnosis; however, the
      uncertainty in how well and when these results reach the physician diminishes the usefulness of
      many home medical devices.
   3. The burden of maintaining and storing an accurate database of the medical device readings to
      physically convey to the physician at a later stage is neither easy nor always practical. This
      results in a loss of critical data that, in a medical case, could be crucial to the patient‟s health.
   4. Until now, the physician has had no direct benefit in the existence of home medical monitoring
      devices. With access to a home database, the physician can make faster and more informed
      medical analyses and decisions.

The UII will magnify the utility of the home medical monitoring devices by providing the physician
with the access to a medical database of the user, as well as add a feedback path for the user to get an
input from the doctor based on his health monitoring device database. The end result shall be to provide
the physician with the comfort in the knowledge of his patient‟s current health, and provide the user the
satisfaction that his physician has a constant update on his health status. [1]
                                                                                               Page 4 of 52

2.1 Comparison with Previous Work
The UII has been in development for the past two years as a part of two RIT Electrical Engineering
Senior Design projects. When the project was continued this year the UII had the functionality to:
         1. Maintain and update a web server to store patent data and interface with the physician.
         2. Interact with the user through a PDA via IrDA.
         3. Talk to a medical device translator via Bluetooth. The translator will interpret data from
             various medical devices and send it to the UII in a form it can understand.
With this functionality the UII in this form not only shows the feasibility of the concept but also shows
that it is practical to achieve this concept. However the goal of the Senior Design Project this year has
changed. The goals for this year‟s project are to improve upon this design to make a marketable
affordable product. Another goal is to show that the medical devices in the future will not need any
external hardware to be UII compliant but can follow our reference design to create a UII complainant

2.2 Contrast with Previous Work
This year, the initial concept has been enhanced. Using cutting edge technology the UII will become
more robust, consistent and user friendly. The goal is to improve its practical performance and usability.
The only way for the user to interact with the UII is through a PDA. The PDA is touch screen and very
user friendly; the architecture for this interface will cross over into the UII‟s final design. However, the
interface between the UII and the PDA is via IrDA. This will require the user to be pointing the PDA at
the UII‟s IrDA receiver. This reduces the user-friendly aspect of the UII. Using a new wireless
technology Zigbee the user can interact with UII from any room in the house. This technology will also
replace Bluetooth as the means of transmitting medical information from the medical devices to the UII.

An Electrocardiograph/Electro-myograph front-end with an RS-232 output will be built in addition to
the current medical design. The ECG/EMG will be connected to a free-scale board, which will
communicate with the UII via ZIGBEE. The ECG/EMG-ZIGBEE configuration will be called the Fifth

2.3 Split Team Design
In order to meet the specifying needs of this project three groups will be used. The three parts to the
project are: web server and interface, wireless communications network, and a bio-potential amplifier
design. These needs will be completed over a period of three quarters. The first quarter was the over all
design and planning stage. Second quarter was the implementation of a wireless communications link
and the fabrication of the bio-potential amplifier. The final quarter will consists of the complete medical
monitoring device implementation with the UII and a web server design.

                                                                                               Page 5 of 52

3.1 UII Communications Protocol
To make the UII a feasible device, it has to be able to connect to as many medical devices as possible.
As an initial concept implementation, the UII will be shown to interact with four basic medical devices.
However an important part of the project will be to create and define a communications protocol, which
will enable manufacturers to create their medical devices with an extension, which will support this
protocol implementation. This protocol should be robust enough to handle the various possible data
transfers yet at the same time well defined enough so that it can be practically used by the original
medical manufactures or third party integration module developers. The UII communications protocol
will try to bring a cost effective, easily implement-able standard into the medical device industry for
talking to the UII. [1]

3.2 Zigbee for all Wireless Communication
The main role of the UII is to form a reliable yet convenient mode of data transfer. The most standard
way of connecting two devices is through a cable connection. However in a home environment, having
cable connections running between medical devices restricts mobility and makes having the UII a
liability. For this reason it was decided to use a wireless communication method to talk between the
medical devices and the UII. [1] The latest and greatest standard for short to medium wireless
communication is Zigbee.

3.3 The ECG/EMG Peripheral
The ECG is a bio-potential differential device that will be used in monitoring the electrical activity of
the patient‟s heart as well as collecting related data that can be analyzed by a physician. Signal
collection is done through the use of surface (non-invasive) electrodes that are placed at strategic points
on the user‟s body in order to adequately capture the heart‟s sequence of activities during ventricular
activation. In addition, the design is such that the user can also collect electro-myograms (recordings of
other muscle activity) through a switch in the circuit.

3.4 PDA User Interface
The UII in its current form will have no externally configurable options. The only way for the user to
communicate with the UII will be through a PDA, which will use Zigbee to communicate. Since there
are no PDA‟s that are Zigbee compatible a Zigbee transceiver will have to be attached to the PDA
through the USB port on the PDA. The UII will support multiple users however, there will only be one
user allowed on a PDA. For households with more than one user they can simply purchase another

3.5 USB for AHMD
The original concept for the UII rose from the need to have a device capable of connecting the AHMD
(Automated Home Medication Dispenser) to the Internet. The AHMD will be connected to the UII
through a USB connection. For its functionality all the AHMD needs is a file from the physician‟s
computer, this could have been implemented with Zigbee, but it was decided to have the AHMD
connect to the UII through the UII. This would allow the UII to show its compatibility with a USB
                                                                                           Page 6 of 52

enabled device. The USB port on the UII‟s motherboard (the CerfCube) will be used for this purpose.
This implementation will require no further hardware addition. 1

3.6 Internet Connectivity

3.6.1 Ethernet Connection to Internet
The Internet is the backbone of the link the UII creates between the user and the physician. To
implement Internet connectivity of the UII, the UII will support Ethernet connections to LANs and other
network topologies. The Ethernet port on the CerfCube will be used to support this feature, and no
further hardware additions are required. The Ethernet connectivity will allow home users to use their
cable and DSL connections to the Internet enable the UII. 1


4.1 PDA Electrical Interface
The way in which users will communicate with the UII is by using a PDA. The UII team thought about
several different issues that would make the UII user-friendly as well as reliable. Further, two main
communication protocols were discussed; whether the PDA should communicate with the UII over
Zigbee (sharing a communication channel with the medical devices), or IrDA. Both communication
protocols are secure and have low power consumption. Zigbee was chosen as the best way to
communicate with the UII. Most importantly with IrDA you have to be pointing the PDA at the IrDA
receiver on the UII in order to establish a link. Zigbee only has to be in range of the UII (which is
100meters) in order to establish a link. Even though there are no Zigbee enabled PDAs currently in the
short future there will be. A link through the USB port on a PDA will work as a reference design to
show that a Zigbee-enabled PDA will work with the UII.

4.2 Translator
The goal of the translator is to have a programmable microprocessor capable of transmitting Zigbee data
and communicating with the UII. To meet these goals, the design of a translator had to have a
microprocessor to interface between a medical device, via RS-232, and the UII via Zigbee. At todays
present time the only Zigbee devices that exist are development boards. These development boards have
a Zigbee transceiver, a microprocessor, memory, an RS-232 port, and some LEDs. There were few
companies that were selling each of these development boards, Crossbow, Chipcon, and Freescale.
Each different company makes a different version of the Zigbee transceiver and has slightly different

                        Table 1: Decision Grid for Zigbee Development Board
                                            Weight   Freescale   Chipcon   X-Bow
                      RS-232 port             4          10         10        10
                      Microprocessor          5          9           8        8
                      Low power               4          8           8        8
                      Memory                  3          6           8        9
                      Ease of programming     4          9           8        7
                      Cost                    5          9           6        2
                      Total                             216        198       177
                                                                                            Page 7 of 52

Based on the results of the decision grid above, the team decided to go with the Freescale Development
board. The Freescale board was significantly cheaper then the other development boards and comes
with all the programming and debugging software necessary. Freescale has also been very helpful in
any questions that the team needed answered. The only drawback is the lack of available memory on
the Freescale board, compared to the other two development boards. However, this is not an issue since
the Freescale board has sufficient memory for the teams needs.

4.3 Zigbee
Zigbee is a reliable, cost-effective, low power wireless communication device based off of the IEEE
802.15.4 standard. Zigbee operates in the worldwide 2.4 GHz band. Zigbee‟s low power consumption
comes from its ability to be in a deep-sleep mode when it is not actively being used and will only wake
up for a fraction of a second to confirm its presence in the network. Zigbee can be set up into a beacon
mode and a non-beacon mode. The beacon mode of Zigbee is used to synchronize the network.
Intervals can be set anywhere from 15ms to 4 minutes. Non-beacon mode in which each device is
autonomous and can initiate a conversation at will. However when a device initiates a conversation it
cannot interfere with other devices. Zigbee security comes from the IEEE 802.15.4 standard, which has
4 security services. Each device will maintain a list of trusted devices within the network. Zigbee has a
128-bit advanced data encryption standard. The last standard will reject data frames that have been
replayed. The Zigbee stack only requires 4Kb of memory for minimum capabilities and for full function
only 32 KB of memory.1

4.3.1 Bluetooth vs. Zigbee
Bluetooth is a wireless standard that has been around for many years, so why replace this standard?

                                                                                               Page 8 of 52

                                  Table 2: Standard Wireless Comparison Chart


A quick comparison between Zigbee and Bluetooth can be seen in Table 1. In terms of system
resources, battery life, network size, bandwidth and transmission range Zigbee is better than Bluetooth
in every category except for bandwidth. The UII will be installed in the home and user should not be
restricted as to where the UII can be installed. The cheapest, most popular, and readily available form of
Bluetooth has a range of 10 meters. This limited range will restrict the user; it will require them to
install the UII as close as possible to all the medical devices they wish to use. Zigbee will eliminate this
restriction to the user because it has a range of 100m. In today‟s modern technological world there are
many home medical devices available. Bluetooth would limit the number of medical devices to be used
with the UII. The one category in which Bluetooth is better than Zigbee is in bandwidth. Since only
small amounts of data are being transferred a large bandwidth is not necessary. A smaller system
resource requirement and a longer battery life will be a significant improvement over Bluetooth.
Therefore Zigbee is the logical choice as a form of wireless communication standard for better
performance and enhanced user features.

4.4 ECG/EMG Front-end
ECG/EMG devices cost anywhere from a couple of hundred dollars to thousands of dollars depending
on the functional capabilities of the device. The fifth element (ECG-EMG front-end) is an efficient
device that incorporates both an ECG and EMG at a relatively low cost. The fifth element will be used
in collecting important data such as the electrical activity of the heart and other muscles in the body,
thereby providing the physician with a greater range of information for the analysis of the patient‟s
                                                                                              Page 9 of 52

The mission of the Universal Internet Interface (UII) is to provide physicians access to users‟ recent
medical information without the need for regular in-office checkups. Given the advent of home medical
monitoring devices, patients now have the freedom to stay at home and still provide doctors with recent
medical information. The UII provides the patient with one extra freedom: the elimination of the need to
note the medical information themselves. The UII automatically maintains a medical record for the
patient and provides access for the doctor to this record.

The UII is a medical data transfer device with temporary storage capabilities for that data. The UII is a
central hub for the identification and interfacing of medical monitoring devices and an Internet
communications point through which authorized users may access the data. The UII is able to
communicate with all devices that communicate using the “UII Communications Protocol” (a wireless
data transfer protocol). For devices that do not support this protocol, the UII provides “translators” for
specific medical instruments. [1]

5.1 Wireless Communications Link
The wireless communications link will be the backbone of the UII. This will be how medical
information is transferred from a medical device to the UII. This concept will be realized by connecting
a medical device, a digital scale, to the Zigbee wireless development board. The Zigbee board
connected to the scale will send the scale‟s medical information to another host Zigbee board connected
to a PC. The user interface for this design will be through direct interaction with the Zigbee board.

5.1.1 Zigbee Board User Interface
The user will be limited in how they can interface with the Zigbee board. Restricted user intercalation
will keep the user from accidentally creating a malfunction with the hardware. A limited interface is
also a benefit so the user will not be confused by too many options.

As long as the Zigbee wireless board is on and functioning, LED 4 will be light. The user will have to
use the scale by turning it on with a button. The user must then wait until the scale has zeroed out and
then step on the scale and stand still until the weight measurement stabilizes. This will cause LED 1 on
the wireless board to light up.

LED 1 will signify to the user that a valid data measurement has been taken. If the user is satisfied with
the measurement taken they will press button 1 on the Zigbee development board. This step is added
for a future design addition of an LCD on the Zigbee board which will display the weight measurement
that has been taken. The data will then be stored in memory upon the user pressing button 1.

In order to send the data the user will then press button 2 on the Zigbee development board. The data
will be sent out to the host Zigbee board, connected to the PC. Once the host has received all the data it
will send back an acknowledgement. Upon receiving this acknowledgement LED 2 will then light up.

5.1.2 Verification of Transmission
                                                                                               Page 10 of 52

The Freescale Zigbee Development board will be connected to a PC and act as the host receiver. This
board will always be on and waiting for a Zigbee wireless transmission. Once a transmission has been
received the board will then output the data via its RS-232 port in a standard ASCII format. This data
can be displayed in a standard serial interface program such as Hyper Terminal or ZOC term.

5.2 Fifth Element
The Fifth Element is a bio-potential differential device that will be used in monitoring the electrical
activity of the user‟s heart and collecting related data that can be analyzed by a physician. Data
collection is done through the use of non-invasive (surface) electrodes that are placed at strategic points
on the user‟s body in order to capture the heart‟s sequence of activities during atrial and ventricular
activation. In addition, the design is such that the user can also collect electro-myograms (recordings of
other muscle activity) by flipping a switch in the circuit.

The Bio-amplifier consists of a two channel front-end device operating in a frequency range from 0.1-
100Hz (ECG) and 20-200Hz (EMG). Unlike the other medical devices, the output is an analog signal
and it needs to be sampled by the A/D converter on the Freescale Zigbee board before the data is
formatted and sent wirelessly to the Freescale board connected to the PC.

                               Fig. 1: General Block diagram of Bio-potential Amplifier.

5.3 Overall Functionality
For any medical device that will communicate with the UII a custom designed software program for the
Zigbee board will be created. Therefore the software used to establish the link needs to be designed in a
fashion that will allow for simple portability to different devices. There will be no change in the user
interface between different medical devices.

The UII will be the hub of the system. The Zigbee board connected to the UII must be able to
differentiate between multiple medical device transmissions. Medical transmissions will be stored on
the UII in a specified format. The format in which the information will be stored will be stored as
shown in Figure 2.

Device                      Date                      Time                          Data
                                    Figure 2: UII Data Storage Format

5.3.1 Physician’s Perspective
The UII exists on the Internet as a unique IP. The doctor can connect to the UII directly through that IP
to be served with the medical databases stored on the UII.

The first level of this interaction is the doctor authorization screen. Since the UII is available to anyone
who knows its IP (which is, in fact, difficult to determine without aid), the UII must insure that it does
                                                                                              Page 11 of 52

not provide discreet medical information to anyone who is not authorized. The authorization shall ask
for a predetermined user name and password.

When the doctor has successfully been authorized, the patient (user) profile selection screen is
presented. Each available user is indicated as a link with their name as the link. Each link directs the
doctor to the user‟s home page.

Each homepage contains the users name and some statistics on their activity. Such statistics could
include the date and time of the first and last measurements that the UII has stored. The homepage
contains a link to an Extensible Markup Language (XML) document that contains all the acquired data
for that user.

The XML is a structured representation of the database. It contains a link to a style sheet that is not
hosted by the UII that will format this XML data into an easily comprehensible table. If the doctor
downloads the XML file, then its data can be integrated with previous records.

If the doctor is satisfied with the data and sees that the UII cannot store much more, then they have the
option to delete a portion of or all of the database information. [1]

5.4 AHMD Interface
The UII, in addition to all its other responsibilities, provides the connection between the Automated
Home Medication Dispenser (AHMD) and the physician. [1]

5.5 Failure Conditions and Modes
To make the UII reliable and user-friendly, the team discussed several issues that could prevent the UII
from operating properly. A summary of the discussion is listed below. [1]

5.5.1 Scenarios of User Mistakes
A complete picture of the causes of failure of the UII begins with the user. A design goal of the UII was
to make it user-friendly and consistent; if the user makes a mistake is therefore a failure of the design.
To help prevent such circumstances, the following list of possible situations was developed:

   1. Turn off UII during measurement: While taking a measurement, the UII is turned off. The UII
      will have to be programmed in such a way, as its state is stored in non-volatile memory
      whenever it is hanged. This will insure that when it is re-activated, it will be able to recover and
      operate as if nothing extraneous occurred.
   2. Turn off the Zigbee Board during measurement: If the Zigbee board is turned off any data
      stored will be lost. No wireless transmission can occur with the Zigbee board off. The only way
      to restore a connection and transmit data would be to turn on the board and retake the
   3. Press the reset button during measurement: The zigbee board has a reset button if pressed all
      data stored on the Zigbee board will be lost. To restore data the user will have to retake the
   4. Physician purges UII and looses data: The doctor fails to record the reading from the UII
      before purging them. Protection from this could take the form of a “Recycle Bin” or “Trash”
                                                                                              Page 12 of 52

        container into which a database is placed when deleted. The metaphor already exists for most
        computer users and will therefore be readily apprehended. [1]

5.5.2 Ways Zigbee can Fail
Below are anticipated scenarios in which Zigbee communication fails.

   1.   Strong Interference other than Zigbee. The radio signals do not communicate as required.
   2.   Out of range: The device is too far for the Zigbee range of the UII.
   3.   Jammed signal: The Signal gets jammed with data.
   4.   Encryption key mix-up: The security key of the devices is interchanged.
   5.   Broken antenna: Hardware failure.
   6.   Lack of regulated power: The transmitter does not get enough power to function.
   7.   De-synchronization due to poor protocol implementation: Bad software. [1]

5.5.3 Ways Zigbee board can Fail
Below are anticipated scenarios in which the translators can fail.

   1.   Power shortage
   2.   Power surge
   3.   Breakdown in pin connection
   4.   Doesn‟t show LED signals
   5.   Doesn‟t initialize correctly
   6.   Cannot handle two UIIs
   7.   Power loss in middle of transmission[1]

5.5.4 Ways UII can Fail
Below are anticipated scenarios in which the UII itself can fail.

   1. Out of RAM: The software requirements of the RAM are too much, bugs.
   2. Out of flash memory: too much user data being stored.
   3. Zigbee card not recognized: Incapability with Zigbee board.
   4. Serial port not recognized
   5. Battery failure: UII‟s internal battery fails.
   6. DOS attack on web server
   7. Cannot find doctor sever: Can‟t connect to server.
   8. Cannot get through router address translation
   9. Multiple transmissions (handling/storage)
   10. Web server blocks transmission from doctor[1]

5.5.5 Ways the ECG/EMG front-end can fail
Listed below are ways that the ECG front-end can possibly fail to function as.

   1.   Battery Failure: 9V batteries provide the power supply of the ECG front-end
   2.   Saturation or Distortion of Signal data due to high offset voltages at the electrodes.
   3.   Interference due to ground loops (if patient is attached to more than one electrical device)
   4.   Broken electrode wires which results in inaccurate recordings
                                                                                             Page 13 of 52


6.1 Food and Drug Administration
“FDA‟s Center for Devices and Radiological Health (CDRH) is responsible for regulating firms who
manufacture, repackage, re-label, and/or import medical devices sold in the United States”3. For the UII
to be a commercially viable it has to meet the regulatory specifications of the CDRH. The basic
regulatory requirements that manufacturers of medical devices distributed in the U.S. must comply with

1. Pre-market Notification 510(k), unless exempt, or Pre-market Approval (PMA),
2. Establishment registration on form FDA-2891,
3. Medical Device listing on form FDA-2892,
4. Quality System (QS) regulation,
5. Labeling requirements, and
6. Medical Device Reporting (MDR)

Going into the details of the regulatory requirements needed a basic understanding of the FDA‟s role in
the UII development. This was done based on the guidelines in “Getting to Market with a Medical
Device”4 and “Telemedicine Related Activities”5 [1]

6.1.1 Determining if the Device Meets the Definition of a Medical Device
A medical device is defined as: "an instrument, apparatus, implement, machine, contrivance, implant, in
vitro reagent, or other similar or related article, including a component part, or accessory which is:

         Recognized in the official National Formulary, or the United States Pharmacopoeia, or any
          supplement to them,
         Intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation,
          treatment, or prevention of disease, in man or other animals, or
         Intended to affect the structure or any function of the body of man or other animals, and which
          does not achieve any of it's primary intended purposes through chemical action within or on the
          body of man or other animals and which is not dependent upon being metabolized for the
          achievement of any of its primary intended purposes."6
Since the UII is intended to be marketed as a Home Medical Device with the goal to supplement
diagnosis and treatment but at the same time not directly perform these activities there seemed to be
some ambiguity if it would fall into the category of a medical device. This was however clarified by the
following argument “It should also be noted that the classifications are not considered to apply to
general purpose products, such as general purpose software, digital communications devices, and
storage devices that are not intended for medical use. The Center recognizes that such products may be
used in a medical setting, and ordinarily they are not considered to be medical devices. However, when

                                                                                             Page 14 of 52

such general purpose products are labeled for medical use, or included as components of systems labeled
for medical use, they are considered to be within the scope of the proposed classifications”7 This meant
that “IF” the UII was marketed solely as a Universal Internet Interface, and not labeled as a medical
device or included as component of a medical device, then it would be exempt from FDA regulations.
Since the goal of the UII is to define and propose the incorporation of translators and a communication
standard in home medical device monitoring devices our current definition of the UII would definitely
come under the classification of a medical device.

The definition for “Telemedicine” under CDRH is “The delivery and provision of health care and
consultative services to individual patients and the transmission of information related to care, over
distance, using telecommunications technologies, and, incorporating the following activities.

1. Direct clinical, preventive, diagnostic, and therapeutic services and treatment, including procedures
where a provider may be present with the patient, and clinical training and consultative clinical Grand
Rounds, if used for decision-making regarding the clinical care of a specific patient.
2. Consultative and follow-up services.
3. Remote monitoring, including the remote reading and interpretation of results of patient's procedures.
4. Rehabilitative services.
5. Patient education provided in context of delivering health care to individuals.”8
The UII fits all five points with a conformity that makes it seem like the UII was designed to handle
“telemedicine” in its entirety. [1]

6.1.2 Pre-market Review of Telemedicine Devices.
The FDA broadly classifies all devices into three classes, which are class I (general controls), class II
(special controls) and class III (pre-market approval (PMA)). If a device is not in commercial
distribution prior to May 28th 1976, and not found by the FDA to be substantially equivalent to a legally
marketed device, then it requires a submission of a PMA. However it was noted that certain class 1
devices are exempt from various degrees of e.g. exemption from GMP (Good Manufacturing Practice)
review and /or 510(k) submission. For Class III devices and non-exempt Class I and Class II devices a
510(k) will be required for marketing.

Another point noted was that when a parent device wants to use the UII or incorporate the UII‟s
translator it will have to get an approval from the Office of Device Evaluation (ODE) division with
which the parent device is classified under. Which, means if a medical device measuring physiological
parameters as body temperature decides to use the UII‟s translator it would have to be reviewed in the
Division of Dental, Infection Control and General Hospital Devices (DDIGD) once again because now it
would further classify as a telemedicine device. [1] Device Determination
Products which are components of or accessories to a medical device are typically regulated in the same
way as the "parent" device, e.g. if the parent device is subject to GMPs and pre-market notification, the
normal presumption is for an accessory to be subject to the same requirements, even if marketed

                                                                                              Page 15 of 52

separately. Furthermore, the manufacturer of a device is responsible for assuring that the full device,
including all components, complies with the regulations. The medical device manufacturer is
responsible for the safety and effectiveness of all components, including any general-purpose articles
incorporated within the device. This again proves that having the UII certified, as a FDA approved
medical device would credibly ease the process of allowing medical monitoring device manufactures to
incorporate the UII. Other points of note under Device determination are:

      1. An individual physician ("licensed practitioner") who develops a medical device genuinely for
         use in his own personal practice is exempt from the registration and listing and 510(k) provisions
         of the Act.
      2. Multiple site use of a device (even within a single company) constitutes commercial distribution.
      3. Finished product and products under development have different regulatory rules.
      4. Source code is not considered regulated, where as commercially distributed or executable code
         related with medical devices is considered regulated. [1] Software Policy Development
Because software is integral to the operation of the UII, it was looked into. At the present time the FDA
website only lists its attempts to form a clear regulatory standard for software. Since the UII has a great
dependency on software this will have to be looked into detail at a later stage. Considering all the
functions of the UII and an exhaustive period of research looking into similar products (using keywords
home, modem, phone, database, wireless etc) and remembering that the UII would also be classified
under the same class as the devices it attaches to the UII will definitely be a class II device which will
require both GMP as well as 510(k) (or PMA) submission. [1] The Pre-market Notification [510(k)]
The FDA has the following definition for the 510(k):

“Each person who wants to market Class I, II and some III devices intended for human use in the U.S.
must submit a 510(k) to FDA at least 90 days before marketing unless the device is exempt from 510(k)
requirements. There is no 510(k) form but instead a format for the submission described in 21 CFR 807
and in the pages that follow.”

A 510(k) is a pre-marketing submission made to the FDA to demonstrate that the device to be marketed
is as safe and effective, that is, substantially equivalent (SE), to a legally marketed device that is not
subject to pre-market approval (PMA). Applicants must compare their 510(k) device to one or more
similar devices currently on the U.S. market and make and support their substantial equivalency claims.
A legally marketed device is a device that was legally marketed prior to May 28, 1976 (pre-amendments
device), or a device which has been reclassified from Class III to Class II or I, a device which has been
found to be substantially equivalent to such a device through the 510(k) process, or one established
through Evaluation of Automatic Class III Definition”9. Unlike PMA, which requires demonstration of
reasonable safety and effectiveness, 510(k) requires demonstration of substantial equivalence. SE means
that the new device is as safe and effective as the predicate device(s). A device is SE if, in comparison to
a predicate device if it:

                                                                                              Page 16 of 52

• has the same intended use as the predicate device; and
• has the same technological characteristics as the predicate device; or
• has different technological characteristics, that do not raise new questions of safety and effectiveness,
and the sponsor demonstrates that the device is as safe and effective as the legally marketed device.

A claim of substantial equivalence does not mean the new and predicate devices must be identical.
Substantial equivalence is established with respect to intended use, design, energy used or delivered,
materials, performance, safety, effectiveness, labeling, biocompatibility, standards, and other applicable
characteristics. Detailed information on how the FDA determines substantial equivalence can be found
in the Pre-market Notification Review Program 6/30/86 (K86-3) blue book memorandum”10.

The UII will in our estimate qualify for a 510(k) and can avoid a PMA because a similar product is
available on the US market and claims to have all required FDA approvals. This device is the “PSTN
Telehealth Gateway”11. However this device was not found on the FDA website. Communication is on
with the manufacturing company about their claims of regulatory adherence. “Until the applicant
receives an order declaring a device SE, they may not proceed to market the device. Once the device is
determined to be SE, it can then be marketed in the U.S. If FDA determines that a device is not SE, the
applicant may resubmit another 510(k) with new data, file a reclassification petition, or submit a pre-
market approval application (PMA).”12 The SE determination is usually made within 90 days and is
made based on the information, which will have to be submitted by us. The FDA has guidelines on
preparing a 510(k), which have been identified and noted.13 [1] Selecting the Appropriate Marketing Application14
The development of data and/or information is necessary to submit a marketing application, and to
obtain FDA clearance to market. For some 510(k) submissions and most PMA applications, clinical
performance data is required to obtain clearance to market. In these cases, conduct of the trial must be
done in accord with FDA's Investigational Device Exemption (IDE) regulation, in addition to marketing
clearance. An IDE allows the investigational device to be used in a clinical study in order to collect
safety and effectiveness data required to support a Pre-market Approval (PMA) application or a Pre-
market Notification [510(k)] submission to FDA. Clinical studies are most often conducted to support a
PMA. Only a small percentage of 510(k)‟s require clinical data to support the application.
Investigational use also includes clinical evaluation of certain modifications or new intended uses of
legally marketed devices. All clinical evaluations of investigational devices, unless exempt, must have
an approved IDE before the study is initiated. The FDA further lists these two requirements that the UII
have to meet before it reaches the market and after it is a marketed product. [1]

                                                                                 Page 17 of 52

                                      Figure 3: Flow chart of 510(k) process15

                                                                                             Page 18 of 52

6.1.3 Other Requirements16
The FDA further lists these two requirements that the UII have to meet before it reaches the market and
after it is a marketed product. [1] Pre-market Requirements: Labeling, Registration, Listing
Before marketing clearance is obtained the manufacturer must assure that the device is properly labeled
in accordance with FDA's labeling regulations. Once clearance for marketing is obtained, the
manufacturer must register their establishment and list the type of device they plan to market with the
FDA. This registration and listing process is accomplished by the submission of FDA Form 2891 and
2892. [1] Post-market Requirements: Quality System, Medical Device
Once on the market, there are post-market surveillance controls with which a manufacturer must
comply. These requirements include the Quality Systems (QS) (also known as Good Manufacturing
Practices, GMPs) and Medical Device Reporting (MDR) regulations. The QS regulation is a quality
assurance requirement that covers the design, packaging, labeling and manufacturing of a medical
device. The MDR regulation is an adverse event-reporting program. [1]

6.2 Federal Communications Commission
The UII posses two ways to communicate with the outside world: via the Zigbee development board
transceiver (this applies to the translators also) and through the Ethernet connection. The FCC regulates
each one of these means in some way.

6.2.1 Zigbee
The FCC has this official stance on unlicensed spread-spectrum devices [2]:

          Create a minimal amount of rules to control (or prevent) interference.
          “Encourage Innovation through flexibility”
          Continuously update the rules in response to technological advancements, developments, or
          Create the set of broad rules as a framework within which the private sector can develop

The project utilizes a Zigbee IEEE 802.15.4 radio that has been certified to meet all regulations of the
FCC. Specifically, it has been approved to operate at up to range of approximately 100 m. [1]

6.2.2 Modems
Regarding modems, there are two important regulations: FCC-15 and FCC-68.

FCC Regulation Part 15 describes the limitations on the amount of electromagnetic interference (EMI)
allowed from electronic devices. It was originally developed to limit possible interference with

                                                                                              Page 19 of 52

broadcast communications and is still with us today. Nearly all devices have to pass this regulation and
the modem is no exception.

FCC Regulation Part 68 describes the requirements for connecting to the U.S. telephone network. The
report defines a variety of terms and goes into detail on how to test a device that will eventually be
connected to the network. Such tests include: the reaction of the device to unforeseen external influences
(high voltage down the transmission line), the possible ways the device can damage the network when it
fails, insurance that the output power levels of the device will not cause problems on the network
(crosstalk, etc.), billing protection (such that it is assured that telephone companies will be able to bill
for the line usage, and other limitations (such as maximum number of redial attempts). [1]

In all, it is assured that the UII meets these two regulations because the integrated modem on the UII is
itself certified to do so. [1]

6.2.3 Ethernet
With regards to the Internet, the FCC practices “regulatory openness” – that is, it does not regulate it
beyond the mandates of Part 15 (which is discussed in the previous section). [1]

6.3 IEEE
In order for the UII to become a commercial product, it should also meet the IEEE standards
requirements for wireless home medical devices. [1]

6.3.1 Medical Device Communications Standard
This standard is intended to enable medical devices to interconnect and interoperate with computerized
healthcare information systems in a manner suitable for the clinical environment. The key requirements
are that this standard shall

   1. Meet applicable requirements for patient and user safety of medical devices.
   2. Accommodate frequent network reconfiguration.
   3. Provide an extremely simple user interface, the only required user action being to connect the
      medical device to the network.
   4. Unambiguously associate a medical device with a specific patient.
   5. Support a wide range of host computer topologies, allowing implementations ranging from those
      limited to a single bedside to those that span multiple beds and care units, with various
      gradations between these extremes.
   6. Minimize implementation complexity for high-volume medical devices.

Communications are modeled as a collection of systems exchanging messages (see figure 4). More
specifically, communications between medical devices associated with a specific patient environment
and a patient care information system responsible for the data of that patient.
                                                                                           Page 20 of 52

                           Figure 4: Medical device communications model

Medical Device System (MDS) is a medical device that is actively connected to a type of
communications link. Patient Care System (PCS) is a patient care information system that is actively
connected to a type of communications link. Medical Device Data Language (MDDL) is the protocol
used to transfer data. [1]

6.3.2 Zigbee
Zigbee technology falls under the IEEE 802.15.4 standard. Its key features are robustness, low
complexity, low power and low cost. Zigbee is a direct-sequence spread spectrum (DSSS) device. A
DSSS device combines a high data rate bit sequence, referred to as the chipping code, with the data
signal that divides the user data according to a spreading ratio. The chipping code is a redundant bit
pattern for each bit that is transmitted, which increases the signal‟s resistance to interference.
                                                                                                            Page 21 of 52

                                         Figure 5: Zigbee stack architecture17

Frequency Bands and Channel Arrangement18
          Frequency Band 2.4 – 2.4835 GHz
          It supports 16 Channels (11-26)

Spreading Parameters
          Chip rate 2.0Mchips/s
          Modulation O-QPSK

6.4 Patents
During patent search, there were few patents that were close to our project. Detailed information on the
patents are given below:

           1. Integrated medical information management and medical device control system and method
           2. Physician information system and software with automated data capture feature.
           3. Pharmaceutical patient information system.
           4. Distributed system and method for managing communication among healthcare provider,
              patients and third party.

6.4.1 Integrated Medical Information Management and Medical Device
     Control System and Method: (United States Patent Application #20040215490)
      Zigbee: “Wireless Control That Simply Works”, William C. Craig,
                                                                                            Page 22 of 52


        An integrated medical information management and medical device control system and method
are described that links multiple users and multiple medical devices together in a coordinated fashion.
The linkage of users and medical devices is accomplished using a bi-directional network and a
centralized host system. Users of the system are able to communicate with each other, operate medical
devices from remote locations, access information from diverse sources automatically monitor a patent's

Inventors: Duchon, Douglas J.; (Chanhassen, MN); Wilson, Robert F.; (Roseville, MN)
Filed: May 18, 2004

6.4.2 Physician Information System and Software with Automated Data
      Capture Feature: (United States Patent Application #20040220830)

        A system and method for collecting, storing, processing, and referencing information in a
personal digital assistant system configured as an electronic physician assistant is provided. The system
comprises a personal digital assistant having an electronic physician data module therein, a scanning
device coupled to the electronic physician assistant, and an automated data collection module for
electronically storing scanned data, the automated data collection module being associated with the
electronic physician data module. The method scans a patient identification and associates the identified
patient with a patient record. Furthermore, the method records medical data as an electronic file of
information and assigns a readable code to the information. Then, when the code is accessed, the method
associates the information with a patient record.

Inventors: Moreton, Paul Y.; (Plano, TX); Moreton, David W.; (Columbia, MO); Breda, David C.;
           (Plano, TX)
Filed: December 1, 2003

6.4.3 Pharmaceutical Patient Information System:
       (United States Patent Application #20040215489)


        A patient information system for the provision of individual-specific information on the effects
and risks of a medicament includes an expert system, in which relevant data on the medicament, for
example, compositions, application area, contra-indications, mode of action, risks and side-effects are
stored. The expert system is embodied such that, on a user inquiry about a particular medicament by
inputting particular personal status data about the user, an individual user information reply, which
matches the personal status data including the education and the knowledge state of the user-- (a
personalized enclosure) is generated including all relevant data, and excluding data on the medicament
which need not be introduced according to the special requirements of the user.
                                                                                            Page 23 of 52

Inventors: Abraham-Fuchs, Klaus; (Erlangen, DE); Bieger, Johannes; (Munchen, DE); Eisermann, Uwe;
           (Erlangen, DE); Hengerer, Arne; (Erlangen, DE); Rumpel, Eva; (Erlangen, DE); Schmidt,
           Kai-Uwe; (Erlangen, DE); Tietze, Daniel; (Spardorf, DE)
Filed: January 16, 2004

6.4.4 Distributed System and Method for Managing Communication among
Healthcare Provider, Patients and Third Party:
(United States Patent Application #20040220829)


        In a distributed system for managing communication among healthcare providers, patients and
third parties, users interact via clients connected to a server. Modules resident on the server provide
functions that facilitate efficient communication among all the parties. System functions include: an
online consultation platform that provides an interactive patient interview, produces a succinct message
to the provider, and a prompt response to the patient's query; online prescribing and refills and
transmission of the prescription; streamlined messaging between patient and provider employs via
specialized message types; practice and workflow management for the provider that includes specialized
message types, customizable routing, and role-based permissions; customizable practice web sites for
registered providers, wherein patients can visit to access online services; broadcast of patient education
materials customized and automatically distributed to targeted patient groups; and integrated charging
and collections, determination of eligibility for coverage, and reimbursement.

Inventors: Baharav, Ofir; (Palo Alto, CA); Weinstein, David R.; (Danville, CA); Morag, Assaf; (Palo
           Alto, CA); Gannot, Gary; (Kensington, CA)

Filed: February 5, 2003

        All the patents mentioned above are directly or indirectly related and very close to what we are
trying to achieve. Hence, if commercialization was an option, then all the patents mentioned above
should be considered and necessary steps should be taken before launching the product.


7.1 Hardware

7.1.1 UII
The hardware requirements of the UII are
    Zigbee
    Connectivity to AHMD
    Broadband Internet
                                                                                             Page 24 of 52 CerfCube
The core of the UII is the CerfCube 250 developed by Intrinsyc. The CerfCube was developed as a
starting point for low power Internet devices and fitted in well with out requirements. [1]

The CerfCube 250with a central Intel variety arm-complying microprocessor called the PXA250. The
included peripheral supports are Ethernet, a CompactFlash connector, 3 serial ports, and a USB port.
Kernel and file-system images can be downloaded through Ethernet and written into Flash by the boot
loader. The CerfCube is loaded with an I-Linux kernel specially built for the CerfCube 250. Device
drivers are provided for all on-board peripherals. Through the Intrinsyc website it is possible to find a
cross compilation tool chain to enable kernel and application development.

                                       Table 3: CerfCube Features
                ITEM                                 DESCRIPTION
                CPU                                  INTEL PXA 250
                Memory                               16 MB Flash
                SDRAM                                32 MB, 32 bit Data Bus
                Serial and I/O                       3 RS-232, 16 Digital I/O lines
                Displays                             4 LEDs
                Power                                5.0 V DC 1 Amp Peak Power
                Dimensions                           69mm by 57mm
                Ethernet                             10 base-T
                CompactFlash                         Type I/II CF/CF+
                USB                                  Type B receptacle

                                 Figure 6: Available ports on the CerfCube

The following gives a brief description of the pertinent ports to the UII:
                                                                                           Page 25 of 52

Compact Flash Connector
The Type II CompactFlash Connector comes with the following features:
    Compact Flash (CF) cards are hot-swappable
    Only 3.3V CF cards are supported
    Type II header allows Type I or II CF (or CF+) cards to be used

USB Interface
The USB interface is a standard Type B interface.

Serial Ports
The serial ports allow three RS-232 connections to be made to the UII.

The Ethernet port has a standard RJ45 connector to connect to Cable/DSL modems.

Based on the available ports and the hardware requirements of the UII the CerfCube could be configured
with two options. The options are covered in the below table.

                                  Table 4: CerfCube Configurations
                                           Configuration 1                     Configuration 2
           Ethernet                           Internet                              Internet
            USB                               AHMD                                  AHMD
         CompactFlash                         Modem                           Additional Memory
           RS-232                              Zigbee                                Zigbee

The CompactFlash Socket on the CerfCube can be configured based on a customers needs. If the
customer does not have a Cable or DSL Internet connection they can still connect the UII to the Internet
with a dial up connection. This can be done through a CompactFlash 56K modem card. However if a
customer has multiple users, then extra memory storage might be necessary. 128MB compact Flash
Memory Card should solve this problem for the customer. [1]

7.1.2 Translator
The hardware requirements of the Translator board are
    ZIGBEE 802.15.4 standard
    RS-232 input and RF output
    Programmable processor with enough storage for embedded program and data to be transmitted
    Battery operated and low power consumption Freescale Development Board as Translator
The translator functions are going to be implemented using the Freescale development board. Freescale
developed the MC13191/92 developer‟s kit as a tool to implement wireless network designs compatible
                                                                                            Page 26 of 52

with the IEEE 802.15.4 standard. The developer‟s kit also fit the team‟s hardware and software needs.
19 Freescale Development Board20
The Freescale development board is equipped with a programmable 40-MHz HCS08 (8 bit) micro
controller unit (MCU). The HCS08 micro controller comes with 60 Kbytes in-application re-
programmable FLASH memory and 4 Kbytes of RAM. Freescale provides Code Warrior development
studio software from programming the HCSO8 MCU. The development board also is equipped with
LED‟s to help with debugging and status of data transfer. A further understanding of the development
board can be seen by dividing it functionally into a front end and a back end.

The front end of the Freescale development board processes data and communicates with the UII. Data
processing is done with the HCS08 CPU and transmitted to the UII via Zigbee radio. The HCS08
processor formats data from the back end in a usable form the UII will understand.

The back end of the Freescale development board consists of a RS-232 communication port. This port
allows for peripheral devices to be connected to the development board. Unfortunately the hardware
configuration cannot be changed to accept external inputs other than RS-232. For now if a peripheral
does not come with an RS-232 communication port then a converter will have to be bought or made to
connect the peripheral to the Freescale development board.

                                      Table 5: Freescale Features
ITEM                                                Description
MCU                                                 40-MHz HCS08 (8 bit)
Memory                                              60 Kbytes in-application re-programmable FLASH
RAM                                                 4 Kbytes
Serial                                              1 RS-232 port
Wireless                                            Zigbee IEEE 802.15.4 Standard
Power                                               9 volt battery or external power supply
Monitoring                                          LED‟s

                                                                                              Page 27 of 52

                                 Figure 7: Freescale Development Board

                       Figure 8: Example Block Diagram for Sensor Application

7.1.3 5th Element

The Fifth Element is a bio-potential differential device that will be used in monitoring the electrical
activity of the user‟s heart and collecting related data that can be analyzed by a physician. Data
collection is done through the use of non-invasive (surface) electrodes that are placed at strategic points
on the user‟s body in order to capture the heart‟s sequence of activities during atrial and ventricular
activation. In addition, the design is such that the user can also collect electro-myograms (recordings of
other muscle activity) by flipping a switch in the circuit.

The Bio-amplifier consists of a two channel front-end device and unlike the other medical devices, the
output is an analog signal and it needs to be sampled by the A/D converter on the Freescale Zigbee
board before the data is formatted and sent wirelessly to the Freescale board connected to the PC.
                                                                                               Page 28 of 52 The ECG-EMG signal properties

To collect electrocardiogram or electro-myogram readings, electrodes will be attached to the patient on
the left and right arm, and also on the right leg (which acts as a reference point). Bioelectric signals are
generally small signals. The various types of recordings are usually differentiated based on the
frequency response of the signal.

For both the EMG and the ECG, there are many unwanted components and interferences that are
collected with the signal and need to be filtered effectively in order for the correct recording to be
derived. Examples of these interferences include electric/electromagnetic interference- like the noise
from the power mains (that is 60Hz noise) or radar devices (televisions etc.); noise due to electrode-skin
contact and changes in impedance due movements between the electrode and the skin.
These noise issues are addressed simply by using a high pass filter, low pass filter and a 60Hz notch

The high pass and low pass filters form a band-pass region that varies depending on the type of signal
being recorded. A decent frequency range for ECG signals is from 1Hz to 100Hz. These values are used
as the cut-off values for the low-pass and high-pass filters in the ECG design. The ECG signal amplitude
is usually on the order of about 0.5-5mV. EMG signals really have a frequency range from about 25Hz
to around 3kHz1. However, the significant EMG signal collection frequency range is usually from 2 to
500Hz2. This design uses a pass band of 20-200Hz which is also sufficient. The EMG signal amplitude
for surface electrodes is usually on the order of about 0.1-2mV. The ECG-EMG design

A simplified block diagram of the „fifth element‟ can be seen in Figure 9:

                      Figure 9: General Block diagram of Bio-potential Amplifier. Basic components of ECG/EMG Bio-potential amplifier

   1. Right leg drive
   2. Electrostatic discharge (ESD) protection
                                                                                               Page 29 of 52

   3. Pre-amplifier -> Initial amplification prior to filtering
   4. Amplifier block
   5. Power supply

    • Right leg drive
The right leg drive is a portion of the circuit that ensures that the user is protected from leakage currents
by acting as a reference or ground point. It is connected to the right leg of the user (which is implanted
on the ground). Its feedback loop minimizes the effect of common-mode voltages.

    • Electrostatic discharge (ESD) protection
The initial portion (i.e. at the channel inputs) of the circuit is configured to protect the circuit from
electrostatic discharges. It acts as a current limiter that prevents destructive voltages from passing
through to the rest of the device. In addition to this, an isolation amplifier IC is placed with the power
                        R1                                                R3        R4
                        2.2k                                              2.2k      2.2k
                                                  Q1              BC557

                               C1               BC547              Q3
                                                BC547              Q4
                                                  Q2              BC557
                        R2                                                R7        R8
                        2.2k                                              2.2k      2.2k

                    Figure 10: The Schematic showing the ESD protection circuit

Figure 11 is a plot of the input voltage with a DC sweep of the voltage across the electrodes. The plot
indicates that the input to the ECG circuit eventually saturates with increasing voltage across the
                                                                                          Page 30 of 52

         Figure 11: Voltage output of the ESD Protection circuit with increasing input voltage

Figure 12 is a plot of the output voltage (ADIN1) with a DC sweep of the voltage across the electrodes.
The plot shows that the ECG output voltage eventually becomes saturated (indicated by the leveling off)
with increasing voltage across the electrodes.

                  Figure 12: A DC Sweep analysis of the output of the „fifth element‟
                                                                                                                                                                                                                                   Page 31 of 52

    • Pre-amplifier
The incoming signals from the ESD protection circuitry passes through the pre-amplifier, which is
characterized by high input impedance and a low common-mode gain, before entering the amplifier
block. Just as important is that it serves to provide initial amplification prior to filtering.

    • Amplifier block
 This section of the design is responsible for signal filtration and most of the amplification. The
amplifiers in this stage also provide significant amplifications of the incoming signals. The gain in this
region is about 1000. This is necessary because ECG and EMG signals are very small and are usually on
the order of a few milli-volts.

The amplifier block consists of two identical high pass filters and a Sallen-Key low pass filter. It is also
for the above that reason that is it essential that the incoming signals be filtered efficiently. The ECG
signal filters create a band-pass from 0.1Hz to about 100Hz, while the EMG signal filters create a band-
pass from 20Hz to 200Hz. Many other signals easily get mixed up with the desired signal and pose a
problem when recording the ECG/EMG.

After the signal leaves the protection circuitry, it passes through two major amplifiers. The amplification
is split into two steps and in between them is a high-pass filter which serves to remove DC-voltage
offsets. This aspect of the design is important since electric charge can easily accumulate on the surface
of the electrodes used for data acquisition and end up building a significant DC voltage. Theoretical
amplification would imply that such a small voltage on the order of a couple of 100mV can be amplified
to give a voltage on the order of tens of volts. Without this high pass filter, it will be possible to collect
data without the desired signal content.]




                                                  C6                                    U2A            PWR                                                                                                                                                              R7


                                                                                        +                          C8                        R14            R15                 U7B
                                                  1u                                                                                                                                                                                                                    2k
                                                              R12                                              1        1u                                                 5

                                                                                                   OUT                                                                           +                                                                                      R2
                                                              1000k                                                                          22k            22k
                                                                                    2                  TLC277/101/TI                                                                             7 ADIN1

                                                                                        -                                                                                                  OUT
                                                                                                             AGND                                                                                                                                                       12.1k
                                                                                                                                     R18                                   6


                                                                                                                                                                  C11            -
                                                                                                                                     1000k                                                           AGND
                                                                        R10             R11                                                                       0.047u                                                                                                R1

                                                                        1k              100k                                                                                                                                                                            2k
                                                           20k                          C7
                                                                                                                                                                               8.2k                                                                                                  V1
                                                           SET = 0.5


                                   0                                                                                                                                                                                                                   4                             12Vdc

                                                                                                                                                                           R145                                                                        5    +
                                                                                                                                                                           100k                                                                       12    -                   6
                                                                                                                                                                                                                                                       3    IN1   OUT
                                                                                                                                                                                                                                                       2    IN2                 1
                                                       0                                                                                                                                                                                               8    IN3 LPOUT           7
                                                                                                                                                                                                                                                      14    ADJ1BPOUT           13
                                                                                                                                                                                                                                              R6             Gnd
                 Figure 13: Showing the configuration for the filters of a single channel                                                                                                                                                     4.99k


The high pass filters were of the first order and the desired cut-off values and chosen capacitor values                                                                                                                                                           2650000

were used in determining the values of the resistors needed.                                                                                                                                                   C42


                                                        1                                                                                                                                                      0.1u

                                                fc            (Equation 1)


                                            C41                                                   U11A       PWR                                                                                     U10B

                                                                                              3                                                                                                  5


                                                                                                   +                         C45                   R47                           R48                  +
                                                                R46                                                     1       1u                                                                                      7
                                                                                                             OUT                                                                                               OUT
                                                                8.2k                                                                                                             12k

The Sallen-Key low pass filter was created using the standard formulas. Various values of capacitors
                                       V4                                                     2                TLC277/101/TI                          12k                                        6


                            1Vac                                                                   -                                                                                                  -            TLC277/101/TI
                            0Vdc                                                                                    AGND                       R54


                                                                                                                                               8.2k                               C43                                 R49

where chosen and used to create different configurations which were then simulated in software.



                                       0                         R53
                                                                 20k                               C44
                                                                 SET = 0.5


                                                                                                       Page 32 of 52

                                 Figure 14: Typical Sallen-Key Low pass filter*

The cutoff frequency of 100Hz (ECG) or 200Hz (EMG) was first chosen. Then a capacitor value
between 100pF and 0.1 uF is chosen for C2.

C1 = 2 x C2

R1 and R2 are of equal value. R2 is calculated as follows:

R2 = 0.707 / (2 · π · fo · C2)

RA and RB are set to create the necessary gain. ( In this design, RA and RB are set to 8.2K and 100K

The configuration that resulted in the best simulation results, in terms of frequency analysis, was used
for the final design.

                                                      ECG: Configuration A




            10mHz       30mHz   100mHz   300mHz   1.0Hz      3.0Hz           10Hz   30Hz   100Hz   300Hz   1.0KHz

                                 Figure 15: Frequency analysis of the ECG filters
                                                         Page 33 of 52

   Figure 16: Frequency analysis of the EMG filters

Figure 17: Frequency analysis for a single ECG Channel
                                                                                            Page 34 of 52

                        Figure 18: Frequency analysis for a single EMG Channel

Specifically, the resulting frequency analysis for the ECG signal shows that the roll-off is about 48dB
per decade, while that of the EMG signal is approximately 40dB per decade.

                               Figure 19: Portion of Signal Amplification

Some major sources of noise include 60Hz noise from the power mains, surface, noise due to electrode-
skin contact and noise due to radar devices. The 60Hz noise is taken care of by the 60Hz notch filter.
                                                                                                               Page 35 of 52

   This filter is created by using a UAF42 chip which is an active second order filter that efficiently gets rid
   of unwanted noise at 60Hz frequency when configured appropriately.







                                                          4                             12Vdc

                                                          5    +
                                                         12    -                   6
                                                          3    IN1   OUT
                                                          2    IN2                 1
                                                               IN3 LPOUT                                 VDB
                                                          8                        7
                                                         14    ADJ1BPOUT           13

                                                 R6            ADJ2HPOUT

                                                 4.99k                                   V3


                                       V4                                                        0
                                0Vdc                                                     12Vdc
                                       0     0



                   Figure 20: Schematic showing the UAF42 60Hz notch filter configuration

                               Figure 21: The notch filter frequency analysis The Power Supply and Isolation Circuit
                                                                   Page 36 of 52

Figure 22: Schematic of the Power Supply and Isolation Circuitry
                                                                                            Page 37 of 52

The power supply to the circuit comes from any 12V source. The 12V directly powers the UAF42 chips
which require this as a minimum voltage supply value. The rest of the circuitry (other chips and
amplifiers) only need 5V to operate. The 12V is voltage regulated and sent through a DC-DC converter
which provides an output of 5V. The 5V is then isolated and filtered before being used to power up the
rest of the circuitry. Diode D4 allows reverse polarity. The DC/DC converter powers the rest of the
device and also serves to protect the user from large voltages. The inductor/capacitor networks placed
before the DC/DC are filters that serve to reduce the switching noise from the converter. In addition, the
5V is used to derive a buffered 2V bias (this is achieved through a simple voltage divider) which is used
to create a reference point for many of the circuit components- thus preventing the desired output
voltage from swinging negative. In other words, the output signals will swing around 2V as opposed to
                               Page 38 of 52

Figure 23: ECG/EMG Schematic
                                                                                             Page 39 of 52

The DIP SPST Switches

Since the device is intended to also function as an electromyograph, certain components were included
in order to minimize the number of circuit components. For example, the use of 4 position DIP SPST
switches (2 position DIP SPST switches would have been sufficient for a single channel, but there are
two channels). The signal through a single channel is the same for both an EMG and ECG up until the
amplifier block where the signal filtration and amplification takes place. Consequently, a DIP SPST
switch is placed at the output of the pre-amplifier. The output of the pre-amplifier is connected to two of
the DIP inputs (four position switches implies two DIP inputs per pre-amplifier channel). Depending on
which switch is toggled on, the signal from the pre-amplifier will either be filtered like an EMG or ECG
signal. However, only one switch can be toggled on at a time. Also, there is one UAF42 notch filter per
channel and another DIP SPST switch is placed at the input of the UAF42 notch filters. Although there
is only one signal (ECG or EMG) that is allowed through to the channel‟s notch filter, the presence of so
many components might pose a problem in terms of leakage currents in different parts of the circuit. To
avoid the effects of leakage currents and undesired impedances, the additional DIP SPST serves to limit
or localize the area of the circuit through which current flows during a particular recording.
The final output is an analog signal which is sampled by the AD converter on the Freescale board,
formatted as necessary and then sent wirelessly to the Freescale board attached to the PC.

7.2 Software
Large part of the project is based on software architecture. Basically most of the data will be processed
in the UII. Hence, programming the UII will be most important task.

7.2.1 UII Communications Protocol
UII‟s Communication protocol will work as a push method. A user would use a medical device which
would then be pushed into the UII. This will simplify the user interface on a palm pilot. The user would
use they‟re own medical device as they normal would then press the send data button on the palm pilot
to send the data. By using the medical device will cause the Zigbee board to wake up and establish a
connection with the UII and palm pilot. Once this has been established the UII will then wait for the
palm pilot to signify to take data from the currently active medical device.

Each manufactured device has a unique identifier. In addition to this identification, each device is
capable of reporting its data to a specified datatype and in a specific dataunit. Together called dataform.
The datatype specifies the format of the binary data stream that will eventually be retrieved by the UII.
For multiple-byte datatypes, the most significant bytes are transmitted before the least significant bytes.
The protocol allots for 256 distinct datatypes. Current datatype includes:

   1.   8-bit integer
   2.   2‟s complement 8-bit integer
   3.   16 bit integer
   4.   2‟s complement 16-bit integer
   5.   32 bit integer
   6.   2‟s complement 32-bit integer
                                                                                              Page 40 of 52

   7. 64 bit integer
   8. 2‟s complement 64-bit integer
   9. 32 bit IEEE floating point
   10. 64 bit IEEE floating point

The dataunits parameter specified the scientific units of the data. The protocol allots 256 distinct
dataunits. Some of these units are:

   1. Pounds (lbs)
   2. Kilograms (Kg)
   3. Hz (1/s)

7.2.2 UII Architecture

The UII runs a modified version of the Linux 2.4 kernel. That kernel provides for process management,
memory management, device management, inter-process communication, a file system, and networking
system. The UII code shall run as separate processes that shall act like Unix daemons (background

The UII code is responsible for a multitude of tasks. These include:

      Establishing a connection to the Internet through either Ethernet or PPP through the modem.
      Updating the central server with the current Internet address of the UII.
      Communicating with the user interface device (PDA).
      Managing the user identities and databases.
      Implementing the UCP to communicate with the medical devices.
      Communicating with the AHMD to provide it with the information that it requires.
      Providing a web server and set of web pages and scripts to provide the physician with a user
       interface. User Interface Architecture

The user interface software is responsible for communicating with the external user interface device
using Zigbee development board on the UII connected through one of the RS-232 port. IT shall run as a
separate process that is tightly coupled to the software that implements the UCP since the User Interface
essentially drives it. Further, the user interface software must be able to access the medical database and
the configuration information. Essentially, the user interface software is the backbone of the UII‟s
operations with respect to the user.

The software shall be constructed on the principle of a finite state machine where the particular state is
driven by the functionality of the user interface as described in the functional specifications. Medical Database Architecture
All the information of a user is stored on a mySQL database on the UII. This database will be accessed
by a boa page with displays all the information on a page over the net. Access to the user database will
                                                                                             Page 41 of 52

be given exclusively to one process at a time. If the database is already held by another process, then the
requesting process must wait until the other process is finished. Final database will look like table
shown below:

                                     Table 6: Sample UII Data Base AHMD Implementation[1]

The AHMD requires certain files to be placed in its memory in order to function as required. It is up to
the UII to provide the AHMD with those files. The true source of the files is the physician who is able to
provide them to the UII via the user‟s homepage. Once the UII has received those files from the
physician, it shall make use of its USB connection to the AHMD to transmit those files to it. The precise
messaging protocol is not specified here, but the following function shall be used when attempting to
transfer data from the UII to the AHMD.

First, the UII will attempt to establish communication with the AHMD. This is necessary because the
two devices do not stay in regular contact. Essentially, a short ping message is sent and the AHMD
software waits a certain amount of time to receive an acknowledgement. If it does not receive one within
an appropriate amount of time (approximately 1 second), then it will return an error code to the process
that originally requested the action. (For information on the RPC mechanism, see the UII Software
Architecture section.)

Once communication has been established, the UII shall transmit the filename, the user identity, and the
file length of the file that is to be transferred to the AHMD. Again, the UII shall wait for either an
acknowledgement or a non-acknowledgement (in which case the file access was denied). If the file
access was denied, then the AHMD software shall return an error code specifying so.
                                                                                             Page 42 of 52

Upon acknowledgement, the UII shall transfer the data in a byte-sequential form. At the end of the
transfer, it will also transmit a two-byte check sum on the file. Again, it will wait for an
acknowledgement from the AHMD. If it receives one, then it will return a success code. Otherwise, it
will return another error code. Web Server Implementation[1]

The UII shall provide a web server to provide the physician with a user interface (as described in the
Functionality section). The web server will not be designed as a part of this project; instead a pre-
designed server shall be chosen. The pre-designed server chosen was boa.

It is required that the web server be able to run server-side scripts in response to actions taken by users
of the web pages. These scripts shall facilitate retrieving external files and communicating with the
appropriate UII processes to dispatch information data back to the physician. The scripts themselves
shall contain no logic specific to the operation of the UII (such as the UCP protocol) but will instead rely
on the individual parts of software detailed above to do those types of operations.

7.2.3 Translator Architecture [1]

The translator‟s software is designed such that the programmer – whose real task is to interface with the
specific medical instrument – will not be burdened with learning or debugging the UII Communications
Protocol. Instead, the programmer need only learn a basic API that will be provided to them along with
the translator hardware.

Installation of the API requires the programmer to invoke one initialization function, provide the
required interrupt handlers, and to respond to the API‟s needs through a set of callbacks. Aside from
those requirements, the programmer is free to work on the interface to the specific medical instrument.

8 Software Architecture

8.1 Programming the HC(S)08

The HC(S)08 microcontroller can be accessed through 8 Analog pins, a JTAG connection and a RS-232
port. The HC(S)08 can be programmed through either the RS-232 port or the JTAG connection. To
program the microcontroller through the serial port a special Test Tool application must be used. This
program will load a .s19 executable file onto the board. However this program has many bugs and may
cause errors during operation. The JTAG connection uses the Background Debug Module connected to
the HC(S)08 and will load a .elf executable file. In order to download the executable file to the
HC(S)08 a USB Multilink S08 cable must be used. This cable will interface directly with the
CodeWarrior IDE to load the code onto the board. CodeWarrior IDE is the software Integrated
development environment used to create, compile, and debug the code used for this project.

8.2 The Medical Instrument Data Output
                                                                                                Page 43 of 52

For this project it was required to show the feasibility of home medical wireless transmission. The
medical device used was a digital scale with an RS-232 output. The scale outputs data in a specific
format with two header characters, 8 data characters, two unit characters, and 2 termination characters.
The header characters will be ST for stable or US for unstable. The Data characters will be a „,‟
followed by a „+‟ or „-„ for positive or negative weights, then the weight in this format “XXXX.X”. The
units will be lb for pounds. The termination characters are a carriage return followed by a linefeed
character. This format is shown in figure 24.

                                   Figure 24: Sample scale output format

The format of each transfer will have a start bit followed by 7 data bits, an even parity bit, and ending
with a stop bit. Data will be sent out from the scale at a baud rate of 2400bps.

The scale and the Zigbee SARD board were both designed to be serial devices. A serial device would
then be connected to a serial host, in most cases a PC. However, for this project the scale and SARD
board were to be connected to each other. This posed a problem since the scale outputs data using the
RD serial data line and the SARD board looks for incoming data on the TD serial data line. In order for
the SARD board to recognize that there was incoming data a serial crossover cable had to be used. This
cable would switch the RD and TD lines so that the scale would output its serial data on the TD serial
data line, which would be noticed by the SARD board.

8.3 Software Organization

The software organization for this project consists of 3 projects. The 3 projects are: Select MCU
Target, SMAC, and Wireless UART. The Select MCU Target is common code used to select between
different Freescale Zigbee Development boards. Each one of these boards contain a different processor
from the HC(S)08 family. For this project the MC9S08GT60 processor was used. The SMAC, simple
media access control, project contains the common code used to access the MC13192 Zigbee
transceiver. This is the code that will send out the wireless data. The Wireless UART project is the
code for the main application. This code has two main files wireless UART and SCI.

The SCI (serial communication interface) files contain the code for the UART operation. There are two
files, the header file (SCI.h), and the source file (SCI.c). The header file contains the all the registers for
the UART. Included in this file is the baud rate definition. Since the scale uses a baud rate of 2400 the
value that must be set to the SCIBDL register is D0(hex) which is calculated from equation (2).
                                         BUSCLK 
                            SCIBDL                                (Equation 2)
                                         16  BaudRate  HEX
                                                                                               Page 44 of 52

The bus clock speed of the GT60 MCU used in equation (2) is 8MHz. This will result in a value of 208,
which when converted to hex is D0.

The source file contains the functions which will send out serial data and take in serial data. The
function that displays serial data is very basic and will check to make sure the UART buffer is full and if
it is not it will load to the UART buffer to send out the data serially. The serial receive function is more
complicated and tailored to meet the specifications of the scales output. The receive function is an
interrupt handler which will occur whenever there is incoming serial data. Since the SARD board is
connected to the scale via the RS-232 port all incoming serial data will come from the scale. The form
in which data is sent out wirelessly does not have a parity bit therefore; the scale data must be converted
into 8 bits with no parity. The only data to be saved are stable values. The header portion of the scale
output will contain “ST” for stable and “US” for unstable. In both of these cases there is an „S‟
character therefore in order to check for a stable value the code will look for the character „T‟. If a „T‟ is
contained in the output string then the rest of the scales output will be stored on the MCU. Once all the
data has been collected the code will check to see if the 4 data characters to the left of the decimal point
are non „0‟. Only the data characters to the left are checked because no person will weigh less than 1
pound and a weight less than 1 is defined to be an invalid measurement. An invalid measurement and
will do nothing. If there is a valid measurement, the four data characters are non „0‟, then a flag will be
set to signify that valid data has been acquired. A visual interpretation of serial interface can be seen in
figure 25.
                                                                           Page 45 of 52

        Initialize counter (i) to put
          data in SCIsave vector


                  Is there
F             incoming data
                from serial


    F              Is the
              incoming data
               an ASCII „T‟


         Put SCID into SICsave
          vector. Increment (i)

    T          If (i) counter
                    < 13


             Check to see if              T
                                                      Data ready for
                                                   transmission flag set
              equals zero.


                      Figure 25: Serial Input Flow Chart
                                                                                              Page 46 of 52

The wireless UART file was created in a state machine format. The states used were
Receiver_Always_On, Waiting_for_ack, Transmit_data, Transmit ACK, and Timeout. On the
transmitting side the states used are: receiver always on, waiting for ACK, and transmit data. The
receiver side uses the receiver always on state and the transmit ACK state. The Timeout state is only
used if a transmission fails and it will retry 4 times before failing.

The transmission side, the scale side, will be in the receiver always on state while there is no data to
transmit. At the end of every state the code will check to see if a transmit flag has been set, indicating to
switch to the transmit data state. If this flag has been set to indicate that valid data is ready to be sent
then LED 1 will turn on and LED 2 will turn off (if it was on). The main system architecture of the
main loop for the transmitting Zigbee board can be seen in Figure 26.
                                                                         Page 47 of 52

            Idle state

              Is data          T
            ready flag                          LED 1 ON
                set.                           LED 2 OFF


             If push           T                    Is push
            button 1 is                            button 1
             pressed                              still being
                                                   pressed           T


F        If pushbutton                        Fill transmit buffer
        1flag is set, and                         with data in
        pushbutton 2 is                          SCIsave. Set
             pressed                           pushbutton flag.


                                             Set transmit flag

             Is push
            button 2
          still pressed                       Go to transmit
    T                                         data function

                            Figure 26: Transmission Main Loop
                                                                                               Page 48 of 52

While in the transmit data state, the receiving function is disabled to avoid conflicts on the same
channel. Then the transmit data state it will check to see if button 2 has been pressed, by checking a
flag. If button 2 has been pressed then the transmit buffer will be loaded with the first half of the data
and a „\0‟ character to represent the end of the transfer. Once the buffer is full it will call the SMAC
project to send out the data. If the data has been sent out successfully it will then turn the receiver back
on to wait for an acknowledgement. This state will then increment the index so the next time this
function is called the second half of the data will be sent out. It will check to see if all the data has been
sent and if it has then the buffer is filled with 0‟s. This is done to prevent the user from sending multiple
data transfers without taking another measurement. When the buffer is filled with all 0‟s then nothing
will be transmitted. In addition to clearing the buffer once all the data has been sent, the flags will be
cleared and the index set back to zero. Also LED 1 will turn off because there is no data available to be
sent out and LED 2 will turn on to signify that all the data has been sent out successfully. An illustration
of the transmission data function architecture can be seen in figure 27.
                                                                                  Page 49 of 52

          Disable the
        receive function

                If              F             Is (j) counter        F
            transmit                            between 0
             flag is                               and 8

                   T                           T

Reset transmit flag

Transmit 7 data characters                Go to main loop
followed by null character in
transmit buffer

Increase (j) counter by 7 for
next transition

Reactivate receive function

                                    Clear transmit buffer and set
             If (j)             T          (j) counter to 0.
            counter                       Turn Off LED 1
             is 14                        Turn On LED 2


                                                                         If ACK        F
                       Figure 27: Transmit Data Loop
                                                                                            Page 50 of 52

The waiting for ACK stage will simply wait for an acknowledgement. This is because a timeout of zero
was set. Once an ACK has been received then the code will change back to the transmit data state to
send out more data if necessary.

The receiver side will always be in the receiver always on state waiting for data. Once data has been
received the SMAC project will call the function MPCS data indication, which will check to see what
was received. If the incoming data was not „A‟, „C‟, „K‟ an acknowledgement then the data received
should be outputted through the serial port. This is done through the SCItransmitSTR function. This
function will serially step through a string and output one character of the string through the RS-232
port. A flow chart describing the receiver code is shown in figure 28.

                      Waiting for receive
                       Turn receiver on

                            Has data                             Is the Data
                F                               T                 received
                            received                                ASCII
                                                                   “ACK”                T


                                                            Output data received
                                                               to serial port

                                    Figure 28: Receiver Flow Chart
                                                                                                            Page 51 of 52

9 Bill of Materials

                                          Table 7: The Fifth Element B.O.M
RESISTORS: 1% metal film, 0.25W, 10mm Pitch
Amount        Value               Components                           Manufacturing details
              2.2K                R1-R8,R34-R41
              1M                  R9,R13,R42,R46
              1K                  R11,R21,R44,R54,R77
              100K                R12,R22,R45,R55,R27,R16,R50,R60
              10K                 R51,R71,R72,R18
              100-Ohms            R76
              9.1K                R74
              470-ohms            R73
              2K                  R28,R30,R61,R63
              12K                 R24,R25,R57,R58           R29,R62
              5K                  R31,R64
              2.65M               R32,R33,R65,R66
              15K                 R75
              8.2K                R17,R19,R23,R26,R49,R59,R52
              120K                R14,R15,R47,R48
              7.5K                R69,R70
              200K                R67

Amount        Value               Components                           Manufacturing details
         2    10pF                C1,C16                               100V, 5mm pitch, COG, Package C5
         4    100pF               C2,C3,C17,C18                        100V, 5mm pitch, COG, Package C5
                                                                       EL25B, 35V, 2.5mm
         2    1uF tantalum        C59,C60                              pitch
         8    1uF film            C6,C8,C11,C13,C21,C23,C26,C28        C-10,5%     tolerance, 10mm pitch
         17   100nF               C4,C5,C19,C20,C33-C38,C41,C42,C50,   X7R, C-5, 100V, 5mm pitch
         5    10nF                C44,C45,C48,C51,C54                  X7R, C-5, 100V, 5mm pitch
         1    47uF tant. (1ohm)   C43                                  ES-5, >6.3V, 5mm pitch, ESR=0.8-1.2ohm
         4    47uF tantalum       C46,C49,C52,C56                      EL25B, >6.3V, 2.5mm pitch
         2    0.047uF             C15,C30
         2    0.01uF              C10,C25
         2    0.022uF             C9,C24                               5mm pitch, max 3.5mm wide, 5%, C-5
         6    1nF                 C7,C31,C32,C12,C22,C27               X7R, C-5, 200V, 5mm pitch
         2    0.1uF               C14,C29
         2    220nF               C39,C40
                                                                       EL25B, 16V, 2.5mm
         1    10uF                C47                                  pitch

Amount        Value               Components                           Manufacturing details
              TLC277P             U2,3,5-8A&B,U10,U12
         2    UAF42               U9,U11
         2    1NA114P             U1,U4
         3    IN5818              D1,D3,D4                             Schottky
                                                                                                    Page 52 of 52

           1   LED               D2                              5mm
               TMV0505S          U14
                          7805   U15                             Voltage Reg- 5V, >= 500mA, size TO220
               TL431CLP          U13                             Adjustable Volt. Reg., TO92-CL
                                                                 R-125,SRF>13MHz,Lmax>285mA, 12.5mm
               22uH              L1,L2,L3                        pitch
               BC547, T092       Q1,Q2,Q5,Q6                     NPN TRANSISTOR
               BC557, T092       Q3,Q4,Q7,Q8                     PNP TRANSISTOR
                                                                 4 POSITION, DIP SPST SWITCHES

                                       Table 8: Final Bill of Materials
                      Component                                            Estimated Cost
                      PCB Boards                                                $105
                       Capacitors                                                $40
                        Resistors                                                $10
       Discrete Semiconductors (Diodes, BJTs...)                                  $4
                           ICs                                                  $140
                         Sockets                                                  $1
       Misc. Parts (cable connectors, electrodes,                                $60
             Freescale Development Board                                      4 x $199.10
      Code Warrior for HC(S)08 Microcontrollers                                  $150
              USB Multilink BDM Cable                                           No cost
                        TOTAL                                                  $ 1,306.4

10 Citations
[1]       Critical Design Report for the Universal Internet Interface; Mohammed Benmansour, Frank
          A. Krudger, Reuben Mathew

[2]       Trends in Unlicensed Spread Spectrum Devices. FCC Commission Meeting. May10, 2001.