50
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

Smart Power Monitoring Report

Embed Size (px)

DESCRIPTION

Smart Power Monitoring

Citation preview

  • 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.