+

WO2002035997A1 - Systeme de surveillance - Google Patents

Systeme de surveillance Download PDF

Info

Publication number
WO2002035997A1
WO2002035997A1 PCT/AU2001/001403 AU0101403W WO0235997A1 WO 2002035997 A1 WO2002035997 A1 WO 2002035997A1 AU 0101403 W AU0101403 W AU 0101403W WO 0235997 A1 WO0235997 A1 WO 0235997A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
subject
medical
mobile
assessment
Prior art date
Application number
PCT/AU2001/001403
Other languages
English (en)
Inventor
Laurence Sydney Wilson
Ian Francis Sharp
Robert Wyatt Gill
Original Assignee
Commonwealth Scientific And Industrial Research Organisation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commonwealth Scientific And Industrial Research Organisation filed Critical Commonwealth Scientific And Industrial Research Organisation
Priority to AU2002213656A priority Critical patent/AU2002213656A1/en
Publication of WO2002035997A1 publication Critical patent/WO2002035997A1/fr

Links

Classifications

    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/72—Signal processing specially adapted for physiological signals or for diagnostic purposes
    • A61B5/7232—Signal processing specially adapted for physiological signals or for diagnostic purposes involving compression of the physiological signal, e.g. to extend the signal recording period

Definitions

  • the present invention relates to a monitoring system and more particularly, though not exclusively, to a medical monitoring system.
  • 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.
  • a medical monitoring system to allow the medical status of a subject located in a monitoring zone to be determined, the system comprising:
  • the senor 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.
  • 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.
  • the senor 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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;
  • a detected fall may often be followed by the detection of a period of low or no motion.
  • 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
  • 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
  • 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.
  • 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
  • Fig. 30 illustrates the appearance of web-based viewer. Detailed description of the embodiments
  • 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.
  • 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.
  • the HWW monitoring system 10 includes a Central Data Base Computer 12 located in an Assessment Centre, a plurality of Home Stations
  • 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
  • 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.
  • Base Station #3.2 serves cell 18 which includes Mobile Terminals
  • 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.
  • 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.
  • This component provides the control, monitoring and data archiving facility within the home.
  • 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
  • the Home Station (not shown), which is a portable PC temporarily connected to the Home Station, and a Technical Workstation.
  • the Home Station (not shown), which is a portable PC temporarily connected to the Home Station, and a Technical Workstation.
  • Station can be based on a Notebook computer or an "Industrial PC" (with no user interfaces such as keyboard or monitor).
  • 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:
  • 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.
  • FIG. 2 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
  • 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:
  • SCADA Home Station Supervisory Control and Data Acquisition
  • the components in the medical software are as follows:
  • Nurse Station 22 for accessing the Home Station data base.
  • Assessment Centre Workstation 27 for accessing the Assessment Centre data base.
  • 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:
  • 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.
  • the networking utilises the TCP/IP protocol between the PCs.
  • 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.
  • 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.
  • 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:
  • the Schedular 42 includes patient Motion Analysis module 44, Heart Rate L0 Analysis module 46 and a Spirometer Analysis module 48.
  • SCADA Supervisory Control And Data Acquisition module 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.
  • SCADA Supervisory Control And Data Acquisition module
  • the Network module also providing communication support for the Home
  • - Technical User Interface 58 comprising a PC to be used by technical personnel in maintaining the HWW monitoring system 10.
  • 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.
  • the SQL data base 56 several standard data base packages could be used such as IBM DB2, Oracle, or MYSQL
  • the Supervisory Control and Data Acquisition (SCADA) 50 sub-system of the Home Stations is illustrated in more detail
  • .5 detail in Fig. 4 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.
  • the Home Station includes a data base 56, the data files associated with the scanned devices are not duplicated
  • the data logged from the monitored units 24 are preferably temporarily saved in RAM, until the data can be transferred to the data base.
  • RAM temporary buffer 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the communications hardware 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • Point descriptor text
  • Point address An address, using the standard HWW monitoring system device addressing method
  • the dynamic data in the circular buffer can be L records of the following format:
  • 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.
  • (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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the reply may incorporate multiple records of the scanned device; in this case multiple records are written into the Points Table.
  • 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.
  • the procedure of archiving is of low priority, the use of the Lock function is important for the real-time performance.
  • the suggested procedure is to call the
  • 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
  • the point data can be displayed by the Mimic
  • 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 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.
  • 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
  • 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.
  • the base station 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.
  • Fig. 5 shows a block diagram of the HWW Radio Communications System 100 for the HWW monitoring system 10.
  • 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
  • This port may communicate directly with a computer, or via a modem. Communication speeds up to say 115,200 baud is possible.
  • 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.
  • 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.
  • 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.
  • the transmitter power is preferably 20 dBm (maximum allowable in ISM band).
  • 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.
  • 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).
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the power limit in the ISM band is 200 milliwatts, the system can be largely immune to co-channel interference.
  • FDMA is a conceptually simple method for multiple access, and is in fact the most common method.
  • the application of FDMA to a spread-spectrum system is not particularly appropriate, as it is very spectrally inefficient.
  • 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)).
  • FCC regulation 15.247 (2) FCC regulation 15.247 (2)
  • 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).
  • 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.
  • TDD time division duplex
  • FDMA hybrid FDMA TDMA
  • FDMA could be used for the HWW radio communications from the mobile, but is spectrally inefficient.
  • TDD is required for full-duplex communications to the mobile.
  • TDMA is a common multiple access protocol used in modern digital radio systems.
  • 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).
  • the scheme can be used with any modulation scheme, including spread-spectrum modulation.
  • 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.
  • 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 Code Division Multiple Access
  • all mobiles transmit simultaneously (like FDMA), but the transmissions are all in the same broad band.
  • 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.
  • the propagation delay will in general be different for each mobile, the synchronisation process should adjust for this delay.
  • the propagation delay is small compared with the chip period, so that synchronisation error is negligible.
  • the codes can be truly orthogonal over the integration period.
  • 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 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.
  • both CDMA types have considerable complications regarding the implementation.
  • the CDMA system shares the same problem as FDMA with regards to full duplex operation in the same band.
  • the solution is to use a hybrid TDM A/CDMA system, known hereafter as EDMA.
  • EDMA EDMA
  • CDMA Code Division Multiple Access
  • TDMA Time Division Multiple Access
  • 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.
  • the auto-correlation function is a triangular pulse.
  • the chip period is much larger than the delay spread, so that this pulse width is not affected by multipath interference.
  • the pulse amplitude is susceptible to Rayleigh fading.
  • 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.
  • each epoch slot can be used for Epoch Shift Keying (ESK) modulation.
  • ESK Epoch Shift Keying
  • 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.
  • 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).
  • a frame of the signal protocol will have nine time slots, repeated continuously.
  • the data rate per slot
  • 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.
  • the design of the protocol should allow the mobile power to be turned off as much as possible.
  • 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.
  • 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.
  • the time slot should be much greater than the 1 milliseconds period, say at least 5 milliseconds.
  • 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.
  • 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).
  • DPSK differential phase shift keying
  • 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.
  • pn-code bit per symbol 5
  • 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.
  • 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).
  • 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.
  • 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.
  • the base station switches to antenna element #1 to receive the data.
  • 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
  • receiver is used to measure the receiver power.
  • the third pn-code period is used to measure the signal from antenna element #2.
  • the fourth pn-code period is used to process the data from antenna element #2, thus determining the signal strength from the second element.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the signal processing can be represented by the equation:
  • 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.
  • the above processing can be considerably simplified.
  • the multiplication can be eliminated by assuming the bandlimited pn-code is ⁇ 1 (the ideal case).
  • 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 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
  • 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:
  • 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.
  • 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
  • the transmitter and receiver 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 .
  • the base station FPGA performs the correlation function to despread the received signal, the mobile performs this function using analog circuits in the radio.
  • 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:
  • 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.
  • 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.
  • the radio receiver can have quite poor sensitivity (noise level around 15 dB).
  • 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.
  • the signal is generated/decoded using in-phase/quadrature signal processing. This design requires duplication of these signal' processing components.
  • 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.
  • the baseband signal (after dispreading) is a 100 kHz tone, with phase modulation at the pn-code rate (10 kHz).
  • 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.
  • 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.
  • 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.
  • the interface can be with the FPGA digital logic subsystem, rather than directly with the microcontroller.
  • 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.
  • 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.
  • Table 2 This implementation uses all 6 bits).
  • 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.
  • PLL Phase Locked Loop
  • 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.
  • 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):
  • 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.
  • the signal acquisition process for the spread-spectrum signal is a difficult process due to the uncertainty in the signal.
  • 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.
  • 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.
  • 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).
  • Ts 10 kHz
  • Ts is the symbol period of 100 microseconds.
  • the acquisition process is thus to detect output power from the IF bandpass filter.
  • 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 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.
  • the receiver should search (potentially) through all nine slots to detect the signal.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 21 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.
  • 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).
  • 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).
  • the propagation delay 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.
  • 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.
  • the received signal strength will exhibit Rayleigh fading statistics.
  • the probability that the signal strength is greater or equal to signal "s" is given by: s 2
  • the fade margin required is 10 dB.
  • 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.
  • the received signal strengths is statistically independent.
  • the probability that at least one antenna element will receive an adequate signal is given by:
  • 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.
  • 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.
  • a dual-diversity receive antennas are used for communications from the mobile to the base station.
  • 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).
  • 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.
  • 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.
  • 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).
  • AA batteries 1.5 Amp-hours
  • 3.75 WH 13.75 WH
  • 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.
  • 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.
  • 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.
  • the accelerometer data requires about one message per second, and the heart rate monitor about one message every five seconds.
  • the radio buffers the data between messages, so that no data is lost by reducing the message rate.
  • 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.
  • the radio can be powered off while not in use, big increases in battery life can be achieved.
  • 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:
  • 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.
  • 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.
  • peripheral devices which are expected to be used in the initial HWW monitoring system 10 are as follows:
  • 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.
  • 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.
  • 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).
  • Motion Detector 149 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).
  • 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.
  • the design provides for flexibility, while not imposing additional complexity on the radio.
  • the physical layer is based on voltages of approximately 0 V and 3 V for the serial binary data.
  • 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.
  • the radio does not require circuits to generate the RS-232 voltages.
  • the RS-232 voltage conversion circuit is incorporated into the connecting cable.
  • 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.
  • 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.
  • Magnetic Coupled Interface 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 35 minutes operation will result in about a 10 percent reduction in the battery life (28 days to 25 days).
  • 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
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • the radio system is capable of receiving audio from up to eight mobiles simultaneously.
  • the average data rate supported for transmissions from the base station to the mobile is only about 1000 bps.
  • 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:
  • S Slloott 33 Audio communications from the mobile (8,000 bps).
  • 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 can then take place.
  • 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.
  • the HWW audio subsystem main function is to provide emergency audio communications between the patient wearing
  • 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.
  • 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.
  • the radio 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.
  • the motion detector subsystem 149 of Fig. 12 is designed to monitor the motion of the patient.
  • 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.
  • 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.
  • 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.
  • 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.
  • T1/T2 duty cycle 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 %.
  • 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.
  • 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.
  • the measured SNR should be at least 20 dB, so that the measurement noise should not exceed 0.01 g.
  • the data output are in the range 0-400 (9 bits).
  • the peak acceleration is limited to ⁇ 1.28 g with a sensitivity of 0.01 g.
  • N 500V1.5BW ⁇ g/VHz (6)
  • N 10 mg
  • BW 267 Hz
  • T2 3.75 milliseconds.
  • T2 can be set to about 4 milliseconds, or 250 samples per second.
  • 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.
  • the 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)
  • 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.
  • the accelerometers are turned on for 12ms very 100 ms, and the periods TI and T2 measured.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • the offset parameter (pO) can be directly determined, as the scaling factor does not affect the zero reading.
  • this axis has a data maximum (assumed to be 1 g)
  • the sensitivity parameter (K) can be estimated.
  • a measure of the quality of the calibration is that the magnitude acceleration vector will average to approximately 1 g, independent of the orientation.
  • 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.
  • the acceleration is about 0.15 g.
  • the acceleration falls to about 0.04 g.
  • the sensitivity of the motion detector is designed to be about 10 mg, the basic raw data is adequate to reliably detect walking.
  • FIG. 26 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.
  • 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.
  • 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.
  • 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.
  • the mobile When a command to a particular mobile is detected, the mobile will typically respond with the requested data.
  • 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.
  • these two modes cannot be interspersed.
  • acknowledgment requests cannot be sent to the mobile.
  • the detailed message structure is defined generically. Thus the allocation of bits and bytes are described as below.
  • 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.
  • the rate reduces to one every two seconds. This data rate may be undesirably low.
  • 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.
  • 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 Last frame of message.
  • 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 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).
  • Unused bytes in the last frame should be padded with zeros.
  • 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).
  • 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.
  • the data is sent continuously, after the initial request.
  • 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).
  • ARQ error correcting is to use Forward Error Correcting (FEC). This technique allocates some of the data transmission to redundant
  • 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.
  • 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
  • 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).
  • the Header format is similar to that defined for multi-frame messages sent from the base station, namely:
  • Bits 0-7 8-bit unique identifier (mobile and device, both 4 bits).
  • Bit 12-15 Sequence number (0..15). For ARQ, same as original message. Increments with each frame, with wrap-around.
  • Bit 16:23 Length of the message block (including Header) in bytes.
  • Bit 24-31 Control byte (see paragraph (c) below).
  • Bit 32-47 CRC-16 of message.
  • Bit 5 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
  • the ARQ messages all originate from the base station, so that the mobile cannot initiate communications with the base station.
  • 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.
  • 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.
  • 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:
  • the initialisation message allows components of the system to be initialised (reset), according to the message identifier field.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • the initialisation acknowledgment are the same, regardless of the address specified (mobile or device).
  • 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.
  • 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:
  • 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.
  • Byte 23 Two 4-bit fields associated with the power-on cycling.
  • 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:
  • 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.
  • 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.
  • 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).
  • SQL Structured Query Language
  • 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.
  • ISP Internet Service Provider
  • 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.
  • the data can be represented as follows:
  • 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:
  • 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.
  • 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 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 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.
  • 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 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 282
  • the viewer table stores the personal details of the viewer (doctor, nurse etc.).
  • the grantview table 286 is the general details of the viewer (doctor, nurse etc.).
  • the grantview table can be used for administration purpose. Its purpose is to map the master-detail relationship between patient and viewer 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.
  • the software can be constructed around a central "Assessment Centre Network Controller" which controls access to the database.
  • 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.
  • Access Control Module 291 The major (software) modules of the Network Controller can be as follows: Access Control Module 291
  • 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.
  • the 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
  • 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.
  • TCP/IP 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.
  • 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.
  • 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.
  • 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.
  • the Home Station Communications Module of the Network Controller is responsible for establishing the Internet
  • TCP/IP Transmission Control Protocol/IP
  • 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.
  • 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.
  • 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.
  • the Home Station Communications Module 292 shall use a Network Controller Data Base to determine the phone number of the requested Home Station.
  • 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.
  • the Home Station PC can intercept this call, and initiate a request to contact the Assessment Centre via the local ISP.
  • 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.
  • 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.
  • 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
  • the 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:
  • 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).
  • 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.
  • XML Extensible Markup Language
  • 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.
  • Java applets can give a graphical display of patient information.
  • Events which are associated with a particular time 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

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Pathology (AREA)
  • Epidemiology (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Biophysics (AREA)
  • Primary Health Care (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Molecular Biology (AREA)
  • Surgery (AREA)
  • Animal Behavior & Ethology (AREA)
  • Veterinary Medicine (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Ce système de surveillance médicale permet de déterminer l'état médical d'un sujet se trouvant dans une zone de surveillance, et il comprend: une unité de données d'évaluation, située à distance de la zone de surveillance et conçue pour collationner des données médicales de surveillance associées audit sujet, un premier poste situé au niveau de la zone surveillée et conçu pour recevoir des données provenant de l'unité de données d'évaluation et pour émettre des données en direction de cette unité, sur un réseau de télécommunications, ainsi qu'au moins un capteur pouvant communiquer des données avec le premier poste, afin de surveiller les données médicales associées audit sujet et émettre les données en direction du premier poste, de sorte que, lors de l'utilisation du capteur, les données médicales de surveillance émises sont transmises à l'unité de données d'évaluation et aux informations utilisées pour déterminer l'état médical du sujet.
PCT/AU2001/001403 2000-10-31 2001-10-31 Systeme de surveillance WO2002035997A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002213656A AU2002213656A1 (en) 2000-10-31 2001-10-31 A monitoring system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AUPR1139 2000-10-31
AUPR1139A AUPR113900A0 (en) 2000-10-31 2000-10-31 A monitoring system

Publications (1)

Publication Number Publication Date
WO2002035997A1 true WO2002035997A1 (fr) 2002-05-10

Family

ID=3825182

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2001/001403 WO2002035997A1 (fr) 2000-10-31 2001-10-31 Systeme de surveillance

Country Status (2)

Country Link
AU (2) AUPR113900A0 (fr)
WO (1) WO2002035997A1 (fr)

Cited By (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004010863A1 (fr) * 2002-07-31 2004-02-05 Harosi Ferenc Moniteur d'electrocardiographie a detection d'alarme amelioree
WO2004012132A3 (fr) * 2002-07-29 2004-12-16 Siemens Med Solutions Health Systeme d'acquisition et de distribution de parametres medicaux des patients
WO2005016143A1 (fr) * 2003-08-15 2005-02-24 Medcare Systems Pty Ltd Appareil de surveillance pour patient en ambulatoire et procede de surveillance associe
WO2005048830A1 (fr) * 2003-11-18 2005-06-02 Alive Technologies Pty Ltd Surveillance de signes vitaux et de niveaux de performance
FR2864388A1 (fr) * 2003-12-22 2005-06-24 Estaris Monitoring Systeme d'acquisition modulaire et temps reel de signaux, et notamment de signaux biomedicaux
WO2005107207A1 (fr) 2004-04-29 2005-11-10 British Telecommunications Public Limited Company Reseau de notification d'evenements
WO2006039752A1 (fr) * 2004-10-11 2006-04-20 Newsouth Innovations Pty Limited Systeme de securite pour patient
EP2069004A2 (fr) * 2006-11-20 2009-06-17 Proteus Biomedical, Inc. Récepteurs de signaux de santé personnelle à traitement actif du signal
WO2009109779A1 (fr) * 2008-03-06 2009-09-11 Toumaz Technology Limited Surveillance et suivi de dispositifs de capteur sans fil
WO2010025166A1 (fr) * 2008-08-28 2010-03-04 Delphi Technologies, Inc. Ecran personnel couplé indirectement, permettant d’obtenir au moins un paramètre physiologique d’un sujet
EP2845133A2 (fr) * 2012-05-04 2015-03-11 Medtronic MiniMed, Inc. Recouvrement actif d'informations de gestion du diabète sur un affichage
US9060708B2 (en) 2008-03-05 2015-06-23 Proteus Digital Health, Inc. Multi-mode communication ingestible event markers and systems, and methods of using the same
US9198608B2 (en) 2005-04-28 2015-12-01 Proteus Digital Health, Inc. Communication system incorporated in a container
US9433371B2 (en) 2007-09-25 2016-09-06 Proteus Digital Health, Inc. In-body device with virtual dipole signal amplification
US9489815B2 (en) 2011-04-29 2016-11-08 Koninklijke Philips N.V. Apparatus for use in a fall detector or fall detection system, and a method of operating the same
US9603550B2 (en) 2008-07-08 2017-03-28 Proteus Digital Health, Inc. State characterization based on multi-variate data fusion techniques
CN106821353A (zh) * 2017-04-05 2017-06-13 合肥酷睿网络科技有限公司 一种人体健康辅助监控系统
US9756874B2 (en) 2011-07-11 2017-09-12 Proteus Digital Health, Inc. Masticable ingestible product and communication system therefor
US9883819B2 (en) 2009-01-06 2018-02-06 Proteus Digital Health, Inc. Ingestion-related biofeedback and personalized medical therapy method and system
US9941931B2 (en) 2009-11-04 2018-04-10 Proteus Digital Health, Inc. System for supply chain management
US10084880B2 (en) 2013-11-04 2018-09-25 Proteus Digital Health, Inc. Social media networking based on physiologic information
CN109246235A (zh) * 2018-09-30 2019-01-18 广州圣亚科技有限公司 监测数据的接收方法、装置和数据监测系统
US10187121B2 (en) 2016-07-22 2019-01-22 Proteus Digital Health, Inc. Electromagnetic sensing and detection of ingestible event markers
US10223905B2 (en) 2011-07-21 2019-03-05 Proteus Digital Health, Inc. Mobile device and system for detection and communication of information received from an ingestible device
US10238604B2 (en) 2006-10-25 2019-03-26 Proteus Digital Health, Inc. Controlled activation ingestible identifier
US10398161B2 (en) 2014-01-21 2019-09-03 Proteus Digital Heal Th, Inc. Masticable ingestible product and communication system therefor
US10441194B2 (en) 2007-02-01 2019-10-15 Proteus Digital Heal Th, Inc. Ingestible event marker systems
US10517506B2 (en) 2007-05-24 2019-12-31 Proteus Digital Health, Inc. Low profile antenna for in body device
US10529044B2 (en) 2010-05-19 2020-01-07 Proteus Digital Health, Inc. Tracking and delivery confirmation of pharmaceutical products
CN113742427A (zh) * 2021-09-10 2021-12-03 中国长江电力股份有限公司 一种基于104规约通信异构系统单边数据点上送同步方法
US11468711B2 (en) 2010-08-09 2022-10-11 Nike, Inc. Monitoring fitness using a mobile device
US11464423B2 (en) 2007-02-14 2022-10-11 Otsuka Pharmaceutical Co., Ltd. In-body power source having high surface area electrode
US11471062B2 (en) 2003-04-17 2022-10-18 Nike, Inc. Adaptive watch
US11495341B2 (en) 2010-11-01 2022-11-08 Nike, Inc. Wearable device assembly having athletic functionality and milestone tracking
US11568977B2 (en) 2010-11-10 2023-01-31 Nike, Inc. Systems and methods for time-based athletic activity measurement and display
US11676699B2 (en) 2006-09-07 2023-06-13 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US11710549B2 (en) 2010-11-05 2023-07-25 Nike, Inc. User interface for remote joint workout session
US11744481B2 (en) 2013-03-15 2023-09-05 Otsuka Pharmaceutical Co., Ltd. System, apparatus and methods for data collection and assessing outcomes
US11915814B2 (en) 2010-11-05 2024-02-27 Nike, Inc. Method and system for automated personal training
US11928614B2 (en) 2006-05-02 2024-03-12 Otsuka Pharmaceutical Co., Ltd. Patient customized therapeutic regimens

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1988002237A1 (fr) * 1986-09-23 1988-04-07 Advanced Medical Technologies, Inc. Systeme portatif a canaux multiples pour le controle de donnees physiologiques
WO1999004685A1 (fr) * 1997-07-25 1999-02-04 Vaeaenaenen Mikko Procede permettant de donner l'alarme sur l'etat de sante d'une personne
WO1999014882A2 (fr) * 1997-09-19 1999-03-25 Georgia Tech Research Corporation Systeme de telemedecine en mode paquet permettant la communication d'informations entre une station de surveillance centrale et des stations de surveillance de patients a distance
WO1999044494A1 (fr) * 1998-03-03 1999-09-10 Card Guard Scientific Survival Ltd. Appareil cellulaire individuel de controle de la sante pour malade ambulatoire
WO2000006018A1 (fr) * 1998-07-30 2000-02-10 Rapid Patient Monitoring Llc. Systeme de telesurveillance de patient a vetement et distributeur automatique de medicaments
WO2000027277A1 (fr) * 1998-11-10 2000-05-18 Ineedmd.Com, Inc. Dispositif de telediagnostic
WO2000054236A1 (fr) * 1999-03-12 2000-09-14 Advanced Marketing Systems Corporation Systeme individuel de reaction d'urgence

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1988002237A1 (fr) * 1986-09-23 1988-04-07 Advanced Medical Technologies, Inc. Systeme portatif a canaux multiples pour le controle de donnees physiologiques
WO1999004685A1 (fr) * 1997-07-25 1999-02-04 Vaeaenaenen Mikko Procede permettant de donner l'alarme sur l'etat de sante d'une personne
WO1999014882A2 (fr) * 1997-09-19 1999-03-25 Georgia Tech Research Corporation Systeme de telemedecine en mode paquet permettant la communication d'informations entre une station de surveillance centrale et des stations de surveillance de patients a distance
WO1999044494A1 (fr) * 1998-03-03 1999-09-10 Card Guard Scientific Survival Ltd. Appareil cellulaire individuel de controle de la sante pour malade ambulatoire
WO2000006018A1 (fr) * 1998-07-30 2000-02-10 Rapid Patient Monitoring Llc. Systeme de telesurveillance de patient a vetement et distributeur automatique de medicaments
WO2000027277A1 (fr) * 1998-11-10 2000-05-18 Ineedmd.Com, Inc. Dispositif de telediagnostic
WO2000054236A1 (fr) * 1999-03-12 2000-09-14 Advanced Marketing Systems Corporation Systeme individuel de reaction d'urgence

Cited By (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004012132A3 (fr) * 2002-07-29 2004-12-16 Siemens Med Solutions Health Systeme d'acquisition et de distribution de parametres medicaux des patients
WO2004010863A1 (fr) * 2002-07-31 2004-02-05 Harosi Ferenc Moniteur d'electrocardiographie a detection d'alarme amelioree
US11471062B2 (en) 2003-04-17 2022-10-18 Nike, Inc. Adaptive watch
WO2005016143A1 (fr) * 2003-08-15 2005-02-24 Medcare Systems Pty Ltd Appareil de surveillance pour patient en ambulatoire et procede de surveillance associe
WO2005048830A1 (fr) * 2003-11-18 2005-06-02 Alive Technologies Pty Ltd Surveillance de signes vitaux et de niveaux de performance
WO2005065532A1 (fr) 2003-12-22 2005-07-21 Estaris Monitoring Systeme d’acquisition modulaire et temps reel de signaux, et notamment de signaux biomedicaux
FR2864388A1 (fr) * 2003-12-22 2005-06-24 Estaris Monitoring Systeme d'acquisition modulaire et temps reel de signaux, et notamment de signaux biomedicaux
WO2005107207A1 (fr) 2004-04-29 2005-11-10 British Telecommunications Public Limited Company Reseau de notification d'evenements
US8135863B2 (en) 2004-04-29 2012-03-13 British Telecommunications Public Limited Company Event notification network
WO2006039752A1 (fr) * 2004-10-11 2006-04-20 Newsouth Innovations Pty Limited Systeme de securite pour patient
US9198608B2 (en) 2005-04-28 2015-12-01 Proteus Digital Health, Inc. Communication system incorporated in a container
US11928614B2 (en) 2006-05-02 2024-03-12 Otsuka Pharmaceutical Co., Ltd. Patient customized therapeutic regimens
US11955219B2 (en) 2006-09-07 2024-04-09 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US11676699B2 (en) 2006-09-07 2023-06-13 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US11676696B2 (en) 2006-09-07 2023-06-13 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US11676698B2 (en) 2006-09-07 2023-06-13 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US11676697B2 (en) 2006-09-07 2023-06-13 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US11676695B2 (en) 2006-09-07 2023-06-13 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US11682479B2 (en) 2006-09-07 2023-06-20 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US11972852B2 (en) 2006-09-07 2024-04-30 Nike, Inc. Athletic performance sensing and/or tracking systems and methods
US10238604B2 (en) 2006-10-25 2019-03-26 Proteus Digital Health, Inc. Controlled activation ingestible identifier
US11357730B2 (en) 2006-10-25 2022-06-14 Otsuka Pharmaceutical Co., Ltd. Controlled activation ingestible identifier
EP2069004A2 (fr) * 2006-11-20 2009-06-17 Proteus Biomedical, Inc. Récepteurs de signaux de santé personnelle à traitement actif du signal
US9444503B2 (en) 2006-11-20 2016-09-13 Proteus Digital Health, Inc. Active signal processing personal health signal receivers
US9083589B2 (en) 2006-11-20 2015-07-14 Proteus Digital Health, Inc. Active signal processing personal health signal receivers
EP2069004A4 (fr) * 2006-11-20 2014-07-09 Proteus Digital Health Inc Récepteurs de signaux de santé personnelle à traitement actif du signal
US10441194B2 (en) 2007-02-01 2019-10-15 Proteus Digital Heal Th, Inc. Ingestible event marker systems
US11464423B2 (en) 2007-02-14 2022-10-11 Otsuka Pharmaceutical Co., Ltd. In-body power source having high surface area electrode
US10517506B2 (en) 2007-05-24 2019-12-31 Proteus Digital Health, Inc. Low profile antenna for in body device
US9433371B2 (en) 2007-09-25 2016-09-06 Proteus Digital Health, Inc. In-body device with virtual dipole signal amplification
US9258035B2 (en) 2008-03-05 2016-02-09 Proteus Digital Health, Inc. Multi-mode communication ingestible event markers and systems, and methods of using the same
US9060708B2 (en) 2008-03-05 2015-06-23 Proteus Digital Health, Inc. Multi-mode communication ingestible event markers and systems, and methods of using the same
US8228188B2 (en) 2008-03-06 2012-07-24 Toumaz Technology Limted Monitoring and tracking of wireless sensor devices
WO2009109779A1 (fr) * 2008-03-06 2009-09-11 Toumaz Technology Limited Surveillance et suivi de dispositifs de capteur sans fil
US10682071B2 (en) 2008-07-08 2020-06-16 Proteus Digital Health, Inc. State characterization based on multi-variate data fusion techniques
US9603550B2 (en) 2008-07-08 2017-03-28 Proteus Digital Health, Inc. State characterization based on multi-variate data fusion techniques
US11217342B2 (en) 2008-07-08 2022-01-04 Otsuka Pharmaceutical Co., Ltd. Ingestible event marker data framework
WO2010025166A1 (fr) * 2008-08-28 2010-03-04 Delphi Technologies, Inc. Ecran personnel couplé indirectement, permettant d’obtenir au moins un paramètre physiologique d’un sujet
US9883819B2 (en) 2009-01-06 2018-02-06 Proteus Digital Health, Inc. Ingestion-related biofeedback and personalized medical therapy method and system
US10305544B2 (en) 2009-11-04 2019-05-28 Proteus Digital Health, Inc. System for supply chain management
US9941931B2 (en) 2009-11-04 2018-04-10 Proteus Digital Health, Inc. System for supply chain management
US10529044B2 (en) 2010-05-19 2020-01-07 Proteus Digital Health, Inc. Tracking and delivery confirmation of pharmaceutical products
US11468711B2 (en) 2010-08-09 2022-10-11 Nike, Inc. Monitoring fitness using a mobile device
US11783637B2 (en) 2010-08-09 2023-10-10 Nike, Inc. Monitoring fitness using a mobile device
US12230064B2 (en) 2010-08-09 2025-02-18 Nike, Inc. Monitoring fitness using a mobile device
US11783638B2 (en) 2010-08-09 2023-10-10 Nike, Inc. Monitoring fitness using a mobile device
US11776321B2 (en) 2010-08-09 2023-10-03 Nike, Inc. Monitoring fitness using a mobile device
US11600114B2 (en) 2010-08-09 2023-03-07 Nike, Inc. Monitoring fitness using a mobile device
US11749395B2 (en) 2010-11-01 2023-09-05 Nike, Inc. Wearable device assembly having athletic functionality and milestone tracking
US12125575B2 (en) 2010-11-01 2024-10-22 Nike, Inc. Wearable device assembly having athletic functionality and milestone tracking
US11495341B2 (en) 2010-11-01 2022-11-08 Nike, Inc. Wearable device assembly having athletic functionality and milestone tracking
US12062424B2 (en) 2010-11-01 2024-08-13 Nike, Inc. Wearable device assembly having athletic functionality
US11798673B2 (en) 2010-11-01 2023-10-24 Nike, Inc. Wearable device assembly having athletic functionality and milestone tracking
US11735308B2 (en) 2010-11-01 2023-08-22 Nike, Inc. Wearable device assembly having athletic functionality and milestone tracking
US11710549B2 (en) 2010-11-05 2023-07-25 Nike, Inc. User interface for remote joint workout session
US11915814B2 (en) 2010-11-05 2024-02-27 Nike, Inc. Method and system for automated personal training
US11600371B2 (en) 2010-11-10 2023-03-07 Nike, Inc. Systems and methods for time-based athletic activity measurement and display
US12224053B2 (en) 2010-11-10 2025-02-11 Nike, Inc. Systems and methods for time-based athletic activity measurement and display
US11568977B2 (en) 2010-11-10 2023-01-31 Nike, Inc. Systems and methods for time-based athletic activity measurement and display
US12170138B2 (en) 2010-11-10 2024-12-17 Nike, Inc. Systems and methods for time-based athletic activity measurement and display
US11817198B2 (en) 2010-11-10 2023-11-14 Nike, Inc. Systems and methods for time-based athletic activity measurement and display
US11935640B2 (en) 2010-11-10 2024-03-19 Nike, Inc. Systems and methods for time-based athletic activity measurement and display
US9489815B2 (en) 2011-04-29 2016-11-08 Koninklijke Philips N.V. Apparatus for use in a fall detector or fall detection system, and a method of operating the same
US9756874B2 (en) 2011-07-11 2017-09-12 Proteus Digital Health, Inc. Masticable ingestible product and communication system therefor
US10223905B2 (en) 2011-07-21 2019-03-05 Proteus Digital Health, Inc. Mobile device and system for detection and communication of information received from an ingestible device
EP2845133A2 (fr) * 2012-05-04 2015-03-11 Medtronic MiniMed, Inc. Recouvrement actif d'informations de gestion du diabète sur un affichage
US11744481B2 (en) 2013-03-15 2023-09-05 Otsuka Pharmaceutical Co., Ltd. System, apparatus and methods for data collection and assessing outcomes
US10084880B2 (en) 2013-11-04 2018-09-25 Proteus Digital Health, Inc. Social media networking based on physiologic information
US11950615B2 (en) 2014-01-21 2024-04-09 Otsuka Pharmaceutical Co., Ltd. Masticable ingestible product and communication system therefor
US10398161B2 (en) 2014-01-21 2019-09-03 Proteus Digital Heal Th, Inc. Masticable ingestible product and communication system therefor
US10797758B2 (en) 2016-07-22 2020-10-06 Proteus Digital Health, Inc. Electromagnetic sensing and detection of ingestible event markers
US10187121B2 (en) 2016-07-22 2019-01-22 Proteus Digital Health, Inc. Electromagnetic sensing and detection of ingestible event markers
CN106821353A (zh) * 2017-04-05 2017-06-13 合肥酷睿网络科技有限公司 一种人体健康辅助监控系统
CN109246235A (zh) * 2018-09-30 2019-01-18 广州圣亚科技有限公司 监测数据的接收方法、装置和数据监测系统
CN113742427B (zh) * 2021-09-10 2023-07-18 中国长江电力股份有限公司 一种基于104规约通信异构系统单边数据点上送同步方法
CN113742427A (zh) * 2021-09-10 2021-12-03 中国长江电力股份有限公司 一种基于104规约通信异构系统单边数据点上送同步方法

Also Published As

Publication number Publication date
AUPR113900A0 (en) 2000-11-23
AU2002213656A1 (en) 2002-05-15

Similar Documents

Publication Publication Date Title
WO2002035997A1 (fr) Systeme de surveillance
US20190343461A1 (en) Wireless physiological sensor patches and systems
JP6108470B2 (ja) ロケーションベースのワイヤレス医療装置
CN1968645A (zh) 采集患者的生理信号的传感器
WO2002067122A1 (fr) Systeme et interface de suivi de bio-telemetrie par internet hertzien
Bradai et al. A comprehensive overview of wireless body area networks (WBAn)
Jain Wireless body area network for medical healthcare
Al-Thobhani et al. Implementation Wearable WBANs for e-Healthcare
Al-Thobhani IoSTs in e-healthcare services
Wahane et al. A survey: wireless body area network for health monitoring
Yau et al. IEEE 802.15. 4 Wireless mobile application for healthcare system
Moron et al. J2ME and smart phones as platform for a Bluetooth Body Area Network for Patient-telemonitoring
Al-Thobhani Using WBANs in Healthcare Services
Wang et al. A wireless sensor system for biopotential recording in the treatment of sleep apnea disorder
Al-Thobhani Smart Wireless Sensor Network
Saeed et al. Plug-and-play sensor node for body area networks
Katzis et al. Evaluation of LoRaWAN for Remote Health Monitoring: A Preliminary Study
Coelho et al. A biomedical wearable device for remote monitoring of physiological signals
Yuce Wearable and implantable wireless body area networks
Meeran Smart home technology for aging
Li A mobile ECG monitoring system with context collection
Kirsche Coexistence and Cooperation for IEEE 802.15. 4 powered Wireless Health Care Applications in Scenarios with Dense Radio Conditions
Agila et al. STUDY SOLUTIONS HEALTHCARE MONITORING USING WIRELESS SENSOR NETWORK
Jovanov System architecture of wireless body sensor networks
Gomes Modeling and experimental performance analysis of ZigBee-IEEE 802.15. 4 for wireless body area networks

Legal Events

Date Code Title Description
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WPC Withdrawal of priority claims after completion of the technical preparations for international publication

Ref country code: WO

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载