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

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

2
 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

3
 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

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

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

6
 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

team’s expectations, and only transmitted for a few feet. The team’s 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.

7
 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

8
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 module’s 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

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

10
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 microcontroller’s 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

11
 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

12
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 transformer’s primary side. 30 amps was chosen as the

primary side’s 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

13
 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

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

15
 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

Uno’s 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

16
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

17
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

18
 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 coordinator’s 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.

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

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

21
 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 doesn’t 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.

22
WiFi Range Testing

The smart power team tested the range of the CC3000 WiFi module from Texas Instruments.

This module is coupled with TI’s 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

23
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

24
 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

team’s 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 Arduino’s 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

25
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 coordinator’s 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:

5 olts
√31 121 139 119 3 RMS
1024

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

200
linearity of this curve this translate to 17.09 amp per volt (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

26
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 Arduino’s 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

27
 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

28
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

29
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

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

31
 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

32
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

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

34
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 CSU’s 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

35
 Figure 22: 900 MHz radio packet % vs distance

radio didn’t 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.

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

37
 Figure 24: RSSI versus Distance for 60 mW Zigbee Radio

Figure 25: % Packets Received vs RSSI for 60 mW Zigbee radio

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

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

40
 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 doesn’t occur all of the time

and it doesn’t 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.

41
 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/

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

43
Appendix C: Time lines

44
45
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<(3*NUMSAMPLES); i++)
{
// subtract DC bias. The Current transformer's bias is 2.5 V!! 2.5 V is 1/2 or 50% of the Vcc of
Arduino UNOs
tempSquare = analogRead(CURRENT_PIN) - (RESOLUTION / 2);
tempSum += tempSquare * tempSquare; // square current values and add them to current sum
// delay by a setpoint determined by the frequency of the signal (60Hz in the US),
// and the number of samples.
delayMicroseconds(DELAY_MICROSECS);
}
// return squared value. The final value will be calculated on the coordinator side to save processing time on
the sensors.
return (uint16_t)tempSum / (3*NUMSAMPLES);
}

uint16_t getVoltageVal()
{
uint32_t tempSum = 0;
int32_t tempSquare = 0;
for(uint16_t i=0; i<(3*NUMSAMPLES); i++)
{
// subtract DC bias. The voltage transformer's bias is 3.3 V!! 3.3 V is 33/50 or 66% of the Vcc of
Arduino UNOs
tempSquare = analogRead(VOLTAGE_PIN) - (RESOLUTION * 11 / 17);

tempSum += tempSquare * tempSquare; // square current values and add them to current sum
// delay by a setpoint determined by the frequency of the signal (60Hz in the US),
// and the number of samples.
delayMicroseconds(DELAY_MICROSECS);
}
// return squared value. The final value will be calculated on the coordinator side to save processing time on
the sensors.
return (uint16_t)tempSum / (3*NUMSAMPLES);
}

uint16_t getRealPower()
{
int16_t voltage;
int16_t current;
uint16_t power = 0;
for(uint16_t i=0; i<(3*NUMSAMPLES); i++)
{
// subtract DC bias. The voltage transformer's bias is 3.3 V!!
voltage = analogRead(VOLTAGE_PIN) - (RESOLUTION * 11 / 17);
// subtract DC bias. The Current transformer's bias is 2.5 V!!

46
 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

47
 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<64; y++){
Serial.print("Time: ");
Serial.print(time[y]);
Serial.print(" Voltage: ");
Serial.println(voltage[y]);
}

return 0;
}

Appendix E - Useful Literature

Arduino Uno Specifications and Details

http://arduino.cc/en/Main/arduinoBoardUno

IEEE 1459 - IEEE Standard Definitions for the Measurement of Electric Power Quantities Under
Sinusoidal, Nonsinusoidal, Balanced, or Unbalanced Conditions
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=5439061

Interfacing Current Transformers with Arduino

http://openenergymonitor.org/emon/buildingblocks/ct-sensors-interface

30 Amp Non-invasive Current Transformer Specifications

http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Current/ECS1030-L72-SPEC.pdf

TMP36 - Low Voltage Temperature Sensor Datasheet

http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Temp/TMP35_36_37.pdf

48
Appendix F - Calcualtions

1 10 3 Seconds
Maximum number of samples required for a 60 Hz signal given 1 A/D conversion:
120 10 Seconds

13 92 Samples (1)

Sampling Period for 64 samples on a 60 Hz signal

1 10 3 sec
4 samples
2 04 s (2)

Average microsecond delay between A/D reads.

110 s 120 s
2 04 s 2
145 4 s (3)

Average microsecond factor for 2 A/D reads (for power calc. delay).

145 4 s
4 4 (4)
2 04 s 2 115 s

Instantaneous power calculation (According to IEEE 1459)

1 τ kT
P ∫
kT τ
vi dt (5)

Digital to Analog conversion (10 bit resolution)

ref
D , (6)
210

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

2 500
C 100 1 50 (7), C 10
(8)

where V1 is the voltage in Volts, and V2 is the voltage in milliVolts.

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

50