Commit fb228471 authored by U-RAJESH-SIS\rajesh's avatar U-RAJESH-SIS\rajesh
parents 23c38919 4a432a88
This is BibTeX, Version 0.99d (TeX Live 2017/Cygwin)
Capacity: max_strings=100000, hash_size=100000, hash_prime=85009
The top-level auxiliary file: batteryless.aux
The style file: ACM-Reference-Format.bst
Reallocated singl_function (elt_size=4) to 100 items from 50.
Reallocated wiz_functions (elt_size=4) to 6000 items from 3000.
Database file #1: batteryless.bib
Warning--I'm ignoring rozner2010's extra "author" field
--line 529 of file batteryless.bib
Warning--I'm ignoring rozner2010's extra "title" field
--line 531 of file batteryless.bib
Warning--I'm ignoring rozner2010's extra "booktitle" field
--line 533 of file batteryless.bib
Warning--I'm ignoring rozner2010's extra "series" field
--line 535 of file batteryless.bib
Warning--I'm ignoring rozner2010's extra "year" field
--line 537 of file batteryless.bib
Warning--no key, author in solepower
Warning--no author, editor, organization, or key in solepower
Warning--to sort, need author or key in solepower
Warning--no key, author in stm32L053
Warning--no author, editor, organization, or key in stm32L053
Warning--to sort, need author or key in stm32L053
Warning--no key, author in warpv3
Warning--no author, editor, organization, or key in warpv3
Warning--to sort, need author or key in warpv3
Warning--no key, author in solepower
Warning--no key, author in solepower
Warning--no key, author in stm32L053
Warning--no key, author in stm32L053
Warning--no key, author in warpv3
Warning--no key, author in warpv3
Reallocated singl_function (elt_size=4) to 100 items from 50.
Warning--no key, author in warpv3
Warning--no author, editor, organization, or key in warpv3
Warning--no key, author in solepower
Warning--no author, editor, organization, or key in solepower
Warning--no key, author in stm32L053
Warning--no author, editor, organization, or key in stm32L053
Warning--empty address in campbell2014
Warning--page numbers missing in both pages and numpages fields in campbell2014
Warning--empty address in campbell2014b
Warning--page numbers missing in both pages and numpages fields in campbell2014b
Warning--empty publisher in chen2013
Warning--empty address in chen2013
Warning--page numbers missing in both pages and numpages fields in chen2013
Warning--empty address in ertin2011
Warning--empty publisher in felini2014
Warning--empty address in felini2014
Warning--page numbers missing in both pages and numpages fields in felini2014
Warning--page numbers missing in both pages and numpages fields in hande2007
Warning--empty address in hester2017
Warning--page numbers missing in both pages and numpages fields in hester2017
Warning--empty address in hester2017b
Warning--page numbers missing in both pages and numpages fields in hester2017b
Warning--empty publisher in jain2011practical
Warning--empty address in jain2011practical
Warning--page numbers missing in both pages and numpages fields in li2017
Warning--empty address in lin2005
Warning--page numbers missing in both pages and numpages fields in lin2005
Warning--empty address in parate2014
Warning--empty publisher in pu2013whole
Warning--empty address in pu2013whole
Warning--empty address in rozner2010
Warning--page numbers missing in both pages and numpages fields in rozner2010
Warning--page numbers missing in both pages and numpages fields in ryokai2014
Warning--empty publisher in sen2008
Warning--empty address in sen2008
Warning--empty publisher in talla2015powering
Warning--empty address in talla2015powering
Warning--empty address in thomaz2015
Warning--empty address in vasisht2016
Warning--empty booktitle in xiong2013arraytrack
Warning--empty publisher in xiong2013arraytrack
Warning--empty address in xiong2013arraytrack
Warning--page numbers missing in both pages and numpages fields in xiong2013arraytrack
Warning--articleno or eid field, but no numpages field, in xu2013
Warning--page numbers missing in both pages and numpages fields in xu2013
Warning--articleno or eid, but no pages or numpages field in xu2013
Warning--empty publisher in tran2017
Warning--empty address in tran2017
Warning--page numbers missing in both pages and numpages fields in tran2017
Warning--empty publisher in yeager2008
Warning--empty address in yeager2008
Warning--page numbers missing in both pages and numpages fields in yeager2008
Warning--no number and no volume in yildiz2007
Warning--page numbers missing in both pages and numpages fields in yildiz2007
You've used 34 entries,
5706 wiz_defined-function locations,
1512 strings with 22579 characters,
and the built_in function-call counts, 37124 in all, are:
= -- 4389
> -- 1589
< -- 0
+ -- 498
- -- 518
* -- 2840
:= -- 3845
add.period$ -- 166
call.type$ -- 34
change.case$ -- 255
chr.to.int$ -- 33
cite$ -- 115
duplicate$ -- 3022
empty$ -- 2219
format.name$ -- 629
if$ -- 8987
int.to.chr$ -- 2
int.to.str$ -- 0
missing$ -- 143
newline$ -- 335
num.names$ -- 247
pop$ -- 1511
preamble$ -- 1
purify$ -- 424
quote$ -- 0
skip$ -- 1067
stack$ -- 0
substring$ -- 2251
swap$ -- 231
text.length$ -- 0
text.prefix$ -- 0
top$ -- 0
type$ -- 860
warning$ -- 69
while$ -- 192
width$ -- 0
write$ -- 652
(There were 74 warnings)
......@@ -2,9 +2,10 @@
\label{sec:conclusion}
In this paper, we presented \names, a first of its kind system that uses
beamforming to harvest up to 800$\mu$W of energy using WiFi transmissions on
a receiver located 3 to 4 meters away. \name couples this harvesting with
smart event triggering to duty cycle a full wearable device that uses 40 or
more mW of power. We demonstrated this via detailed systems and user study
results with a prototype wearable sensing device that periodically transmits
sensor data.% \raj{what do we say here?}
beamforming of WiFi transmissions to enable a wearable receiver to harvest up to 800$\mu$W of energy,
while located 3-4 meters away. \name couples this harvesting with smart event triggering, using a kinetic motion sensor, to duty cycle a full wearable device whose instantaneous power drain is 40 mW or higher. Via measurements and user studies performed in a representative office setting, we see
that \name can be a viable approach for batteryless wearable sensing. We also identify open issues to tackle, before \name can
be ubiquitously deployed in a production environment.
% name demonstrated this via detailed systems and user study
% results with a prototype wearable sensing device that periodically transmits
% sensor data.% \raj{what do we say here?}
\section{Discussion}
\label{sec:discussion}
Our research results, using an admittedly `proof-of-concept' wearable platform, show that the \name paradigm of beamformed WiFi energy harvesting can be used to monitor the gestural activities of individuals, at least in an office-like environment. There are, however, several open issues and considerations that need further exploration.
Our results, using an admittedly `proof-of-concept' wearable platform, show that \namef paradigm of beamformed WiFi energy harvesting can be used to monitor the gestural activities of individuals, at least in an office-like environment. There are, however, several open issues to explore further.
\textbf{Beamforming for Multiple Receivers:} The bulk of our studies have considered just a single wearable device. Limited studies (in Section~\ref{sec:multiuser}) show that, when multiple client devices are present, an AP can judiciously either time-multiplex its power packet transmissions to different devices, or adjust its beamwidth to simultaneously cover multiple devices, albeit with lower harvesting power/device. Such multi-device environments require the WiFI AP to optimize its operations carefully considering coverage vs. energy density tradeoffs (as a function of beamwidth), similar to the prior exploration of rate vs. coverage tradeoffs for multicast wireless traffic~\cite{chou2006} or throughput maximization under directional transmissions~\cite{sen2008}. In addition, different client devices may have different residual energy and/or different priorities in energy harvesting policies. In particular, clients can transmit `ping' packets that encode the criticality of their energy demand, thereby allowing an individual WiFi AP to dynamically adjust its optical choices of (beamwidth, direction, timeslice).
\textbf{Beamforming for Multiple Receivers:} The bulk of our studies have considered just a single wearable device. Limited studies (in Section~\ref{sec:multiuser}) show that, when multiple client devices are present, an AP can judiciously either time-multiplex its power packet transmissions to different devices, or adjust its beamwidth to simultaneously cover multiple devices, albeit with lower harvesting power/device. Such multi-device environments require the WiFI AP to optimize its operations carefully considering coverage vs. energy density tradeoffs (as a function of beamwidth), similar to the prior exploration of rate|throughput|coverage tradeoffs in broadcast wireless networks~\cite{chou2006,sen2008}. In addition, different client devices may have different residual energy and/or different harvesting priorities. In particular, clients can transmit `ping' packets that encode the criticality of their energy demand, thereby allowing an individual WiFi AP to dynamically adjust its optical choices of (beamwidth, direction, timeslice).
\textbf{Multi-AP Operation:} Our controlled user studies have been performed using a single WiFi AP. In a practical campus or factory environment, multiple APs are likely to `cover' a specific location (from measurements, the typical number of APs overhead at a location in our campus buildings is 5-6). This opens up additional possibilities. First, the presence of multiple APs can lead to an additive increase in the harvested energy, as a single client device can receive RF energy from multiple transmitters. On the other hand, as suggested by Figure~\ref{fig:edev2beam}, beams on the same channel may also interfere destructively. However, this will also require enhancements to the RF harvester module on the wearable (similar to the design innovations in~\cite{talla2015powering}), to allow the harvester to simultaneously have multiple resonant frequencies, each corresponding to a different AP's operating frequency. The benefits of such added harvested energy vs. additional receiver complexity are unclear and require further investigation. Second, our current WARP-based AP implementation focused only on power packet transmissions. In practice, each AP will have to perform CSMA-based channel access to avoid contentions with the data traffic transmissions. Moreover, if RF charging may be viewed as a secondary benefit of WiFi APs, it is important to adjust the schedule \& duty cycle of power packet transmissions (e.g., by using multiple virtual queues similar to NAPman~\cite{rozner2010}) to ensure that they do not cause unacceptable loss or latency of data packets.
\textbf{Multi-AP Operation:} Our controlled user studies have been performed using a single WiFi AP. In a practical campus or factory environment, multiple APs are likely to `cover' a specific location (from measurements, the number of APs overheard at a typical location in our campus buildings is 5-6). This opens up additional possibilities. First, the presence of multiple APs can lead to an additive increase in the harvested energy, as a single client device can receive RF energy from multiple transmitters. On the other hand, as suggested by Figure~\ref{fig:edev2beam}, beams on the same channel may also interfere destructively. However, this will also require enhancements to the RF harvester module on the wearable (similar to the design innovations in~\cite{talla2015powering}), to allow the harvester to simultaneously utilize multiple resonant frequencies, each corresponding to a different AP's operating channel. The benefits of such added harvested energy vs. additional receiver complexity are unclear and require further investigation. Second, our current WARP-based AP implementation focused only on power packet transmissions. In practice, each AP will have to perform CSMA-based channel access to avoid contentions with the data traffic transmissions. Moreover, as RF charging may be viewed as a secondary benefit of WiFi APs, it is important to adjust the schedule \& duty cycle of power packet transmissions (e.g., by using multiple virtual queues, similar to NAPman~\cite{rozner2010}) to ensure that they do not cause unacceptable loss or latency of data packets.
\textbf{Additional \& Improved Energy Harvesting:} One of our key contributions is to demonstrate that, with appropriate beamforming, standards-compliant WiFi transmissions can provide harvestable power levels of O(100$\mu$W) at reasonable distances (2-3m). In contrast, as an exemplary alternative,
ambient light energy (indoors) is projected to provide~\cite{yildiz2007} a harvestable power density of 100$\mu$W/cm$^2$, implying a harvesting capability of roughly around 1200$\mu$W for a typical $12cm^2$ smartwatch surface. It is entirely possible that, depending on the use case, wearables may combine WiFi/RF harvesting with other other ``traditional'' harvestable energy alternatives, such as ambient light and vibrations. The attractiveness of the \name prototype comes from our belief that WiFi is more pervasive and that WiFi-based harvesting can occur continuously (e.g., at night, in a dark room). In addition, our wearable prototype uses a straightforward whip antenna for energy harvesting. The antenna has a gain of 2.1 dBi, but it's performance is poor in the vertical direction. It is very likely that alternative antenna form factors (e.g., a metallic strip-based ``patch antenna, illustrated in Figure~\ref{fig:patchantenna}) can increase the harvested energy significantly (see~\cite{chen2013})--the development of suitable design forms for such RF-powered wearables remains an open question.
ambient light energy (indoors) is projected to provide~\cite{yildiz2007} a harvestable power density of 100$\mu$W/cm$^2$, implying a harvesting capability of roughly around 1200$\mu$W for a typical $12cm^2$ smartwatch surface. It is entirely possible that, depending on the use case, wearables may combine WiFi/RF harvesting with other other ``traditional'' harvestable energy alternatives, such as ambient light and vibrations. The attractiveness of the \name prototype comes from our belief that WiFi permits more pervasive and continuous harvesting (e.g., at night, in a dark room). In addition, our wearable prototype uses a straightforward whip antenna for energy harvesting. The antenna has a gain of 2.1 dBi, but it's performance is poor in the vertical direction. It is very likely that alternative antenna designs (e.g., a metallic strip-based ``patch antenna, illustrated in Figure~\ref{fig:patchantenna}) can increase the harvested energy significantly (see~\cite{chen2013}). The development of suitable design forms for such RF-powered wearables remains an open question.
\begin{figure}[!h]
\centering
......@@ -18,6 +18,6 @@ ambient light energy (indoors) is projected to provide~\cite{yildiz2007} a harve
\label{fig:patchantenna}
\end{figure}
\textbf{Other Application Domains \& Paradigms:} Our investigations in this paper have been confined to the use of a single AP, with 1-2 users, in an office-like setting. Variations of the core \name concept may find applicability in other settings. For example, WiFi AP-based energy harvesting may be used to capture key locomotion and gesture-related behaviors (e.g., fall \& eating detection) by elderly inhabitants in smart home environments. Similarly, such WiFi harvesting may be used by static sensors, deployed in industrial sites, warehouses and offshore platforms. In such cases, the RF power may be delivered not by static WiFi APs, but by mobile drones which move around to both collect data (like a data mule) and deliver energy (like a postman). Our current experience, however, suggests that, even with the increased power efficiency of beamformed WiFi transmissions, the client devices will need to adopt an event-triggered sensing paradigm, as the energy is unlikely to be enough to sustain continuous sensing.
\textbf{Other Application Domains \& Paradigms:} Our investigations in this paper have been confined to the use of a single AP, with 1-2 users, in an office-like setting. Variations of the core \name concept may find applicability in other settings. For example, WiFi AP-based energy harvesting may be used to capture key locomotion and gesture-related behaviors (e.g., fall \& eating detection) of elderly inhabitants in smart homes. Similarly, such WiFi harvesting may be used by static sensors, deployed in industrial sites, warehouses and offshore platforms. In such cases, the RF power may be delivered by mobile WiFi drones which move around to both collect data (like a data mule) and deliver energy (like a postman). Our current experience, however, suggests that, even with the increased power efficiency of beamformed WiFi transmissions, client devices will require an event-triggered sensing approach, as the harvested energy is unlikely to sustain continuous sensing.
\section{Discussion}
\label{sec:discussion}
Our research results, using an admittedly `proof-of-concept' wearable platform, show that the \name paradigm of beamformed WiFi energy harvesting can be used to monitor the gestural activities of individuals, at least in an office-like environment. There are, however, several open issues and considerations that need further exploration.
\textbf{Beamforming for Multiple Receivers:} The bulk of our studies have considered just a single wearable device. Limited studies (in Section~\ref{sec:multiuser}) show that, when multiple client devices are present, an AP can judiciously either time-multiplex its power packet transmissions to different devices, or adjust its beamwidth to simultaneously cover multiple devices, albeit with lower harvesting power/device. Such multi-device environments require the WiFI AP to optimize its operations carefully considering coverage vs. energy density tradeoffs (as a function of beamwidth), similar to the prior exploration of rate vs. coverage tradeoffs for multicast wireless traffic~\cite{chou2006} or throughput maximization under directional transmissions~\cite{sen2008}. In addition, different client devices may have different residual energy and/or different priorities in energy harvesting policies. In particular, clients can transmit `ping' packets that encode the criticality of their energy demand, thereby allowing an individual WiFi AP to dynamically adjust its optical choices of (beamwidth, direction, timeslice).
\textbf{Multi-AP Operation:} Our controlled user studies have been performed using a single WiFi AP. In a practical campus or factory environment, multple APs are likely to `cover' a specific location (from measurements, the typical number of APs overhead at a location in our campus buildings is 5-6). This opens up additional possibilities. First, the presence of multiple APs can lead to an additive increase in the harvested energy, as a single client device can receive RF energy from multiple transmitters. On the other hand, as suggested by Figure~\ref{fig:edev2beam}, beams on the same channel may also interfere destructively. However, this will also require enhancements to the RF harvester module on the wearable (similar to the design innovations in~\cite{talla2015powering}), to allow the harvester to simultaneously have multiple resonant frequencies, each corresponding to a different AP's operating frequency. The benefits of such added harvested energy vs. additional receiver complexity are unclear and require further investigation. Second, our current WARP-based AP implementation focused only on power packet transmissions. In practice, each AP will have to perform CSMA-based channel access to avoid contentions with the data traffic transmissions. Moreover, if RF charging may be viewed as a secondary benefit of WiFi APs, it is important to adjust the schedule \& duty cycle of power packet transmissions (e.g., by using multiple virtual queues similar to NAPman~\cite{rozner2010}) to ensure that they do not cause unacceptable loss or latency of data packets.
\textbf{Additional \& Improved Energy Harvesting:} One of our key contributions is to demonstrate that, with appropriate beamforming, standards-compliant WiFi transmissions can provide harvestable power levels of O(100$\mu$W) at reasonable distances (2-3m). In contrast, as an exemplary alternative,
mbient light energy (indoors) is projected to provide~\cite{yildiz2007} a harvestable power density of 100$\mu$W/cm$^2$, implying a harvesting capability of roughly around 1200$\mu$W for a typical $12cm^2$ smartwatch surface. It is entirely possible that, depending on the use case, wearables may combine WiFi/RF harvesting with other other ``traditional'' harvestable energy alternatives, such as ambient light and vibrations. The attractiveness of the \name prototype comes from our belief that WiFi is more pervasive and that WiFi-based harvesting can occur continuously (e.g., at night, in a dark room). In addition, our wearable prototype uses a straightforward XXX\am{Vu:say a couple of words about the antenna} antenna for energy harvesting. It is very likely that alternative antenna form factors (e.g., a metallic strip-based ``patch antenna, illustrated in Figure~\ref{fig:patchantenna}) can increase the harvested energy significantly (see~\cite{chen2013})--the development of suitable design forms for such RF-powered wearables remains an open question.
\begin{figure}[!h]
\centering
\includegraphics[height=1.7in,width=2.8in]{patch.png}
\caption{Patch Antenna for RF Harvesting}
\label{fig:patchantenna}
\end{figure}
\textbf{Other Application Domains \& Paradigms:} Our investigations in this paper have been confined to the use of a single AP, with 1-2 users, in an office-like setting. Variations of the core \name concept may find applicability in other settings. For example, WiFi AP-based energy harvesting may be used to capture key locomotion and gesture-related behaviors (e.g., fall \& eating detection) by elderly inhabitants in smart home environments. Similarly, such WiFi harvesting may be used by static sensors, deployed in industrial sites, warehouses and offshore platforms. In such cases, the RF power may be delivered not by static WiFi APs, but by mobile drones which move around to both collect data (like a data mule) and deliver energy (like a postman). Our current experience, however, suggests that, even with the increased power efficiency of beamformed WiFi transmissions, the client devices will need to adopt an event-triggered sensing paradigm, as the energy is unlikely to be enough to sustain continuous sensing.
......@@ -106,14 +106,14 @@ Figures~\ref{fig:2usertime} and~\ref{fig:2userseparated} plot the case for the t
\centering
\begin{minipage}{.48\textwidth}
\centering
\includegraphics[height=1.4in, width=2.6in]{2user_time.pdf}
\includegraphics[height=1.5in, width=3in]{2user_time.pdf}
\vspace{-0.1in}
\caption{Power drain (2 users) in Multiplexed mode.}
\label{fig:2usertime}
\end{minipage}%
\begin{minipage}{.48\textwidth}
\centering
\includegraphics[height=1.4in, width=2.6in]{2user_neg.pdf}
\includegraphics[height=1.5in, width=3in]{2user_neg.pdf}
\vspace{-0.1in}
\caption{Power drain (2 users)in Concurrent mode}
\label{fig:2userseparated}
......
......@@ -23,7 +23,7 @@ In this section, we present the overall functional architecture of \names, detai
\end{subfigure}
\end{tabular}
\vspace{-0.1in}
\caption{3-step model of \name architecture. a) Step1: The wearable send a ping packet when triggered by gestures. b) Step2: The AP receive ping packets and estimates AoA of the device, and concentrates its energy toward the device. c) Step3: The device harvests the energy and operate its sensors, and transmit the data back the the server once available.}
\caption{3-step model of \name architecture. a) Step1: The wearable send a ping packet when triggered by gestures. b) Step2: The AP receives ping packets and estimates AoA of the device, and concentrates its energy toward the device. c) Step3: The device harvests the energy and operate its sensors, and transmit the data back the the server once available.}
\vspace{-0.1in}
\label{fig:overview}
\end{figure*}
......@@ -51,7 +51,7 @@ With the adoption of MIMO technologies in the latest 802.11n and 802.11ac WiFi s
\end{figure}
\subsection{Locating the Client Device}
For beamformed energy transfer to be effective, the WiFi AP needs to know the location of the client device. More specifically, the AP does not really need to know the client's precise location; what it needs is the \emph{angular direction} of the client, \emph{relative to the AP's own location}. To compute this, the WiFi AP utilizes its antenna array to determine the AoA of any wireless transmissions from the client device. The key principle for such angle/direction estimation is that the same signal propagates different amounts of distances to reach different antennas located at the AP, and thus manifests itself in slight shifts in the signal phase changes across the different antenna elements at the AP. As the spacing between the antennas is fixed and known, by measuring the signal phase difference between adjacent antennas, we can estimate the angle of arrival of the signal (device). In practice, the presence of multipath (reflected signals) causes errors in such AoA estimation. Accordingly, we employ the state-of-the-art MUSIC signal processing algorithm~\cite{schmidt1986multiple} to obtain the AoA information for both direct path and multipath signals. Figure~\ref{fig:musicerror} shows the AoA estimation error observed in our office room setting, utilize a 4-element antenna array: we can see that the multi path effect in office environment is quite strong. At 1 location with 10 ping packets, the highest peak in a AoA spectrum is not always the correct angle of the device. However, if the system observes a sufficient number of continuous packets, it can still estimate the real angle of the device. This has been demonstrated in \cite{xiong2013arraytrack}. Note also that this functional step is needed only for mobile clients (e.g., wearable devices worn by an individual), and is unnecessary for more static settings where the location of the sensor devices are predetermined.
For beamformed energy transfer to be effective, the WiFi AP needs to know the location of the client device. More specifically, the AP does not really need to know the client's precise location; what it needs is the \emph{angular direction} of the client, \emph{relative to the AP's own location}. To compute this, the WiFi AP utilizes its antenna array to determine the AoA of any wireless transmissions from the client device. The key principle for such angle/direction estimation is that the same signal propagates different amounts of distances to reach different antennas located at the AP, and thus manifests itself in slight shifts in the signal phase changes across the different antenna elements at the AP. As the spacing between the antennas is fixed and known, by measuring the signal phase difference between adjacent antennas, we can estimate the angle of arrival of the signal (device). In practice, the presence of multipath (reflected signals) causes errors in such AoA estimation. Accordingly, we employ the state-of-the-art MUSIC signal processing algorithm~\cite{schmidt1986multiple} to obtain the AoA information for both direct path and multipath signals. Figure~\ref{fig:musicerror} shows the AoA estimation error observed in our office room setting, utilize a 4-element antenna array: we can see that the multi path effect in office environment is quite strong. At 1 location with 10 ping packets, the highest peak in an AoA spectrum is not always the correct angle of the device. However, if the system observes a sufficient number of continuous packets, it can still estimate the real angle of the device. This has been demonstrated in \cite{xiong2013arraytrack}. Note also that this functional step is needed only for mobile clients (e.g., wearable devices worn by an individual), and is unnecessary for more static settings where the location of the sensor devices are predetermined.
\begin{figure}[!htb]
\centering
......
......@@ -53,7 +53,7 @@ work, such as ArrayTrack~\cite{xiong2013arraytrack} and
Chronos~\cite{vasisht2016} have shown how to leverage active client RF
transmissions, coupled with precise AoA computations to very precisely
locate the client. We use similar methods in \names. Device-free
localisation approaches, such as WiSee~\cite{pu2013whole}, and single AP
localization approaches, such as WiSee~\cite{pu2013whole}, and single AP
methods, such as Bharadia et. al~\cite{bharadia2013full}, Jain et.
al~\cite{jain2011practical}, and IndoTrack~\cite{li2017} were also
considered. But they were not robust enough for our arbitrary deployment
......
......@@ -99,7 +99,7 @@ Each WARP board can be connected to 4 antennas. We use one WARP board with a 4-a
Therefore, for our experimental studies, we place the two antenna-array at 2 edges of a table (1 meter from each other). In our implemented system, the wearable transmits 2 types of packets: (1) a `ping' packet (to aid AoA estimation) containing 1 preamble byte, 3 address bytes, 1 dummy data byte and 1 CRC byte; and (2) a data packet contains the same preamble, the address is different by 1 bit, a 2-byte packetID and 30 bytes of accelerometer data which is corresponding to 3 seconds of recorded data.
\subsection{Wearable Client Device}
Via our experimental studies, we are interested in not only studying the wearable device in isolation, but when it is being used by regular users. To perform such studies, we need to ensure that the wearable device can be mounted on an individual's wrist. Clearly, our current prototype isn't a true wearable device: its form-factor is simply too unwieldy for constant wear. However, to perform experimental studies, we place the wearable device in a custom-fabricated container, which is then attached to a person's wrists using multiple velcro straps (see Figure~\ref{fig:wearablecontainer}).
Via our experimental studies, we are interested in not only studying the wearable device in isolation, but when it is being used by regular users. To perform such studies, we need to ensure that the wearable device can be mounted on an individual's wrist. Clearly, our current prototype isn't a true wearable device: its form-factor is simply too unwieldy for constant wear. However, to perform experimental studies, we place the wearable device in a custom-fabricated container, which is then attached to a person's wrists using multiple Velcro straps (see Figure~\ref{fig:wearablecontainer}).
\subsection{Access Point \& Directional Beams}
\begin{figure}
......@@ -124,6 +124,6 @@ Via our experimental studies, we are interested in not only studying the wearabl
\noindent \textbf{Multiple Ping Packets:} In our initial implementation, the client device generated a single `ping' packet whenever the motion harvester indicated significant hand motion. However, the WARP RF transmitters continue to cause interference-induced packet loss at the WARP receiver, making it unable to correctly perform the AoA update on the ping packet. Eventually, we adopted a modified packet generation process, where the client device generate multiple (10 ping packets), with an inter-packet gap of 0.6 msecs. While this slightly increased the RF power consumption after a significant movement event, it dramatically improved the reliability of correct packet reception by the WARP receiver, which was then able to correctly track the motion trajectory of the wearable throughout the duration of our studies.
\noindent \textbf{Reliable Transmission of Data Packets:} Currently the WARP board we use which is controlled by matlab is slow to capture all packets. So the receiver WARP board captures and decode only the preamble and address of ping packets to estimate the AoA and to distinct different devices. We employ a separate wearable board to record acceleration data, and to make sure the WiFi harvested devices is working.
\noindent \textbf{Reliable Transmission of Data Packets:} Currently the WARP board we use which is controlled by matlab is slow to capture all packets. So the receiver WARP board captures and decodes only the preamble and address of ping packets to estimate the AoA and to distinct different devices. We employ a separate wearable board to record acceleration data, and to make sure the WiFi harvested devices is working.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment