WO2002035997A1 - A monitoring system - Google Patents

Abstract

A medical monitoring system to allow the medical status of a subject located in a monitoring zone to be determined, the system comprising: an assessment data means remote from the monitoring zone, to collate monitored medical data associated with the subject; a primary station located at the monitored zone and adapted to receive and transmit data with the assessment data means over a communications network; and at least one sensor device in data communication with the primary station, to monitor medical data associated with the subject and to transmit the data to the primary station, wherein in use, the transmitted monitored medical data is relayed to the assessment data means and the information used to determine the subject's medical status.

Description

A Monitoring System

Field of the invention

The present invention relates to a monitoring system and more particularly, though not exclusively, to a medical monitoring system.

5 Background of the invention

Fundamental changes in the delivery of health care are being driven by factors such as increasing health care costs and an aging population on the one hand, and improvements in technology on the other. Both sets of factors have produced trend towards maintaining as many potential hospital patients as possible in their own homes rather than in the considerably more expensive hospital system, or even nursing homes. There are, of course, social and lifestyle benefits to patient's remaining in L0 familiar surroundings rather than the hospital environment. Increasing adoption of new telecommunications and information technologies may permit certain patients to be treated and monitored in their homes with potentially substantial cost savings. A report from the United States Council on Competitiveness suggests that the daily cost of supporting a patient through home telemedicine is $US30, compared with $US74 for home visits, $US100 for nursing home care and $US820 for in patient hospital care.

L5 Further, people confined to hospital institutions may suffer psychologically more than if they were in their own homes.

Further, measurement of many physiological parameters may be influenced by the so-called "white coat effect", where the environment in which the measurement is made (doctor's surgery or clinic) influences measurement outcomes such as blood pressure.

The applicant does not concede that the prior art discussed in this specification forms part of the common general 10 knowledge in the art at the priority date of this application.

Summary of the invention

It is an object of the present invention to provide an improved form of monitoring system.

According to a first aspect of the present invention, there is provided a medical monitoring system to allow the medical status of a subject located in a monitoring zone to be determined, the system comprising:

15 an assessment data means remote from the monitoring zone, to collate monitored medical data associated with the subject; a primary station located at the monitored zone and adapted to receive and transmit data with the assessment data means over a communications network; and at least one sensor device in data communication with the primary station, to monitor medical data associated with the 50 subject and to transmit the data to the primary station, wherein in use, the transmitted monitored medical data is relayed to the assessment data means and the information used to determine the subject's medical status.

Advantageously, the sensor is a motion detector and is adapted to detect the motion of a subject. The motion detector may be adapted to determine if the subject is involved in particular activities such as falling, walking, running, sitting, sleeping. 55 The motion detector may include a 3-axis accelerometer. The assessment data means may further include an algorithm to detect if a subject falls. The sensor device may be worn by the subject in a mobile unit, the mobile unit having communications means to transmit the medical data to the primary station.

Preferably the sensor further comprises a microphone to detect audio signals and a radio transmitter to thereby permit the subject to communicate with a user of the assessment data means. Further, the sensor may include a speaker to allow the subject to verbally communicate with a user of the assessment data means.

The sensor device may detect any one or more of the following variables related to the subject: heart rate, heart rhythm, motion, speech, blood pressure, cholesterol, neurological activity, blood sugar.

In one embodiment, a plurality of the primary sub-stations may be located in the monitoring zone to assist in transmission of data between the sensor device and primary station as the subject travels through the monitoring zone. The plurality of primary stations can be located throughout the subject's home.

The assessment means may include an archive data base to record the transmitted data for use by the medical professional. Further this data may be transmitted by the primary station to the assessment data means according to a predetermined time period to thereby save on processing power in the assessment data means. The assessment data means may comprise a data base to store the transmitted monitored data and the data base may be written in SQL. The assessment data means can have an application program which raises an alarm to a medical professional upon the receipt of the medical data is important to the subject's medical condition. Optionally, the assessment data means may filter the monitored data and present it to the user of the assessment data means in a summarised form.

The communications network may be the Internet.

The plurality of primary stations can exchange data with a master transmission station and further, the master transmission station may exchange the data with the assessment data means. The master transmission station may further include a user interface to allow a user, in particular a clinician, to interact with the assessment data means.

The master transmission station may further include a user interface to allow a person to interface with any one or more of the following: the assessment data means, the master station, the plurality of primary stations and the mobile unit.

The master transmission station may include a filter to filter data received from the plurality of primary stations before it is sent to the assessment data means. Optionally, data received by the master transmission station may include a database in which subject data is stored. The master transmission station may include a computer and the monitored data that is monitored in real time may be stored in RAM on the master transmission station computer to thereby save on processing resources.

According to a second aspect of the present invention, there is provided transmission protocol for use in a medical monitoring system of the type which allows the medical status of a subject located in a monitoring zone to be determined, the system comprising an assessment data means remote from the monitoring zone to collate monitored medical data associated with the subject; a primary station located at the monitored zone and adapted to receive and transmit data with the assessment data means over a communications network; and at least one sensor device in data communication with the primary station, to monitor medical data associated with the subject and to transmit the data to the primary station, and wherein in use, the transmitted monitored medical data is relayed to the assessment data means and the information used to determine the subject's medical status, the transmission protocol comprising: at least one activation time slot used to establish signal transmission with the signal processor means of the primary station; and a plurality of message time slots to transmit data messages to the primary station, wherein a receiver of the protocol transmission includes a predefined codeword and an initial subset of the message time slots consist of the predefined codeword to thereby maintain synchronisation of the protocol transmission with the receiver.

According to a third aspect of the present invention, there is provided a motion detector for use in a medical monitoring system which allows the medical status of a subject located in a monitoring zone to be determined, the medical monitoring system comprising an assessment data means remote from the monitoring zone to collate monitored medical data associated with the subject; a primary station located at the monitored zone and adapted to receive and transmit data with the assessment data means over a communications network, the motion detector comprising: a three-axis accelerometer, wherein two of the axes detect inertial acceleration of the subject and one axis detects gravitational acceleration which may be used to detect the fall of a subject; and a transmitter to transmit motion data from the three-axis accelerometer to the assessment data means via the primary station.

In one embodiment, the assessment data means may further include software to detect if a subject falls from data transmitted by the motion detector according to a predefined series of events. Preferably the predefined series of events may comprise: (a) setting the initial acceleration vector of one of the axes to be aligned with the earth's gravity axis;

(b) the acceleration vector rotates towards the horizontal in a time period of about 0.5 and 1.5 seconds; and

(c) the acceleration is terminated with an impulse.

Optionally a detected fall may often be followed by the detection of a period of low or no motion.

According to a fourth aspect of the present invention, there is provided a mobile unit for use in a monitoring system of the type in which the medical status of a subject located in a monitoring zone is determined, the medical monitoring system comprising an assessment data means remote from the monitoring zone, to collate monitored medical data associated with the subject; and at least one primary station located at the monitoring zone, the primary station having signal processor means adapted to receive and transmit data with the assessment data means over a communications network, the mobile unit comprising: at least one sensor device to monitor medical data associated with the subject; data converter means to read the medical data from the at least one sensor device and convert it into a signal; a transmitter means for establishing signal communications with signal processor means of the primary station; and logic means for receiving the signal from the data converter means and for executing a protocol to be sent to the transmitter means, the protocol comprising: at least one activation time slot used to establish signal transmission with the signal processor means of the primary station; and a plurality of message time slots to transmit data messages to the primary station; wherein the signal is a radio frequency signal; or wherein the activation time slot is sub-divided into a predefined set of pseudo-noise codes (pn-codes); or wherein a first pair of the predefined set of pn-codes are used to allow the radio frequency communication means to turn on, or to switch from receive to switch mode; or wherein a second pair of the predefined set of pn-codes are used for epoch tracking; wherein the logic means further includes a synchronisation codeword to allow bit synchronisation of the protocol upon 5 transmission with the radio frequency communication means.

According to a fifth aspect of the present invention, there is provided a primary station unit for use in a monitoring system of the type in which the medical status of a subject located in a monitoring zone is determined, the medical monitoring system comprising: assessment data means remote from the monitoring zone to collate monitored medical data associated with the subject 10 and a mobile unit located in the monitoring zone; and adapted to transmit medical data obtained from a sensor connectable to the subject, the primary station comprising: signal processor means for transmitting a protocol to the mobile unit, the protocol comprising at least one activation time slot used to establish radio frequency communications with the mobile unit and a plurality of message time slots to transmit L5 data messages to the primary station upon signal communications being established with the primary station by the activation time slot; and communication network means to connect to a communications network and thereby exchange transmission of data with the assessment means.

Messages are preferably transmitted by the system using a hierarchical addressing structure. The addressing structure .0 preferably can include fields for at least one of: device identifier, mobile identifier, base station identifier, home station identifier and assessment centre identifier. Predetermined devices are preferably scanned at a rate determined by a corresponding scan table entry and scanned data values are preferably stored in a circular buffer on the primary station.

A dual element spatial diversity antenna can be used to communicate between the primary station and the at least one sensor device, with the communications switching between the elements in accordance with signal quality parameters. The

'5 sensor device can comprise a battery operated body-worn unit. The sensor device preferably can include power saving control circuitry to shut down portions of the sensor device when not in use. An epoch division multiple access protocol can be used for communication between the primary station and sensor devices and the communication between any sensor devices and the primary station can be at a rate determined by the data acquisition of the sensor device. The sensor device preferably can include an audio emission device and the system can be adapted to send prerecorded audio reminders to the emission device at

SO predetermined times.

System preferably can include means for determining if a subject can be walking from data received from the motion detector. Monitored data can be stored on the assessment data means as a SQL database. In one embodiment, the assessment data means can be interconnected to the primary station over a TCP/IP type interconnect.

In the description and claims of this specification the word "comprise" and variations of that word, such as "comprises" >5 and "comprising" are not intended to exclude other features, additives, components, integers or steps but rather, unless otherwise stated explicitly, the scope of these words should be construed broadly such that they have an inclusive meaning rather than an exclusive one. Brief description of the drawings

Notwithstanding any other forms which may fall within the scope of the present invention, preferred forms of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Fig. 1 illustrates a first embodiment of the present invention; Fig. 2 illustrates the major software components of the first embodiment;

Fig. 3 illustrates the structure of the home station software of the first embodiment;

Fig. 4 illustrates the block diagram of the SCADA software of the first embodiment;

Fig. 5 illustrates a block diagram of the radio communications system;

Fig. 6 illustrates the overall structure of the signal protocol; Fig. 7 illustrates further detail of the signal protocol;

Fig. 8 illustrates the format of a transmission slot from the mobile;

Fig. 9 illustrates a summary of the protocol for transmission from the mobile;

Fig. 10 illustrates a correlogram using an approximate correlation method;

Fig. 11 illustrates a block diagram of the receiver signal processing logic; Fig. 12 illustrates a block diagram of the mobile unit;

Fig. 14 illustrates a block diagram of the HWW mobile radio;

Fig. 15 illustrates the simulated performance of PLL for data decoding;

Fig. 16 illustrates a block diagram of the transmitter signal generator;

Fig. 17 illustrates a block diagram of the data decoder; Fig. 18 illustrates the epoch error determination process;

Fig. 19 illustrates an example of the IF signal spectrum with an aligned PN code;

Fig. 20 illustrates the scanning process;

Fig. 21 illustrates the simulation of receiver output during the epoch scanning process;

Fig. 22 illustrates a block diagram of the analog signal processing of the receiver unit; Fig. 23 illustrates the signal strength statistics for single and dual antennas;

Fig. 24 illustrates the reconstruction of the signal from the interrupt data;

Fig. 25 illustrates a block diagram of the HWW audio subsystem;

Fig. 26 illustrates an example of the measured acceleration for walking;

Fig. 27 illustrates an example structure of a second embodiment of the HWW database structure; Fig. 28 illustrates an entity relationship model for the HWW database of the second embodiment;

Fig. 29 illustrates an example structure of the HWW controller of a second embodiment; and

Fig. 30 illustrates the appearance of web-based viewer. Detailed description of the embodiments

A preferred embodiment of a medical monitoring system will now be described and is herein referred to as the "Hospital Without Walls" (HWW) monitoring system. In the particular embodiment described herein, the HWW monitoring system provides the ability to monitor the health status of individuals at locations remote from a hospital environment, and in particular in the home. However, it should be realised that the HWW monitoring system could be used elsewhere, including such places as nursing homes, retirement villages, and other quasi-health related areas such as sport medicine facilities and gymnasiums.

Referring to Fig. 1, the architecture of the software for the HWW monitoring system 10 is shown. The HWW monitoring system 10 includes a Central Data Base Computer 12 located in an Assessment Centre, a plurality of Home Stations

14 (Home Station #1 ... Home Station #4) each having a PC (not shown). System monitoring data is exchanged between the

Assessment Centre 12 and the Home Stations 14 by a packet switched communications network using TCP/IP network protocol.

An example operating system utilised on the Home station can be the Windows ^m operating system by Microsoft Corporation.

The Home Stations 14 are based on a standard PC running a Windows operating system. Each of the Home Stations 14 has a radio communications infrastructure which, referring to Home Station #3 as an example, include a plurality of Base

Stations 16 (Base Stations #3.1 ... #3.3). Each of the Base Stations 16 provides a radio communication service for a plurality of cells located throughout a patient's home. In this example, Base Station #3.2 serves cell 18 which includes Mobile Terminals

#3.2.1 ... Mobile Terminals #3.2.8.

Software for the HWW monitoring system 10 is widely distributed, from the large central data base computer of Assessment Centre 12 to the embedded processors in the mobile radios 18.

System Components and Hierarchy

Hence, the system architecture of the HWW monitoring system is based on a hierarchical arrangement of components, as shown in Fig. 1. These components, from the highest to lowest level are therefore:

Assessment Centre 12: This component provides overall control and monitoring of the HWW monitoring system. The main function is to provide an archive data facility for all the data collected by the remote Home Stations 14. The data base of the Assessment Centre 12 can be accessed via separate PC-based programs, either locally at the Assessment Centre, or remotely using Internet-type communications.

Home Stations 14: This component provides the control, monitoring and data archiving facility within the home. The

Home Station 14 also acts as a communication node to one or more Base Stations (Base Stations 16 in the case of Home Station #3), and the communications to the Assessment Centre 12. Additionally, the Home Stations 14 support the interface to a Nurse

Station (not shown), which is a portable PC temporarily connected to the Home Station, and a Technical Workstation. The Home

Station can be based on a Notebook computer or an "Industrial PC" (with no user interfaces such as keyboard or monitor).

Base Stations 16: The Base Stations 16 are a radio communications subsystem, which can communicate with up to the eight Remote Mobile Units (Mobile #3.2.1 ... Mobile #3.2.8, in the case of Base Station #3.2). Mobile Units 18: The Mobile units 18 provide a basic peripheral interface to the monitoring peripheral equipment, and has two-way radio communications with the Base Stations 16. The mobile units 18 can be either mobile (body-worn) or static for interfacing to non-mobile medical equipment. Devices 20: The Devices 20 include sensors and medical Instruments. These components are at the lowest level of the hierarchy, and provide the basic data for the monitoring of a patient. These instruments and sensors can incorporate a wide range of both medical and non-medical devices. The list of devices in this embodiment can include:

Heart Rate Monitors (body-worn) Motion Detectors (body-worn)

Blood Pressure monitor

Room motion detectors

Audio input output (body-worn)

The monitoring devices at the bottom of the tree can be accessed by devices further up the tree. The hierarchical addressing structure described above and shown in Fig. 2 is used to define a universal addressing scheme, whereby any component is uniquely identified. The scheme is based on a 32-bit address, defined as following:

Bits 0-3: Device identifier. Range 1 ... 15. Only the first four addresses are defined on the HWW monitoring system mobile.

Bits 4-7: Mobile identifier. Range 1 ... 15. Only the first eight addresses are defined on the HWW monitoring system base station.

Bits 8-13: Base Station Identifier. Range 1 ... 63. Each Home Station can (architecturally) support up to 63 base station (radios).

Bits 14-29: Home Station Identifier. Range 0 ... 65634. A hospital Assessment Centre can manager up to 65K Home Stations, which in turn can support 64 base stations. Thus the architectural limit for base stations is approximately 4 million.

Bits 30-31: Assessment Centre (hospital) identifier.

The above-defined address are used in all messages passed around the system. A node in the system thus can identify the next node in the chain. Originating messages set the addresses higher in the hierarchy to zero. Address "zero" is thus a null address. This scheme allows the receiver of a message to identify the originator, so that (if required) a reply can be generated. Software Components

An alternative view of the system is illustrated in Fig. 2, in which the main software modules of HWW monitoring system 10 are shown.

The software components can be further subdivided into two broad categories, defined as Technical Software and

Medical Software. It is preferable to separate these two areas, as the requirements of each may be different. For example, the Technical Software is concentrated in the telecommunications, networking and data base areas, which is of little interest to the medical practitioners (doctors, nurses, medical administrators). Further, the display and manipulation of the data is peculiar to the Technical and Medical software subsystems. Thus the two components are grouped as follows:

Technical Software

The components in the technical software are as follows: Home Station Supervisory Control and Data Acquisition (SCADA);

Home Station data base; Home Station networking;

Home Station workstation;

Base Station software 34;

Mobile unit software 26; Assessment Centre database 12; and

Assessment Centre communications server 14.

Medical Software.

The components in the medical software are as follows:

2.1 Nurse Station 22 (for accessing the Home Station data base). 2.2 Assessment Centre Workstation 27 (for accessing the Assessment Centre data base).

Home Station

The home station software can run on a personal computer using the Windows NT operating system. The computer provides the overall control and monitoring of the equipment in the home and data communications to the Assessment Centre 12 and a Nurse Station 22. The Base Station software 34 relays monitoring data received from mobile unit 24 software. The monitoring units monitor variables associated with a patient's health and may be either Mobile Units 26 (in the case of heart rate and motion detectors) or Static Units 28 software, in the case of medical instruments to measure blood pressure, cholesterol levels or blood sugar.

A Development and Diagnostic workstation software 25 is also located in a PC connected to the Home Station for providing a user interface for medical personnel in monitoring the patient from the example Home Station # 3.

The software is ideally modular in design utilising object oriented design techniques, so that the functionality can be enhanced over time and is designed to operate essentially in a stand-alone fashion.

The main functions of the Home Station are as follows:

- Scheduling of patient monitoring, data logging and remote data base access (eg. Via Assessment Centre database 12).

- Access to a radio base station 34, and hence the mobile terminals 26. These terminals incorporate many different sensors (depending on the application), and the data from these sensors are communicated to the Home Station by an RF link to the Base Station 34.

- Networking to external systems, such as the Assessment Centre 12 and the Nurse's Station 22. The networking utilises the TCP/IP protocol between the PCs. In the case of the Assessment Centre 12, a dialup modem is used for the physical communications, while in the case of the Nurse's Station 22, a serial cable (or alternatively a wireless e.g., infra-red link) is used.

- A Data Base for all the logged data. The logged data is an SQL-compatible data base, so that the form of the data storage can be the same in both the Home Station #3 and the Assessment Centre 12. To facilitate the upgrading of the system, all access to the data base is preferably via SQL commands. - A Technical User Interface 25. This user interface assists in the on-going technical development of the software, and provides technical operators information on the performance of the Home Station #3 software. The patient is not required to use this interface and is preferably not given access.

The Home Station #3 software is designed as a number of independent modules, which preferably operate as separate 5 tasks under the Windows NT operating system. These independent tasks are loosely coupled via the data base, with no other direct coupling between the components.

Referring now to Fig. 3, there is shown a block diagram of the Home Station #3 software structure 40. With reference to the software structure 40, these tasks are:

- An overall function Schedular 42. The Schedular 42 includes patient Motion Analysis module 44, Heart Rate L0 Analysis module 46 and a Spirometer Analysis module 48.

- Supervisory Control And Data Acquisition module (SCADA) 50 which interfaces with an Interface Library 52 which provides access to monitoring data while simultaneously providing the necessary interlocks to prevent simultaneous access to the same data by the independent modules.

- Networking Module 54, to support the TCP/IP network protocol communication layer for data communication L5 between the Home Station #3 and the Data Base 56. The Network module also providing communication support for the Home

Station #3 between the Nurse's Station 22 and the Base Station 3.1.

- Technical User Interface 58 comprising a PC to be used by technical personnel in maintaining the HWW monitoring system 10.

- SQL data base 56 associated with the Assessment Centre 12. The data base module 56 including an interface library 10 60, which shall provide easy access to the HWW monitoring system data, while simultaneously providing the necessary interlocks to prevent simultaneous access to the same data by the independent modules. For the SQL data base 56, several standard data base packages could be used such as IBM DB2, Oracle, or MYSQL

SCADA

The Supervisory Control and Data Acquisition (SCADA) 50 sub-system of the Home Stations, is illustrated in more

.5 detail in Fig. 4 and is the module responsible for the scanning of the devices attached to the mobile units 24, thus providing facilities for both logging data and outputting control commands. The software design is based on a generic core, which performs the required scan schedule from data in a "Scan List". This list specifies the devices to be scanned, the scan rate, and other functions to be performed on the logged data.

Because the Home Station includes a data base 56, the data files associated with the scanned devices are not duplicated

50 in the SCADA 50. The data logged from the monitored units 24 are preferably temporarily saved in RAM, until the data can be transferred to the data base. By using a RAM temporary buffer, the real-time scanning process is decoupled from the slow data base access process, thus minimising the problems associated with the synchronisation of the SCADA 50 data logging and the separate writing to the data base 56.

If required, the data base can be external from the Home Station # 3 computer 25, provided a TCP/IP protocol 55 communications link is available linking the computers. Thus the SCADA unit incorporates two scanning processes, one for scanning in real-time the devices attached to the mobile terminals, and a second scan of the logged data in RAM.

The basic component for the scanning process is a device, also known as a "point". Each point has a number of descriptors, which describe the type of point, its address for access (in this case by the radio), and other relevant details, as described below in the section: "Points RAM Data Base". The data describing each point is contained in an ASCII file, denoted the points configuration file 66, with one record for each point. The number of points in the file is essentially unlimited, so that the system can be configured to cater for any physical configuration of devices. The SCADA 50 can handle more than one base station (ie radio), with the number being only limited by the number of serial ports on the Home Station #3 (and the processing and I/O power of the computer). The ASCII file 5 can be created by an off-line utility program, which initially is simply a text editor. However, other embodiments may use an interactive graphics-based tool, which would create the ASCII file as an output.

When the SCADA 50 is initialised, the file is read into a RAM buffer, and a points scan list created. This scan list is then used for the scanning process described above. In the initial implementation, this scan list, and the associated points data base is static, but it would be obvious to readily provide for the dynamic changing of the points' data (such as the scan rate) by 0 an appropriate external module.

The scan list defines the points to be scanned, and the scan rate. From this information, a generic output record is generated, one for each scan request (input or output). This generic format allows the physical output to the communications system (in this case the radios) to be decoupled from the internal format details. A separate interface module translates the generic commands to the specific commands required by the specific communications hardware. For example, devices connected 5 directly to the Home Station #3 (say by a serial port), can be scanned, as well as those attached to the radios. The generic internal format of the input/output commands would be the same for both physical communications devices.

The SCADA 50 core functions provide for the automatic scanning and logging of data, so that a user interface is not necessarily required. Indeed, during normal operation, user interaction with the Home Station is not permitted. However, during development and testing (and possibly at a later stage when remote access is desirable), a user interface, such as a PC, is '0 required.

The design of SCADA 50 can be highly modular in accordance with modern Object Oriented Techniques, with data base structures, files, and communications interfaces linking the modules. Many of the modules can be set up as individual tasks (or threads), thus ensuring the high priority tasks (such as the interface to the radio) are not constrained by the low priority tasks (such as the database access).

'5 The overall modular design and associated interactions of SCADA are shown in Fig. 4. Details of the functions and operations of some of the sub-modules are described in further detail below.

Initialisation Module 64

When the SCADA 50 starts up, the first task is to initialise the generic RAM data structures which guide the operation of the real-time functions. The data are read from the Points Configuration file 66, and the data transferred to RAM tables 62. 10 The tables 62 are:

Points Table: For each point in the file, a record is created in the Points Table.

Scan List: For each point in the file, one entry is made in the Scan List.

Once these tables are set up, the communications hardware (radios) should be initialised. The "initialisation" command defined in the communications Library is used to establish the communications to each physical device connected to the Home >5 Station and referenced in the Points Configuration file 66. The file will have the address of the radio required to communicate with each point, and the associated communications port number (ie COM1, COM2, ...).

The translation of the logical address of the radio to the physical address is contained in records in the Points Configuration file 66. This record type defines all the physical addresses (port number) and port characteristics (such as serial port set up parameters), and the logical to physical port translation. The User Interface module 68 is also initialised and functions as is explained below. The SCADA 50 is then ready for normal operation, as will now be described.

Scanner Module 70

The Scanner Module 70 is the high-level module which scans the points defined in the Scan List. The Scanner module 70 is generic in character, and simply scans the points according to the Scan List data.

The Scan List is typically a 2-dimensional table, organised in Time and Points, as shown the following Table 1.

Table 1. Example of the Scan Table

The scan time is in multiples of a basic time increment, defined initially in the Points Configuration file and time increment is set to 1 second.

Table 1 shows an example of the scan table, with scan periods defined in multiples of the time increment (in this case 1, 2, 4, 6, 50). The points to be scanned at each scan period is in the columns. Thus, for example, points (P5, P8, P10) are scanned at 4 times the basic scan period (or 4 x 1.0 = 4. seconds). The entries in the table are not the point data, but merely pointer to the Points Table, which contains all the data associated with each point. Note that the physical communications channel will have a finite capacity in terms of the number of points that can be scanned in the basic scan period. For the initial implementation of the HWW monitoring system radio, a maximum of 5 points a second can be scanned using a simple random scan procedure. The scan algorithm can be summarised as follows:

The scanner loops continuously through the scan table, with a period defined by the maximum period in the table (50 in the above example). Thus the scanning process potentially has scan periods from 1 to the maximum period (50) times the basic scan period (only 1, 2, 4, 6, 50 are actually used in this example).

For each of the possible scan periods (1 ... 50 above), a check is made for possible points to be scanned. For scan period N, the points to be scanned are those that satisfy the condition (N mod Pj) = 0, where P; is the period of the "ith" column in the Scan Table. For example, if N = 4, then the points for P = 1, 2, 4 are scanned. When more than one column of points are involved in the scan, the scan order is the higher column number first (or 4, 2, 1 in the above example). The data associated with each point in the list generated by step (b) are extracted from the Points Table 62, and the Generic Scan Message generated.

The Generic Messages are passed to the Output Message Formatter module 72 which will generate the protocol messages for the transmission of the request, and the receipt of the response. The Output Message Formatter 72 is implemented as a separate task from the Scanner task, and is activated once per basic time period. The Output Message Formatter 72 is activated by the Scanner module 70, then outputs each message, waits for a response, and finally returns to a suspended state until the next request from the Scanner module 70. To avoid overload, only the first five messages are processed, with all other messages ignored.

The HWW monitoring system 10 radio communications sub-system has a point-by-point scan procedure mode. In this mode, a point scan request is transmitted, and the requested data is returned. The maximum rate of this procedure is 5 points per second. Only two points are initially required (heart rate, accelerometer), although a more complex procedure involving group broadcast messages can increase the point scan rate to 40 points per second.

Points RAM Data Base 62

The Points RAM Data Base 62 (or Points Table) is a structure which contains all the data associated with the points defined originally in the Points Configuration file 66. The data for each point have two separate types, namely static data (loaded from the Points Configuration file), and dynamic data typically associated with the scanned point data.

The static data from the Points Configuration file are as follows:

(a) Point name (text). Used for display. Maximum 8 characters

(b) Point descriptor (text). Any text to describe the point. Maximum 80 characters. (c) Point address. An address, using the standard HWW monitoring system device addressing method

(see Section 2.1.1).

(d) Update period T_p (in basic update periods). 32-bit number. Zero implies no scanning of the point.

(e) SQL data base update period T_q (in seconds). 1 byte.

(f) Algorithm name. This algorithm is executed after the logging of the scanned data is complete. (g) Data type (byte, 16-bit, 32-bit, byte array of length N, N = 1 ... 256).

(h) Circular buffer length L (L = 8 ... 256). The circular buffer should be large enough to store the real-time dynamic data between data base updates (see (e) above). Thus L > T_q / T_p The buffer also defines the size of any trend data that can be displayed on a Mimic diagram.

These data are defined in Points Configuration file 66. The dynamic data in the circular buffer can be L records of the following format:

(a) Time stamp of record. The time stamp should provide a precision of 1 millisecond, and a maximum of 30 years from (say) 1999. Suggest 48 bit number. The time stamp is the time the data is written into the Points Table, not the time of logging of the data.

(b) Record of type defined paragraph (g) above. (c) Data Base archiving flag. This flag is cleared when the data is written into the Points Table, and set when the data is archived into the data base 56. The flag is used by the Data Base Logging module to determine which data are to be archived. The data is organised as a circular buffer, with pointer indicating next record for the logging of the data. When new data is received from the Scanner module 70, the oldest data is over-written.

Because the Points Table 62 is accessed by several independent processes/tasks, access control is highly desirable. Thus a lock/unlock mechanism is required for the access to the RAM data base. When a process requires to access (read or write) the data base, a call is made to the Lock procedure. This procedure will then lock access to all other tasks, until the Unlock procedure is called. If a process calls the Lock procedure when the data base is already locked, the process is suspended, and placed in a prioritised queue. When the data base 56 is unlocked, the highest priority task will then resume, lock the data base, and then access the data. This procedure will ensure orderly access to the data.

Radio Interface Module The Scanner module 70 provides the high-level scanning process, whereby a Generic Message of the points to be scanned is placed in an input queue to the Radio Interface Module. A Generic Scan Message is independent of the protocol of the communications channel; it is the responsibility of the module to translate the Generic Message to a format suitable for the radio. The radio interface is defined by a Library 76, which allows the channel to be connected or disconnected, or data transmitted or received. The Generic Scan Messages have a standard format, with a header of 13 bytes, followed by optional data fields. The

Generic Scan Messages have the following structure:

(a) Byte 0: The length of the message in bytes.

(b) Byte 1: The type of input output operation. Type 1 is a simple half-duplex type, and is the only type supported initially. Other types (2,3, ...) may be implemented in the future. (c) Byte 2-5: 48-bit time stamp.

(d) Byte 6. The scan period (in update increments).

(e) Byte 7-10: 32-bit point address.

(f) Byte 11-12: Pointer (index) to the Point Table for this point.

(g) Byte 13-(N+12): N-12 bytes of data (for output commands only). The messages are placed in a queue, and are processed in a FIFO manner. The time stamp is the time the message was placed in the queue. If the current time has incremented by more than the scan period, the message is deemed to have expired, and is not transmitted. The point address is then examined to determine which address (and hence the port) of the base station associated with the point. The message for the radio is then formatted and the message transmitted by a call to the Radio Interface Library 76. For type 1 messages (synchronous, half-duplex), a call is made to the Radio Interface Library 76 and waiting for the reply (with timeout). The reply data is then saved in the Points Table 62, using the pointer in the original message to provide the necessary access. The timestamp of the writing of the data is also included. In some embodiments, the reply may incorporate multiple records of the scanned device; in this case multiple records are written into the Points Table.

Data Base Logging Module The Data Base Logging module has the function of regularly archiving the data in the SCADA RAM data base 62. The logging function is asynchronous with the point scanning procedure, and thus is not time critical. The RAM data base is organised as a circular buffer of records of the point data, so that the archiving process should be scheduled with a period less than the product of the point scan period by the circular buffer length (T_q < L*T_P). The parameters are preferably chosen so that L*T_p is at least 30 seconds. These parameters are defined for each point in the Points Table in the SCADA RAM data base 62. Additionally, an "archive flag" is cleared when the data is written in the Points Table, and set when the data is archived. Thus the data to be archived can be detected.

The Data Base Logging module is scheduled regularly, typically once every 5 seconds. Each point is scanned, and all 5 data not archived is written to the SQL data base 56. The access to the SQL data base 56 is via an Interface Library 60, so that details of the Data Base 56 structure are not required by the SCADA.

The RAM data base 62 lock unlock procedure should be used to access the data. As the procedure of archiving is of low priority, the use of the Lock function is important for the real-time performance. Thus the suggested procedure is to call the

LOCK procedure, then make a copy of a point data to be archived, then Unlock the data base. The copied data is then written to

L0 the SQL data base. This procedure ensures that the lock time is not affected by the access time to the SQL data base, and thus has minimal effect on the high priority Scanner module.

Mimic Display Module 68

The Mimic Display module 68 is an optional component of the SCADA 50 system, and is designed to provide a user interface to display the operation of the SCADA 50. The basic SCADA operation is designed to function without user

L5 intervention, and thus no user controls are required. However, especially during software development and maintenance, it is useful to display the data associated with operation of the SCADA 50. In particular, the point data can be displayed by the Mimic

Display module 68.

The Mimic display includes two basic components, a Static Display which mimics the equipment being monitored (in this case the home, and the patient), and a Dynamic Overlay which shows the real-time data. Object-oriented design principles £0 are used so that a particular "object" on the Mimic display can be selected, and then various operations performed on that object. These functions could be to alter the scan rate, stop the scan, or to display the data as a trend graph.

Radio Communications System

It is desirable that the radio system of the HWW monitoring system 10 should have the following characteristics:

The base station unit should be able to communicate with multiple "mobile" units.

J5 The mobile should be a small battery-powered unit, which can be interfaced to a wide range of sensors and medical monitoring equipment. For adequate medium-term operation, a battery life of about one month is desirable.

The range of the radio communications should be somewhat larger than the size of a home (and associated garden), and should operate satisfactorily indoors, or indoors-outdoors. Propagation conditions will require

50 the penetration through the inner and outer walls of a home, so that sufficient margin should be incorporated for at least three walls. This requirement is difficult to achieve with a low-powered battery device. The preferable range (through three walls) is 100 metres.

The main requirement is monitoring, so that the data flow is (largely) from the mobile. The minimal requirement should be to cater for the (Micromedical) ECG unit, which requires 2,400 bits per second. The data flow to !5 the mobile is low, and is mainly associated with "control" functions such as turning equipment on/off.

Multiple access from the base station to a number of mobiles is essential, with (potentially) the same data rate of 2,400 bits per second. The number of units should be sufficient to connect several medical instruments, as well as a number of monitor points within the home. The number of units is a compromise between the data rate, transmitter power and battery life. For applications which might include a household or possibly a nursing home, eight mobiles per base station is appropriate.

Functional Requirements

The overall concept of the HWW radio system is illustrated in Fig. 5, which shows a block diagram of the HWW Radio Communications System 100 for the HWW monitoring system 10. Fixed Terminal Unit

The following is a functional summary of the requirements for the Base Station 102:

(a) The Base Station 102 should provide the necessary communications with up to 8 mobile units eg 104, and to an external computer system 106. The communications with the mobiles units 104 are via a suitable two-way radio system. The communications with the computer are via a serial port

(RS-232). This port may communicate directly with a computer, or via a modem. Communication speeds up to say 115,200 baud is possible.

(b) The Base Station 102 operates in the 2.4 GHz ISM band. Normally, no licence is required in this radio band, but other band users could cause interference. The ISM band requires modulation based on a spread-spectrum type, either frequency hopping or direct sequence. The proposed system uses a 500 kchip per second direct-sequence spread spectrum signal to the mobile and 1 Mchip per second from the mobile. A 500 kchip per second rate is the minimum bandwidth allowable in the ISM band, and is chosen to minimise the signal processing requirements, particularly in the mobile.

(c) The transmission frequency to the mobile units 104 is in the band 2463 MHz to 2483 MHz. Transmissions to the mobile are mainly for control functions, such as turning a mobile on or off.

The mobiles "listen" to the broadcast transmissions, and if the message includes the mobile address, the command in the message is actioned. The time to send a message to each mobile (scan mode) preferably does not exceed 1 second. The data rate to the mobile is at least 800 bits per second.

(d) The transmission frequency from the mobile units 104 are in the band 2463 MHz to 2483 MHz (same as transmissions to the mobile). TDMA is preferably used for multiple access. The base station supports (logically) continuous transmissions from each mobile at 8,000 bps, or a total received transmission rate of 64,000 bps. Additionally, four TDMA time slots may be concatenated, so that transmissions of up to 32,000 can be supported from one mobile. This data rate is sufficient to support good quality voice communications. (e) The transmitter power is preferably 20 dBm (maximum allowable in ISM band).

(f) A dual-element spatial diversity antenna is used to cater for the in-door fading environment. The antenna elements are at least 1 wavelength (120 mm) apart. Vertical linear polarisation is used.

(g) Anti-interference signal processing in the Base Station DSP 102 is implemented to provide protection from interference sources. The process gain associated with the signal dispreading is at least 18 dB. Noise whitening techniques can be used to increase the interference rejection to narrowband interference sources by another 30 dB (total of 48 dB process gain).

(h) Allowable propagation loss to the mobile is at least 100 dB. The nominal propagation range is 100 metres, including losses associated with penetration through walls and other similar structures. The associated line-of-sight propagation loss is 80 dB, so that an additional 20 dB is allowed for penetration losses.

Mobile Unit 104

The following is a functional summary of the requirements for each of the mobile units 104: The mobile units are designed to be a battery operated body-worn unit. The units are designed to interface to a wide range of sensors and instruments.

The radio communications are as defined above for the Base Station 102. The transmitter power is 100 microwatts. No power control is used (except on/off).

The unit size is approximately 80 mm x 60 mm x 15 mm. The unit can be powered by two AA batteries (not included in the above size).

At the full 8,000 bps data rate, the battery life is approximately at least 28 days. This will require power cycling of the electronics. For non-continuous data transmission the battery life is proportionally shorter.

The mobile unit 104 has two analog sensor inputs, one serial (RS-232) port, and one magnetically-coupled sensor for inputs from instruments. The analog sensors are configurable as either voltage or current sensing. The inputs shall provide general-purpose interfaces to equipment. Communications data protocols can be software defined.

The mobile unit 104 supports an external audio input/output unit (microphone and speaker). The audio peripheral uses the analog input and analog output ports, but data transfer within the unit is digital. The speech unit can derive power from the main radio unit, but is normally powered off. A speech codec in the audio peripheral unit can be used to compress the speech to a digital data streams of not greater than 8 kbps. Full duplex operation is supported. The size of the audio unit is about 40 mm x 40 mm x 15 mm, including the microphone and speaker.

The antenna can be a patch antenna, approximately 20 mm x 20 mm.

Design Requirements

The overall design requirements for the HWW radio communications system 100 will now be described. The signal protocol is preferably designed to achieve the maximum possible data rate, and is not to be limited by the capabilities of the existing hardware. Thus the signal protocol may incorporate an "initial" low/medium speed option, which can be expanded in the future to higher data rates.

The modulation scheme for operation in the ISM band is based on spread spectrum (either direct sequence or frequency hopping). The preferred system is based on direct sequence modulation. Spread spectrum modulation is particularly appropriate for low powered devices, due to the interference rejection capability. In effect, the transmitter power is increased by the process gain associated with the signal processing (demodulation). The pn-code length of 63 chips provides a classical process gain of 18 dB, but additional anti-interference techniques can boost this to about 50 dB. Thus the 100 microwatts transmitter (-10 dBm) requires an interference source of about -10 + 50 = 40 dBm (or 10 watt). As the power limit in the ISM band is 200 milliwatts, the system can be largely immune to co-channel interference.

The other major design decision is associated with the multiple access scheme. The classical possibilities are Frequency Division (FDMA), Time Division (TDMA), and Code Division (CDMA) for spread-spectrum systems. An additional method, which has been developed for utilization with the preferred embodiment, is Epoch Division (EDMA); this system has aspects common to TDMA and CDMA, but with advantages overborn these methods. An analysis of the alternatives follows.

Multiple Access Design There will now be provided a discussion of a comparison between the different multiple access methods, so that the optimum solution can be obtained. Note that all systems are here assumed to operate in the ISM band from 2463 MHz to 2483 MHz, a total bandwidth of 20 MHz. The radiated power is restricted to 200 mW (ACA Radio communications Class Licence - Spread Spectrum Devices). FDMA

FDMA is a conceptually simple method for multiple access, and is in fact the most common method. However, the application of FDMA to a spread-spectrum system is not particularly appropriate, as it is very spectrally inefficient. In the case of the HWW application, the spread-spectrum bandwidth is limited by the processing power available in the mobile, so the bandwidth is assumed to be in minimum allowable of 500 kHz (FCC regulation 15.247 (2)). Thus there theoretically could be 40 ' users in the band, provided there is sufficient filtering between channels. Suitable IF filters may be feasible for about 20 users. A further practical consideration is the possibility of interference on some of the channels (due to other uses in the ISM band). Thus the effective number of useable channels may be considerably less than 20 (say 10).

The main technical problem is implementing both the communications to and from the mobile in the same 20 MHz band. This is considered technically difficult with filters which are practical (small). Thus a full duplex communications system is not desirable and an alternative solution is to use time division duplex (TDD), or a hybrid FDMA TDMA system.

Thus in summary, FDMA, could be used for the HWW radio communications from the mobile, but is spectrally inefficient. However, TDD is required for full-duplex communications to the mobile.

TDMA

TDMA is a common multiple access protocol used in modern digital radio systems. For example, TDMA is used for the GSM cellular telephone system, and the DECT system (which is an in-door equivalent system). The basic idea of time multiplexing solves the problem associated with building adequate filters (in the FDMA system), as time division provides essentially 100 percent isolation between users (they use different time slots). Further, the scheme can be used with any modulation scheme, including spread-spectrum modulation. Although TDMA with spread-spectrum modulation is spectrally inefficient, for the HWW application this is not a major problem. The main technical difficulty with TDMA is that the base station and the mobile should be accurately time synchronised. This synchronisation is complicated when, the propagation path is long (as for example in GSM), but this is not a problem with the HWW application. The basic idea is that the base station broadcasts a time-repetitive but intermittent control and timing transmission, to which all mobiles listen. When a mobile is first switched on, the mobile will perform a search in time until the signal is detected. The mobile clock is thus synchronised, so that the mobile can transmit in the time slot assigned to the particular mobile. Some loss in efficiency results from the time to switch between transmitting and receiving, but this loss can be reduced to insignificant levels if the transmissions times are much greater than the switching time.

A further advantage for the mobile case is that once time synchronisation is achieved, the mobile electronics (apart from the clock itself) can be switched off. This procedure maximises battery life.

Thus in summary, TDMA appears to be highly suited to the HWW application, with no significant implementation problems. The relatively low spectral efficiency of TDMA with spread spectrum modulation is not a problem for the HWW application.

CDMA

The classical multiple access scheme used for spread-spectrum systems is CDMA. In CDMA, all mobiles transmit simultaneously (like FDMA), but the transmissions are all in the same broad band. However, each mobile uses a different pseudo-random code for modulating the RF signal. The signals from each mobile are detected by correlating the received signal with a (known) code. Because the cross-correlation between codes is low, the output of the correlator is dominated by the signal from the wanted mobile; the signals from all other mobiles appear as random noise.

A CDMA system can be of two types, namely synchronous and asynchronous. The synchronous system assumes that the base station and all the mobiles are time synchronised, so that all the codes are aligned at the base station. As the propagation delay will in general be different for each mobile, the synchronisation process should adjust for this delay. However, in the HWW case, the propagation delay is small compared with the chip period, so that synchronisation error is negligible. With time synchronisation, the codes can be truly orthogonal over the integration period. For example, if Walsh functions are used (in addition to spreading pn-code), each symbol consists of the RF signal modulated by the (same) pn-code, and then phase modulated by a Walsh function with a period equal to the pn-code period. Finally, phase modulation of the Walsh function provides the data modulation. This relatively complicated scheme results in orthogonally between mobiles. This is important, as it relaxes the need for accurate power control (as explained below).

The complications of the synchronous method (described above) usually results in the adoption of an asynchronous design. In this case, the pn-codes are not time synchronised at the receiver (the timing is random, as determined by the clocks in each mobile). Further, each mobile uses a different pn-code to modulate the RF signal. The correlation process in the base station will extract the signal from each mobile separately. However, the pn-codes are only approximately orthogonal, so that the "cross- correlation noise" limits the number of mobiles to about the square-root of the length of the pn-code. For eight mobiles, the code length should be greater than 64 chips. However, if the received power from each mobile is not approximately equal, then the high-powered mobile will tend to jam the other mobiles. Thus an asynchronous system requires that accurate power control is achieved. This power control requires a feedback loop, whereby the base station outputs a message to the mobile to adjust the power to the correct value. As the received power can vary rapidly as the mobile moves, the feedback loop should operate quickly, typically tens of times a second. Thus the control messages can place a considerable background load on the data transmission capability of the system, reducing the capacity for the "real" data.

In conclusion, both CDMA types have considerable complications regarding the implementation. Further, the CDMA system shares the same problem as FDMA with regards to full duplex operation in the same band. In the preferred embodiment the solution is to use a hybrid TDM A/CDMA system, known hereafter as EDMA.

EDMA

The EDMA technique for multiple access was developed by the inventors to overcome some of the limitations of other multiple access techniques. EDMA provides the benefits of the CDMA system, while simultaneously having the good orthogonality properties of TDMA. Further, the data capacity of the system can be greater than both CDMA and TDMA.

The basis for the multiple access scheme is the correlation properties of the pn-code. For a maximum length sequence (m-sequence), the auto-correlation function is a triangular pulse. Further, for the HWW application, the chip period is much larger than the delay spread, so that this pulse width is not affected by multipath interference. (The pulse amplitude, however, is susceptible to Rayleigh fading). Thus the position of the pulse within the code length can be divided into "epoch slots" (analogous to time slots in TDMA). For example, a 64-chip code could be divided into 8 slots of 8 chips each. Each of the eight mobiles can be assigned a separate slot, with minimal interference between slots. The interference between slots is low (but not zero), as the m-sequence has a off-peak correlation amplitude of one (the peak is N for a code of N chips). Thus for the above example, the signal-to-interference ratio (SIR) is 64:^7 = 24 or about 27 dB. (For comparison, the equivalent CDMA SIR is only 9 dB). Note also that each epoch slot can be used for Epoch Shift Keying (ESK) modulation. In the above example, with one- chip separation, a total of 8 position (3 bits) are defined for each slot. Further, when ESK is combined with QPSK, a symbol of 5-bits can be obtained (compared with a 2-bit symbol for CDMA). Thus EDMA offers considerable advantages over CDMA. However, while EDMA is considerably better than CDMA, it does suffer from the same limitations. Thus while the

SIR is much larger at 27 dB, this margin is not sufficient to overcome the signal strength variations between the mobiles. Thus some form of power control is still desirable, albeit not as tightly controlled. Thus the overheads for the power control loop messages is less than for CDMA, but power control remains a significant implementation complication. Also, full duplex operation in the same band is not possible, again requiring a hybrid EDMA/TDMA implementation.

HWW Application Multiple Access

The previous subsections provided an overview of the types of multiple access that could be used for a radio system. The conclusion is that the most appropriate scheme for the HWW radio is TDMA. The HWW application is a little unusual in that there is not a symmetrical data transmission to and from the mobile. Thus the time slots should be roughly allocated equally for each data transmission, namely from the base station to the mobiles (one slot), and one slot for each mobile (total of eight). Thus a frame of the signal protocol will have nine time slots, repeated continuously. Further, because more sophisticated signal processing is possible in the base station, the data rate (per slot) can be higher from the mobile. Thus while the functional requirement is for data to be transmitted eight times faster from the mobile than to the mobile, the time slots can be equal in length. A further consideration in the TDMA design is the requirement to conserve battery power in the mobile. Thus the design of the protocol should allow the mobile power to be turned off as much as possible. As each mobile should be "on" during transmissions from the base station, and during its own transmission time slot, the radio is required to be on only 2/9 of the time. This concept can be approximately extended to the digital and microcontroller circuits, provided all data processing is performed in real-time. However, the RF local oscillators require (typically) about 1 millisecond to stabilise after power-on. This requirement imposes further constraints on the design of the TDMA signal protocol. In particular, the time slot should be much greater than the 1 milliseconds period, say at least 5 milliseconds. Thus if the slot is 5 milliseconds, the actual power-on period is 6 milliseconds (twice), or 12/45 = 0.266 (compared with the theoretical limit of 2/9 = 0.222). Thus this design will extend battery power by about a factor of four.

Signal Protocol This section provides details of the signal protocol for communications between the base station and the (eight) mobiles. The signal protocol design is based on the principles of multiple access and the data rate requirements described above.

The overall concept of the signal protocol is a TDMA structure of a frame, which provides one time slot for communications from the base station to the mobiles, and one slot per mobile (total eight) for communications from a mobile to the base station. A frame is exactly 63 milliseconds, and one time slot is exactly 7 milliseconds. This frame structure is repeated continually, resulting in about 15.87 frames per second. This structure is illustrated in Fig. 6.

These particular timings illustrated are related to the pn-code length (63 chips), and the chip rate used. The pn-code length was chosen to be sufficiently long to provide useful process gain, while not compromising the data rate too much. The timing figures described in the following subsections are based on a nominal pn-code period of either 50 or 100 microseconds. The actual timings may be slightly different depending on requirements. Protocol Structure for Transmissions to the Mobile

The time slot format for the transmissions to the mobile is illustrated in Fig. 7. The basic protocol is a 63-chip spread- spectrum modulation 110, with data encoded using differential phase shift keying (DPSK). The chip rate is chosen to be 630 kchips per second, so that the pn-code period is exactly 100 microseconds. The data are thus encoded with one bit per symbol 5 (pn-code), or a raw data rate of 10 kbps. However, due to the TDMA structure, the actual data rate is reduced to about 1016 bps.

The time slot of 7 milliseconds is subdivided into 70 pn-codes. The first two pn-code periods (200 microseconds) 111 are not used for data transmission, but are a guard time to allow the radio to turn on, or to switch from receive to transmit (or vice- versa) mode. The next two pn-codes 112 are used for epoch tracking and as a phase reference for the first data bit. The mobile receiver will track the correlogram at two points (leading and lagging) 113, 114, thus ensuring that the receiver clock is .0 synchronised to the incoming spread-spectrum signal. The receiver frequency is adjusted to ensure the receiver clock is synchronised to that in the base station.

The following 64 pn-code periods are used for transmission of 64 bits of data. These 64 bits are allocated as follows. The first 16 bits are used for the synchronisation codeword F134 Hex (most significant bits transmitted first). The synchronisation codeword allows the receiver to obtain bit synchronisation, by correlating with the known synchronisation ^5 codeword. The receiver will correlate a sliding window of 16 bits of received data with the known synchronisation codeword, until the peak of the correlation is detected. Once synchronisation is received, the receiver checks subsequent frames to ensure that the bit synchronisation is maintained.

The next 32 bits of data are the message component of the data block. However, the message will typically consist of a single 32-bit block, including the device ID (0 to 7), a function code (such as to turn on/off a monitoring function), and a data £0 field. Longer messages can be catered for by concatenating multiple blocks. The effective data rate (after the protocol overheads) is about 500 bps.

The last 16 bits of the data block is a CRC16 check of the 32-bit message block. This check provides high integrity in the data communications to the mobile.

The last two pn-code periods 115 are used for power down of the transmitter, and for switching from transmit to £5 receive mode (or vice-versa).

Protocol Structure for Transmissions from the Mobile

The time slot format for the transmissions from the mobile is illustrated 120 in Fig. 8. The 7 millisecond time slot is divided into guard periods 121, antenna switching periods 122, and four identical data blocks 123. There is a total of 140 pn- code periods in the slots, or 140 x 50 microseconds = 7 milliseconds.

50 The first two pn-code periods (100 microseconds) 121 are for power-on, and switching from transmit to receiver (or vice-versa). The next four pn-code periods are for the diversity antenna selection 122. During the first pn-code in this block, the base station switches to antenna element #1 to receive the data. In the next pn-code period, the antenna is switched to element #2, and the data from antenna #1 is processed to determine the received power. The received power is the product of a correlogram amplitude and a AGC signal strength reading. An FPGA performs the correlation process, while the RSSI output from the

55 receiver is used to measure the receiver power. The third pn-code period is used to measure the signal from antenna element #2. Finally, the fourth pn-code period is used to process the data from antenna element #2, thus determining the signal strength from the second element. Finally, the antenna is switched to whichever element has the strongest signal. This element is used for all the subsequent data pn-codes.

The data is transmitted in four identical blocks, each with 33 pn-codes 124. The first pn-code 125 in each block is used 10 as a phase and epoch reference for the following data pn-codes. The data encoding is a combination of 8-Epoch Shift Keying and Differential Phase Shift Keying. Thus each symbol has 4 bits, or a raw data rate of 80 kbps. However, this raw data rate is shared between eight mobiles, so the raw data rate per mobile is 10 kbps.

The principle of 8ESK PSK is illustrated in Fig. 9. The block 130 has 33 pn-codes e.g. 131. The first pn-code 132 is used as an epoch and phase reference, while the remaining 32 blocks are for data transmission. Thus each block has a total of 32 x 4 = 128 bits, or each frame has 512 bits. The general principle is that both short messages (acknowledgment of messages received from the base station), and quasi-continuous data streams can be transmitted from the mobile.

Base Station Design

The base station can be designed around three main signal processing components, namely FPGA logic, a Digital Signal Processor (DSP), and a 80186-based microcontroller. The microcontroller is responsible for formatting or decoding the data messages. For transmissions to the mobile, messages are organised into data blocks, for processing by the DSP. The DSP has few processing tasks, as the transmitter modulation can be essentially completely implemented in the FPGA logic under the control of the DSP. For data received from the mobile, the FPGA is responsible for the basic spread-spectrum demodulation (via a correlator). The in-phase and quadrature correlator outputs are processed by the DSP to decode the data. The data blocks are then passed to the microcontroller, for decoding and processing of received messages. The DSP is also responsible for receiver signal acquisition, and the tracking of the spread-spectrum signal.

The system is based on 63-chip pn-code transmission, as is the basic signal processing. However, the current chip rate is much higher at 18.432 Mchips per second. The nominal chip rate for the HWW system is 630 kchips per second for transmissions to the mobile, and 1260 kchips per second from the mobile. However, preferably the HWW system will use chip rates of 18.432 / 14 = 1.317 Mchips per second for transmissions from the mobile, and 18.432 / 28 = 658.3 kchips per second for transmissions to the mobile.

Transmitter Signal Processing

The transmitter spread-spectrum signal uses PSK. The transmitter outputs a bandlimited version of the pn-code at twice the chip rate (to satisfy the Nyquist requirement). The signal bandwidth is about twice the chip rate, or about 1.3 MHz. Because of the low data rate in the HWW system, very little DSP processing power is required.

The message software is in the microcontroller, and thus will not impact on the DSP or FPGA design.

Receiver Signal Processing

The HWW signal uses 8ESK/PSK modulation and decodes the data in all eight time-slots associated with each mobile.

The receiver data decoding can be performed entirely digitally, with most of the signal processing performed in the FPGA logic. The receiver in-phase and quadrature output signals are sampled at twice the chip rate (about 2.6 M samples per second). The dispreading process is a correlation with the known pn-code at eight different offsets (the 8ESK offsets). Thus the signal processing can be represented by the equation:

125

C_x = s_iPN^_offeθlχ (x = 0...7) (1) i=0

The above processing should be performed for both the in-phase and quadrature signals. The "offset" is that associated with each of the eight epoch shifts. However, the above processing can be considerably simplified. The multiplication can be eliminated by assuming the bandlimited pn-code is ±1 (the ideal case). Thus the correlation reduces to simply 126 additions/subtractions. The effect of this simplification is illustrated in Fig. 10, in which the correlogram is normalised by the RMS signal level in the pn-code (nominally unity for the ideal signal). The ideal autocorrelation function is triangular of amplitude unity, and a width of ±1 chip. The effect of both bandlimiting and quantising the pn-code to ±1 is that the correlation peak 135 is reduced to about 0.86 (-1.3 dB), and the off-peak noise about 30 dB below the peak correlation output. (The ideal triangular correlogram has an SNR of 201og(63) = 36 dB). However, this degraded performance is quite acceptable for decoding the data.

The receiver architecture is shown 137 in Fig. 11; the in-phase and quadrature processing are identical (only one shown). The correlator outputs to eight separate accumulators 138, selected by the offset index (0...7) 139. The correlation process takes about 50 microseconds, and results in the output 132 of eight sets of in-phase and quadrature data. These data are processed by the DSP to decode the data.

The DSP data decoding process requires separate processing for the 8ESK and the DPSK. The eight sets of data are processed to determine the largest |I| + |Q| value. The corresponding index (0..7) provides three bits of data. The DPSK data bit is determined by evaluating the dot product of the current signal vector with the last signal vector as follows:

B^ U^ + Q_nQ^ (2) where "n" is the nth symbol in a data block (n=0 is the reference signal). If B>0, then the bit is "1", otherwise the bit is "0". Thus the decoded symbol provides 4 bits of data.

The DSP organises the decoded data according to the protocol. Thus the data for each mobile is grouped for each data block and frame. The data are passed to the microcontroller for further processing. Mobile Design

This section provides details of the design of the mobile radio. This device is designed specifically for the HWW application. The overall suitable design is to make the unit as simple as possible, while still satisfying the functional requirements described above. The adopting of a simple design has a large impact on the physical size and the power consumption, so that much effort has been expended in determining a signal protocol that can be implemented with low amounts of hardware. The mobile radio unit is shown schematically in Fig. 13, will consist of four main subsystems, namely:

A radio (transmitter and receiver) 141. Due to the TDMA signal protocol adopted, the transmitter and receiver operate at the same frequency, eliminating duplication of components such as filters. Further, the In-phase/Quadrature design of the base station radio is not used. This simplification further reduces duplication, but places constraints on the type of modulation that can be used. For example, binary (rather than quadrature) phase modulation is used in the signals both transmitted and received. A microcontroller 142 provides high-level control and monitoring of the overall unit 140. The microcontroller can be a low-power processor, which operates at relatively low clock frequencies. The microcontroller is self-contained, including all necessary RAM, ROM, timer/counters, A/D converters, and digital I/O lines. The microcontroller will, however, interface to the digital signal processing unit, and other peripheral devices (including the radio itself)-

The high-speed signal processing associated with the generation of the transmitted spread-spectrum signal, and the generation of the pn-code for the reception of the spread-spectrum signal, can performed by a FPGA 13. The FPGA module is chosen for its low-power consumption, but this also limits its logic capability . Thus while the base station FPGA performs the correlation function to despread the received signal, the mobile performs this function using analog circuits in the radio. The

FPGA is also be used for the logical processing associated with interfacing to the peripheral devices (including the radio itself). To save power, this unit is powered off whenever it is possible, as the FPGA is likely to have the highest power consumption of all the subsystems.

The fourth subsystem is the peripheral interface 144 to external devices. The devices include an asynchronous serial port 145, a magnetic induction loop receiver 146, and two general purpose analog inputs 147. The general design philosophy is to provide only a physical layer interface to the external devices, with the data transmission/reception being performed in the software. This approach means that the mobile unit can be readily adapted to interface to a variety of external devices, without any modification to the hardware. More details are set out below:

Radio 141

This section defines the characteristics of the radio subsystem 141. The main design criteria for the radio is to provide functionality in a simple design, even if this results in loss of performance, or constrains the possible signal modulation. Simplifications in the design desirably both reduce the size of the radio, and minimise the power consumption. An overall schematic of the radio subsystem 141 is shown in Fig. 14.

The radio transmissions are at the upper end of the 2.4 GHz ISM band. This band has two ranges, 2400 to 2463 MHz where the allowable radiated power is 4 watts, and 2463 to 2483.5 MHz where the allowable radiated power is 200 milliwatts. For the HWW embodiment, 10 frequency channels were chosen, starting at 2464 MHz in 2 MHz steps. These are designated as channels 1..10. The transmissions from the base stations are offset by +100 kHz relative to these channel frequencies, while the transmissions from the mobile is the nominal channel frequency with no offset. The nominal frequency for single base station installations was determined to be channel 5 (or 2472 MHz). The actual frequency is within ±20 ppm of the nominal frequency.

The radio communications are not symmetrical, so that the "weak" link is the transmissions from the mobile. Thus the radio receiver can have quite poor sensitivity (noise level around 15 dB). Further, as the signal protocol uses TDMA, the transmit and receive frequencies are (essentially) the same; some components (such as the RF filter, local oscillator) can be common. A further simplification in the design is the direct modulation demodulation of the signal. In the base station, the signal is generated/decoded using in-phase/quadrature signal processing. This design requires duplication of these signal' processing components. To simplify the design of the mobile radio, a direct conversion radio is proposed. For the transmitter, the spread- spectrum is generated by direct analog mixing of the RF signal with the pn-code. Further, because of the low output power, no power amplifier is necessary, further simplifying the design. For the receiver, reduction to baseband is not possible, as there is a phase uncertainty. This phase uncertainty can cause the demodulated signal to be reduced to (near) zero, as the output demodulated signal is effectively multiplied by the sine of the phase uncertainty. The solution to this problem is to offset the base station transmissions by a small amount (100 kHz is proposed). Thus the baseband signal (after dispreading) is a 100 kHz tone, with phase modulation at the pn-code rate (10 kHz).

The exact magnitude of this frequency offset is not critical, as the data is detected by step changes in the phase of the signal. This BPSK data modulation can be decoded using a Phase Locked Loop (PLL). Both analog and digital implementation of the PLL are possible. While either design would be feasible, the analog design is likely to require less power, and so is preferred. Also in this design the PLL determines the signal amplitude. This signal is digitised .(8-bit), and input to the microcontroller. This amplitude signal is used to acquire and track the spread-spectrum signal.

Fig. 15 shows a simulation of the PLL used for data decoding. When the differential data changes state e.g. 160, the PLL error phase 161 will reach a peak about half a pn-code period after the change. By sampling the data at this point, the differential BPSK can be decoded.

The radio is under the control of the microcontroller, so that digital interfaces are required between these two subsystems. However, for many of the digital signals (pn-codes, transmit/receive control), the interface can be with the FPGA digital logic subsystem, rather than directly with the microcontroller. However, the FPGA subsystem is controlled by the microcontroller, so that radio is still indirectly controlled by the microcontroller.

Fig. 14 illustrates schematically the radio. It will be evident to those skilled in the art that the actual design may vary in some details. Transmitter Signal Processing

The transmitter signal processing generates the 8ESK/PSK baseband modulation of the spread-spectrum signal. This baseband signal phase modulates the carrier signal, as described above. This sub-section describes the method for generating the baseband modulation signal. Fig. 16 shows a block diagram of the signal generation. This circuit is implemented in the FPGA.

The baseband signal is based on the generation of a 63-chip pn-code using the shift register method. The PSK modulation is generated by simply inverting the pn-code. The eight epoch positions are generated by initialising the shift register with eight different binary patterns. These patterns are defined by three digital outputs from the microcontroller 165-167; a fourth output 168 is used for inverting the output. As the shift register 169 for a 63-chip code has six stages, the outputs 165-167can only initialise three of the six stages; the other three stages are initialised with a fixed pattern. The epoch locations should (ideally) be equally spaced, but this may not be possible when only three stages can be initialised. The details of the register initialisation for each shift are given in Table 2 below. (This implementation uses all 6 bits).

Table 2. Details of the Shift Register Initialisation for the EPSK modulation.

Table 2. Details of the Shift Register Initialisation for the EPSK modulation.

Receiver Signal Processing The receiver signal processing for the decoding of the BPSK modulated spread-spectrum signal is performed by the analog circuits within the radio. A block diagram is shown in Fig. 17. The radio receiver shall output a baseband signal offset by a nominal 100 kHz. This signal is a consequence of the despreading mixer, which can have as inputs the 100kHz received signal and the 63-chip pn-code. This pn-code is generated by a six stage shift register with feedback, similar to that shown for the transmitter. However, the register initialisation from the microcontroller is not required (each register is initialised once with a "1"). The design requires only half the RF components of a I/Q receiver, but limits the options for signal demodulation

The despread signal is a phase modulated signal 100 kHz sinewave, with a bandwidth of about 10 kHz. The signal is differentially phase modulated at the pn-code rate by the data. The data is decoded by a Phase Locked Loop (PLL) 152. The PLL detects the phase inversion as a phase error in the PLL feedback loop. This output is slightly delayed from the epoch position. The magnitude of the differential phase (it may be positive or negative) is input to a comparator (with a suitable threshold for noise), and this digital signal is input into the microcontroller 142 (gated by the epoch signal generated by the pn-code signal generator). The resulting digital signal generates an interrupt into the microcontroller which occurs every 100 microseconds during the receive TDMA time slot. The effective data rate is around 1000 bps.

The PLL 152 also outputs the amplitude of the received signal. This signal is digitised by a 8-bit D/A converter 153, which are input to the microcontroller 142. This signal provides an estimate of the received signal strength. To provide signal tracking, this pn-code signal is dithered one chip (half a chip either side of the nominal peak), as shown in Fig. 18. The epoch error (in chips) is determined from the two amplitudes "al" and "a2" by the formula (3):

ΔE = ^{1 ~ a} (chips)

2(aι + a₂ j ₍₃₎

The signal tracking loop attempts to keep the signal amplitudes equal by varying the frequency of the VCXO 155(155), and thus the location of the epoch of the local pn-code relative to the epoch of the received signal. The PLL amplitude output is also be used to acquire the signal initially.

Receiver Signal Acquisition Processing

The signal acquisition process for the spread-spectrum signal is a difficult process due to the uncertainty in the signal. In particular, the receiver should determine the TDMA timing, the epoch of the pn-code, and the frequency of the received transmissions. The later uncertainty is due to the fact that the local oscillator frequency may only be accurate to +20 ppm. Thus even though the transmitter frequency is known, the receiver should perform a systematic search for the transmission frequency about the nominal frequency. A similar search should be performed for the signal epoch and the TDMA time slot. Once the signal has been acquired, a tracking loop can be used to maintain frequency, time and epoch lock.

The radio outputs the Received Signal Strength Indicator (RSSI) from the detected power in the 100 kHz baseband bandpass filter. The baseband signal for random BPSK data is illustrated in Fig. 19. The signal is centred 201 at the nominal IF frequency, with the phase modulation resulting in a sine-squared power distribution (assuming the pn-codes are aligned). The nulls 202 in the sine function are separated by 1 Ts = 10 kHz, where Ts is the symbol period of 100 microseconds. By averaging the output power, the effect of the data phase modulation is typically be small, say a few percent. Also 90 percent of the signal energy is within the first lobe of the spectrum. The acquisition process is thus to detect output power from the IF bandpass filter. In the preferred embodiment a moving average of the detected power is used, with four samples averaged, and the sample rate equal to twice the symbol period, or 20,000 samples per second.

The details of the scanning process are as follows:

The frequency inaccuracy is +20 ppm, or about ±50 kHz. The baseband receiver bandwidth is 10 kHz, so that a frequency step of 5 kHz is appropriate. This implies 20 frequency steps (maximum). The pn-code has 63 chips. For higher certainty, the pn-code should be stepped in 0.5 chip increments. Thus 126 steps is required to search through the complete pn- code.

The TDMA structure has nine time slots of 7 milliseconds, but the base station transmits in only one of these slots.

Thus the receiver should search (potentially) through all nine slots to detect the signal. As the receiver will not be time synchronised, there is two 7-millisecond receiver time slots that overlap the transmitter time slot, and one of these nine receiver slots will overlap by at least half a transmitter slot period. In this overlap period, the receiver should search for the pn-code by progressively scanning the pn-code epoch.

The epoch scanning process described above is illustrated in Fig. 20. The suggested scan rate is 2 pn-code periods for each half-chip step. As the slot has 70 pn-code periods, one slot scan will result in scanning about 32 steps (ignoring the power down and power up periods. Thus a total of a maximum of eight repetitions per time slot should be performed, in order to detect the signal in a particular slot; this will take about 0.5 seconds, as there are about 16 base station transmissions per second. As shown in the diagram, the epoch is scanned twice, once up 210 and once down 211. This procedure ensures that the signal epoch is located, regardless of the size and location of the noise/signal section in the scan period. Further, up to nine slots will have to be checked, so that a complete scan will take about 9 x 0.5 = 4.5 seconds. With 20 frequency steps, the search time is 20 x 4.5 = 90 seconds maximum, or 45 seconds on average.

A simulated scan is shown in Fig. 21. The receiver output shows a distinct peak 221 when then signal and local pn- codes are aligned. The expected peak to RMS correlation noise ratio is about 7:1, based on the ratio of the spread-spectrum signal bandwidth and the filter bandwidth. The peak of the noise will, however, reduce this ratio to about 3 : 1.

Once the approximate frequency and epoch positions are determined, the tracking loop will accurately track the frequency to about 0.2 ppm (about 500 Hz), and the epoch to 0.1 chips (0.2 microseconds). As the timing and frequency is accurately tracked in the mobile, no corresponding search is required in the base station. The only uncertainty in the base station is the effect of the varying range (up to 100 metres). Thus the propagation delay (round-trip) is in the range of 0 to 0.6 microseconds (or ±300 ns); This compares with about 700 ns chip period for the transmissions from the mobile.

Base Station Diversity Antenna

The HWW radio will most likely operate in an in-door environment, where line-of-sight propagation conditions generally will not exist. Because of the scattering of the signal, severe signal fades will occur. The radio performance should make allowances for the statistics of these signal fades. As a design goal, the radio 15 is designed to operate at the maximum range 95 percent of the time.

For a severe scattering environment, the received signal strength will exhibit Rayleigh fading statistics. In this case, the probability that the signal strength is greater or equal to signal "s" is given by: s²

P(signal < s) = 1 - e ^2cj2

Mean = J— σ

V 2 ₍4)

As shown in Fig. 23, at the 95 percent probability, the fade margin required is 10 dB. Thus for a single base station antenna, the mobile transmitter should transmit 10 dB more power than calculated using the mean signal strength. This design is not desirable, as it would severely reduce the battery life. If the transmitter power is not increased, the range is greatly reduced.

To minimise the effect of signal fading, dual base station antennas are utilised. If the antenna elements have at least one wavelength separation, then the received signal strengths is statistically independent. In this case, the probability that at least one antenna element will receive an adequate signal is given by:

P2(signal > s) = 2X - X²

-s² X = Θ ^2(J2 (5)

From Fig. 24, it can be observed that the fade margin for 95 percent probability is reduced from 10 dB to 3 dB, thereby leading to improved operational capabilities.

The use of the diversity antenna is as follows. For transmissions from the base station, the signals are "broadcast" to all the mobiles. The optimum antenna element for each mobile will (in general) be different, and thus in a broadcast mode the dual- diversity antenna cannot be used. Thus in broadcast mode, a fade margin of 10 dB is assumed. However, because of the relatively large transmitter power (compared with that of the mobile transmitter), the signal strength (even in a fade) is adequate. When the base station is attempting to communicate to just one mobile, diversity can be used to improve performance. If the attempt to communicate with a particular mobile fails after three attempts, the communications is transferred to the alternate antenna. If communications also fails with this antenna element, then communications with that mobile will fail.

For communications from the mobile to the base station, a dual-diversity receive antennas are used. Thus for each transmission, as noted previously a preamble of 4 pn-codes is used by the base station receiver to check the signal strength as received by each antenna. The antenna element with the strongest signal is used for the complete frame (7 milliseconds). As the fading will only occur if the mobile moves more than (say) a quarter of a wavelength (about 3 centimetres), the signal strength is approximately constant throughout the frame period, provided the mobile speed is less than 0.03 / 0/007 = 4.3 m/s. This condition is most often met, as walking speed are about 1 m/s.

Battery Life

The design goal for the mobile terminal is to operate for a period of up to 28 days on two AA batteries. The estimation of the battery life are on the basis of continuous transmissions from the mobile terminal in one time slot, and receiving commands from the base station in a second time slot (or a total of two slots on out of nine slots). The hardware is assumed to be off in all other time slots, except for the crystal oscillator which is required to provide continuous time (for activation of the radio at the appropriate times). The radio subsection consists of three main sub-sections, namely the receiver, the transmitter, and the RF oscillator. The transmitter and receiver are active for only one slot in nine, or about 12.5 percent of the time allowing some time for initiation after power down. The RF oscillator is on for about two slots, or about 25 percent of the time. The microcontroller is required to be on for an additional time to either prepare the data for transmission, or process the data just received. Thus the microcontroller should be on for more than 25 percent of the time; if time equivalent to two extra slots is allocated, the microcontroller is required to be on for about 50 percent of the time. At all other times, the electronics can be powered down, thus extending the battery life. A further consideration is the time required to input the data from external peripheral devices. For these estimates, it is assumed that the inputs are interrupt driven, so that the processor can be in a powered-down status while waiting for inputs from peripheral devices. Thus while it is assumed that the peripheral interface hardware is powered on, the microcontroller is powered on only for a period of the interrupt service routine. As this period will typically be small, the 50 percent estimate for power-on time for the microcontroller appears satisfactory.

:5 The electronics is designed to operate at 3 volts. One design is to use one 1.5 V AA (alkaline) battery, with a switching regulator used to generate the required 3 V for the electronics. The capacity of a AA alkaline battery is about 2.5 Amp-hours, or 3.75 WH (13,500 joules). For a battery life of 28 days, it is assumed that two AA batteries are required, while one battery will provide 14 days. Thus the corresponding available energies are 27,000 Joules and 13,500 Joules respectively. The energy should be split between the four mobile terminal subsystems, namely the microcontroller, the FPGA digital logic, the radio, and the peripheral interface. The following table 3 summarises estimates of the power requirements.

Table 3 Estimation of the power and energy requirements for each subsystem.

The above table shows that the energy requirements for 28 day operation is estimated at about 67,000 Joules, so that the battery life is 5.5 days with one AA battery, and 11 days with two AA batteries. Thus the initial design cannot meet the desirable 28 day requirement. From Table 3, it can be observed that two components use the majority of the power. The FPGA consumes 18,000 Joules (27 percent) of the energy, and the RF oscillator 30,000 Joules (45 percent) of the energy.

The above estimates for the RF oscillator are based on readily available off-the-shelf components, with no attempt made to minimise the power. The power requirement could be reduced from 50 mW to 30 mW by the use of a more expensive VCO. If a customised VCO was built, the power could be reduced further to an estimated 20 mW. The frequency synthesiser power consumption also could be further reduced, so that with improved fabrication technology 15 mW may be possible in 1-2 years time frame. This figure would reduced the RF oscillator energy requirements (for 28 days) to 9,000 Joules. The reduction in the power consumption of the FPGA appears to be more difficult, as currently the lowest available power version is being used in the design.

Based on the above estimates for reduced power consumption, the energy requirements for 28 days operation can be reduced from 67,000 Joules to 46,000 Joules. The corresponding times for a single AA battery is 8 days, and 16 days for a dual AA battery version. It is thus suggested that the performance requirements are reduced to 7 days on a single AA battery, and 14 days on dual AA batteries. Obviously in coming years as lower powered versions become available, these components could be used.

The above estimates are based on "continuous" operation of the data channel, but the initial requirements (for heart rate monitor and accelerometer data) will not require the full capacity of the radio channel. In particular, the accelerometer data requires about one message per second, and the heart rate monitor about one message every five seconds. In this mode, the radio buffers the data between messages, so that no data is lost by reducing the message rate. As the communications protocol has about 16 frames per second, the above message strategy reduces the communications rate by a factor of 16 for the accelerometer and by a factor of 80 for the heart rate. As the radio can be powered off while not in use, big increases in battery life can be achieved. Because of the lower message rates, and the consequence reduction in battery capacity, it is therefore possible that the radio can optionally use much smaller batteries, while still meeting the 28 day life time of the battery. Further, the size of the battery can be reduced considerably, thus reducing the overall size of the radio. The preferred battery is a nickel metal hydride rechargeable battery, with the following characteristics:

Size: 49 mm x 15 mm x 8 mm. Voltage: 1.2 V

Capacity: 750 mA H = 3200 Joules.

Charge cycles: 500.

The battery is mounted on its side, so that the footprint is only 8 mm wide, and 15 mm in height. This orientation results in minimal increase in the size of the overall radio, with the minimum height of 15 mm and minimum length of 50 mm. From Table 3, the energy requirement per day is about 2,400 Joules. Thus the above battery would last about 30 hours if the radio link operated at full capacity. With a duty cycle of 16:1, the battery life is about 20 days. For a AA battery, the corresponding battery life is 112 days (4 months).

Peripheral Equipment This section defines the characteristics of the peripheral devices associated with the HWW radio. The general concept is that the radio incorporates only the basic communications infrastructure and peripheral interfaces, while the specific peripherals are external to the radio. This architecture means that the system can be configured in many different modes according to the application. Thus the radio hardware is as simple as possible, avoiding the incorporation of features which are only used infrequently. This design decision means that the radio is as small as possible, and consumes minimal power.

Returning to Fig. 12, the peripheral devices which are expected to be used in the initial HWW monitoring system 10 are as follows:

(a) Serial Interface (RS-232) 145. This interface is used to interface to external medical and other monitoring devices. These devices would not normally be body-worn. The particular signal protocol to drive the device would be in the application in the Home Station rather than the radio.

The radio can be considered as an extension of the serial port of the computer.

(b) Generic Analog Interface 147. This interface will provide a general capability to access analog inputs, or output analog signals. The interface in the radio converts the analog data to/from digital data for the transmission over the radio. The radio shall support two such interfaces, thus (potentially) providing two-way communications to an external device.

(c) Magnetic Coupled Interface 147. This interface is designed to allow easy access to body-worn devices, such as heart rate monitors. The initial design is base on the Polar heart rate monitor. Only inputs are supported. The expected range is up to one metre.

(d) Audio Subsystem Design 148. This subsystem can allow audio communications between the Home Station (or Assessment Centre) and the patient wearing the mobile radio. The audio subsystem can interface to the radio via the generic analog interface (see paragraph (b) above).

(e) Motion Detector 149. The motion detector provides information on the motion of the patient, based on a 3-axis accelerometer. The motion detector can interface to the radio via the general-purpose analog interface (operating in a digital mode). Serial Interface (145)

The serial interface is designed to interface to a wide range of peripheral devices. The typical requirement is to interface to medical equipment at a fixed location (that is not body-worn), but the design allows for interfacing to body-worn equipment. The serial interface supports data rates up to 9,600 baud.

The most common physical layer interface for serial data communications is RS-232. This standard presents some implementation difficulties for the HWW radio, as the basic DC voltage in the radio is +3 V, while RS-232 requires ± 12 V. The microcontroller will have a UART capable of encoding/decoding the serial data, but the output will not be compatible with the RS-232 standard voltages.

Thus the design provides for flexibility, while not imposing additional complexity on the radio. For body-worn devices, the physical layer is based on voltages of approximately 0 V and 3 V for the serial binary data. For other devices which require a RS-232 interface, the above voltages are converted to the required RS-232 voltages by an external circuit. This circuit will obtain power from the external device, rather than the HWW Radio. Thus the radio does not require circuits to generate the RS-232 voltages. In typical implementations, the RS-232 voltage conversion circuit is incorporated into the connecting cable.

Generic Analog Interface (147) The generic analog interface provides general-purpose facilities for the input and output of analog data. The interface is flexible in allowing either inputs or outputs on each to the two lines. Further, these may be configured as ether current-driven or voltage driven. These interface options can be selected by appropriate jumpers on the radio printed circuit board.

The analog I O shall interface with the microcontroller via D/A and A D 8-bit converters. The voltage range is at least 0 V to 3 V. Multiplexers are used to provide the necessary outputs/inputs to the two ports. The maximum data rate required to any port is 1,000 samples per second. However, the ports are capable of operating in a quasi-digital mode of 8000 samples per second; in this mode, the input/output is treated as digital data, so that the effective data rate is 8,000 bps. The microcontroller

(software) shall control the multiplexers and the data formatting.

Magnetic Coupled Interface (146) This subsection defines the requirements for an interface to the radio based on magnetic induction coupling. The reason for using magnetic coupling is that wire coupling for body-worn monitors (such as a heart rate monitor) typically use this form of output due to the inconvenience of wires. The interface provides low data rate (around 10 bps) outputs at a range of up to 1 metre.

The particular design is based on the Polar heart rate monitor. However, the signal decoding is mainly in software, so that the interface can be adapted to different signal protocols.

The receiver signal processing to determine the heart rate is based on performing a correlation with the known signal signature. To simplify the signal processing, it is proposed that the analog signal processing merely detects the "zero crossing" (relative to a threshold). Fig. 22 shows a block diagram of the detection hardware.

The detection circuit is based around an automatic gain control function. As the signal is only present for at most 1 percent of the time, the AGC circuit sets the output level to that associated with the background noise. Further, as the time constant of the AGC circuit 233 is set to be much longer than the signal period, this level is largely unaffected by the presence of the signal. The AGC sets the signal output level to about one tenth the amplifier maximum. When the signal is present, the amplifier 232 may saturate, but this is of no consequence as the output signal is based on zero crossing detection. Both the positive and negative zero crossings are detected, with a threshold set to a third of the amplifier peak level. This level has been found sufficient to reject virtually all of the noise signal, and requires a SNR of about 10 dB for detection of the signal. The zero crossing logic interrupts the microcontroller, which shall record the time (and type) of the interrupt. These interrupt data are used in the correlation signal processing.

Referring simultaneously to Fig. 22 and Fig. 24 which shows an example simulation, the proposed signal processing is as follows: (a) When a positive or negative zero crossing 240 is detected by the analog hardware 230 within the peripheral interface 144, an interrupt is generated into the microcontroller; this will occur about every 100 microseconds when the signal is present (less than 1 percent of the time), so that the overall interrupt processing load is low.

(b) An Interrupt Service Routine in the microcontroller 142 records the time of the interrupt, using a 16-bit timer-counter clocked at 40 kHz. This counter wraps after about 1.6 seconds, which is longer than the maximum time between heart beats.

(c) After a maximum period of 4 milliseconds, the correlation commences after the first interrupt. This consists of reconstructing a square wave version eg. 241 of the signal 240, including a zero signal when no data is received. This reconstructed signal 241 is then used to perform a correlation with the known signal signature. The SNR in this example is about 2 dB before the bandpass filter 231. The signal in Fig. 24 is shown after the filter.

The output signal 241 is tri-state (-1, 0, +1), so that the correlation does not involve any multiplications. This simplification greatly reduces the processing load in a microcontroller. The maximum correlation possible is 42, but a correlation 5 of at least 28 is acceptable. Random noise will result in a expected correlation of zero, with a standard deviation of 7. Thus if the threshold is set at (say) 28, the noise correlation is at the four standard deviations level. Statistically this will only occur about 0.0062 percent of the time. As the signal is present at most 1 percent of the time, the probability of false detection is about 0.62 percent. However, to minimise the signal processing required, a threshold level is set so that no interrupts occur if the magnitude of the signal is less than the threshold. If the threshold is set at 0.3 times the saturation amplitude, the simulation shows that the 10 signal can be reliably detected with an SNR of about 2 dB. There is a loss of about 2 dB in the signal power due to the exponential attenuation of the signal in the first 3 cycles, and the suppression of the seventh half cycle.

The time difference between consecutive detection of the signature will provide the period between heart beats. The heart rate can be simply calculated from these data.

Audio Subsystem (148 of Fig. 12)

15 The audio subsystem provides the ability to send and receive audio using the HWW radio and an external audio peripheral unit. This subsection provides suitable design details of both the external module and the signal protocols associated with the transmission of the audio data.

General Characteristics

The audio subsystem 148 is an optional external unit which provides the capability to send and receive audio signals 20 using the HWW mobile radio. The intention of the audio subsystem is to provide emergency voice communications with the person wearing the mobile radio. For privacy reasons, the transmissions from the mobile can only be activated by the person, but transmissions to the mobile may be activated remotely. The audio mode is activated by a on/off push button on the audio unit, or possibly via a magnetically-coupled "panic" button. The activation of the audio mode will automatically cause a dialup to the Assessment Centre, so that a conversation can be had with staff at the centre. The operation is essentially the same as a mobile 25 phone, but the sensitivity of the microphone and the audio output of the speaker is such that hand-held operation will not be necessary. In general, it is expected that the radio and the audio unit is attached to a belt around the waist.

Turning to Fig. 25, there is illustrated schematically the audio subsystem 25. Because of the size of the audio subsystem, the integration into the radio enclosure is not required, as in most applications the audio unit will not be required. The audio unit is thus be considered as one of many possible peripheral attachment for the HWW radio. The audio unit uses the two

30 general purpose I/O ports of the radio 250, 251 for the transfer of audio data. This data is in a compressed digital format, with a maximum data rate of 8,000 bps. Full duplex operation is supported so that "press to talk" is not required. The audio unit can receive power from the main radio, so that the audio unit does not require a separate battery. The power requirement is considerable, particularly for the audio output (up to 1 watt). However, normally the audio unit is powered off, so that the 28 day battery life will not be greatly affected. The reduction of the battery lifetime is minimal for most applications. For example, 30

35 minutes operation will result in about a 10 percent reduction in the battery life (28 days to 25 days).

While the main functional use is for a "panic" situation, the audio output can be used to provide feedback for the patient, and to remind the patient to perform regular tasks. For example, there may be a requirement to perform a regular medical-related measurement (such as blood pressure). These audio prompts could be programmed automatically into the Home

Station computer. When the operation has been successfully completed (or if there is a problem), appropriate messages can be

+0 output to the audio module. External Audio Unit

The external audio unit is designed as a peripheral unit of the HWW radio. The main functions of the unit are twofold. The input functions are to receive from the microphone 252 the audio signal, amplify the signal 254, convert to digital format 255, compress the data 256 to a data rate not exceeding 8,000 bps, and finally to output 251 the digital data to the radio 140. The 5 output functions are to receive the compressed audio digital data (up to 8,000 bps) from the radio 250, decompress the data 256, convert the data to an analog signal 257, amplify the analog audio signal to about 1 watt 258, and output the signal to the speaker 253. Thus the external audio unit has both analog and digital signal processing functions.

The audio unit has two operator controls, namely the power on/off push button 259 and a volume control (thumbwheel) 260. The on/off button is effectively the only control to be used to activate a conversation, and thus this on/off state 0 should be detectable by the radio (so that the necessary signal protocols can be activated). The volume control will allow an audio output of up to 1 watt. No manual control is required for the audio input; the audio input amplifier shall incorporate an automatic gain control, with squelch action for low input signals (when no speech is detectable).

An important feature of the HWW environment is data compression. Typical audio (telephony quality) will result in 64,000 bps data rate, which should be compressed by an audio codec. The compression can be an ITU standard, either G.723 5 (preferred) or G.729. The G.723 standard results in either 5,300 or 6,300 bps compressed voice data rate, while G.729 results in 8,000 bps data rate; G.729 has somewhat better audio quality.

In the preferred embodiment, the audio unit will not exceed 40 mm x 40 mm x 15 mm in size, including an internal microphone and speaker. Provision are made also for connections to an external microphone and speaker. Power for the audio unit can be from the radio, but a jack for external power can be included.

'0 Transmission Protocols

The signal protocols described above are basically the same for audio transmission. The slot structure allows transmissions from up to eight mobiles at a data rate of 8,000 bps for each mobile. This data rate is compatible with that described above. Thus the radio system is capable of receiving audio from up to eight mobiles simultaneously. However, the average data rate supported for transmissions from the base station to the mobile is only about 1000 bps. As described above, the '5 data rate per slot is 9,142 bps, so that the data rates associated with audio signals can be transmitted, provided multiple slots are used. If the G.723 standard at 5,300 bps is used, then six slots are required. As a frame has nine slots, the allocation could be as follows:

(a) Slot 1: Control slot (same as used in the "normal" operating mode).

(b) Slot 2: Reserved for communications with other mobiles, other than the mobile with audio.

>0 ( (cc)) S Slloott 33:: Audio communications from the mobile (8,000 bps).

( ) Slots 4-9: Audio communications at 5,300 bps to the mobile.

Thus full duplex audio can be established with the mobile, while simultaneously maintaining communications (albeit at lower data rates) with the other seven mobiles.

Typically the mode of operation is as follows. When the patient presses the activation button, a "request audio"

>5 message is received at the base station (and Home Station). The link protocol will then be changed to the audio mode described above. The Home Station establishes communications with the Assessment Centre, so that a (digital) audio channel is established between the patient and the operator at the Assessment Centre. Two-way conversations (similar to that associated with a mobile phone) can then take place. When the conversation is complete, the audio link is terminated by the patient again pressing the activation button. Note that the patient (rather than the operator at the Assessment Centre) is in control of the audio mode, thus ensuring privacy.

Interaction with Home Station and Assessment Centre

The HWW audio subsystem main function is to provide emergency audio communications between the patient wearing

5 the HWW mobile and the operators at the Assessment Centre. The operation is thus similar to a mobile phone with direct connection to the Assessment Centre. Because of the potential of invasion of privacy with such technology, the system design should ensure that control of the audio input to the Assessment Centre is with the patient, even though the technology could be used as a remote listening device.

When the patient activates the audio subsystem, the main functions of the Home Station are to control the 0 communications protocol to the mobiles, and to establish communications with the Assessment Centre. Because the data capacity of the link to the mobile is comparatively low, the communications protocol should be changed to allow full-duplex voice communications. When the patient presses the on/off button on the audio unit, the radio will detect this activation, and send an appropriate message to the Home Station. An automatic confirmation procedure can be activated, involving the output of "canned" messages to the mobile. If the audio subsystem activation is genuine, the Home Station will initiate the connection to 5 the Assessment Centre (usually via a dialup modem). The progress of this procedure could be indicated to the patient by appropriate audio messages sent to the mobile. Once the communications is established with the Assessment Centre, an alarm is raised within the Assessment Centre, alerting the operator. The operator and the patient can then conduct a conversation, essentially identical with a telephone conversation.

The data associated with the audio subsystem is in compressed form and complies with the ITU standard H.723. The '0 data rate required is less than 8,000 bps, so that modem communications data rates are more than adequate. A H.723 software codec is readily available for PCs, and can be installed in the Assessment Centre computer which is responsible for the voice data compression and decompression at the Assessment Centre. The Home Station merely passes the data transparently through to the Assessment Centre; there is no need for any codec functionality in the Home Station. However, some functions local to the Home Station may require the output of "canned" messages to the mobile. Again, the codec functions can be performed by '5 software within the Home Station PC.

Motion Detector 149

The motion detector subsystem 149 of Fig. 12 is designed to monitor the motion of the patient. However, in the preferred embodiment, the subsystem is not intended to provide detailed information on the position of the patient; rather the typical applications of the motion detection are twofold. Firstly, there is considerable clinical benefit in simply knowing how i0 much activity an (elderly) patient has during the day. The motion detector should be able to distinguish activities such as walking, resting, and sleeping, and thus an application program can provide useful information on the types of activities over an extended period. The second main area of interest is associated with the detection of falls, and its correlation with other monitored parameters such as heart rate. Further, from the type and direction (forward, backwards, sidewards) of fall, possible causes can be inferred.

>5 The basic technology associated with the motion detector is a 3-axis accelerometer. The three axes are required to detect all possible motions from the acceleration components. A particularly suitable device is an Analog Devices type ADXL202, which provides two axes of inertial acceleration; thus two of these devices (one flush with the printed circuit board, one perpendicular) are required.

The accelerometer provides true inertial outputs, that is it can detect both gravitational and motion acceleration(but not 1-0 distinguish between them). Thus the outputs can be used to determine the angle of the device relative to the earth's gravitational field if the wearer is not moving. This function is particularly important for the analysis of falls. The device can also detect the acceleration associated with movement. This feature can be used to detect particular motions such as walking, and even the step rate. All these features can be functions of the analysis package in the Home Station, rather than the motion detector itself.

The actual hardware can be configured two ways. The first method provides for a separate unit from the radio, with an interface to the radio by two of the analog inputs. The power (3.3 V) can be derived from the radio. The analog output is converted to digital by the radio. The second design provides for direct integration of the accelerometers into the radio itself. Because of the small size of the accelerometer, there is very little penalty in this integrated approach.

Motion Detector Design

The detailed design of the Motion Detector will depend on such aspects as the desired data rate, measurement sensitivity, power consumption, and the calibration of the measurements. The particular design of a suitable embodiment is based on the ADXL202.

The ADXL202 accelerometer has a range of ±2 g. The output is in the form of a square wave of period T2, and measurement period TI. For a nominal 0 g reading the T1/T2 duty cycle is 50 percent. However, there is considerable variability in the value, so that it may be in the range 25 % to 75 %. The nominal measurement sensitivity is 12.5 % per g, but this may vary in the range of 10 % to 15 %. Thus the basic output will have a wide range of variability between units, and this should be considered in the design. One approach is to calibrate each unit separately, but a more practical approach is to have the application software perform this calibration function. Note that while there is considerable variability between accelerometers, each unit is very stable at the calibrated value. The main source of variability is due to temperature, which is about 0.5 % per degree C. The ADXL202 output noise depends on the output bandwidth, which in turn depends on the sampling rate. While high sampling rates can be achieved, the power consumption is likely to be too high for the HWW application of the preferred embodiment. The sensitivity of the measurement should be such that the small variations in the measured lg acceleration during walking can be detected.

It is estimated that during walking the measured acceleration is l±O.l g. This signal is preferably measured at least 10 times per second for adequate interpretation of the signal. Further, the measured SNR should be at least 20 dB, so that the measurement noise should not exceed 0.01 g. With this sensitivity the data output are in the range 0-400 (9 bits). As an 8-bit output is desirable, it is suggested that the peak acceleration is limited to ±1.28 g with a sensitivity of 0.01 g.

The design notes for the ADXL202 device indicates that the RMS noise is given by:

N = 500V1.5BW μg/VHz (6) Applying equation (6) with N = 10 mg gives BW = 267 Hz, or T2 = 3.75 milliseconds. Thus T2 can be set to about 4 milliseconds, or 250 samples per second.

As noted previously the HWW radio is required to operate at very low power levels, with a budget for all the peripheral devices of 3 milliwatt (see Table 3). The power consumption for the ADXL202 is 1.8 mW, so that the total for the two devices is about 3.5 mW. As a design goal, the power consumption should not exceed 0.5 mW. Thus power cycling is required. The power cycling is affected by the time to power-on the devices, and this in turn is affected by the filter time constant. The device application note shows that the 99 % turn-on time is given by:

Ton = -^ + 0.3 (ms) (2) With the sample rate of 250 samples per second, the turn-on time is 3.5 ms, or about one cycle of the sampling waveform. If (say) three cycles are used (the first for power-on, two for measurement), then the turn-on period is 12 ms. As the data rate is 10 per second, the power-on duty cycle is 12:100 or 12 percent. Thus the power consumption is about 0.4 mW, which satisfies the above-defined requirement of less than 0.5 mW. Thus the accelerometers are turned on for 12ms very 100 ms, and the periods TI and T2 measured. It is suggested that the second cycle (after power on) is used to measure TI, and the third cycle to measure T2; the ratio of these two times is a measure of the acceleration. These time periods are measured by a timer/counter in the FPGA. The nominal value of T2 is 4 milliseconds, and TI will range from about 0.3 ms to 3.6 ms. If the scaling is set to 400 for 4 ms (100 kHz clock), then the precision of the measurement is about 2.5 mg (measurement noise is estimated at 10 mg above). The timer/counter should be 10 bits to allow for some variation in the nominal values. The output data is two 8-bit numbers, scaled to 1-bit per 10 mg.

Motion Detector Signal Processing

This subsection provides an overview of the signal processing associated with the motion detector. The fundamental measurements by the radio interface are of the time periods TI and T2. The DSP converts these measurements to a ratio, and scales the data into one byte for each axis. As there are two accelerometers, and the data rate is 10 per second, the sensor data rate is 40 bytes per second, or 320 bps. This raw data rate is well below the maximum capability of transmission of 8,000 bps by the radio. The sensitivity of the data measurement is 10 mg, and the range is ±1.28 g. The raw data forms the input to the signal processing algorithms. Note that only three orthogonal sets of data are required, so that there is some redundancy in the raw data. This redundancy will provide some checks on the calibration process, and hence the reliability of the measurement.

The signal processing is designed to detect different types of movement. The input data is processed to detect walking, resting (seated), lying down, and falls. An outline of the signal processing for each of these are given in the following subsections. The signal processing is further complicated by the variability in the calibration between accelerometer units. One approach is to calibrate each unit during manufacture, but an alternate approach is to perform this calibration within the application program itself.

Calibration The ADXL202 accelerometers are a cheap and convenient package for the measurement of inertial acceleration, but this device suffers from the need to calibrate each unit individually. The simplest approach is to calibrate each unit during manufacture, but an alternative approach is to calibrate within the application program itself.

The ADXL202 have two parameters to be calibrated. The first parameter (pO) is the O g T1/T2 ratio, which is nominally 50 percent but may range from 25 to 75 percent. The second parameter (K) is the acceleration scaling factor, which is nominally 12.5 percent per g, but can range from 10 to 15 percent. These calibration parameters vary from unit to unit, but are largely invariant over time. However, the parameters do vary by about 0.5 percent per degree C; however for a body-worn device, this variability is not of much concern. Thus the equation for the acceleration (α) is given by: α = K(p - p₀) (7)

The basis for the application program calibration is the known one-g of the earth's gravity, as well as its orientation. Thus it is possible to continually monitor the raw input data to provide updated calibration data. The orientation of the unit is another variable that is desirable to consider in the calibration process. In the preferred embodiment, the radio unit is normally worn on a belt, which will define the gravity vector. However, the design should allow for the unit to be worn in any orientation.

The two accelerometers provide two orthogonal measurements of acceleration. Further, the normal orientation is such that the outputs are for the (x, z) axes for one and the (y, z) for the other (z being the g-vector direction). Thus the normal outputs (in a standing or sitting orientation) for the z outputs should both read 1 g, while the other two outputs should read 0 g. While there may be some variability due to movement, when averaged over time it would be expected that the z outputs will average 1 g. Similarly, the quadrature accelerometer will have a zero output when the z outputs are 1 g.

Thus the calibration algorithm can monitor the data, searching for the above-defined pattern. When a maximum and a 5 minimum are simultaneously found, then it is assumed that the 1 g and 0 g orientation is present. More formally, the calibration algorithm is as follows:

(a) Initially the parameters are set to their nominal values.

(b) The data is monitored, searching for a maximum on one axis and a minimum on the other. This is assumed to represent 1 g and 0 g. Some averaging of the data (say over 1 second) is used to

L 0 minimise random variations due to motion.

(c) For the 0 g case, the offset parameter (pO) can be directly determined, as the scaling factor does not affect the zero reading. When this axis has a data maximum (assumed to be 1 g), the sensitivity parameter (K) can be estimated.

(d) The above procedure is repeated continuously, which will causes the parameters to slowly converge L 5 to their calibrated values.

(e) A measure of the quality of the calibration is that the magnitude acceleration vector will average to approximately 1 g, independent of the orientation.

(f) Thus providing there is sufficient variability in the data, the parameters can be calibrated from the data associated with the motion.

20 Detection of Walking

The basis of detection of walking is that the measured acceleration will vary about the nominal one-g value. This variation is correlated with each step, so that the rate of steps and the number of steps can be measured. The step data is likely to have high clinical relevance.

An approximate model of walking can be developed to estimate the magnitude of the signal variation. The position of 25 the accelerometer will move cyclically up and down with each step, in a quasi sinusoidal manner. Thus if the amplitude of this variation is A, and the step rate is R, the acceleration (peak) is approximately given by:

Z = (2πR)²A (8)

For example, if the step rate is 2 per second, and the amplitude is 1 centimetre, then the acceleration is about 0.15 g. At the slower rate of 0.5 steps per second (perhaps more typical of the elderly), the acceleration falls to about 0.04 g. On top of these 30 estimates, there may be an acceleration impulse when the foot hits the floor. As the sensitivity of the motion detector is designed to be about 10 mg, the basic raw data is adequate to reliably detect walking.

A sample of measured accelerations associated with walking is shown in Fig. 26. This data was measured by attaching the accelerometers to a notebook PC, and carrying the PC/accelerometer while walking. The recorded data shows the system noise for the first three seconds, followed by the acceleration impulses associated with picking up the equipment, and finally 35 walking around the room. The X and Y data 262, 263 were normalised to zero during the initial stationary period, and the Z data 264 to lg. The data was sampled 20 times a second, and the accelerometer bandwidth was 200 Hz. The expected noise (according to the design notes for the ADXL202) should be about 9 milli-g. The actual measured RMS noise was in the range of 20 to 40 milli-g, somewhat worse than expected. However, the measured acceleration associated with walking was about 150 milli-g RMS, so that the SNR is an acceptable value of about 20 dB.

The basic algorithm can scan the data looking for local peaks (the absolute magnitude is unimportant). The calibration of the accelerometer is notoverly significant, but the peaks should be approximately aligned along the earth's gravity axis. The processing algorithm provides the step rate and counts the number of steps.

Detection of Falls

The fall detection algorithm are designed to distinguish falls from all other types of acceleration events. The "signature" of a fall will vary considerably, but there are some general characteristics. These characteristics can be summarised as follows: The initial acceleration vector is approximately aligned with the earth's gravity axis (falls occur from a standing position).

The acceleration vector will rotate towards the horizontal in a time of between approximately 0.5 and 1.5 seconds.

The fall is terminated with an impulse (the magnitude of which is greater than 0.2 g).

A fall will often be followed by a period of low or no motion. The rates should be respectively not greater than 5 percent or less than 95 percent for an acceptable system. One suitable algorithm rates the suspected event in the above four categories, and thus generate a fall index measure. A fall is detected if the index exceeds a specific threshold.

Communications System Architecture

This section provides the details of the communications system architecture of the HWW system. Mobile Communications

As noted previously, the mobile communications are associated with the radio communications between a base station and a mobile. The physical layer communications are based on spread-spectrum radio signal at 2.4 GHz, organised on a TDMA basis. The communications with the mobile are not symmetric. When a command to a particular mobile is detected, the mobile will typically respond with the requested data. Broadly, there are two types of message transfers from the mobile, namely acknowledgment mode and streaming mode.

The acknowledgment mode is a simple one-off response for data, as requested in the broadcast message. Streaming mode results in continuous transmission of the requested data, without any further requests from the base station. The streaming data continues until a termination request is received from the base station. To simplify the design, these two modes cannot be interspersed. Thus if the streaming mode is active, acknowledgment requests cannot be sent to the mobile. In the following subsections, the detailed message structure is defined generically. Thus the allocation of bits and bytes are described as below.

Communication Messages to the Mobile

As described above, the communications to the mobile provides 64 bits of data approximately 16 times a second. Because of the broadcast nature of this message, this corresponds to two messages per mobile per second (on average). This acknowledgment mode message rate is probably adequate for telemedicine data, such as heart rate. However, if the messages should be shared with the four devices attached to the mobile, the rate reduces to one every two seconds. This data rate may be undesirably low. As an improvement, the detailed messages can utilise a structure described below to provide the required data acquisition characteristics. The message protocols described are designed to provide high levels of flexibility to the applications programs. Thus while the principle requirement for the telemedicine applications is for the input of data from the mobile only, other applications may have a requirement for data transmissions to the mobile. Thus the message protocol provides for two types of messages, single frame and multi-frame messages. A 64-bit block of the message to the mobile is allocated as follows:

Bits 0-11 : Synchronisation codeword. The codeword can be E54 hex. This field is used by the receiver to determine bit and frame synchronisation, and thus these bits are not associated with the message protocol.

Bits 12-15: Frame sequence number. This field is used to identify frames (in the range 0 to 15), and is used in power saving mode whereby the radio is powered on only in specific frames. Thus frames can be uniquely identified in a time period of about 1 second.

Bits 16-47 : Message data field. This 32-bit field for single frame messages is further sub-divided as follows:

(1) Bits 0-3: Control bits which define the purpose of the remaining 28 bits. The control field is always present. The bits are defined as follows: Bit 0: 0 = single-frame message, 1 = multi-frame message.

Bit 1: 0 = first transmission, 1 = retransmission of the message.

Bit 2: 0 = More data in next frame. 1 = Last frame of message.

Bit 3: Spare.

Bits 4-7: Sequence number (in range 0..15). The sequence number increments with each message, and wraps around after the 16th message. The sequence number is used to identify response messages in the base station. This is particularly important when multiple messages with retries are active.

Bits 8-15: Mobile identification code. This field identifies the mobile (most significant 4 bits) and device (least significant 4 bits) associated with the message.

Bits 16-19: Function code. Up to 16 function codes can be defined. These codes will include generic functions, and function codes specific to applications.

Bits 20-31: The 12-bit data field provides auxiliary data associated with the function code.

Bits 48-63: Message CRC-16 (single frame messages only). This field is inserted by the Medium Access Control (MAC) layer. The CRC-16 provides a check on the data integrity (but not the synchronisation field). Only messages which pass the CRC is processed by the mobile. For multi-frame messages the structure of bits 16-63 can be different, depending on the location of the frame in the message. This 48-bit data block in each frame can consist of a header block in the first frame, followed by up to 254 data blocks of 48 bits (6 bytes) per frame. The details of the structure are as follows:

Frame 0 is used for a header. The 48-bit data field is used for the transmission of the multi-frame messages (not implemented initially in the HWW project). The message structure consists of a header block followed by a variable number of data frames. The 48-bit header has the following structure:

Bits 0-7: A 8-bit unique identifier. The same format as used in single frame messages.

Bits 8-12: Function code. Bit 13-15: Message Sequence number.

Bit 16:31: Length of message (including Header) in bytes. Range 1 to 6 x 255 =1530.

Bit 32-47: CRC-16 of message, including the header and the following data frames.

The frames 1 to a maximum 255 following the header can be used (optionally) for data. The first byte is a 5 frame sequence number (range 1 to 255). The following five bytes are used for data, so that the maximum number of data bytes is 254 x 5 = 1270. Unused bytes in the last frame should be padded with zeros.

Communication Messages from the Mobile

The communications of data from the mobile (as described above) consists of blocks of 64 bytes per frame, so that much higher data rates are possible when compared with the data rate to the mobile. As the frame rate is about 16 per second, the L0 raw data rate is about 1024 bytes per second. The message protocol is designed to support two types of messages, acknowledgment messages and streaming messages.

The acknowledgment messages are always a response to a message sent from the base station. The rate of these messages (and hence the data rate) is limited by the broadcast channel capacity, namely two messages per second per mobile (assuming equal distribution to all eight mobiles). Thus the raw data rate for acknowledgment messages is about 128 bytes per L5 second per mobile. While this data rate is relatively low, the advantage of this protocol is that data transmission errors can be both detected and corrected (by retransmission). If an error or timeout occurs, the message is retransmitted up to three times, before failing. An individual mobile can-transmit at up to the full physical channel capacity (1024 bytes per second), but this is at the expense of other mobiles; the total capacity is constrained to this maximum figure by the broadcast channel capacity.

To overcome the relatively low data rate in acknowledgment mode, a second message protocol is engaged, namely

20 streaming mode. In this mode, the data is sent continuously, after the initial request. In this case, the data rate is not limited by the broadcast channel, so that the full physical channel rate of 1024 bytes per second is possible. The penalty paid for this increased data rate is that no ARQ error correction is possible (at least at the full data rate). The alternative to ARQ error correcting is to use Forward Error Correcting (FEC). This technique allocates some of the data transmission to redundant

"parity" data; if an error occurs (up to some limit), then the redundancy in the data can correct this error. For example, a 30

25 percent parity overhead in a BCH code can correct for up to 10 percent errors. The errors are usually associated with signal fades, which typically last for hundreds of milliseconds in an in-door environment with slow (walking speed) movement. As these fades are of the same order (much greater than) the length of a frame of data, FEC may be of limited use in the HWW environment.

Further, the streaming mode should be restricted to situation where either the SNR is sufficiently high to avoid errors (the mobile is near the base station), or gaps in the data are not critical. The CRC can check for detected errors, so that the application can

50 process only the "good" data.

The details of the message protocol are as follows:

Both acknowledgment and streaming messages-have the same overall 64-byte block structure, namely a 6 byte header, and a 58 byte data field. The functional difference lies in the ARQ mode always responding to a message from the base station, while in the streaming mode the mobile autonomously sends data (after the initial request from the base station).

55 The Header format is similar to that defined for multi-frame messages sent from the base station, namely:

(1) Bits 0-7: 8-bit unique identifier (mobile and device, both 4 bits).

(2) Bits 8-11: Function code.

(3) Bit 12-15: Sequence number (0..15). For ARQ, same as original message. Increments with each frame, with wrap-around. (4) Bit 16:23: Length of the message block (including Header) in bytes.

(5) Bit 24-31 : Control byte (see paragraph (c) below).

(6) Bit 32-47: CRC-16 of message. The control byte has the following meaning: (1) Bit 0: 0 = ARQ message, 1 = streaming message.

(2) Bit 1 : 0 = first transmission, 1 = retransmission of the message.

(3) Bit 2: 0 = More data in next frame. 1 = Last frame of message.

(4) Bit 3: 0 = no FEC, 1 = FEC (not yet defined).

(5) Bit 4: 0 = no data interleaving, 1 = data interleaving (6) Bit 5: Spare.

(7) Bit 6: Spare.

(8) Bit 7: Spare.

The data block has no defined structure at this level of the protocol; this can be defined by the application. Note that the effective data rate (for a 63 ms frame) is about 7,300 bit per second. HWW Messages

This section described the messages passed between the base station and the mobile. The ARQ messages all originate from the base station, so that the mobile cannot initiate communications with the base station. Thus the intended mode of operation is based on regularly scanning the mobiles/devices for data, rather than the mobile/data transmitting when data is available. Messages to the Mobile

The messages to the mobile use the basic structure described above. The address field is a byte, with bits 4-7 defining the particular mobile (in the range 1 to 8), and bits (0-3) defining the particular device (in the range 1-4). The address zero for the device is reserved for the "null device"; in this case, the message is directed to the mobile, rather than a device attached to the mobile. Further, the address 15 in both cases means "all devices" or "all mobiles". For example, if the mobile address is set to 15, then all mobiles within range will respond to the command. This type of global addressing is useful for implementing global functions, such as resetting all mobiles. Similarly, if the device field is set to 15, then all devices on each mobile is reset.

The message type supported can be as follows:

Initialisation (function code 0). The initialisation message will cause the addressed mobile and/device to reset to a quiescent state. Set Time (function code 1).

Get Status (function code 2).

Get Heart Rate (function code 3).

Get Accelerometer Data (function code 4).

Function codes 5-15 are spare for future expansion. The following subsections describe the various messages and the corresponding acknowledgment messages. 1 Initialisation Message

The initialisation message allows components of the system to be initialised (reset), according to the message identifier field. Thus a single device on a single mobile can be initialised, all devices on a mobile can be initialised, or all devices on all mobiles can be initialised. The message shall cause the specific device to be reset. This shall include the hardware itself, and the associated software. For example, all counters are reset, and the time set to zero.

The initialisation message has two 4-bit data fields (auxiliary data), as follows:

(a) Power-on frame count (range 1-16, add one to field number). This number determines the rate of turning-on of the radio. For low data rates, the radio does not need to be powered on for each frame, so that considerable power can be saved by turning-on at a lower rate. Thus count=l means that the radio will turn on every frame, while count=16 means that it will turn on every 16 frames

(or about once per second). The radio needs to turn-on on a regular basis to maintain synchronisation with the base station, and thus the maximum duty cycle is set at 16.

(b) Power-on frame offset, (range 0-15). The rate of turn-on is defined by the power-on frame count, but the particular frame on which the radio is turned on is defined by this field. This field is matched to the frame sequence number transmitted in the header of the message. Clearly the mobile radio and the scanning process should be synchronised to a particular frame for this scheme to function correctly. Thus initially, the radio is turned-on in every frame, until this initialisation message is received.

2 Set Time Message The Set Time message allows the real-time to be set in the mobile radio. This is required because the data logging process in the radio is decoupled from the scanning of the data. The time is defined in a universal 48-bit format. A complication arises in that the time auxiliary data field in the message is only 12 bits in size, so that the time should be sent as 6 messages. These six types of messages are determined by a three-bit auxiliary data field for the byte number (0 to 5), and an eight-bit field for the time data. Thus auxiliary data 0 is for the least significant 8 bits, auxiliary data 1 bits 9-15, auxiliary data 2 bits 16-23, auxiliary data 3 bits 24-31, auxiliary data 4 bits 32-39, auxiliary data 5 bits 40-47. The data should be transmitted in the order of auxiliary data 0, 1, 2, 3, 4, and 5. The mobile will only set the time when auxiliary data 5 is received, and the other three codes have been received within one second. The accuracy of the time set in this manner will be of the order of 0.25 seconds.

4 Get Status Message

The Get Status message requests the return of the status of the mobile, including the devices attached. There is no requirement to get the status of an individual device on mobile. There are no auxiliary data for this message (set to zero).

5 Get Heart Rate Message

The Get Heart Rate message requests the return of the latest heart rate data. The data may include the data for more than one heart beat. The mobile will save up to 32 heart rate data records, so that the scanning process is totally decoupled from the rate of scanning for the data. There are no auxiliary data for this message (set to zero). 6 Get Accelerometer Message

The Get Accelerometer message requests the return of the 3-axis accelerometer data. Because of the relatively high data rate associated with this device, this message should be issued at least once a second. There are no auxiliary data for this message (set to zero).

7 Messages from the Mobile The messages from the mobile will always be in response from the request messages described above. The acknowledgment message is matched with the out-going request message by matching the function code, the identifier address and the sequence number. If the mobile is out of range, there is no response. The typical response time for a message is 200 milliseconds, due to delays in the queuing of messages, the transmission of messages, and finally the receiving of the reply. Thus the timeout period should be set at (say) 300 milliseconds.

The following sections define the format of each acknowledgment message. Each message can have a 6 byte header, and up to 58 bytes of data. The format of the data field is given for each message in the following sections.

Initialisation Message Acknowledgment

The initialisation acknowledgment are the same, regardless of the address specified (mobile or device). Set Time Message Acknowledgment

The Set Time acknowledgment shall return the current time defined in the mobile real-time clock. The format are the standard 48-bit format for time.

Get Status Message Acknowledgment

The Get Status acknowledgment shall return the status of the mobile at the time of the request. The data are extracted from internal registers maintained by the mobile terminal software. The message shall have the following format:

(a) Bytes 0-5: Time in the standard 48-bit format.

(b) Byte 6: Receiver power (in dBm).

(c) Byte 7: Receiver SNR (in dB).

(d) Bytes 8-11: Number of messages received since the last reset. ( (ee)) B Byytteess 1122--1155:: Number of messages output since the last reset.

(f) Bytes 16-19: Number of "bad" messages (received with invalid CRC).

(g) Bytes 20-21. ^• Current Bit Error Rate. LSB is 10-4.

(h) B Byyttee 2222:: OOnme-bit status for each device. The bit is set if the device is functioning normally, and cleared if it is faulty. (i) Byte 23: Two 4-bit fields associated with the power-on cycling.

Get Heart Rate Message Acknowledgment

The Get Heart Rate acknowledgment returns one or more heart rate data records. Each record shall consist of the time of the measurement, and the heart rate (per minute). The record can be 7 bytes. The message can be as follows:

(a) Byte 0: Count of the number of records following (0 to a maximum of 17). ( (bb)) B Byytteess 11--66.. Time of first heart beat record (in standard 48-bit format).

(c) Bytes 7-9: First record of heart rate. The first two bytes are the time offset of the heart beat (zero for the first record), with LSB of 10 millisecond, and the third byte is the heart rate.

(d) Bytes 10-57 Up to 16 further records of the same format as the first record.

The message can record up to 17 heart beats. Thus if this message is transmitted every 5 seconds, heart rates of up to 204 beats per minute can be recorded and transmitted. Get Accelerometer Message Acknowledgment

The Get Accelerometer acknowledgment shall return up to one second of accelerometer data (on 3 axes). As the available data size is 58 bytes, the maximum accelerometer data rate is 17 per second (without data compression). The details of the message are as follows: (a) Byte 0: Number of acceleration samples (0 to 17).

(b) Bytes 1-6: Time of first sample in standard 48-bit format. Subsequent samples assume contiguous at the sampling data rate of 17 samples per second.

(c) Bytes 7-9: Record number 1 of acceleration data (x, y, z axes, where "z" is the gravity vector direction). LSB is 20 milli-g, data range is ±2.54 g). (d) Bytes 10-57: Further records of the same format as the first record.

Software and Internetworking Design

As noted previously, outside the home computer, all data in the HWW system is stored in a Structured Query Language (SQL) database. This includes data produced by the patient-worn mobile monitors, as well as data produced by fixed measuring equipment located in the home, or data entered by carers and other health professionals. Information in the database, is uploaded at various times to central computer servers, from which health professionals are able to access the information. Virtually all data accessing by medical professionals will be via the database. Upload of data can be by means of whatever data communication system is available in the home. This may be via a standard telephone line via a modem, or it may be via a cable modem or other means. Unless there is an emergency or real time access is required, data upload is done on a daily basis. In general, the telephone connection will take the data to an Internet Service Provider (ISP) and transmission to the assessment centre is via the Internet. The assessment centre computer can contain a copy of all data generated in all of the homes connected to it.

Fig. 27 illustrates one form of suitable operational structure similar to that discussed with reference to Fig. 1 wherein a mobile device e.g. 18 interconnects with a home computer or base station 16 which in turn uploads data to an ISP 271 which transmits the information to the assessment centre database 12. The database 12 can be interrogated by a health professional 272 on a confidential basis. Within the database 12, the data can be represented as follows:

Tables

Each data type in the database is represented by a "table", and as new data types are added to the system, new tables are added. Data in the tables can come from three different sources:

1 Continuously monitored data resulting from measurements performed on the patient's body and transmitted via the mobiles' radio link via the SCADA software.

2 Information generated by a specific action by the patient or a medical professional, such as a one-off measurement of, for example, blood pressure, or the recording of written notes.

3 Tables containing data computed from raw data, and generated by analysis software running either continuously or at regular intervals in computers on which the database is running. These generate summary records or records signifying events which may be of clinical interest.

An example Entity-Relationship model for the HWW database is shown 280 in Fig. 28. The model can include one-to- many relationship between patient table and all sensor tables. For instance, a patient can wear zero or more accelerometers and each accelerometer is worn by zero or one patient(s). The patient 281 and viewer 282 tables have a many-to-many relationship. In this case the patient can have zero or more viewers (doctors, nurses etc.) and viewer can have one or more allocated patients.

The patient table 281

The patient table stores the "static" data associated with each patient, such as surname, first name(s), address, and so on. Whilst some of these fields will change periodically, say if a patient changes address, they are more or less "static" when compared to the continuously monitored data like heart rate and accelerometer values. The table contains one record for each patient that is "registered" with this database.

The device table 283

The device table keeps track of various significant events relating to the individual devices (sensors). For example, attaching a device to a new patient is an "association event" whereupon the the device is "associated" with that patient. As far as the database is concerned, the device remains associated with that patient from that moment on until it is reassigned to another patient. Devices can be assigned to a special "nobody" pid of 1 when they are not connected to a real patient.

Other kinds of events are spot measurements, and starting/stopping of continuous data streams. These kinds of events are essentially summary records as they can be derived from the raw data in the other tables. Continuous record tables e.g. 284

Devices such as heart rate monitors and accelerometers produce continuous records in the form of time series, and these can be recorded in a number of ways, such as (for heart beats) recording a time stamp for each heart beat, or records which contain information over a fixed period such as one minute.

Structured data entry tables 285 Tables may be generated by health professionals making notes or performing measurements on patients. Such tables may consist of free ASCII text, structured data such as blood pressure measurements, or other forms of media such as photographs.

The viewer table 282

The viewer table stores the personal details of the viewer (doctor, nurse etc.).. The grantview table 286

The grantview table can be used for administration purpose. Its purpose is to map the master-detail relationship between patient and viewer tables.

Summary and event tables

Because the volume of data generated by a continuously-monitored system may exceed what can be manually inspected, it is necessary to produce tables which provide overviews of the data at various scales.

Summary tables

The Summary table will contain information about the periods over which data of various types is available. Other summary tables may contain averages, extreme values or other statistics calculated every minute, hour day or whatever time period is appropriate. The calculation of these tables may be tailored to the needs of a particular patient. Event tables In order to draw the attention of clinicians to particular events such as falls, stumbles, arrhythmias or other events which may require detailed data inspection by an expert, the software can be automated to regularly inspect the data with algorithms required to detect such events. Each detected event will generate a record detailing the time and nature of the event.

Certain events will further trigger action such as initialising a dial-up from the patient's home to the assessment centre. Such an event would be a fall.

In a further modified embodiment designed to adapt the HWW system more closely to an Internet type environment, the software can be constructed around a central "Assessment Centre Network Controller" which controls access to the database. Such a modified arrangement is illustrated 290 in Fig. 29 in block diagram form.

The Assessment Centre Network Controller 290 is the main module in the HWW Network which is responsible for the management of the data flow between the Home Stations and Assessment Centre data bases. To simplify the design, ideally the only allowable interactions shall be between databases using the IP address of the required data base. The Network Controller determines the correct IP address and supplies it to the requesting entity. Once this is supplied, the actual physical network activity can be within the Internet (or Intranet for LAN transactions) without any further involvement of the Network Controller.

The major (software) modules of the Network Controller can be as follows: Access Control Module 291

Home Station Communications Module 292

Dial-up Networking Control Module 293

Data Base Upload Schedular Module 294

Network Controller Data Base Maintenance Module 295 Log Viewer Module 296

Fig. 29 shows a block diagram of the Network Controller, and the major interactions and data flow between the modules. The functional requirements of each of these modules are defined in the following sub-sections.

Access Control Module 291

Before an external user (doctor/nurse using the Medical Interface Software) or a Technical Interface Software user can access data in a data base (in the Assessment Centre or a Home Station), a successful log-in must occur. The Access Control

Module is responsible for vetting all such requests. The access information from the external user will be an identifier (User_ID) and an associated password. The data will be saved in the Access Controller Data Base. The data will be entered by the Network

Controller Data Base Maintenance Module.

The Access Control Module in the Assessment Centre communicates with the Log-in modules in the Medical/Technical Interface software using TCP/IP at the protocol layer. A simple message structure can be used for the actual data flow in both directions. The User_ID and Password can be encrypted in these messages. To establish the TCP/IP protocol, the IP address of the Assessment Centre will be globally known. The User can use the Intemet/ISP to establish communications with the Assessment Centre Access Control Module.

The User_ID and Password in the input message can be compared with the corresponding data in the Network Controller Data Base 295. At this point, the user specifies the PatientJD (Home Station) for which the data is required. This Patient_ID is then compared with that allowable for the particular User in the Network Controller Data Base; if a match is found the log-in is successful. After a successful log-in, the user has two choices, either to select the Assessment Centre or the Home Station data base. For the former, control is merely passed to the Assessment Centre Data Base, using the appropriate IP address. If the Home Station data base is selected, then control is passed to the Home Station Communications Module.

Home Station Communications Module 292 The Home Station Communications Module of the Network Controller is responsible for establishing the Internet

(TCP/IP) connection with a Home Station. The task of this module is to determine the IP address of the requested Home Station. For security and other technical networking reasons, the IP address may not be known by remote user, and in some cases (dial-up networking) it is not known by the Network Controller itself. For wideband connections with permanent IP address allocations (LAN and possibly WAN), the Home Station Communications Module will access the IP address from the Network Controller Data Base. This address is then returned to the remote user to complete the log-in procedure.

However, the use of the Internet currently creates some problems with the communications to homes if dial-up networking is used by the Home Station. In this case, the IP address can be determined by the Dial-up Networking Control Module 293. If a successful connection is made by this module, the (temporary) IP address will be returned, and the log-in completed by returning the IP address in the same manner as described for wideband connections. Once the IP address has been returned to the remote user, the communications via the Internet Intranet may not involve the Network Controller; rather the communications will be direct application-to-application communications using the TCP/IP protocol.

Dial-up Networking Control Module 293

The Dial-up Networking Control Module is responsible for establishing an Internet connection with the Home Station using dial-up networking to the Internet. This method of connection can be difficult. Firstly, with dial-up networking using the same line as voice communications (telephone), confusion can occur to the occupants of the home when the phone is being used for Internet connections. The preferred option in this case is to have dual telephone numbers (on the same physical line), one for the Internet connection and one for the telephone. The second problem is that access to the Internet via an ISP requires that the connection be made from the home, and not from the Assessment Centre. This problem is alleviated with broadband (permanent) Internet connections. The following strategy can be used for remote access to the Home Station.

1 After the Assessment Centre has validated the request, the Home Station Communications Module 292 shall use a Network Controller Data Base to determine the phone number of the requested Home Station.

2 The Home Station Communications Module then shall directly phone the requested home. The communications protocol will not be TCP/IP, but a simple message protocol. The message will simply be a request for the Home Station to connect to the local ISP, and then to connect to the Assessment Centre via the IP address in the message.

3 The Home Station PC can intercept this call, and initiate a request to contact the Assessment Centre via the local ISP.

4 The Assessment Centre then hangs-up, awaiting a connection from the Home Station via the Internet. This connection will have a temporary IP address assigned by the ISP.

5 The Assessment Centre informs the remote access user of the temporary IP address of the requested Home Station. The remote user then uses this IP address to directly access the Home Station.

The above technique allows direct Internet connections between remote users and the Home Station, but with appropriate security checks by the Assessment Centre. The above procedure is also applicable when the Assessment Centre requires to contact a Home Station; for example, the uploading of the latest data base information from the Home Station Data Base to the Assessment Centre Data Base.

Data Base Upload Schedular Module 293

A major function of the Network Controller 290 is to manage the uploading of the Home Station data base to the Assessment Centre Data Base. This function can be performed regularly, typically once a day. The uploads from the Home

Stations can be scheduled (staggered) to ensure the communications with the Home Stations and access to the data base does not overload the Assessment Centre computer and the Internet connections. The time of the commencement of the upload will be defined in the Network Controller Data Base. Typically the time would be after midnight each day.

The establishment of the Internet link to a Home Station can use the Home Station Communications Module 292. This module returns the IP address of the Home Station (as currently connected to the Internet via a local ISP). The module then accesses the Home Station Data Base to locate records which are up to (typically) 24 hours old. The access can be by the TCP/IP method supported by the database. The records are then saved into the Assessment Centie Data Base. All transfers from the Data Base Upload Schedular Module to the Assessment Centre Data Base also can use TCP/IP for access, even though the data base may be physically located in the same computer as the Network Controller. The Data Base Upload Schedular module 294 logs all significant events, including but not limited to:

1 Successful or unsuccessful establishing of communications with the Home Station.

2 The record time of the commencement of the upload of records.

3 The record time of the completion of the upload of records.

4 Completion of the upload. Network Controller Data Base Maintenance Module 295

The Network Controller Data Base Maintenance Module allows an operator to enter, modify, view and print all the data associated with the Network Controller Data Base. This shall include, but not be limited to:

All Home Station data (communications (telephone number) details, upload schedule time, associated patient ID).

Configuration of the Home Station network, and the associated devices. This will be a copy of the SCADA configuration data. These data will be used to guide the process of uploading records from the Home Station Data Base.

Remote Users (doctors, nurses) identifiers and passwords. Password control is required access to these records.

List of all patients (Home Stations) associated with each doctor/nurse.

Log Viewer Module 296

This module logs all major events for later review. External data access

Ideally there is a number of ways that external users of the system such as medical practitioner, nurses, or even the patients themselves and their carers are be able to access the data for a given patient. These include:

Direct notification

Direct notification is generated within the server by automated software. The means of notification can be by e-mail or similar means. This will be particularly important for emergency situations requiring intervention. However, it could also generate a regular (e.g. weekly) report on a patient's condition. Interface to EPR

Users of electronic Health Record Systems can incorporate some or all of the database information into their own electronic health record.- This can be done (as, for example, in the Good Electronic Health Record) by generating a Schema written in Extensible Markup Language (XML) which translates data from the database into objects recognised with that electronic health record.

Web-based access

Health professionals with both Internet access and appropriate security can be able to access the data using standard

Internet browsers such as Netscape or Microsoft Internet Explorer. In order to facilitate this, the software on the server can, in response to requests from the user's web browser, generate Java applets which can give a graphical display of patient information. There can be a number of linked views to the data, with the "top" view showing the existence of data represented as horizontal lines plotted against time. A typical appearance of this window is shown 300 in Fig. 30.

Events which are associated with a particular time (such as the measurement of a blood pressure) are represented as icons, and clicking on the icon brings up another window with details of the event. Some of the icons are generated automatically by software in the home computer or the server and show events. Real time display

For some diagnoses it may be necessary to view data in real time. This will require that the health professionals' computer has special software which can display the data. In this case the database in the server is updated continuously and the data is viewed with only a few seconds' delay.

It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are therefore, to be considered in all respects to be illustrative and not restrictive.

Claims

Claims

1. A medical monitoring system to allow the medical status of a subject located in a monitoring zone to be determined, the system comprising: an assessment data means remote from the monitoring zone, to collate monitored medical data associated with the 5 subject; a primary station located at the monitored zone and adapted to receive and transmit data with the assessment data means over a communications network; and at least one sensor device in data communication with the primary station, to monitor medical data associated with the subject and to transmit the data to the primary station,

L0 wherein in use, the monitored medical data transmitted to the assessment data means is used to determine the subject's medical status.

2. A system as claimed in claim 1 wherein the sensor is a motion detector and is adapted to detect the motion of the subject.

3. A system as claimed in claim 2 wherein the motion detector is adapted to determine if the subject is involved L 5 in particular activities including one or more of falling, walking, running, sitting, sleeping.

4. A system as claimed in claim 2 wherein the motion detector is a 3 axis accelerometer.

5. A system as claimed in any previous claim wherein the assessment data means includes means for processing transmitted data to determine if a subject has fallen.

6. A system as claimed in any previous claim wherein the sensor device is worn by the subject in a mobile unit, 20 the mobile unit having communications means to transmit the medical data to the primary station.

7. A system as claimed in any previous claim wherein the sensor further comprises a communicator to detect audio signals and to thereby permit a subject to communicate with a user of the assessment data means.

8. A system as claimed in claim 7 wherein the sensor includes a speaker to allow the subject to verbally communicate with a user of the assessment data means.

25 9. A system as claimed in any previous claim wherein the sensor device detects any one or more of the following variables related to the subject: heart rate, heart rhythm, motion, speech, blood pressure, cholesterol, neurological activity, blood sugar.

10. A system as claimed in any previous claim wherein a plurality of relay stations are located in the monitoring zone that relay data from the sensor device to the primary station for transmission to the assessment data means.

50 11. A system as claimed in claim 10 wherein the plurality of relay stations are located throughout the subject's home.

12. A system as claimed in any previous claim wherein the assessment data means includes an archive data base to record the transmitted data.

13. A system as claimed in any previous claim wherein the data is transmitted from the primary station to the 55 assessment data means according to a predetermined schedule.

14. A system as claimed in any previous claim wherein the assessment data means comprises a data base to store the transmitted monitored data.

15. A system as claimed in any previous claim wherein the assessment data means includes an application program which raises an alarm to a medical professional upon receipt of medical data indicating an alarm condition of the subject's medical condition.

16. A system as claimed in any previous claim wherein a plurality of primary stations exchange data with a master transmission station and further, the master transmission station exchanges the data with the assessment data means.

17. A transmission protocol for use in a medical monitoring system of a type which allows the medical status of a subject located in a monitoring zone to be determined, the system including an assessment data means remote from the monitoring zone to collate monitored medical data associated with the subject; a primary station located at the monitored zone and adapted to receive and transmit data with the assessment data means over a communications network; and at least one sensor device in data communication with the primary station to monitor medical data associated with the subject and to transmit the data to the primary station, and wherein in use, the transmitted monitored medical data is relayed to the assessment data means and used to determine the subject's medical status, the transmission protocol comprising: at least one activation time slot used to establish signal transmission with the primary station; and a plurality of message time slots to transmit data messages to the primary station, wherein a receiver of the protocol transmission includes a predefined codeword and an initial subset of the message time slots consist of the predefined codeword to thereby maintain synchronisation of the protocol transmission with the receiver.

18. A system as claimed in any one of claims 1 to 16 wherein the assessment data means further includes software to detect if a subject has fallen from data transmitted by the motion detector by determining if a predefined series of motion events has occurred.

19. A system as claimed in claim 18 wherein the predefined series of motion events comprise:

(a) determining an initial acceleration vector of one axis to be aligned with earth's gravity axis;

(b) determining when the acceleration vector rotates towards the horizontal in a time period of about 0.5 and 1.5 seconds; and

(c) determining if said rotation is terminated with an impulse.

20. A mobile unit for use in a monitoring system of a type in which the medical status of a subject located in a monitoring zone is determined, the monitoring system comprising an assessment data means remote from the monitoring zone, to collate monitored medical data associated with the subject; and at least one primary station located at the monitoring zone, the primary station having signal processor means adapted to receive and transmit data with the assessment data means over a communications network, the mobile unit comprising: at least one sensor device to monitor medical data associated with the subject; data converter means to read the medical data from the at least one sensor device and convert it into a signal; transmitter means for establishing signal communications with signal processor means of the primary station; and logic means for receiving the signal from the data converter means and for executing a protocol to be sent to the transmitter means, the protocol comprising: at least one activation time slot used to establish signal transmission with the signal processor means of the primary station; and a plurality of message time slots to transmit data messages to the primary station.

21. A primary station unit for use in a medical monitoring system of a type in which the medical status of a subject located in a monitoring zone is determined, the medical monitoring system comprising: assessment data means remote from the monitoring zone to collate monitored medical data associated with the subject and a mobile unit located in the monitoring zone and adapted to transmit medical data obtained from a sensor connectable to the subject, the primary station comprising: signal processor means for transmitting a protocol to the mobile unit, the protocol comprising at least one activation time slot used to establish communications with the mobile unit and a plurality of message time slots to transmit data messages to the primary station upon signal communications being established with the primary station by the activation time slot; and communication network means to connect to a communications network and thereby exchange transmission of data with the assessment means.

22. A system as claimed in claim 1 wherein messages are transmitted by said system using a hierarchical addressing structure.

23. A system as claimed in claim 22 wherein said addressing structure includes fields for at least one of: device identifier, mobile identifier, base station identifier, home station identifier and assessment centre identifier.

24. A system as claimed in claim 1 wherein predetermined devices are scanned at a rate determined by a corresponding scan table entry.

25. A system as claimed in claim 24 wherein scanned data values are stored in a circular buffer on said primary station.

26. A system as claimed in claim 1 wherein a dual element spatial diversity antenna is used to communicate between said primary station and said at least one sensor device, with the communications switching between the elements in accordance with signal quality parameters.

27. A system as claimed in claim 1 wherein said sensor device comprises a battery operated body-worn unit.

28. A system as claimed in claim 27 wherein said sensor device includes power saving control circuitry to shut down portions of said sensor device when not in use.

29. A system as claimed in claim 1 wherein an epoch division multiple access protocol is used for communication between the primary station and sensor devices.

30. A system as claimed in claim 27 wherein the communication between any sensor devices and said primary station is at a rate determined by the data acquisition of said sensor device.

31. A system as claimed in claim 1 wherein said sensor device includes an audio emission device and said system is adapted to send prerecorded audio reminders to said emission device at predetermined times.

32. A system as claimed in claim 2 wherein system includes means for determining if a subject is walking from data received from said motion detector.

33. A system as claimed in claim 1 wherein monitored data is stored on said assessment data means as a SQL database.

34. A system as claimed in claim 1 wherein said assessment data means is interconnected to said primary station over a TCP/IP type interconnect.