Introduction
A sensor
(also called detector) is a converter that measures a physical quantity and
converts it into a signal which can be read by an observer or by an (today
mostly electronic) instrument.
Sensors are
used in everyday objects such as touch-sensitive elevator buttons (tactile
sensor) and lamps which dim or brighten by touching the base. There are also
innumerable applications for sensors of which most people are never aware.
Applications include cars, machines, aerospace, medicine, manufacturing and
robotics.
The
tremendous growth of sensor technology in Smartphone increases day by day and
will experience fabulously over the next few years. Success of smart phones is
leading to an increasing amount of MEMS & sensors in mobile phones to provide
new features/ services to end-users, to reduce cost through more integration or
to improve hardware performance.
Application
Area monitoring
Area
monitoring is a common application of WSNs. In area monitoring, the WSN is
deployed over a region where some phenomenon is to be monitored. A military
example is the use of sensors to detect enemy intrusion; a civilian example is
the geo-fencing of gas or oil pipelines.
When the
sensors detect the event being monitored (heat, pressure), the event is
reported to one of the base stations, which then takes appropriate action
(e.g., send a message on the internet or to a satellite). Similarly, wireless
sensor networks can use a range of sensors to detect the presence of vehicles
ranging from motorcycles to train cars.
System Integration
Use of the
mobile phone as a sensor in the bubble-sensing system should not interfere with
the normal usage of the mobile phone. Our bubble-sensing software
implementation is light weight, so users can easily switch it to background,
and use their phone as usual. The software only accesses sensors on demand and
release the resources immediately after use. An incoming or user-initiated
voice call has high priority, and our software does not try to access the
microphone when it detects a call connection. By adapting in this way, our
implementation does not disrupt an ongoing call and also the bubble-sensing
application will not get killed by an incoming call. We test the CPU and memory
usage of our software in a Nokia Phone, using a bench mark application,
CPUMonitor . The peak CPU usage is around 25%, which happens when sound clips
are taken. Otherwise, the CPU usage is about 3%. The memory usage is below 5%
of the free memory, including the overhead of the python virtual machine and
all the external modules
Sensors In Smartphones
1
Microphone
2
Accelerometer
3
Ambient Light Sensor
4
Proximity Sensor
5
Gyroscope
6
GPS Module
Experiment Setup
Ten mobile phones are carried by
people who move around three floors of the Dartmouth computer science building.
The carriers stay mobile for the duration of the experiment, except for
momentary pauses at the water cooler, printer, or desk (to check for important
emails). No particular effort is made to orchestrate the mobility to maintain
density in the sensing bubble or elsewhere. The participants are told to carry
the cell phones as they normally would. Most of the time the mobile phones are
put in the front or back pockets and sometime held in the hand (e.g., when
making a call, checking the time, sensing a SMS message, etc). Static beacons
are used to provide a WiFi localization service. In our experiments, the center
of the task bubble is defined to be the Sensor Lab, which is a room on the middle
of the three floors. The task is assumed to already be registered by the bubble
creator. During the experiment, we play music in the bubble and the task is
simply capturing sound clips in this room once every ten seconds. To emulate a
heterogeneous network, we intentionally limit device capabilities (i.e., long
range connectivity and localization) in some cases. We evaluate the following
five different cases ..............
Online Sensing Task Optimization for Shared Sensors
Sensing systems now allow sensors
to be shared among multiple users and applications . Open interfaces using the Internet
protocol and web services have been prototyped to facilitate such shared access
to sensors. Multiple applications can use such sensing infrastructures to
provide new functionalities using live sensor data. Also, within a single
application, multiple users can access different data based on their needs. As
the numbers of applications and users within applications grow, the amount of
data to be provided from the sensors and the amount of computation performed on
that data go up. This increases the load on the sensing infrastructure,
limiting the number of allowable concurrent application requests. “Hot”
sensors, i.e., ones that contain events of interest to several users, are
likely to become especially overloaded. Consider, as an example, the road
traffic sensors deployed by the Department of Transportation on several roads,
to measure the volume and average speed of traffic for the covered road
segments. In a shared system, multiple sensing applications, such as driving
directions computation, traffic characterization , congestion prediction, cab
fleet management, or urban planning tools, may obtain data streams from these
sensors.
0 comments: