Some Importantant links below
with reports.just view the link below. if u want any project report just
search any project on our search box
Arduino interesting projects:
Arduino 30 simple and good projects
Atmega projects lists
Android Electronics projects lists
Rf based Projects with report
engineering study notes
GSM GPS based projects with report
Bluetooth based projects with reports
System Set up
The following chapter will go step by step through each part of the developed
system, including hardware devices and software involved in the development
process. Everything from the initial set up to the data collection stage is covered.
3.1 Sensors
Sensors as a hardware equipment is an essential part of any monitoring device.
The total amount of sensors involved in a monitoring process can be increased,
providing a more sophisticated level of the analysis and enchanting data processing.
Possible suggestions are discussed in Chapter 4 and 6. It was decided,
however, to use a limited amount of sensors in the current project and establish
a reliable connection for subsequent data transferring.
3.1.1 Accelerometer
The accelerometer sensor is an important component of the developed system
as well as any other system involving patients monitoring. It provides a basic information
about daily activity of the person, which can be further modified and
used as one of the parameters for the analysis. Before describing the accelerometer
application and usage in this particular project we consider it sufficient to
mention several features of this type of sensor.
Conceptually, any accelerometer behaves as a damped mass on a spring.
When the accelerometer experiences an acceleration, the mass is displaced to
the point where the spring is able to accelerate the mass at the same rate as the
casing. The displacement is then measured to give the acceleration.
In commercial devices, piezoelectric, piezoresistive and capacitive components
are commonly used to convert the mechanical motion into an electrical
signal1. Piezoelectric accelerometers rely on piezoceramics (e.g. lead zirconate
1Accelerometer, http://en.wikipedia.org/wiki/Accelerometer
31
Figure 3.1: Accelerometer axes
titanate) or single crystals (e.g. quartz, tourmaline). These crystal structures become
stressed by accelerative forces, which causes a voltage to be generated.
Piezoresistive accelerometers are unmatched in terms of their upper frequency
range, low packaged weight and high temperature range and preferred in high
shock applications. Capacitive accelerometers typically use two silicon micromachined
sensing elements. Having these two micro structures next to each
other, creates a certain capacitance between them. If an accelerative force moves
one of the structures, then the capacitance will change. Additionally, converting
some circuitry from capacitance to voltage we will be able to get a full
accelerometer 2. Performance of these type of sensors is superior in the low frequency
range and they can be operated in servo mode to achieve high stability
and linearity. Modern accelerometers are often based on small electromechanical
devices (micro electro-mechanical systems or MEMS) and normally inbuilt
in the latest generation of the smart phones (including the one involved in the
project). In our case it can be reached by programming through the android
operating system with the help of ”SensorManager“ class and special Sensor
Activity. The simple pseudo code example is provided below:
S e n s o rAc t i v i t y {
g e t S e n s o r S e r v i c e ( ) ;
g e tDe f aul t S ensor ( SensorType ) ;
onResume ( ) {
r e g i s t e r S e n s o r L i s t e n e r ( t h i s , Ac c e l e rome t e r ) ;
}
onPause ( ) {
u n r e g i s t e r S e n s o r L i s t e n e r ( t h i s , Ac c e l e rome t e r ) ;
2A beginner’s guide to accelerometers, http://www.dimensionengineering.com/accelerometers.htm
3.1. SENSORS 33
}
onSensorChanged ( SensorEvent ) {
Do something i f s ensor i s moved ;
}
}
Once the sensor is activated there are several methods provided by the previously
mentioned class which can be used in order to measure activity. It is
represented by three variables x,y,z which output device acceleration along the
raw, pitch and yaw direction[33] (see Figure 3.1). First of all, we need to make
sure at least one sensor is available for the measuring process. A special method
”isSupported“ is used for this purpose:
i sSuppor t ed ( ) {
i f ( notSuppor ted ) {
g e t S y s t emS e r v i c e ( s e n s o r S e r v i c e ) ;
L i s t s ensor s = g e t S e n s o rLi s t ( ac c e l e rome t e rType ) ;
suppor ted = new Boolean ( s e n s o r s S i z e ) ;
} e l s e {
do nothing i f s ensor i s suppor ted ;
}
}
r e turn suppor ted ;
}
The next step is to invoke a special ”startListening“ process which registers
a listener and starts listening to the accelerometer callback for possible events
(shaking, changing position etc.). This method also includes a configuration
component where we can decide on a threshold for the changes in accelerometer
and interval between shakes. It can help to react only on significant changes
and simplify data collection in the next stages.
Now, any change/event, which arises while the accelerometer is in the ”listening
mode” will be registered and processed. It is reasonable to introduce a
threshold for eliminating insignificant changes in raw/pitch/yaw values of the
accelerometer. All the values below this threshold will not be considered. We
can furthermore use previously detected acceleration and display it on a screen
or store it in a file for further processing. Both options are implemented in our
case. Possible approaches for accelerometer data processing will be described
in Chapter 4.
3.1.2 Nonin Wrist 0x2
The following section is dedicated to the technical specifications of the sensor
device used in this project. Description is based on a ”Fingertip Oximeter
Technology Specifications” document [1] and provides additional information
concerning the current system features. The picture of the sensor is provided on
All the technical specification and parameters of the Pulse Oximeter are
combined into an appropriate table (see Figure ??). The most significant information
in terms of the system development are Oxygen Saturation and Pulse
Rate Accuracy.
The table is followed by bluetooth configurations including Operating Frequency
and Operating Range.
Technically, Nonin Wrist 0x2 oximeter is a slave device. To connect sensor
to a master device, the master device must first associate with the 3150 by inquiring
for the 3150. For the initial pairing of a new host device (master) to
the 3150, it is discoverable for a minimum of 2 minutes after power-on. During
the discovery period, the 3150 will broadcast a friendly name to the master.
The name starts with ”Nonin_Medical_Inc._”, followed by a 6-digit number,
referred to as the PIN. The PIN is etched on the back of the 3150 enclosure.
To complete the pairing process once the master (host) device finds the 3150,
the PIN must be provided to the master device. Once paired, the master must
establish the connection to the sensor.
This particular model provides measurements in several different data formats:
• Data format 13 – provides easy spot-check measurements with the storage
and forwarding of measurements.
• Data format 8 – provides real-time oximetry measurements every second.
• Data format 2 – provides real-time oximetry measurements with compressed
waveform (8 bit waveform) every 1/75 of a second.
• Data format 7 – provides real-time oximetry measurements with full resolution
waveform (16 bit waveform) every 1/75 of a second.
For data formats 1, 2, 7 and 8, the 3150 will not initiate the connection using
the attempt to reconnect (ATR) option. If the system has only one COM port
available, data format 2, 7, 8, or 13 should be used with the ATR disabled. The
master device must initiate the connection by occasionally polling for the 3150.
For an automatic wireless reconnection, a software should be designed to periodically
poll for the 3150. If polling for the 3150 is not possible, Bluetooth
connection should be started manually. Because the manual method typically
requires the user to initiate the Bluetooth connection, the seek/polling method
has its advantages.
The 3150 will be discoverable when not paired to an existing master. Any
previous master devices should be off. Once the device pairs and establishes the
Bluetooth connection with the 3150, sensor will automatically send continuous
data to device as defined in Data Format Definition section later. For further details
on establishing a Bluetooth wireless connection see Appendix A. A Bluetooth
connection indicator becomes available on the screen, after pushing and
holding a bluetooth button. Once the Bluetooth connection is established, the
3150 receives and transmits data using the SPP protocol. Additionally, there are
several settings and commands for data format and time information:
(1) Setthe Data Format and Activation,
(2) Set Multiple Parameters,
(3) Set the Date and Time in the 3150,
(4) Set Bluetooth Radio timeout (power saving feature),
(5) Get the Date and Time from the 3150,
(6) Get the Serial Number in the3150,
(7) Get revision number.
In each case user must send a preliminary byte command string in order to
select Data format, set or retrieve time. A data format is a key information for
receiving, displaying and processing the sensor measurements. Thus, it is important
to mention several details on it’s structure. A default Serial Date Format 2
(one of the listed above) was used in development. This data format provides
continuous data transmission of a 5 byte data packet sent 75 times per second.
The data packet includes real-time data of: 8-bit waveform value, beat-to-beat
SpO2 value, SpO2 and Pulse Rates values formatted for both recording and
display purposes, status of the measurement and battery. Each particular byte
represents a valid information.
Byte 1 – START BYTE:
Always set to a 01 value.
Byte 2 – STATUS BYTE:
This byte provides status information at a rate of 1/75 of second.
Range: 128 to 255
Byte 3 – PLETH BYTE:
This byte consists of an 8 bit plethsmographic waveform (pulse waveform).
The pulse oximeter infra-red signal is filtered and then compressed into an 8 bit
value. The compression provides good detail for low to large pulse signals. For
uncompressed waveform refer to Data Format 7.
Range: 00 to 255
Byte 4 – FLOAT BYTE:
This byte is used for SpO2, Pulse Rate, and information that can be processed
at a rate of 1/3 of second.
Range: 00 to 127
When the device is removed from the finger the last SpO2 and Pulse Rate
reading will be reported for 10 seconds before changing to the missing data
value. During this 10 second period the sensor alarm bit (SNSA) is set, indicating
that the finger has been removed. This feature is useful for spot-check
measurements. When SpO2 and HR cannot be computed, the system will send
a missing data indicator. For missing data, the HR equals 511 and the SpO2
equals 127.
Byte 5 – CHK:
This byte is used for the checksum of bytes 1 through 4.
A concrete information on the processing of the sensor measurements can be
found in Chapter 4 of the thesis.
3.2 Processing Device
The current section will go through the second part of system hardware used for
the developing purposes. Several main aspects concerning technical parameters
and programming Android API (Application Programming interface) will be
covered and formulated according to their involvement in the process.
3.2.1 Samsung smart-phones
All the information sent by sensors (excluding accelerometer, inbuilt in phone)
can be received by processing device through Bluetooth connection. Both Samsung
Galaxy S and Samsung Galaxy Tab used for the actual thesis work, have
a Bluetooth functionality. Thus, next step would be to get an access to this feature
through the programming language, which is in our case Java. No license
or special agreement is required to program previously mentioned devices, both
based on an Android operating system.
Before proceeding to the next step, it is important to mention some general
aspects about Bluetooth option. According to the both smart-phones manuals,
Bluetooth is a short-range wireless communications technology capable of exchanging
information over a distance of about 10 m without requiring a physical
connection [36]. Furthermore, we do not need to line up the devices to beam
information with Bluetooth. If devices are within the range of one another, any
information exchange between them is possible even if they are located in different
rooms. However, we should always ensure that sharing and receiving data
is performed with devices that are trusted and properly secured. If there are obstacles
between the devices, the operating distance may be reduced. Moreover,
some devices, especially those that are not tested or approved by Bluetooth SIG
3, may be incompatible with the involved device.
Other than Bluetooth option, there are more technical parameters possessed
by Samsung Galaxy S, making it sufficient enough to be involved in monitoring
system and subsequent data analysis. The parameters within our scope are
memory (capacity) and operating frequency. The Samsung Galaxy S has the
S5PC110 processor. This processor combines a 45 nm 1 GHz ARM Cortex-
A8 based CPU core with a PowerVR SGX 540 GPU made by Imagination
Technologies which supports OpenGL ES 1.1/2.0 and is capable of up to 20
3Special Interest Group, http://www.bluetooth.com/Pages/About-Us.aspx
million triangles per second. The CPU core, code-named ”Hummingbird”, was
co-developed by Samsung and Intrinsity.
In terms of memory, the Samsung Galaxy S has 512 MB of dedicated LPDDR2
RAM (Mobile DDR) and 16-32 MB of OneDRAM. Some variants also come
with either 8GB or 16GB of OneNAND memory combined in a package-onpackage
stack with the processor. An external microSD card slot supports up
to 32GB of additional storage memory 4. Additionally, the smart-phones used
for programming runs on Android 2.1 (a.k.a. ”Eclair”) operating system.
3.2.2 Application development
It was decided to use Eclipse programming environment for development as one
of the most sufficient and user friendly. All the communications between processing
device and sensors are implemented through the application interface.
A special application was designed and successfully ran for this particular purpose.
The first step and a one of the main goals of this program was to establish
a reliable connection. Once connection is initialized and running, it is important
to maintain a signal in order to provide consistent interaction. In other
words, we want to continuously store all the data received from the sensor in
the phone memory and any kind of interruption would negatively affect the
quality of the future analysis. A special android project was created, based on
the Eclipse software in order to use all the available classes of android development
environment. A project consists of two main ”activities” and one special
”service” which is responsible for a consistent data transmission. We consider
it important to highlight main parts of these programming components in the
following description.
Firstly, we want to ensure the Bluetooth option is available and enabled
on the device before we start any kind of operations [27]. Two simple commands
perform a system check for both previously mentioned cases and can be
executed with the following pseudo code:
/ / check i f blue tooth i s suppor ted
i f ( BluetoothAdapter ( notSuppor ted ) ) {
pr intOut ( ’ ’ Blue tooth i s not a v a i l a b l e ’ ’ ) ;
f i n i s h ( ) ;
r e turn ;
}
and
/ / check i f blue tooth i s enabled
i f ( BluetoothAdapter ( notEnabled ) ) {
BluetoothAdapter = Act ionReques tEnable ;
}
The last command sends a request to enable bluetooth on the operating device
in case this option is currently disabled. Once bluetooth function is switched on,
4Samsung Galaxy, http://en.wikipedia.org/wiki/Samsung_Galaxy_S
we can proceed to the next step. An advanced user interface was not among the
highest priorities of this project, however, several options are available within
the main application screen depicted below.
It is important to store some basic patients personal information, which will
be further used in data processing part. So, as it is shown on Figure 3.5, every
user can type in and save his/her age and weight in the corresponding field.
The number will be later written to a special file and ready to be extracted for
processing.
Figure 3.5: Application main screen
Next option allows user to get an access to accelerometer sensor through
the android API. This part was described more specifically in Section 3.1.1 of
this thesis. A data storing procedure is performed again. This time a special
file, representing accelerometer along three axis is created and updated continuously.
Current numbers are displayed on a screen and match the values stored
to the device memory. You can read more about data format in Section 3.2.3
of the current chapter.
After accelerometer is set up and running, we can proceed to the main part,
where connection between a sensor and android phone needs to be established.
A ”START APP” button will initiate a second main activity, which provides
user with a list of paired devices and opportunity to search for new ones (see
Figure 3.6).
In order to create a connection between application and a remote device
(sensor in our case), we must implement either server-side or client-side mechanisms,
because one device must open a server socket and the other one must
initiate the connection (using the server device’s MAC address to initiate a connection).
The server and client are considered connected to each other when
they each have a connected BluetoothSocket on the same RFCOMM channel.
At this point, each device can obtain input and output streams and data trans40
fer can begin. We are interested in client-side option.
So, in order to initiate a connection with a sensor (a device holding an
open server socket), we should first obtain a BluetoothDevice object that represents
the remote device. After that we use the BluetoothDevice to acquire a
BluetoothSocket and initiate the connection. This part of the mechanism is implemented
in a ”BluetoothService” section of the program.
After device is chosen and bluetooth connection service is running, application
will automatically return to a main screen and we can now observe
measurements below the ”Oximeter sensor” section on a display. A step by
step tutorial on starting sensor readings is provided in a special manual (see
Appendix A) written for the Backagården personnel.
3.2.3 Data collection
Once the system is set up properly and the main application has been started
on the testing device, it is possible to start data collection for the subsequent
analysis. Two possible categories of the data that can be processed are represented
by two different scenarios. Firstly, we perform testing with the healthy
person, who is unlikely to have any kind of abnormalities and moreover any
kind of chronic diseases. A second data set is expected to come from preliminary
selected patients, who agreed to participate in the experimental part of
the current research. The experimental part is described in details further below
forming Chapter 5 of the thesis. The process implies receiving, storing and
analyzing the data extracted from the measuring devices. All the information is
sent via Bluetooth channel establishing “mobile phone - sensor” communication.
processing device. Each measurement is retrieved from a different source and
represented by four separate files:
• sensors.txt (pulse rate and oxymetry)
• activity.txt (raw, pitch, yaw from accelerometer)
• age.txt (user input)
• weight.txt (user input)
The first two files have a particular format and consist of three separate column
vectors, including a special time vector.
20110519T175925 82 96
20110519T175927 82 97
20110519T175929 82 96
20110519T175931 82 96
This information is intended to simplify and at the same moment significantly
improve further analysis of the data. Having access to the time makes it easier
to register every particular change and follow the input flow as it is shown on
The entire concept of Chapter 3 was based on several goals announced in
the introduction part of the thesis. Firstly, it was required to establish a reliable
connection between sensor and processing device, which is impossible without
considering key aspects of sensor technical specification such as data format
and operating modes. Secondly, we provide general information on data collection
procedure, which is summarized in Table 3.1 above. Moreover, Table 5.3
T
from Section 5.2 contains detailed information about data transfer, including
data loss in percentage. These measurements are sent and retrieved in a particular
format (see a cutout of measurements above), developed for this particular
application. It was designed to cover all the details and provide user with an
easy interface for a sensor - device communication. The very same application
carries out a data collection procedure.
Some Importantant links below
with reports.just view the link below. if u want any project report just
search any project on our search box
Arduino interesting projects:
Arduino 30 simple and good projects
Atmega projects lists
Android Electronics projects lists
Rf based Projects with report
engineering study notes
GSM GPS based projects with report
Bluetooth based projects with reports
if u like the post just say thank u in comment box.
