Commit 20bb1fab authored by Tran Huy Vu's avatar Tran Huy Vu

add bib stm32l053

parent d098415f
......@@ -475,3 +475,10 @@ month={Secondquarter},}
year={1986},
publisher={IEEE}
}
@misc{stm32L053,
title = {Ultra-low-power ARM Cortex-M0+ MCU with 64 Kbytes Flash, 32 MHz CPU, USB, LCD},
howpublished = {\url{http://www.st.com/en/microcontrollers/stm32l053r8.html}},
year={2018},
note = {Accessed: 2018-04-08}
}
\ No newline at end of file
......@@ -59,7 +59,7 @@ In our current effort, we do not focus on the development of the ``best harveste
The device also contains an RF front end, to transmit the collected sensor data (and any additional `ping' packets). This is the most power-hungry component in the overall system. It consumes 11.3 mA in transmission mode (when it is actively transmitting data at 0dBm), only and 0.9 \micro A in power-down mode (when only the SPI interface is running to maintain communication with the microcontroller). Because the instantaneous RF transmission power far exceeds the harvesting capacity of the device, it is infeasible to run the device using only the instantaneous harvested power. Accordingly, the wearable device include a supercapacitor, which effectively acts as a slowly-draining energy source. We use a 0.47F super capacitor which has an equivalent series resistance of only 45mOhm as the energy storage. The capacitor is small and thin enough (21x14x3.2mm) to be integrated in a wearable device.
\subsection{The Microcontroller+ Sensor}
We utilize a commodity low-power microcontroller, the STM32L053~\cite{XXX}, which consumes 6.6 mW power at normal operation, but only 1 \micro W power during stop mode. In stop mode, all functions of the device is stopped. The microcontroller enter deep sleep mode, but the content of RAM is preserved. The device is waken up whenever an interrupt signal is fired. In our system, when the accelerometer records enough data and fully stored it in a buffer, it generates an interrupt signal to wake up the microcontroller to read the buffer. The micro controller wakes up every 3 seconds to read 60 bytes of acceleration data from accelerometer, if the accelerometer is actually active. It also wakes up at every 1.5 minutes to transfer a block of about 3KB data back to the server, using the wireless interface.
We utilize a commodity low-power microcontroller, the STM32L053~\cite{stm32L053}, which consumes 6.6 mW power at normal operation, but only 1 \micro W power during stop mode. In stop mode, all functions of the device is stopped. The microcontroller enter deep sleep mode, but the content of RAM is preserved. The device is waken up whenever an interrupt signal is fired. In our system, when the accelerometer records enough data and fully stored it in a buffer, it generates an interrupt signal to wake up the microcontroller to read the buffer. The micro controller wakes up every 3 seconds to read 60 bytes of acceleration data from accelerometer, if the accelerometer is actually active. It also wakes up at every 1.5 minutes to transfer a block of about 3KB data back to the server, using the wireless interface.
Our device implementation utilizes the LIS3DHTR 3-axes accelerometer from STMicroelectronics. According to the manufacturer, this low-power sensor consumes 2 \micro A at 1 Hz, and 6 \micro A at 50Hz. For our experimental studies, we set the accelerometer sampling frequency at 10 Hz. At this frequency, the accelerometer can internally buffer 32 samples (i.e., approx. 3.2 seconds of sensor data).
......@@ -108,7 +108,7 @@ We now briefly describe the experimental setup of a \name prototype in our lab.
\label{fig:antennaarray}
\end{figure}
We utilize the WARP v3 platform~\cite{XXX} to implement our prototype AP. In our current implementation and setup (illustrated in Figure~\ref{fig:antennaarray}, we use 3 WARP boards to serve as the AP: two of these WARP boards are chained together to serve as the transmitting AP (allowing us to experiment with 8 antennas), while the other WARP board is used to implement the `receiving AP'. (This is a physical separation due to the limitation of the WARP implementation. In practice, a single full-duplex AP can be used to support both the transmission and reception functionality.) The WARP transmitters effectively transmit the `power packets' continually (at a specified duty cycle)--these packets have no specific data format, as they carry no information content and their sole purpose is to enable RF energy transfer to the client device. Accordingly, in our implementation, we have disabled the WiFi MAC functionality (e.g., the CSMA based backoff mechanism), and instead operate directly on the physical layer (but on the WiFi channel).
We utilize the WARP v3 platform~\cite{warpv3} to implement our prototype AP. In our current implementation and setup (illustrated in Figure~\ref{fig:antennaarray}, we use 3 WARP boards to serve as the AP: two of these WARP boards are chained together to serve as the transmitting AP (allowing us to experiment with 8 antennas), while the other WARP board is used to implement the `receiving AP'. (This is a physical separation due to the limitation of the WARP implementation. In practice, a single full-duplex AP can be used to support both the transmission and reception functionality.) The WARP transmitters effectively transmit the `power packets' continually (at a specified duty cycle)--these packets have no specific data format, as they carry no information content and their sole purpose is to enable RF energy transfer to the client device. Accordingly, in our implementation, we have disabled the WiFi MAC functionality (e.g., the CSMA based backoff mechanism), and instead operate directly on the physical layer (but on the WiFi channel).
Each WARP board can be connected to 4 antennas. We use one WARP board with a 4-antenna array to serve as the receiver to receive packets and estimate the Angle of Arrival, which is the angle of the device with respect to the antenna array. The energy transmitter is implemented with 2 WARP boards with a total 8 antennas placed in a linear array for beamforming. Ideally, the transmitter and receiver antennas should be at the same position. However, because the RF front-end in our wearable only works at 2.4GHz, we have to set the receiver antenna array at 2.4GHz as well. However, this causes interference between the WARP transmitter and receiver antenna array. (To our surprise, if the transmitter and receiver are in close proximity, this interference persists even if we set the transmitter to operate on 802.11b channel 1 and the receiver to operate on 802.11b channel 8. Even in this case, the receiver antenna is saturated by the transmitter, making the receiver WARP board unable to receive packets from the wearable client.)
......
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