Date post: | 10-Nov-2015 |
Category: |
Documents |
Upload: | ahmed-tanveer-ashraff |
View: | 30 times |
Download: | 2 times |
1
Smart Power Management Power meter
Final Report
Fall Semester 2013
-Full Report-
By: Eric Kurtzberg
Zach Zasada
Prepared to partially fulfill the requirements for ECE 402
Department of Electrical and Computer Engineering
Colorado State University Fort Collins, Colorado 80523
Advisors:
Adjunct Faculty James Barnes Industry Advisor Jerry Duggan Professor Anura Jayasumana Grad Student Sachin Soman
Sr. Research Associate Daniel Zimmerle
Approved by: Daniel Zimmerle
2
Abstract
Nearly 40 percent of the total United States energy consumption in 2012 was consumed in
residential and commercial buildings [1]. The average commercial building energy cost can exceed
$30,000 per year [2]. Lowering these energy costs results in direct savings. Two methods for lowering
energy costs include peak load shifting and increasing the efficiency of heating, ventilation, air
conditioning, and lighting. Peak load shifting is avoiding using large amounts of energy during peak
generation when the cost per kilowatt hour is highest. The second technique for lowering cost is
improving the efficiency of the heating, ventilation, air conditioning (HVAC) and lighting systems. These
systems are in place for human comfort; however, if there are no humans in certain areas of a building
throughout the day, then there is no reason to maintain human comforts in those areas. The first step in
implementing these cost saving techniques is to determine a buildings pedestrian usage. Determining the pedestrian usage of commercial buildings has been one of the main tasks of the
Smart Power Management senior design group. In previous semesters the Smart Power design team
attempted to monitor building pedestrian usage by using sensors to count the number of people that
travelled through the exterior doors of a building. However, this method ran into difficulties that will be
discussed later. Therefore, the current Smart Power Management team decided to build and implement
power and temperature sensors to address some of the issues with the previous door sensor design. The power meters were successfully designed, built and implemented this semester. Furthermore,
we were able to collect power and temperature data from inside a computer lab on campus. However,
with the data collected we were unable to determine a correlation between power and temperature
readings and pedestrian usage. We still believe there is a connection between power, temperature and
pedestrian usage. Furthermore, we believe unforeseen software complications led to the unpredictable
measurements that were made by the meters. We believe that if software issues were cleared up in the
future, then a strong correlation could be made between pedestrian usage, power, and temperature
readings.
3
Table of Contents
Abstract ...........................................................................................................................................2
List of figures ............................................................................................................................................... 4
Acknowledgements ..................................................................................................................................... 5
Introduction ....................................................................................................................................6
Overview ................................................................................................................................................... 6
Previous Work .......................................................................................................................................... 7
Current Work ............................................................................................................................................ 8
Power Meter Design Methods .......................................................................................................9
Voltage Measurement Circuit ................................................................................................................... 9
Current Measurement Circuit .................................................................................................................. 12
Temperature Measurement Circuit ......................................................................................................... 15
Arduino Micro-Controller ....................................................................................................................... 16
SD Card ................................................................................................................................................... 16
Arduino SD Card Shield ......................................................................................................................... 16
Zigbee Wireless Radio ............................................................................................................................ 17
Software Architecture ............................................................................................................................. 18
Range Testing ......................................................................................................................................... 21
Algorithms .............................................................................................................................................. 24
Results and Discussions ...............................................................................................................28
Power Meter ............................................................................................................................................ 28
Range Testing ......................................................................................................................................... 35
Modeling ................................................................................................................................................. 39
Conclusion ....................................................................................................................................40
References .....................................................................................................................................42
Appendices ....................................................................................................................................43
Appendix A ............................................................................................................................................. 43
Appendix B ............................................................................................................................................ 43
Appendix C ............................................................................................................................................ 44
Appendix D ............................................................................................................................................ 46
Appendix E ............................................................................................................................................ 48
Appendix F ............................................................................................................................................. 49
4
List of Figures
Figure 0: Load versus time of day for December 9th, 2013[3] ............................................................. 7
Figure 1: Outline of Senior Design Plan of Fall 2011 - Spring 2012 ..................................................... 8
Figure 1a - Sensor Network Block Diagram ...................................................................................... 9
Figure 2: Voltage Transformer ...................................................................................................... 10
Figure 3: Simulated Line Voltage vs Time .......................................................................................... 10
Figure 4: Simulated Transformer Voltage vs Time ............................................................................. 10
Figure 5: Simulated Final Voltage Output ....................................................................................... 11
Figure 6: Voltage Measurement Circuit ............................................................................................... 12
Figure 7: Current Transformer ...................................................................................................... 12
Figure 8: Simulated Current Waveform For 30 Amp Current ............................................................ 13
Figure 9: Simulated Waveform of Voltage out of Current Transformer .............................................. 13
Figure 10: Simulated Output of Current Measurement Circuit ........................................................... 14
Figure 11: Circuit Diagram For Current Measurement Circuit ........................................................... 15
Figure 12: Temperature Measurement Circuit Schematic .................................................................. 16
Figure 13: Image of Arduino Uno .................................................................................................. 17
Figure 14: SD Card Shield With Current, Voltage, And Temperature Circuits Attached ....................... 18
Figure 15: Power Meter Software Flowchart ................................................................................... 19
Figure 16: Arduino Coordinator Software Flowchart. ........................................................................ 21
Figure 17: Zigbee Explorer USB Board (sparkfun.com) ................................................................... 23
Figure 18: CC3000 and MSP-EXP430FR5739 ................................................................................ 24
Figure 19: Power vs time measurements for a power meter. .............................................................. 29
Figure 19a: Actual Voltage Readings versus Time .................................................................... 30
Figure 19b: Originally Expected Behavior of ADC ................................................................... 31
Figure 19c: Fast analog to digital converter ......................................................................................... 32
Figure 19d: Slowest Running ADC converter ............................................................................ 33
Figure 19e: Voltage measurement waveform (without DC Bias) ............................................... 34
Figure 20: Temperature vs time for power meter ............................................................................. 35
Figure 21: Percentage of packets received vs distance between radios. ............................................... 36
Figure 22: 900 MHz radio packet % vs distance .............................................................................. 37
Figure 23: 60 mW 2.4 Ghz Zigbee Radio Received % vs Distance .................................................... 38
Figure 24: RSSI versus Distance for 60 mW Zigbee Radio ............................................................... 39
Figure 25: % Packets Received vs RSSI for 60 mW Zigbee radio ...................................................... 39
Figure 26: RSSI vs Distance for Wifi Module ................................................................................. 40
5
Acknowledgements
The authors would like to acknowledge Dr. Anura Jayasumana, Dan Zimmerle, James Barnes,
and Jerry Duggan for their input on this project. The authors would also like to acknowledge former team
members and Sachin Soman for their contributions to the project. A final acknowledgement to
InGreenium LLC for financial support throughout the project.
6
INTRODUCTION
Overview
Over the past decade, we have become increasingly aware of our limited resources for generating
power and the environmental effects of burning coal and natural gas. Greenhouse gases from automobile
exhaust, power plants, and other sources are polluting our climate. As part of a long-term plan for
sustainable energy use, it is important that we learn to conserve energy and use it wisely.
In 2012 nearly 40% of the total United States energy consumption was consumed by commercial
and residential buildings [1]. For commercial buildings alone energy costs can exceed $30,000 per year
and 75% of that cost is due to heating, ventilation, air conditioning (HVAC), and lighting [2]. There are
two main ways to reduce the cost associated with energy use in commercial buildings, peak load shifting,
and increasing the efficiency of the energy being used.
Peak load shifting is when people minimize the use of electrical equipment during times when
there is heavy loads on the overall grid. This method saves money because during these peak load times
the cost per kilowatt hour of electricity is higher than at other times during the day. Figure 0 below shows
the power load per hour for the Platte River Area which includes the city of Fort Collins on December
9th, 2013 [3]. From the figure it can be observed that peak load on this particular day occurred from 5 pm
to 8 pm. As discussed previously, this is the time of day that the use of electrical equipment should be
minimized.
Another method for lowering the cost associated with the consumption of energy in commercial
buildings is due to the efficiency of the heating, ventilation, air conditioning, and lighting systems. These
systems are used simply for human comfort and convenience. However, if areas of a building are not
being used by humans than it is simply inefficient to be heating, ventilating, air conditioning and lighting
these areas. Therefore, the first step in implementing these cost saving methods is measuring the
pedestrian usage of a building throughout the day.
7
Figure 0: Load versus time of day for December 9th, 2013[3]
Previous Work
In previous semesters, the Smart Power Management team built and installed wireless sensors
that monitored pedestrian usage of a building. They accomplished this by designing and installing sensors
that monitored the movements of exterior doors to calculate the number of people inside the building at a
given time. However, this implementation had problems. Since this was a continuously running system
battery life of the sensors was far less than desired. The Smart Power Management team was hoping to
achieve at least 744 hours of battery life in each sensor; however, they only reached 31 hours of battery
life per sensor. The sensors also had communication problems. The team hoped that the sensors would be
able to transmit at least 50 feet line of sight. However, the sensors once again were unable to meet the
teams expectations, and only transmitted for a few feet. The teams outline for this is shown in figure 1.
From the figure we can see that the team planned to gather data from different sources in order to better
predict the building pedestrian usage. We decided to take a different approach to this problem.
8
Figure 1: Outline of Senior Design Plan of Fall 2011 - Spring 2012.
This semester, our goal was to develop sensors measure analog voltage and current signals. By
analyzing these signals, the power consumption can be determined. The team also expanded to different
protocols of data communication. More specifically: Zigbee (IEEE 802.15), WiFi (IEEE 802.11).
Current Work
The team hypothesized that by measuring power and temperature a model of building usage
(population) can be created. In other words, the team tested for a correlation between power
usage/temperature and building occupancy. A system that measures the temperature and power at
discrete time intervals was implemented. This alleviates the problem of continuous monitoring and
battery life. In addition to implementing this sensor, we explored different means of communication to
address the previous communication issues.
The team initially implemented Arduino microcontrollers with temperature, voltage transformers,
and current transformers sensors which send data via Zigbee to an Arduino coordinator where the data
was stored. This implementation showed the possibilities for collecting and wirelessly transmitting data to
model building use. The team implemented this in one of the computer labs on campus for an initial
9
implementation. The sensors only monitor this one lab; however, the same implementation could be
easily expanded to monitor entire building use for modeling. See figure 1a below for a block diagram
outline of the power meter setup.
Figure 1a - Sensor Network Block Diagram.
All installed sensors communicated wirelessly through ZigBee radios. The wireless
communication was furthered explored by testing these radios range and data rate transfer. Similarly, a
WiFi modules range was also tested by the team for comparison against the ZigBee radios and possible
implementation in future semesters. See appendix for documentation on equipment used or visit the Smart
Power Project website (http://www.engr.colostate.edu/ece-sr-design/AY13/power/).
Power Meter Design Methods
Building a power meter was not a trivial matter since power cannot be measured directly. Power
must be calculated from current and voltage measurements. To accomplish this, the power meter was
designed using the following components: voltage transformer, current transformer, temperature sensor,
Arduino microcontroller, Arduino Wireless SD card shield, ZigBee wireless radio.
Voltage Measurement Circuit
10
The voltage measurement circuit consisted of three main parts: the voltage transformer, voltage
divider, and 3.3VDC bias. The voltage transformer used is seen in figure 2 below. The voltage
Figure 2: Voltage Transformer
transformer served as a means to step down the voltage from the 120 VRMS (measured via oscilloscope
and shown in figure 3) to 12 VRMS (measured via oscilloscope and shown in figure 4). However, the
Arduino microcontroller is only rated for voltages between 0 and +5V on any input pin.
11
Figure 3: Simulated Line Voltage vs Time Figure 4: Simulated Transformer Voltage vs Time
Therefore, the voltage was once again lowered by a voltage divider circuit to 3.2 volts peak to peak. This
peak to peak voltage can be handled by the microcontrollers analog pins; however, a DC bias was needed
to prevent the waveform from dropping below 0 volts. For this circuit, a +3.3VDC bias was applied. This
placed the voltage signal range from +4.9 volts to +1.7 volts which was between the required 0 and +5
volts. The 3.3VDC bias pin was chosen instead of the 5VDC bias pin in order to keep the voltage
measurement circuit and current measurement circuits electrically separated. Calculated in figure 5 below
shows what a typical voltage waveform output looked like and figure 6 below shows a diagram of the
voltage measurement circuit.
Figure 5: Simulated Final Voltage Output
12
Figure 6: Voltage Measurement Circuit
Current Measurement Circuit
Similar to the voltage measurement circuit, the current measurement circuit also has a voltage
divider for the Arduino inputs. The components used are as follows: the current transformer (figure 7
below), burden resistor, voltage divider, and 5 volt source.
Figure 7: Current Transformer
The current transformer stepped the current down from line current to a more tolerable level (refer to
figure 11). However, the Arduino microcontroller cannot read the current directly, it can only read
13
voltages, so a burden resistor was used. This burden resistor converts the current to a limited voltage for
the Arduino to read. For this project, a burden resistor was selected to limit the voltage to 2.4 volts from
the current transformer with 30 amps on the transformers primary side. 30 amps was chosen as the
primary sides limit because that was the max current the CT was rated for, and the circuits being
monitored very likely would never exceed 30 amps on the line. Furthermore, from the data sheet for the
current transformer (http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Current/ECS1030-L72-
SPEC.pdf) we know that for 30 amps on the primary side the transformer will output 15 miliamps from
its secondary terminals. Figure 8 below shows a simulated line current waveform for the max amps
expected. Figure 9 shows what the current waveform would look like transformed into voltage with the
aid of the current transformer and burden resistor.
Figure 8: Simulated Current Waveform For 30 Amp Current
14
Figure 9: Simulated Waveform of Voltage out of Current Transformer
The current waveform has now been transformed into a voltage waveform; however, as discussed
previously, the voltage is still unreadable by the Arduino micro-controller. Therefore, before applying the
signal to the microcontroller, it needs to be passed through a voltage divider and have a DC bias added to
it, so that it stays within the range of readable values for the Arduino. From figure 10 below you can see
that the final waveform oscillates between +0.1 volts and +4.9 volts which is within the 0 to +5 volt
required range of the Arduino micro-controller. Figure 11 below shows the circuit diagram of the
previously discussed circuit.
Figure 10: Simulated Output of Current Measurement Circuit
15
Figure 11: Circuit Diagram For Current Measurement Circuit
Temperature Measurement Circuit
In comparison to the voltage and current measurement circuits, the temperature measurement
circuit was much simpler. Figure 12 below shows the schematic for the temperature sensor circuit. The
temperature sensor has 3 pins, 2 input pins and 1 output pin. The inputs are +5 volts and ground. The
output pin applied a voltage that is proportional to the temperature surrounding the temperature sensor.
16
Figure 12: Temperature Measurement Circuit Schematic
This sensor worked essentially as a variable resistor which resistance changes as a function of
temperature; therefore, the voltage applied to the microcontroller will vary with temperature.
Arduino Microcontroller
The Arduino microcontroller acted as the brains of the power meter. The Arduino was
responsible for all data collecting, calculating, and packet transmission. For the power meters, the team
choose the Arduino Uno (figure 13 below). The Uno was the lowest cost sensor that meet our modularity
and performance requirements for the power meters. The Arduino Uno allows for user designed software
to be downloaded and run on it for data gathering and data processing. All data gathered used the Arduino
Unos 10 bit analog to digital converters interfaced with the voltage, current, and temperature
measurement circuits. Once the data is gathered and calculated, it was temporarily stored on SD cards
until enough data was gathered and can be compiled in one central location.
Figure 13: Image of Arduino Uno
SD Card
SD cards were chosen for data storage because they are inexpensive, reliable, and simpler to
implement than a computer server in the amount of time available for the project. There was an SD card
17
installed in each meter for temporary data storage. A larger SD card was installed in the coordinator
which allows for compilation of all of the sensor data into one central location.
Arduino SD card Shield
Figure 14 below is an image of the Arduino SD card shield with the current, voltage, and
temperature circuits attached. The Arduino SD card shield acts as an interface between the Arduino
micro-controller, current circuit, voltage circuit, temperature circuit, SD card, and zigbee radio.
Figure 14: SD Card Shield With Current, Voltage, And Temperature Circuits Attached
Zigbee Wireless Radio
For the transmission of data between the power meters and the coordinator used were 1 mW
zigbee protocol radios. These were the lowest cost radios available and they fully meet the range and data
transmission requirements of the power meter network. These radios operate in the 2.4 Ghz bandwidth
channels. The team implemented the radios in AT mode (Transparent) where communication occurs
18
similar to wired communication. Any data that was loaded to the serial port of the transmitting radio gets
sent and captured in the serial port of the receiving radio. There are no structure requirements to this form
data transmission and all transmission processing must be performed in software.
Software Architecture
Because this system consists of two specific tasks, a program was written specifically for the
taking power measurements, and a program was specifically written for communicating and storing the
data. The first program was for the Arduinos responsible measuring, collecting, calculating, storing, and
transmitting the temperature, voltage, and current values. The second program handled all data
transmitted by the sensor collecting the data before storing it and sending an acknowledgement the
corresponding sensor.
Power Meter Software
Shown in figure 15 is the program flow chart.
Figure 15: Power Meter Software Flowchart
19
The program began by checking if an SD card is present and if not, it will loop until one is
inserted. This prevents the software from entering the main loop with no place to store the data. After
initializing the SD card and any temporary values need for calculations and transmission, the program
enters the main loop where it will check a temporary time value to see if it is time for transmission.
Currently, this value is set to have transmission every five hours, but this value can be changed for
different time intervals. If this test fails, the program proceeds to measure calculate or read the following:
Temperature Voltage RMS Current RMS Arduino Reference Voltage Real Power Timestamp Object ID Transaction ID
These values are then all written and appended (on the last line) to a file on the SD card. The temporary
time value is then incremented and a software delay is executed. Once this delay terminates, the software
loops back to the initial test. When the initial test is passed (whether to transmit data or not), the program
opens the file found on the SD card for reading. A line is read into a buffer and then sent via ZigBee.
After transmission, the software waits for an acknowledgement from the coordinator which consists of the
Object ID and Transaction ID separated a comma. Once the acknowledgement is received, the next line
in the file is sent. This process is repeated until the end of file is reached, where the software closes the
file, and then repeats the main loop again.
Coordinator Software
The flowchart for the coordinator software is shown in figure 16. As with the Power Meter
Software, this program checks for an SD card before initializing temporary buffers and then entering the
main loop. The coordinators job is to actively collect and store all data being transmitted. In other
words, the coordinator acts similar to a server for all the sensors to transmit data.
20
Slightly less complex than the software discussed in the previous section, this program checks for
any available data in the Serial Buffer (where the ZigBees transmit data). If any data is available for
reading, the software then reads one byte at a time until a newline character is read. Once this byte is read,
the data read appended to the file stored on the SD card. After storing, the software sends a reply
consisting of the received Object ID and Transaction ID. This allows transmitting Arduino to continue
transmitting.
Figure 16: Arduino Coordinator Software Flowchart.
21
Range Testing
Zigbee Range Testing
With any communications network it is important to know the capabilities and limitations of the
network. Therefore, we performed range tests on the 1 milliwatt Zigbee radios that were used on our
power meters. We also explored the capabilities of two other zigbee radios. We tested a 60 milliwatt 2.4
Ghz radio and a 900 MHz zigbee radio.
When performing range tests there are two important statistics to look at, received signal strength
indicator (RSSI) and percentage of packets received versus packets lost. Percentage of packets received is
a very intuitive measurement. It is simply the number of packets received at the receiving radio compared
with the number of packets sent from the transmitting radio. This is an important characteristic to know
because if a packet does not reach the receiving radio then that information is either lost or must be
retransmitted. This parameter was measured using two zigbee radios. One of the radios was connected to
an arduino that sent out 100 packets that were 28 bytes in length and then waited 15 seconds and repeated
this process continuously. The second radio was connected to a zigbee explorer usb board (figure 17
below). This board allows the zigbee radio to communicate directly to a computer through a serial port
connection. To verify the successful delivery of the packets we used CoolTerm software, which is a
freeware program created by Roger Meier. CoolTerm displays the information received on a designated
serial port of the computer. Once all of the packets were received we used the 15 second delay between
transmissions to count and authenticate the transmitted data. We performed this test for 5 meter
increments in the basement hallway of the Colorado State University Electrical Engineering building.
This building was chosen because it best simulated the amount of electrical noise we expected would be
in a typical commercial building.
22
Figure 17: Zigbee Explorer USB Board (sparkfun.com)
The second parameter that we tested for was RSSI values. Received signal strength indicator is a
measurement of the power received by an antenna when a packet is received. This value is less intuitive
because a high RSSI value doesnt necessarily correspond with a stronger signal. A high RSSI value can
be due to a large amount of noise on the transmission channel that is being used. However, RSSI can be
useful because a low RSSI value indicates poor signal strength which means the packet is less likely to be
received by the receiving radio.
To measure the RSSI value we used the same setup as the packet success testing discussed
previously, except instead of Coolterm we used the X-CTU software supplied by Digi.com. This software
can be set up to read the RSSI value for some of the radios; however, this software can only handle slow
data transmission rates. Therefore; we had to slow the packet sending rate down to 4 packets a second so
that the X-CTU software could keep up with the RSSI measurements. Similar to the packet success
testing, we started at zero meters and continued to move five meters at a time and record the average
RSSI values until we no longer received any data packets.
23
WiFi Range Testing
The smart power team tested the range of the CC3000 WiFi module from Texas Instruments.
This module is coupled with TIs MSP-EXP430FR5739 shown in Figure 17.
Figure 18: CC3000 and MSP-EXP430FR5739
Using Code Composer v5.5, the Basic WiFi Application (found online @ processors.wiki.ti.com) was
downloaded and modified for range testing. The original program is explained the this wiki:
http://processors.wiki.ti.com/index.php/CC3000_Basic_Wi-Fi_example_application_for_MSP430
Using the same approach already programmed in the software, another command, 0F, was added to call
the wlan_ioctl_get_scan_results which returns results about various networks found in range. The
results are stored in an array and have the following structure:
4 bytes: number of networks found. 4 bytes: the status of the scan: 0 - aged results, 1 - results valid, 2 - no results. 42 bytes: Result entry
1 bit (isValid) 7 bits (RSSI value). 2 bits: security mode: 0 - Open, 1 - WEP, 2 - WPA, 3 - WPA2 6 bits: SSID name length. 2 bytes: Timestamp of scan 32 bytes: SSID name 6 bytes: BSSID
Each bullet point listed above is stored into the results array as little-endian. The first byte of the result
entry has the RSSI (Received Signal Strength Indicator) value for the scanned network. This value is
observed at fixed intervals (i.e. 5m, 10m, 15m, etc.) until the network is no longer found. Because the
24
CC3000 cannot be used as an access point (AP), a Belkin N150 Wireless Router was used as an AP.
Because of this, all RSSI values received were dependent upon the broadcasting strength of this particular
router.
Algorithms
Number of Samples:
The macro definition NUMSAMPLES found in sensor.cpp (See Appendix D) is the number of
samples to record when sampling a waveform. This constant is defined as 64 for a few reasons. 64 is a
power of 2 which is easily handled in binary. On the Arduino Uno, the A/D converter takes about 115 to
125 microseconds, and since the waveforms have a frequency of 60Hz ( period of 16.67ms), then a
maximum of ~139 samples are needed to record a single cycle of the waveform. See equation (1) in
Appendix C.
The closest power of two (128) would be used; however, since the getRealPower function (see
Appendix D) performs two A/D conversion (one for voltage RMS and one for current RMS), 128 samples
would exceed more than one cycle. Therefore the next closest power of two (64) is used. So, in order to
record 64 samples within a period of 16.67 milliseconds, the waveform must be sampled at about 3.84
kHz (260.5 microsecond period). See equation (2) in Appendix C.
Microsecond Delay
The macro definition DELAY_MICROSECS is the number of microseconds to delay between
each sample. This delay is necessary due to the A/D converter reading faster than 260.5 s. Therefore,
the value of this constant is the difference between this time interval and the average read time for the
A/D converter or about 145 s. See equation (3) in Appendix C.
Because the getRealPower has two A/D conversions, the microsecond delay needed is actually 5
times less than the normal 145 s. See equation (4) in Appenix C.
readVcc() Function
25
Acquired from OpenEnergyMonitor.org, this function returns a more accurate reading of the Vcc
reference voltage in millivolts on the Arduino Uno board. In an ideal world, this function would return
5000mV every read; however, this is never the case. This number is used for the D/A conversion for the
teams calculations.
Temperature, Current, Voltage, and Power measurements
Both the getCurrentVal() and getVoltageVal() calculate RMS values and therefore have almost
identical algorithms. The functions will loop through three times the value of NUMSAMPLES in order
to capture about three cycles for more accurate measurements. Inside this loop, the analog value is read
from the corresponding pin and DC bias is subtracted. This value is squared and added to a temporary
variable where the running total is stored. The running total is stored in an unsigned 32-bit integer value.
This 32-bit value can store values up to about 4.3 billion. For 10-bit A/D conversions, 1024 is the max
value that can be read on a pin, and since only 3 sets of 64 readings are taking place, the running total can
never overflow a 32-bit quantity.
Upon exiting the loop, the running total value is averaged and returned. Note, in order to obtain
the RMS values, the returned average value needs to be square rooted. The square root operation is
avoided in the software due to the Arduinos limited processing power with floating point arithmetic. The
temperature measure involves no calculations other than reading the value from the corresponding analog
pin.
The getRealPower() function returns the real power at the time the function is called. According
to IEEE 1459 section 3.1.1.2, The active power P, which is also called real power, is the average value
of the instantaneous power during the measurement time interval to + kT. In the previous section
(3.1.1.1), the instantaneous power is the product of the instantaneous voltage and current values v and i.
See equation (5) in Appendix C.
This value is approximated in the software, due to successive reads of voltage and current. Since the
analog reads (for voltage and current) do not happen simultaneously and also have a delay of about 120
26
microseconds between reads, the power value obtained the software is not truly instantaneous power but
instead a close approximation. This is a limitation due to the A/D converters on the Arduino Unos.
Temperature, Current, Voltage, and Power Conversion
The values stored on the coordinators SD card are unconverted digital values. The square root of
the current and voltage values need to be taken since these are RMS values (avoid on Arduino to save
processor time). All number can be converted to the equivalent voltage being read on the corresponding
analog pin (see appendix F equation (6) ).
According to the TMP36 datasheet (see appendix F equation (7) & (8) ), the conversion from
voltage to temperature is directly related to the outputted voltage.
The RMS voltage stored can be determined by the following equations (after conversion from 10
bit number to analog value). See Appendix F equation (9). The transformer used steps down 120V to 12V
for a ratio of 10, and the voltage divider steps the voltage from 12V to 861 mV for a ratio of 13.9. In this
case the factor would be 139. For example if the 10 bit digital value stored was 31,121:
31 121 5 olts
1024 139 119 3 RMS
Similar to the voltage conversion, the current value read needs to be converted from a voltage
value to its equivalent current value. According to the Current Transformer ECS1030-L72 datasheet the
ratio of output voltage to primary current is 5 millivolts per amp or 200 amps per volt when the burden
resistor is 10 ohms. The burden resistor used in our circuits is 117 ohms (11.7 times larger) and assuming
linearity of this curve this translate to 17.09 amp per volt (200
11 1 09 . See appendix F equation (10).
SD card storage
Implemented in both software for the power meters and coordinator is an SD card storage
function for storing the data. The SD card libraries (found on the Arduino website) allows the
microcontrollers to read and write to an SD card through the use of various functions. Because the data is
written to a .CSV file, a string is assembled with commas as a delimiter before being appended to the
27
corresponding files. All values stored in the .CSV file on the SD card are unconverted 10 bit digital
numbers. This again was to save processing power due to the Arduinos limitation with floating point
arithmetic. To obtain the real world analog value calculations/conversions, the values stored in the .CSV
file should be converted using equations previously discussed. All results and calculations were found
using Microsoft Excel and presented in the Results and Discussion portion of the report.
Cost
As with any project, the cost of the design should be analyzed for marketability and feasibility.
The team built four power meters and one coordinator. The cost of the power meter is about $112.10 per
sensor. The breakdown of cost is shown below. All prices are approximate.
Arduino Uno - $29.95 Resistors & Capacitors - $1.35 Wireless SD Shield - $20 9V DC 650mA Wall Adapter Power Supply - $6.95 Current Transformer - $9.95 Audio Jack (interface for CT) - $1.50 Temperature Sensor - $1.50 Voltage Transformer - $14.00 SD card (2GB) - $3.95 2.4 GHz ZigBee Radio 1 mW - $22.95
The coordinator cost is slightly less expensive as it does not contain circuits for measuring voltage,
current, and temperature. It does, however, contain a larger SD card for storing all date sent from other
nodes on the network. The cost is about $80.85 per coordinator. Again, all prices are approximate.
Arduino Uno - $29.95 Wireless SD Shield - $20 9V DC 650mA Wall Adapter Power Supply - $6.95 2.4 GHz ZigBee Radio 1 mW - $22.95 SD card (4GB) - $8.00
28
Results and Discussions
Power Meter
Figure 19 below shows the power and temperature readings for one of power meters that was
installed. A single power meter monitored a single workstation which contained: two desktop computers,
two computer monitors, two oscilloscopes, two triple output DC power supplies, two waveform
generators, and two multimeters. The figure shows that the power is very sporadic in behavior. The power
had a mean value of 12.6 watts with a standard deviation of 4.6.
Figure 19: Power vs time measurements for a power meter.
We concluded that the data collected and shown in figure 19 is not actually representative of the
power being used by the workstation in the recorded time period. We believe there are flaws in the
software data collection methods we are using that will have to be addressed in the future.
The team fully expected the current measurements to contain many harmonics due to the
non-linear nature of the loads we are measuring. Furthermore, the team was able to confirm the
unpredictable nature of the current with an oscilloscope when the output of the current circuit
was observed while connected to a computer monitor. In contrast, the team expects a very
different behavior for the voltage waveform. For the voltage readings, an RMS value of about
120 volts was expected. This is expected because the output of the voltage circuit was measured
29
with an oscilloscope and observed a voltage similar to figure 5. However, our actual data does
not match our predictions. Figure 19a shows the actual RMS voltage calculated from a sensor.
As can be seen from the figure the actual values differ greatly from the expected value.
Figure 19a: Actual Voltage Readings versus Time
The team does not believe the problem is in the physical circuit that was constructed, nor
is it believed to be a problem with the analog to digital converter on the Arduino microcontroller.
However, in figure 19a it should be noted that there is a single zero reading. The team believes
that this is due to an ADC error because to receive a reading of zero all 192 samples of the
instantaneous voltage would have to of been zero. Since the power meter never lost power while
it was recording, all the zeroes must be due to an analog to digital converter error.
In previous testing, a variable DC power supply is directly connected to the analog to
digital converter input pin on the Arduino microcontroller. The team then looped a simple
program that used the analog to digital converter to measure the voltage from the DC power
supply and convert the binary value into the actual voltage value. The team displayed this value
on a computer screen through serial communication and compared it to the digital display of the
30
DC power supply. It was found that the displayed voltage on the computer screen was accurate
to within the resolution of the analog to digital converter. This was tested further by adjusting the
DC voltage up and down within the input range of the Arduino microcontroller and found that
the displayed voltage changed accordingly with the change in supply voltage. Therefore, the
team does not believe the problem is in the physical design, but in the software.
More specifically the team believes the problem lies in the timing of the readings. When
the meters were developed it was expected that the analog to digital conversions behaved like the
samples in figure 19b below.
Figure 19b: Originally Expected Behavior of ADC
Originally, to get 64 measurements per cycle, the team expected that the actual analog to digital
conversion would take 120 microseconds and then a delay of 140 microseconds is needed to
cover each of the 260 microsecond sample time periods of the 60 Hz wave.
To determine the conversion time, a test program was run that stored the value of the
microseconds counter, then ran 1000 analog to digital conversions, and then stored the
microseconds again. With each conversion, the value was stored in memory to simulate actual
31
readings. Once all of the conversions completed, the team took the later stored microseconds
value and subtracted from it the value from before the start of the conversions. This value was
then divided by 1000, the number of analog to digital conversions, and found a range between
115 and 125 microseconds per analog to digital conversion with an average of 120
microseconds. This is the value used the software, and the team hypothesizes that the use of this
value is causing the sporadic behavior of our voltage readings.
On page 250 of the Arduino Uno data sheet, which can be found at
http://www.atmel.com/Images/doc8161.pdf, it specifies that the analog to digital conversion time
is between 13 and 260 microseconds. This means that to perform an analog to digital conversion
it can take 13 microseconds, 260 microseconds, or any value in between these values. If all
values between 13 and 260 microseconds are equally likely for a conversion time, than the
average value would be 123 microseconds. A value of 123 microseconds is well within the range
that was previously calculated. However, it is this variance in the analog to digital conversion
time that is causing problems.
If the corner cases are observed for the analog to digital conversion speed, it appears this
variance coupled with our polling software method is resulting in false data. Figure 19c below
shows what the 64 samples per waveform would capture if the analog to digital converter was
working at a max conversion speed possible of 13 microseconds per conversion.
32
Figure 19c: Fast analog to digital converter
From figure 19c, the current method of software could potentially only capture half of a
waveform with 64 samples and set delay of 140 microseconds between readings. On the other
end of the spectrum, if the analog to digital converter is running at its slowest rate then the
software would capture a waveform similar to figure 19d. If the values captured are consistently
failing to capture a full waveform, then the RMS calculations are inaccurate (as shown in figure
19a).
Figure 19d: Slowest Running ADC converter
As can be seen from figure 19d, if the analog to digital converter was running at its slowest rate
of 260 microseconds with a fixed delay of 140 microseconds between readings, the software
would end up capturing just over 1.5 waveforms. The last two examples are extreme cases and a
mixed case of fast conversions in some parts of the waveform and slow conversions in other
33
parts is a more likely scenario. Therefore, it can be concluded that this method of polling the
analog to digital converters after set delays is not the proper method. A better method would be
to use the micros function. This function returns the number of microseconds that the program
has been running. With this number, a sample can be measured about every 260 microseconds
using this function. The number returned was compared to a set time interval (260 microseconds
in this case) and once this time has elapsed, the program allows an analog read to be performed.
This forces the analogread function to take place at even time intervals. The team implemented a
sample program to test this theory, and the following data was produced (shown in figure 19e).
Note for the data presented in 19e, the DC bias was subtracted and digital values were converted
to corresponding analog values.
Figure 19e: Voltage measurement waveform (without DC Bias)
The program was able to capture 64 samples of this waveform within 1 cycle. See appendix D
for the sample program implemented to obtain this waveform.
In contrast to the power reading is the reading for the temperature. Figure 20 below shows the
temperature reading which was much less sporadic than the power reading. The temperature had a mean
34
reading of 72.6 degrees Fahrenheit with a standard deviation of 0.65. As can be seen from the graph the
temperature initially increases and then reaches a near steady state after 50 minutes where it continues to
oscillate around the mean.
Figure 20: Temperature vs time for power meter
Similar to the results from the power readings, the temperature readings were also unexpected.
We were expecting the temperature to fluctuate a few degrees; however, this did not occur. From figure
20 we can see that temperature reached a relative steady state and fluctuated a few fractions of a degree.
We believe this was due to stagnation of air around the temperature sensor and an adjustment to the
physical design of the power meter might give more realistic results.
35
Range Testing
Figure 21 below is a graph of the percentage of packets received versus the distance between
radios for the 1 mW 2.4 GHz radios. As can be seen from the figure out to 50 meters there is nearly
perfect data transfer. However from 55 to 60 meters the percentage of packets received quickly drops
from 82% all the way down to 2%. As stated in the methods section of ZigBee range testing, the data
points were obtained in the basement hallway of CSUs engineering building and all testing for this radio
was done with a line of sight between radios.
Figure 21: Percentage of packets received vs distance between radios.
We were pleased with the results of this range testing. Previous Smart Power design teams tested
these exact same radios and were only able to produce a usable range of a few feet. In contrast we were
able to achieve near perfect data transmission out to 50 m. However, the mode of transmission must be
factored into the difference in ranges. All of our data was sent in AT mode while the previous team used
API mode which has a predefined packet structure. This fact likely has implications for the vast
difference in range capabilities and should be explored further in the future.
Figure 22 below displays the percentage of packets received versus the distance for the 900 MHz
zigbee radios. This radio shared a similar trend to the 1 mW radio; however this
36
Figure 22: 900 MHz radio packet % vs distance
radio didnt begin to lose packets until after 100 meters. It should be noted that at 100 meters in the
hallway where testing was being performed, the hallway turns a corner and line of sight testing is no
longer able to be performed. There is also a second turn in the hallway at 110 meters which places two
concrete walls directly in line between the sending and receiving radios. The increase in power of the
antenna and decrease in the broadcast frequency had a positive effect on the 100% transmission range
when compared to the previous radio.
Figure 23 below displays the packet received percentage versus distance for the 60 mW 2.4 Ghz
Zigbee radios. This radio performed similar to the last two radios. It had nearly perfect packet reception
until it reached 100 meters. From there it quickly dropped to 2 packets received at 115 meters.
37
Figure 23: 60 mW 2.4 Ghz Zigbee Radio Received % vs Distance
We were also able to gather the RSSI versus distance values for the the 60 mW 2.4 Ghz radios.
Figure 24 shows the RSSI versus distance graph and figure 25 shows the packet received percentage vs
RSSI value graph. In figure 24 we see that in general the RSSI value steadily decreases with distance until
after 100 meters where the signal is quickly degraded. In figure 25 we see that for RSSI values up to -86
dB we still receive 100 percent of the packets transmitted. However, after this point the number of
packets received quickly diminishes with the decrease in RSSI values.
38
Figure 24: RSSI versus Distance for 60 mW Zigbee Radio
Figure 25: % Packets Received vs RSSI for 60 mW Zigbee radio
39
Figure 26 below shows the RSSI values versus distance for the wifi radio. From figure 26 it is
apparent that the RSSI value for the wifi drops off nearly linearly to 75 meters. After 75 meters we were
no longer able to receive any packets and therefore unable to read anymore RSSI values.
Figure 26: RSSI vs Distance for Wifi Module
Overall the wifi radio did not perform as well as the zigbee radios in the range tests; however, it
should be explored further if this due to the performance of the wifi radio or the performance of the router
it was communicating with.
Modeling
From measurements on our meters we know that it takes on average 4.5 seconds to send 5 hours
worth of 5 minute reading data (60 packets) from a sensor to the coordinator and receiver
acknowledgements back from the coordinator. This means we are sending 60 packets that are 28 bytes in
length from the power meter and 60 acknowledgements 8 bytes in length from to coordinator. So in the
4.5 seconds of total transmission time we are sending 2160 bytes of data which gives us a rate of 480
bytes per second.
40
It is important to know how many sensors can be used in a single network. From the Zigbee data
sheet we know the Zigbee protocol uses 16 bit addresses for each of the sensors; therefore, 2^16 -1
sensors or 65,535 sensors and 1 coordinator should be possible. However, in actuality data collisions
between sensors would occur and these data collisions limit the number of sensors allowed on a single
network.
Since the power meters transmit data only 4.5 seconds every 5 hours, the other 4 hours 59
minutes and 55.5 seconds is available for other sensors to transmit their data. There are 18,000 seconds in
5 hours. Therefore, with perfect clock synchronization between all meters and all meters only taking 4.5
seconds to transmit all of their data. It should be possible to have 4000 power meters on the same network
using only one coordinator.
However, 4000 power meters relies on the use of drift less internal clocks. This is not the case for
the Arduino microcontroller clocks. According to sparkfun.com the clocks on the Arduino micro
controllers can drift up to 0.5% per day. This means that in 1 days time a single microcontroller running
at 16 MHz can drift + or - 7.2 seconds. This must be factored into the modeling of the max number of
sensors the network can support. Now instead of only 4.5 seconds per power meter to transmit data 18.9
seconds must be allocated to each meter to ensure no data collisions occur between meters during a single
day of recording. This also means that the clocks of the power meters all must be resynchronized once a
day. Therefore, with this new 18.9 seconds of allocated time it would be possible to have roughly 952
power meters in a single network.
Conclusion
Overall our team was successful in designing and implementing power meters that transfer data wirelessly
to be stored in a central location. We were also successful in measuring some of the communication
capabilities of different wireless communication modules. However, there is more work to be done with
the power meters.
41
We are confident in the design and implementation of the power meters physical circuits. We
used oscilloscopes and other lab equipment to verify the proper function of these circuits. The future work
to be done is in the data collection and the data transmission parts of the power meters.
For the data collection we expected a relatively steady rms voltage of 120 volts to be read by the
sensors. We expected this because the power grid acts as a voltage source that delivers 120 Vrms.
However, our data did not reflect this expectation. We observed rather large fluctuations in the observed
rms voltage as recorded by our sensors. Because of the similarities in the voltage and current collection
methods used by our power meters we suspect that the same inconsistencies could be affecting our current
readings. The inconsistent readings could also be attributed to errors in the software architecture or
algorithms. Due to the limited amount of time the team was unable to fully debug the software before
implementation, so this is a strong possibility. Our team strongly recommends, further debugging of the
software for future work.
In contrast to the sporadic voltage and current readings were the relatively steady state
temperature measurements. We believe this could also be addressed in future work. We expected more
deviation in the power meters observed temperature. We believe that the lack in fluctuations may be due
to a stagnation of the air inside of the power meter box.
Finally, there are two issues involved with the transmission of data between the power meters and
the coordinator. Currently, there is no means to validate the data that gets sent from the power meter to
the coordinator for storage. Just because the data is received by the coordinator, does not ensure that the
data is the same data as what was transmitted. There is also another problem with the communication
between the power meters and coordinator. Intermittently, when the power meter accesses the SD card for
transmitting data it will hang and remain stuck until the meter is reset. This doesnt occur all of the time
and it doesnt occur on all of the meters. However, it would be important to figure out why this occurs
and how to avoid it. We were able to achieve many milestones with this research; however, there is still
more that can be done in the future.
42
References
[1] Energy, U.D. (2013, May 28). eia. Retrieved November 7, 2013, from U.S. Energy Information
Administration: http://www.eia.gov/tools/faqs/faq.cfm?id=86&t=1
[2] E Source Companies LLC. (2010). Managing Energy Costs in Office Buildings. Retrieved November
7, 2013, from E source Customer Direct:
http://www.energyright.com/business/pdf/Office_Buildings_ESCD.pdf
[3] City of Fort Collins Utilities - PRPA Load Monitor
http://www.fcgov.com/peakload/
43
Appendices
Appendix A: Abbreviations
HVAC Heating Ventilation and Air Conditioning
IEEE Institute of Electrical and Electronics Engineers
V Volts
A Amps
DC Direct Current
AC Alternating Current
RMS Root mean squared
SD Secure Digital
ID Identification
RSSI Received signal strength indicator
dB Decibels
A/D Analog to digital
T Temperature
CSV comma separated variable
ADC analog to digital converter
Hz Hertz
CSU Colorado state university
Appendix B: Budget
For the budget the team approached the Industry Advisor with our bill of materials for the power meters.
The industry advisor informed the team that InGreenium would cover the cost all of the parts made by
Arduino. The rest came from the $207 left in the ECE department student fund and out of pocket
expenses from the team.
44
Appendix C: Time lines
45
46
Appendix D - Sensor Functions uint16_t getCurrentVal() { uint32_t tempSum = 0; int32_t tempSquare = 0; // read three wave cycles for good measurements. for(uint16_t i=0; i
47
current = analogRead(CURRENT_PIN) - (RESOLUTION / 2); power += voltage * current; // delay by a setpoint determined by the frequency of the signal (60Hz in the US), // and the number of samples. // since we're doing two analogReads here, we delay five times less than the defined amount. See
documentation for this calculation. delayMicroseconds(DELAY_MICROSECS / 5); } return power / (3*NUMSAMPLES); } uint16_t getTempVal() { return analogRead(TEMP_PIN); } void writeVals(uint16_t temperature, uint16_t voltage, uint16_t current, uint16_t voltageRef, uint16_t realPower, uint16_t sensorTimestamp, uint16_t objectID, uint8_t transactionID) { // make a string for assembling the data to log. String sensorString = String(temperature) + "," + String(voltage) + "," + String(current) + "," + String(voltageRef) + "," + String(realPower) + "," + String(sensorTimestamp) + "," + String(objectID) + "," + String(transactionID); // open the file. sensorFile = SD.open("data.csv", FILE_WRITE); // if the file opened, then write to it. if(sensorFile) { sensorFile.println(sensorString); sensorFile.close(); // close the file } else { //Serial.println("Error opening data.csv!!"); // error if the file didn't open. } } ----------------------------------------------------------------------------------------------------------------------------- --------------- Sampling Program #include "Arduino.h" int16_t voltage [64]; int32_t time [64]; int arrayPoint = 0; int32_t microDelay = 260; int32_t tempTime = 0; void Setup(){ Serial.begin(9600); delay(2000); // Give time for Arduino to start up. } void Loop(){ if(micros() > (tempTime + microDelay) ){ // wait for 260 uS then take sample
48
tempTime = micros(); voltage [arrayPoint] = analogRead(A4); time [arrayPoint] = tempTime; arrayPoint++; } } int main(){ init(); Setup(); tempTime = micros(); while(arrayPoint < 64 ){ Loop(); } /// Print out the results for(int y=0; y
49
Appendix F - Calcualtions
Maximum number of samples required for a 60 Hz signal given 1 A/D conversion:1 10 3Seconds
120 10 Seconds
13 92 Samples (1)
Sampling Period for 64 samples on a 60 Hz signal
1 10 3sec
4 samples 2 0 4 s (2)
Average microsecond delay between A/D reads.
2 0 4 s 110 s 120 s
2 145 4 s (3)
Average microsecond factor for 2 A/D reads (for power calc. delay).
145 4 s
2 0 4 s 2 115 s 4 4 (4)
Instantaneous power calculation (According to IEEE 1459)
P 1
kT kT
vi dt (5)
Digital to Analog conversion (10 bit resolution)
D ref
210, (6)
where D is the 10 bit binary number and Vref is the Vcc (in Volts) of the Arduino board.
Voltage to Celsius conversion for a TMP36 temperature sensor
C 100 1 50 (7), C
2 500
10 (8)
where V1 is the voltage in Volts, and V2 is the voltage in milliVolts.
50
RMS voltage conversion from analog number.
RMS f (9)
where V is the voltage value read on the analog pin, and Vf is a scalar factor dependent on the
transformer step-down ratio and voltage divider impedance ratio.
RMS current conversion from analog number.
IRMS I If (10)
where VI is the voltage value read (and converted from a 10 bit binary number) on the corresponding
analog pin in volts, and If is the conversion factor in amps per volt.