You are on page 1of 52

2

Monday, November 16, 15


Wednesday, November 18, 15
Monday, November 23, 15
Wednesday, November 25, 15
Monday, November 30, 15
Wednesday, December 2, 15

Monday,December7,15
Wednesday,December9, 15

Wednesday, December 30, 15


Friday, January1, 16
Wednesday, January6, 16
Friday, January8, 16
Wednesday, January13, 16
Friday, January15, 16
Wednesday, January20, 16
Friday, January22, 16
Wednesday, January27, 16
Friday, January29, 16
Wednesday, February3, 16
Friday, February5, 16
Wednesday, February10, 16
Friday, February12, 16
Wednesday, February17, 16
Friday, February19, 16
Wednesday, February24, 16
Friday, February26, 16
Wednesday, March 2, 16
Friday, March 4, 16
Wednesday, March 9, 16
Friday, March 11, 16
Wednesday, March 16, 16
Friday, March 18, 16

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

Wednesday, March 23, 16


Friday, March 25, 16
Wednesday, March 30, 16
Friday, April 1, 16
Wednesday, April 6, 16
Thursday, April 7, 16
Friday, April 8, 16
Saturday, April 9, 16
Sunday, April 10, 16
Wednesday, April 13, 16
Friday, April 15, 16
Wednesday, April 20, 16
Friday, April 22, 16

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

Syllabus for ECE419 Senior Design I


1. Course number and name
ECE 419 Senior Design I
2. Credits and contact hours
Three (3) hours for lecture and work in sponsored projects.
3. Instructors names
Ravi!Jain!and!Ramiro!Jordan!
!
4. Addition information: Ravi Jain
a. Office Location: CHTM 115B
b. Office Hours: TUE and THU, 11:00am to 12:00 noon
c. Class Meeting Day(s): MON and WED, 12:30 1:45pm
d. Class Location / Room: SARAR-101
e. Email: jain@chtm.unm.edu
f. Office Phone: 272-7482
g. Term / Semester: Fall 2015
h. Final Exam date: NA
5. Addition information: Ramiro Jordan
a. Office Location: ECE 225B
b. Office Hours: MON and WED, 2:00 to 3:00pm
c. Class Meeting Day(s): MON and WED, 12:30 1:45pm
d. Class Location / Room: SARAR-101
e. Email: rjordan@unm.edu
f. Office Phone: (505) 277-2412
g. Term / Semester: Fall 2015
h. Final Exam date: NA
6. Text book, title, author, and year
No textbook is required for this class. Links to web sites plus documents posted
on learn.unm.edu will be used.
7. Specific course information
CourseCatalogInformation
Design methodology and development of professional project oriented skills
including communication, team management, economics and engineering ethics.
Working in teams, a proposal for a large design in prepared response to an
industrial or in-house sponsor.
Restriction
ECE major and senior standing.

ECE PM Attendance Report

My Name Is: Grant Heileman


Our Project Is: #21 (AmbiEnergy)
Attendance Summary

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

PM Weekly Status Reports


Project: Trickle Charging IOT Devices
Memebers: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matth
ew Handing, Jacob
Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Defined teams
- Meet with technical mentor for a tour of K&A Wireless.
- Brainstormed and fleshed out our SOW
- Brainstormed ideas for low power IOT applications
- Spoke with Dr. Christos to resolve concerns about impedanc
e matching after DC-DC
converter
Challenges:
- Finding meeting times that will work for everyone (out sid
e of this class time)
Upcoming Deliverable:
- SOW due Oct. 12th
Met With Sponsor:
- Wed, Oct. 12, 1 hour

Misc
(you fill in)

October 21, 2015


Project: Trickle Charging IOT Devices
Memebers: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matth
ew Handing, Jacob
Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Finished SOW
- Preliminary PRD compleated
- Meet with sponsor and laid out goals for the following
week
Challenges:
- none this week
Upcoming Deliverable:
- Manpower and BOM due Oct. 28th
Met With Sponsor:
- Wed, Oct. 21, 1 hour 15 minutes

October 28, 2015


Project: Trickle Charging IOT Devices
Memebers: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matth
ew Handing, Jacob
Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Obtained Galileo development aboard and radio card.
- completed rough draft of BOM and schematic.
- Meet with sponsor and laid out goals for the following
week
Challenges:
- Trying to figure out the correct configurations of comp
onents without having physical
parts to test our ideas.
Upcoming Deliverable:
7

- Manpower and BOM due Oct. 28th


Met With Sponsor:
- Wed, Oct. 28, 1 hour 15 minutes

November 05, 2015


Project # 21
:
AmbiEnergy
Memebers: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matth
ew Handing, Jacob
Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Ordered development board for DC-DC converter.
- Furthered understanding of
DC
-DC converter configurations.
- Sent request for business school seniors to start he bus
iness plan
- Acquired Edison board.
Challenges:
- Implementing GetHub code for the Galileo board (Moving to
Edison)
- Find nominal values for DC-DC convert

s impedance (specifically Vin)


Upcoming Deliverable:
- Functional Specifications
Met With Sponsor:
- Wed, Oct. 4, 1 hour 15 minutes
November 05, 2015
Project # 21
:
AmbiEnergy
Memebers: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matth
ew Handing, Jacob
Nash
Sponsor: Dr. Jorge Piovesan
Progress:
8

- Ordered development board for DC-DC converter.


- Furthered understanding of
DC
-DC converter configurations.
- Sent request for business school seniors to start he bus
iness plan
- Acquired Edison board.
Challenges:
- Implementing GetHub code for the Galileo board (Moving to
Edison)
- Find nominal values for DC-DC convert

s impedance (specifically Vin)


Upcoming Deliverable:
- Functional Specifications
Met With Sponsor:
- Wed, Oct. 4, 1 hour 15 minutes

November 18, 2015


Project # 21
:
AmbiEnergy
Memebers: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matth
ew Handing, Jacob
Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Officially have working WiFi network running on Edison.
Received a gateway router.
Challenges:
We currently do not have access to a source meter and can not test
our
development board.
Upcoming Deliverable:
- Sponsor presentation
Met With Sponsor:
- Wed, Nov. 11, 1 hour 15 minutes
9

November 25, 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 and presented
Challenges:
- Getting technical work done for the project
Upcoming Deliverable:
- Ethics paper
Met With Sponsor:
- Wed, Nov. 25
,
15 minutes

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

January 20, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Found TI spreadsheets for design consideration.
- Tested boost and buck converter efficiency on eval board
Challenges:
- Assigning footprints to the components in the schematic.
Upcoming Deliverable:
- Finish schematic footprints to make PCB files for test circuit
January 27, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
- Making footprints for components
Upcoming Deliverable:
- Finish Gerber files for test circuit

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

February 24, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
- Exported Gerber files
12

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

March 16, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
13

- Sent footprint design for fabrication


Challenges:
- Keepout file cannot be used as a machine layer
Upcoming Deliverable:
- Fix machine layout/specify keepout so that PCB express can make board.

March 23, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
Upcoming Deliverable:
March 30, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
Upcoming Deliverable:
-

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:
-

April 13, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
Upcoming Deliverable:
-

April 13, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
Upcoming Deliverable:
-

April 20, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
15

Challenges:
Upcoming Deliverable:
-

April 27, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
Upcoming Deliverable:
May 4, 2016
Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
Upcoming Deliverable:
-

May 11, 2016


Project # 21:
AmbiEnergy
Members: Grant Heileman, Aaron D'Arezzo, Craig Robertson, Matthew Handing, Jacob Nash
Sponsor: Dr. Jorge Piovesan
Progress:
Challenges:
16

Upcoming Deliverable:
-

Product Description Documents

LOBOPOWIFI SYSTEMS ENGINEERING ARTIFACTS:


The Building-Blocks of a Successful WiFi Harvester
Produced by Craig Robertson

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

SUMMARY AND CONCLUSIONS.............................................................................................44


Demonstrated Capabilities.........................................................................................................44
System Deficiencies...................................................................................................................44
System Refinements..................................................................................................................44
Recommendations and Estimates..............................................................................................45
Figure
Figure
Figure
Figure
Figure
Figure
Figure

1-Harvester External Block Diagram..............................................................18


2- Router External Block Diagram..................................................................19
3-Initial Measuring of S-Parameters...............................................................21
4-First Try at the Matching Network...............................................................21
5- Second Try at the Matching Network.........................................................22
6-Final Matching Network...............................................................................22
7-Final Matching Network in Action................................................................23

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

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.

Figure 1-Harvester External Block Diagram

20

Figure 2- Router External Block Diagram

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

Table 1-Interconnect Matrix

Internal Block Diagrams

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.

Figure 3-Initial Measuring of S-Parameters

I achieved a matching network that looked more or less perfect.

Figure 4-First Try at the Matching Network

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.

Figure 5- Second Try at 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.

Figure 6-Final Matching Network

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.

Figure 7-Final Matching Network in Action

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

TRICKLE CHARGING IOT DEVICES

VIA

ELECTROMAGNETIC HARVESTING

UNIVERSITY OF NEW MEXICO


SCHOOL OF ENGINEERING
AARON

GRANT HEILEMAN
DAREZZO, MATT HANDING, JACOB NASH, CRAIG ROBERTSON
K&A WIRELESS
2350 ALAMO AVE SE, SUITE 301
ALBUQUERQUE, NEW MEXICO 87122

OCTOBER 12, 2015

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.

3. PRODUCT SCOPE DESCRIPTION

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

50 Ohm, 6 dBi antenna


RF matching networks will be used to mitigate reflections.
Full Wave Rectifierultra-Miniature low-loss diodes and high-quality-factor
low-loss capacitors will be used to minimize loss.

An ultra-low power DC-DC converter will be used to increase the voltage


at the charging end.
Super Capacitors will be utilized to accumulate the excesses energy from
the DC-DC converter
Lithium Iron Phosphate batteries will be charged via the super capacitors.

SystemBoundaryDiagramfortheRouterCircuit

SystemBoundaryDiagramfortheHarvesterCircuit

4. PROJECT SCOPE DESCRIPTION

5. SPONSOR SUPPORT ELEMENTS

Sponsor Support Elements


Element
First Needed
Sponsor's Technical Advisor, at least 1 hr/wk
10/19/15
Access the WiFi Router
10/19/15
Access to PCB design software
10/19/15
Authorization/Funding to order components/PCB
1/1/16
Assistance with fabrication of boards
2/1/16
Approval of poster for public display
4/23/16

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

Preliminary Project Requirements

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

1. Compare eval and Rev. 1S


2. Test load time

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/not to be tested

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

Features not to be tested


Max power output of DC-DC converter.

Our design will never reach these voltages.

5. Pass/Fail criteria

If the average power for PoWiFi is more the 10% of a normal network
(success)

If cold start voltage is lowered by 5% in each board design (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.

7. Testing materials (hardware/software requirements)


Gateway, Computer, VNA, and two 3.5 mm coax cables
Eval board, Rev. 1 board, voltage regulator, digitizer and voltmeter.

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

Boost, Buck voltage and current outputs.

Cold start efficiency

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

8.2 Test Case #2: Page load time/average power

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

Power output of gateway running PoWiFi 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

Set up spectrum analyzer to measure 2.43-2.47 GHz

Calculate average power of waveform

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

PROJECT MANAGER: GRANT HEILEMAN


ROBERTSON, JACOB NASH, AARON D'AREZZO, MATTHEW
HANDING
UNIVERSITY OF NEW MEXICO
SCHOOL OF ENGINEERING

SPONSORS: K&A WIRELESS/INTEL


2617 Juan Tabo Blvd NE # A
ALBUQUERQUE, NEW MEXICO 87112

APRIL 30, 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
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

Rechargeable batteries have changed the face of product design and


even altered how modern technology is implemented. Although
advances in rechargeable technology have significantly increased we
are still limited by the fact that even low power devices need to be
connected to a power supply via power chords. This can limit the
application of low power devices, and at the vary least require
expensive human maintenance simply to replace and recharge
batteries. By creating a wireless charging design, based on existing EM
communication protocols, we developed a system that allows low power
devices to be trickled charged wirelessly.

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

During testing we matched the matching network to 2.49 GHz up from


approximately 1.7 GHz. This refinement was designed to be able to use the
802.11 band that was set in the system requirements. The way we did this was
by correcting some of the data that we had miss calculated in initial tests.

Recommendations and Estimates


Increase of Power from Gateway:
This is a correction in the fact to get the best "bang-for-you-buck" in power
transmission. This increase in the power of the system will benefit power
consumption in two folds: range, and possible power consumption of the
device.
We found signal boosters on line for an average price of 40 dollars, these
would be plug and play.

Meeting/Technical Notes

You might also like