6 International Journal of Telemedicine and Applications Sensor node Read sensors Send data over radio Receive and enqueue sensor data Base No Reached data threshold? Yes Dequeue data and average sensor readings Send averaged sensor data to server Server Receive sensor data Write data to database Figure 4: Flow diagram of the implementation. pc or at a central database accessed through the internet. The central database would allow access to the patient and valid doctor’s only to insure user privacy. Because data is stored on a computer or server, there is plenty of hard drive space for many weeks worth of data. Thus instead of data from only three nights at a sleep center, a user could get a diagnosis from her last month of sleeping habits. This long-term solution is also viable because the technology is noninvasive and would be practical for a patient to use every night for a month. Additionally, the system itself can give recommendations and customized reports based on the data it collects. This is discussed in further detail in architecture—software design Section 5.2. 5. ARCHITECTURE 5.1. Hardware The hardware we have chosen for PATHOS includes the following. (i) Tmote Sky [5]: every sensor node consists of a Tmote Sky with either embedded sensors or sensors attached through analog output. The motes provide the Zigbee wireless connection and are battery powered, allowing complete freedom of placement. (ii) BCI Micro Power Oximeter Board [6]: an extension for the Tmote Sky that allows a ﬁnger pulse oximeter to be connected directly to the mote. This sensor checks blood oxygen level and also records pulse. (iii) EasySen SBT80—Multi Modality sensor board [7]: another extension board for the Tmote Sky, this board provides additional sensors to the mote, the most important of which are two dual-axis accelerometers which, when combined, can measure motion in three dimensions. (iv) Handheld device or personal computer: forming the base of the network and is responsible for managing the collected data. The program will be implemented so that it is deployable on the user’s existing hardware, cutting down costs and the amount of devices present. (v) Cellular phone: used for collecting data during the day. The daytime collection software can be implemented as either a program that runs on the cell phone or a program running server-side that collects information through text messages or an automated phone system. 5.2. Software design Our software design consists of two separate programs: one running on the nodes and one running on the base station. Figure 2 provides an overview of the programs and how they interact with each other and the user. The program running on the motes is responsible for collecting data from the sensors and processing the data before sending it to the base. The sensors are either built into the nodes (temperature, humidity, movement), or are provided via a wired external sensor (pulse oximeter, thermistors, acoustic). The nodes run the TinyOS operating system and as a result are quite capable of preprocessing the data and transforming the analog voltage input to a format that can be interpreted easily by the base. As soon as the data is processed, it is sent wirelessly to the base. Nodes also have the ability to relay signals from another node that is too far away to connect to the base. Because the Tmote Sky’s ZigBee wireless has a range of over 50 meters (indoor), a node will typically never be out of reach of the base, unless the wireless is scaled back in order to ensure a more secure connection. The software running on the base is more important from the user’s point of view because it is the only aspect of the system that he interacts with regularly. The most important part of the base software is the communication module, which is responsible for gathering the data from