Professional Documents
Culture Documents
Monday,December7,15
Wednesday,December9, 15
LECTURE: EngineeringEthics
PM MEETING
PRESENTATIONSTO SPONSORS(Assnt #6)
PM MEETING
PRESENTATIONSTO SPONSORS
PRESENTATIONSTO SPONSORS
PM MEETING
PRESENTATIONSTO SPONSORS
PRESENTATIONSTO SPONSORS
PM MEETING
DUE: EthicsExam(Assnt#10)onlearn.unm.edu
NOCLASS
PM MEETING
DUE: EthicsPaper(Assnt#10)inElectronicformat
NOCLASS
SpringSemester: ECE420
LECTURE: Test Plan
PM MEETING
NO CLASS- WORKINGDAY
MLK, Jr. DAY - NO CLASS
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
DUE: Test PlaninElectronicForm
PM MEETING
NO CLASS- WORKINGDAY
SPRINGBREAK- NO CLASS
SPRINGBREAK- NO CLASS
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
NO CLASS- WORKINGDAY
NO CLASS- WORKINGDAY
PM MEETING
DUE: CharacterizationReportinElectronicform
PRESENTATIONSTOFACULTY
PRESENTATIONSTOFACULTY
DUE: Final Report
PRESENTATIONSTOFACULTY
PRESENTATIONSTOFACULTY
POSTERSESSION
DUE: KnowledgeProbeinHardcopyandElectronic
forms
DUE: ProjectNotebooks
DUE: Posters
FINALEXAMS- NOCLASS
FINALEXAMS- NOCLASS
!!!
ECE 419
Team Member
Grant Heileman
Craig Robertson
Jacob Nash
Aaron DArezzo
Matt Handing
Team Meetings
During
Classtime
%100
%99
%90
%95
%98
Agreed-Upon
Meetings
Outside of
Classtime
%100
%100
%100
%100
%100
Agreed-Upon
Meetings with
Sponsors / Tech
Mentors
%100
%100
%100
%100
%100
Misc
(you fill in)
December 2, 2015
Project # 21
:
AmbiEnergy
Memebers: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matth
ew Handing, Jacob
Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Watched group presentations
Challenges:
- Getting technical work done for the project
Upcoming Deliverable:
- Work on Project over break
Met With Sponsor:
N/A
10
February 3, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
11
Progress:
- Finished schematic for test circuit.
- Exported schematic to .PCB format.
Challenges:
- Creating a 1 layer design
Upcoming Deliverable:
- Finish Gerber files for test circuit
February 10, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Finished PCB design.
Challenges:
- Over 900 error!
Upcoming Deliverable:
- Correct error/fix design rules
February 17, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Changed design rules.
- Completely redesigned PCB
Challenges:
- Having trouble running the Gateway
Upcoming Deliverable:
- Correct error/fix design rules
Challenges:
- Had to redo footprints for exporting BOM. (Do to accidental .pcb to schematic upload and
specifications from Jorge)
Upcoming Deliverable:
- Send board off for fabrication
- Visit with Zach at Intel
March 2, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Learned about fabrication process
- Got a new gateway
Challenges:
- Had to fix the design rules to match the standard fabrication measurements.
Upcoming Deliverable:
- Get quote for standard specifications
March 9, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Made PoWiFi algorithm utilizing CURL command
Challenges:
- Figuring out the correct command to use, after this it became a much simpler task
Upcoming Deliverable:
- Measure efficiency of gateway running PoWiFi
April 6, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
14
Upcoming Deliverable:
-
Challenges:
Upcoming Deliverable:
-
Upcoming Deliverable:
-
17
Table of Contents
Operational Planning.....................................................................................................................18
High Level Systems Diagrams..................................................................................................18
Internal Block Diagrams............................................................................................................20
Architectural Planning...................................................................................................................20
Matching network......................................................................................................................20
Conclusion.....................................................................................................................................23
1. EXECUTIVE SUMMARY............................................................................................................26
2. BUSINESS NEED.......................................................................................................................26
3. PRODUCT SCOPE DESCRIPTION...............................................................................................26
4. PROJECT SCOPE DESCRIPTION.................................................................................................28
5. SPONSOR SUPPORT ELEMENTS................................................................................................28
6. APPROVALS..............................................................................................................................29
Relationship to other documents...................................................................................................34
System overview............................................................................................................................34
Features to be tested/not to be tested.............................................................................................34
Features to be tested.........................................................................................................34
Gateway efficiency.........................................................................................................34
Boost Converter...............................................................................................................34
Features not to be tested.................................................................................................34
5. Pass/Fail criteria................................................................................................................34
6. Approach.............................................................................................................................35
7. Testing materials (hardware/software requirements)........................................35
8. Test Cases...........................................................................................................................35
8.1 Test Case #1: Direct inject..................................................................................................35
8.2 Test Case #2: Page load time/average power......................................................................36
9. Testing Schedule...............................................................................................................37
OVERVIEW..................................................................................................................................40
Executive Summary...................................................................................................................40
Characterization Summary........................................................................................................40
PURPOSE......................................................................................................................................41
Reference Documents................................................................................................................41
SCOPE...........................................................................................................................................41
TEST CASE RESULTS.................................................................................................................41
Test Cases..................................................................................................................................42
Router Algorithm Verification and Validation-......................................................................42
Matching Network Verification and Validation -...................................................................42
Board Output Verification and Validation - ..........................................................................43
18
19
Operational Planning
Dreaming up and building a system from scratch is a daunting task. Luckily UNM
gives its students free access to documentation from INCOSE which lays out some
very simple tools used for systems engineering tasks such as planning the
operational characteristics, functional requirements, and architectural needs. These
tools allowed us as laymen engineers to develop an idea of what our work ahead of
us was, how we were going to complete the work and most importantly, what we
wanted our project to do.
High level systems diagrams were the first thing on our groups plate directly after
the formation of the teams during the first semester. Using these high-level block
diagrams, we were able to effectively map all the inputs and outputs to our system.
Utilizing this tool allowed our group to effectively visualize our system as well as
plan for the coming interfaces that we would have to encounter. In the following
figures you can see the simplicity of our system but also appreciate the intricate
nature of these diagrams. The Blue box in the center of our block diagrams is called
the System of Interest (SOI) which is the main focus of our group. Our team decided
to make two high level block diagrams to detail the two major parts of our system.
20
After we decided what our SOI was, we focused on all the interfacing systems which
are denoted by the gray blocks in the diagram. This allowed us to look at all the
interfaces between our SOI and the various adjacent systems the system interacts
with. The directions of the arrows describes the listener and the speaker or, in the
case of a double arrow, shows an autonomous interconnect. This helped us model
the input and output signals to our system. These interfaces could be mapped in a
table to give us a quick reference guide to what the signals details were.
IC Label
Frequency Voltage
Interface
Characteristi Analog/ Digital/
min/max
Media
c Impedance
Discrete
IC_Harvester_0 2.4GHz
30uVMicrostrip
50 Ohm
Analog
1
30mV
IC_Harvester_0 DC
0-3V
22AWG
N/A
Analog
2
IC_Harvester_0 DC
0-3V
22AWG
N/A
Analog
3
IC_Harvester_0 DC
0-3V
22AWG
N/A
Analog
4
IC_Router_01
60 Hz
115V
NEMA
N/A
Analog
115V
IC_Router_02
N/A
+/- 2.5V
Cat 5e
100 Ohm
Digital
IC_Router_03
2.4GHz
Variable
RG58 Coax 50 Ohm
Analog
IC_Router_04
N/A
+/- 2.5V
Cat 5e
100 Ohm
Digital
21
After we had the high level block diagrams made, it was important to break down
the project into pieces. We followed the age-old electrical engineering motto,
Divide and Conquer here. By dividing the system into block diagrams and
separating the components into different operational circuits we were able to divide
the work amongst the members of our group by specialty. Grant and Aaron took the
analog DC-DC converters and I took the RF matching network and the rectifier
circuits on the hardware side. Jake and Matt took on the router algorithm and the
task of programming the router to broadcast what we wanted it to. The internal
block diagram allowed us to look closer into the internal interfaces amongst the
blocks and allowed us to plan for our physical constraints effectively.
Architectural Planning
By allowing ourselves the proper amount of time to look at the system as a whole
and then work our way down to progressively lower levels, we were able to quickly
and effectively choose the correct hardware for the job. When it came to the RF
portion of the job I chose an elegant and compact diode package along with 0402
footprint inductors. All of these components could easily be modeled in ADS
software allowing me to work in a fast and sometimes reactive manner as the need
arose. By already having the architecture planned out we were able to interconnect
our respective projects easily even though we used different software to model
them.
Matching network
Matching networks can be thought of as an adapter cable from a 50 ohm
impedance matched source to a load of any complex impedance. This allows the RF
signal to move along the transmission line and propagate throughout the circuit
encountering as little impedance as possible. This allowed the RF portion of our
circuit the smallest VSWR we could achieve and massed the most energy through
the circuit.
22
To do this, I modeled the diode package in the simulation program ADS and
recorded the S-parameters through a sweep of frequencies. I then set S11 to my
reflection coefficient and S21 to my transmission coefficient. Naturally, as I
modeled, my matching network I kept in mind that I wanted a massive S21 and an
S11 that was as close to center on the Smith Chart as possible. To ensure that this
happened, I elected to use double stub tuning though a shunt capacitor followed by
a series inductor. This allowed me to match up to the diode package perfectly under
theoretical conditions.
23
Unfortunately, when we connected it to the system there was a huge design flaw. I
had no microstrip lines in the simulation. This proved to be awesome for theoretical
matching but impossible to achieve in practical environments. Therefore, we
tweaked the matching network.
This time we modeled the matching network with microstrip lines in between.
Feeling confident that we has this project whooped we sent the board off to be spun
on the standard FR4 board. This allowed us to have a working prototype and moved
us one step closer to having a completed project.
Unfortunately, I didnt notice that FR4 board had a massive relative permittivity
(which I modeled in ADS). However, I neglected to model tan(d) or the thickness of
the board properly. This resulted in our circuit being perfectly matched 500MHz
below our target frequency. I had to rework the board and we had already spun it.
Luckily, we had the foresight to use discrete components and not printed lines. This
allowed me to remodel the circuit and change the values of out discrete
components. We had to order about $10 worth of parts but out project was back up
and rolling again.
24
This final product allowed us to match up to the diode package almost perfectly and
resulted in a large S12 and a small S11 which passed a large amount of energy
through our circuit at our target frequency of 2.4GHz.
Conclusion
In retrospect, this was a very good project to get my feet wet in the world of RF. I
had modeled an LNA and a VCO in ADS before but I had never modeled with
discrete components. Also, learning the aspects of what is practical and what is not
is important. Modeling tricks like using tan(d) in the substrate model and utilizing
the tuning capability within the program took some of the frustration out of it.
This project also gave me my first chance at actually modeling a project that was
going to be built. Too often in school we stare at a simulation in multisim or SPICE
and we do not get a chance to see if what we built would actually work. In my case
it kind-of worked. This was a blessing that I hit close to the mark because fault
isolation and recovery are always easier when that happens. Also, in a field that is
so often immediate success or catastrophic failure, I feel lucky that my first try at a
difficult circuit was so fortunate.
25
STATEMENT OF WORK
VIA
ELECTROMAGNETIC HARVESTING
GRANT HEILEMAN
DAREZZO, MATT HANDING, JACOB NASH, CRAIG ROBERTSON
K&A WIRELESS
2350 ALAMO AVE SE, SUITE 301
ALBUQUERQUE, NEW MEXICO 87122
26
TABLE
1.
2.
3.
4.
5.
6.
OF
CONTENTS
EXECUTIVE SUMMARY..........................................................................................................9
BUSINESS NEED.....................................................................................................................9
PRODUCT SCOPE DESCRIPTION.............................................................................................9
PROJECT SCOPE DESCRIPTION.............................................................................................11
SPONSOR SUPPORT ELEMENTS............................................................................................11
APPROVALS..........................................................................................................................12
1. EXECUTIVE SUMMARY
The abilities to either store ambient energy or transmit power
wirelessly have begun to garner an increasing amount of public equerry.
Several far-field power harvesting systems made it to the finals of
TechCrunch this year alone. K&Awireless will tap into this market by
designing an RF harvesting network and communications transmission
protocol to maximize the energy transmission capability of a Wi-Fi source. A
50-Ohm antenna will be matched to a full wave rectifier and a low power DCDC converter. Along with this, an algorithm will be developed to maximize
the power output of a Wi-Fi router. By combining these two ideas we will
create a system that can trickle charge low power IOT devices.
2. BUSINESS NEED
The demand for a truly flexible wireless charging system is a largely
untapped market. By developing systems that can work with existing E&M
communication networks we will jump into the forefront of this new business
opportunity. This gives K&Awireless the opportunity to create a unique and
viable revenue stream. Through our system the ability to elongate the
battery life of existing technologies and the opportunity to develop
techniques for continuously charging the next generation of low power IoT
devices will be possible.
1
2 .
r
Considering commercial Wi-Fi is transmitted at 1 watt from a 6 dBi antenna
we know any potential applications must have a low average power. Jointly,
power loss due to reflection at the receiver must be minimized in order to
collect a meaningful amount of charge. This power transmission is
constantly disrupted due to the intermittent nature of Wi-Fi traffic. In order
to sustain this charge a transmission algorithm can be developed that injects
pseudo-traffic over a network.
The Free Space Path Loss(FSPL) of an EM signal is approximately
Features:
2.4 GHz Wireless AC router
SystemBoundaryDiagramfortheRouterCircuit
SystemBoundaryDiagramfortheHarvesterCircuit
Needed Until
4/29/16
4/29/16
3/20/16
-------
6. APPROVALS
The signatures of the people below indicate an understanding in the
purpose and content of this document by those signing it. By signing this
document you indicate that you approve of the proposed project outlined
in this Statement of Work and that the next steps may be taken to create
a Requirements Document and proceed with the project.
Approver Name
Title
K&Awireless
Sponsor
Jorge Piovesan
Technical Mentor
Grant Heileman
Project Manager
Ramiro Jordan
Instructor
Signature
Functional Specification
Date
Test Plan
Conduct spectral analysis of signal from gateway. (Both with PoWiFi running
and under regular network connections) 03/21-04/01
Verify Rev. 1 board with high power signal generator. 04/01-04/08
Test Rev. 1 board with gateway running PoWiFi 04/01-04/08
Verify Rev. 2 board with high power signal generator. 04/15-04/28
Test Rev. 2 board with gateway running PoWiFi 04/15-04/28
Jorges sugestions
TEST PLAN
POWIFI
PROJECT MANAGER: GRANT HEILEMAN
AARON, CRAIG, JACOB, MATT
UNIVERSITY OF NEW MEXICO
SCHOOL OF ENGINEERING
SPONSOR K&AWIRELESS
ABQ, NM 87122
03/23/2016
Revision History:
Versio
n
Revision
Date
Description
Author
Contents
1. EXECUTIVE SUMMARY............................................................................................................18
2. BUSINESS NEED.......................................................................................................................18
3. PRODUCT SCOPE DESCRIPTION...............................................................................................18
4. PROJECT SCOPE DESCRIPTION.................................................................................................20
5. SPONSOR SUPPORT ELEMENTS................................................................................................20
6. APPROVALS..............................................................................................................................21
Introduction....................................................................................................................................26
Relationship to other documents...................................................................................................26
System overview............................................................................................................................26
Features to be tested/not to be tested.............................................................................................26
Features to be tested.........................................................................................................26
Gateway efficiency.........................................................................................................26
Boost Converter...............................................................................................................26
Features not to be tested.................................................................................................26
5. Pass/Fail criteria................................................................................................................27
6. Approach.............................................................................................................................27
7. Testing materials (hardware/software requirements)........................................27
8. Test Cases...........................................................................................................................27
8.1 Test Case #1: Direct inject..................................................................................................27
8.2 Test Case #2: Page load time/average power......................................................................28
9. Testing Schedule...............................................................................................................29
Introduction
The PoWiFi system consists of a router running the PoWiFi algorithm and a
matched DC-DC rectifier. The PoWiFi algorithm occupies a WiFi channel,
increasing the channels occupancy. The receiving end utilizes ultra low loss
components, as well as a highly efficient DC-DC converter.
Relationship to other documents
Functional specifications and Statement of Work
System overview
Our system consists of two parts, the software and the hardware. The software
side is working on an Intel gateway running Linux. We are developing an
algorithm that runs a CURL command on the gateway when channel occupancy
is low.
The hardware side consists of PCB, which we are designing. The PCB we have
designed has a matching network (matched to a 50ohm antenna), and AC-DC
rectifier, and a DC-DC converter. We design is centered around the DC-DC
convert so we will be designing the board so that it can accommodate our
converters functionality.
Features to be tested
PSD and average power output from gateway running normal network and
then test running PoWiFi
Test efficiency of boards. Comparing Eval, Rev. 1 and Rev. 2
Gateway efficiency
Gateway power output
Boost Converter
Board efficiency for boost converter
5. Pass/Fail criteria
If the average power for PoWiFi is more the 10% of a normal network
(success)
6. Approach
We will be using a VNA at K&A to test the PSD of the gateway running PoWiFi.
We will also use the digitizers and voltage regulators supplied by K&A to test
the PCBs.
8. Test Cases
8.1 Test Case #1: Direct inject
Tested By:
Test Type
Test Case Number
Test Case Name
Test Case
Description
Direct Injection
Hardware, board verification
1
2.4 MHz cont. wave source
A 1 W continuous wave source will be used to
check the matching networks efficiency.
Item(s) to be tested
S11-parametere of matching network
4
Specifications
Input
1. 1 V p-p, 2.4 MHz sine wave.
1
2
3
Expected
Output/Result
1. 2.0 V from boost test, 0.8 V from
buck test
Procedural Steps
Connect PoWiFi revicer to Sig. Gen.
Connect PoWiFi output to voltmeter.
Calculate boost charge efficiency from 24. GHz sine wave
PoWiFi vs WLAN
Software, algorithm verification
2
PoWiFi efficiency
The gateway will be ran using both the PoWiFi
and a normal WLAN connection. Average power
output will be measured.
Item(s) to be tested
Power output of gateway running normal network
Tested By:
Test Type
Test Case Number
Test Case Name
Test Case
Description
3
4
Specifications
Input
120 volts, Ethernet connection
Expected
Output/Result
0.5 1V 2.45 GHz WiFi comms
protocol
Procedural Steps
Set up PoWiFi or WLAN
9. Testing Schedule
Test Dates
April 1
April 5
Description
Test Case 1
Test Case 2
Responsible Engineers
Craig, Aaron, Grant
Jacob, Matt, Grant
CHARACTERIZATION REPORT
LOBO POWIFI
CRAIG
Revision History:
Versio
n
Revision
Date
Description
Author
Contents
1. EXECUTIVE SUMMARY............................................................................................................18
2. BUSINESS NEED.......................................................................................................................18
3. PRODUCT SCOPE DESCRIPTION...............................................................................................18
4. PROJECT SCOPE DESCRIPTION.................................................................................................20
5. SPONSOR SUPPORT ELEMENTS................................................................................................20
6. APPROVALS..............................................................................................................................21
Relationship to other documents...................................................................................................26
System overview............................................................................................................................26
Features to be tested/not to be tested.............................................................................................26
Features to be tested.........................................................................................................26
Gateway efficiency.........................................................................................................26
Boost Converter...............................................................................................................26
Features not to be tested.................................................................................................26
5. Pass/Fail criteria................................................................................................................26
6. Approach.............................................................................................................................27
7. Testing materials (hardware/software requirements)........................................27
8. Test Cases...........................................................................................................................27
8.1 Test Case #1: Direct inject..................................................................................................27
8.2 Test Case #2: Page load time/average power......................................................................28
9. Testing Schedule...............................................................................................................29
OVERVIEW..................................................................................................................................32
Executive Summary...................................................................................................................32
Characterization Summary........................................................................................................32
PURPOSE......................................................................................................................................33
Reference Documents................................................................................................................33
SCOPE...........................................................................................................................................33
TEST CASE RESULTS.................................................................................................................33
Test Cases..................................................................................................................................34
Router Algorithm Verification and Validation-......................................................................34
Matching Network Verification and Validation -...................................................................34
Board Output Verification and Validation - ..........................................................................35
SUMMARY AND CONCLUSIONS.............................................................................................36
Demonstrated Capabilities.........................................................................................................36
System Deficiencies...................................................................................................................36
System Refinements..................................................................................................................36
Recommendations and Estimates..............................................................................................37
OVERVIEW
Executive Summary
This project was a collaboration between K&Awireless, Intel, and UNM.
Five team members were selected, with areas of focus including RF
design, applied electromagnetics, software engineering, and analog
design. By sending "dummy data" during periods of low WiFi traffic we
can increase the time averaged power transferred over WiFi. After
achieving this we utilize high quality and low loss components in the
manufacturing of our EM harvester.
Although we designed and tested a working WiFi harvester and
occupancy algorithm we are currently in the development process of our
small footprint design. In general the product has worked exceptionally
well, and we are confident that our upcoming design will increase
harvesting efficiencies. Our algorithm works extraordinarily well and we
are currently working on implementing user-friendly boot-up version of
the software.
Lobo PoWiFi is a project that will allow K&Awireless, Intel, and UNM to
become a leader in the emerging field of wireless power transfer. This
largely untapped market is in the process of an exponential growth and
participation in this project has benefited each sponsor through exposure
to the quickly advancing engineering and product designs.
Characterization Summary
Router Algorithm
Matching Network
Board Output
Specification
70-100%
2.40-2.47GHz
170A
Test Result
80-90%
2.48GHz
17A
Compliant
Yes
Yes
Yes
PURPOSE
Reference Documents
[1]FCC, "https://www.gpo.gov/," FCC, [Online]. Available:
https://www.gpo.gov/fdsys/pkg/CFR-2001-title47-vol1/pdf/CFR-2001-title47-vol1sec15-247.pdf. [Accessed 24 04 2016].
[3]Vamsi Talla, Bryce Kellogg, Benjamin Ransford, Saman Naderiparizi,Shyamnath
Gollakota and Joshua R. Smith, Powering the Next Billion Devices with Wi-Fi
[4]N/A, "www.ti.com," Texas Instruments, [Online]. Available:
http://www.ti.com/lit/ds/symlink/bq25570.pdf. [Accessed 12 9 2015].
SCOPE
LoboPoWiFi will utilize a common wireless router to transmit power used for
farfield reception by an RF Harvester for battery charging of low power
electronics. Our project will be working efficiently and will rectify no less than
20dB of our received signal. Our proof of concept will be complete by May 12,
2016.
TEST CASE RESULTS
During the direct inject testing we observed a maximum of 25 uA (cold start)
and 130 uA (hot start).
The test case for PoWiFi vs WLAN yielded positive result, showing a
significantly higher average power when running PoWiFi. This makes sense as
CSMA/CA reduces the amount of traffic over WLAN. Our PoWiFi algorithm
occupies a full OFMD carrier waveform as can be seen in the following pictures.
Test Cases
Router Algorithm Verification and ValidationSystem Function .
The function of the Router Algorithm was to boost the time-averaged power
that the router transmitted on a continuous basis. This was important to test
because even if we had a perfect harvester circuit, we could not have used it
if our router wasn't transmitting enough power for it to be useful. In essence,
the software was designed to stimulate Wi-Fi traffic.
Functional Capability The performance of the router before the algorithm as compared to after was
night and day. The Lobo PoWiFi algorithm booted the average transmission
from around 0-10% up to 80-90% of the time there was a transmission
occurring. We used a software defined radio as the receiver circuit so there
will be differences between the test environment and the functional
environment although we tried to mitigate them. The differences arose from
the fact that we didn't have a way to connect the same receiver test antenna
to the software defined radio receiver we were using. This meant that our two
radios were communicating over open traffic.
Performance Capability -
While testing the router we saw a significant change between the standard router
transmission levels and the router levels with the implementation of the LoboPoWiFi
algorithm. This was exactly what we expected to see in our power levels. However our
test router, the Intel Gateway, only transmitted a peak average value of ~100 mW. This
was limiting but we could use it as our proof of concept with a set power transmission
factor. Another validation that our algorithm was working was the fact that when we
streamed data off the router the increases transmission power did not slow down our
connection. This meant that we met our goal of not sandbagging our internet data by
implementing our algorithm.
Matching Network Verification and Validation System Function The matching network's main function was to adapt the 50 impedance
matched antenna to the diode and DC-DC converter circuitry. The matching
network needs to be centered at 2.4 to 2.47 GHz to pass the correct
frequency from the antenna. The matching technique was to use a shunt
capacitor that feeds a series inductor. Discrete components were used on
relatively short micro-strip transmission lines to make the design modular as
well as be susceptible to less losses across the network.
Functional Capability -
The matching network performed as expected. When tested, we found that the matching
network was matched to a frequency of 2.43GHz; the ideal frequency for our matching
network. Our tests match exactly what we would expect in a real world scenario and we
expect that our matching network will perform in any settings with a similar climate. We
have not been able to test the board in differing temperatures and do not know how
extreme temperatures or humidity will affect the board. These factors have been known to
affect S-parameters but for the purposes of our project we did not deem it necessary to
temperature test. The device is made for indoor low power use. Therefore there should
not be a reason the temperature fluctuates that much.
Performance Capability -
Wireless networks using the IEEE 802.11b, 802.11g, and 802.11n standards transmit at a
frequency ranging from 2.4 2.47GHz depending on the channel. At 2.43GHz, our
matching network reflects the minimal amount of power along the 802.11 frequency
band. While there are no known deficiencies, we know that all electronics are limited to
their operating temperatures. Our matching network has a max operating temperature of
90 Celcius (I guessed based on other electronics and their max operating temperature)
and works most efficiently at 25C.
Board Output Verification and Validation - .
System Function
Our system is design to provide power to low-power systems by converting WiFi signal
into power. This power is filtered through the matching network to reflect the least
amount of power then passed through to the DC-DC converter. The DC-DC Converter's
main function was to step up the voltage coming from the first stages of our system, to a
usable level for the output. This was accomplished using a Boost Charger within the IC.
The minimum required VIN for this device was 100 (mV) and the maximum that we
could send was 5.1(V), and in turn the Charger would step these values up to 2(V) and
5.5(V) respectively. The IC also has checks to make sure that we don't over charge or
over deplete the batteries we are using in our system. We tested for the amperage that our
board was outputting after the DC-DC Converter.
Functional Capability
The testing environment was much more controlled than any real world environment
would be. Since the input to our device comes from WiFi, and WiFi has difficulty
penetrating substances, there can be many ways to obstruct the path from the router to the
harvesting network. This means that the input voltage could drop sporadically and
therefore diminish the output. Another difference in our test environment stemmed from a
weak gateway. Since we are unable to output enough power from our Intel Gateway, we
need to use a software defined radio transmitter to test the board. Since our ideal
environment is a home using a WiFi router, the amount of power the board will receive
will vary in difference of router, router location, and distance from the router. In our tests,
we measured that we were receiving ~17A when we were using the software defined
radio transmitter. This is enough power to properly power our DC-DC converter and
function properly.
Performance Capability
In our initial calculations and researching, we found that we would need a minimum of
~7A to properly HotStart the DC-DC converter and provide power to a device on the
other end of the board. In our tests, we exceeded our expectations by ~10A and were
seeing a relatively stable output of ~17A. This is more than enough power to ensure that
our board is working properly and supplying a steady stream of power to the other side of
the board. One of our limitations is walls and objects blocking line of site to the router.
When there is something directly in-between the board and the router, there is a
noticeable drop in power delivered to the board.
SUMMARY AND CONCLUSIONS
Demonstrated Capabilities
The PoWiFi algorithm passes "dummy-data" packets during low traffic periods of
WiFi usage. This enables it to remain a constant 2.4Ghz for our hardware system matching
network to detect and harvest. The constant wave is necessary because without it, we will
never achieve the input voltage necessary to bias the DCDC converter. A software
controlled radio signal transmitter was utilized to output at a variety of frequencies in order
to test the matching network of the device. Once the match of 2.49Ghz was detected the
gateway router was able to communicate with the harvesting device. The device itself
operates when it is fed a minimum of 10mV which is good for our system because WiFi
does not deliver a large amount of voltage via the waves. The boost charger was able to
boost the current at our output stage to about 17uA. For these results we used a Huber
Suhner 84059620 vertically polarized patch antenna on both the router and the harvester.
After realizing the Gateway operated at a voltage of 10 mV we concluded that the value of
17uA is equivalent to UWs results. Although we did not try varying distances due to time
constraints we were able to harvest at the energy at a distance of 25 cm, which is the
minimum far field distance. When the PoWiFi algorithm was turned off we could not bies
the IC or harvest energy.
System Deficiencies
Currently, our Intel Gateway outputs at an average of ~100mW. While this is enough
power to see a response from the board, it is not enough energy to power a device. This
deficiency is only a minor problem in simulating a combined router running the PoWiFi
algorithm and the PoWiFi board.
System Refinements
Meeting/Technical Notes