Published February 12, 2019 © MIT

Measuring Power Consumption with the Digilent OpenLogger

How much power does an everyday appliance use? How can we look at and interpret this data?

IntermediateFull instructions provided4 hours1,822

Measuring Power Consumption with the Digilent OpenLogger

Things used in this project

Hardware components

Digilent Openlogger

Story

Introduction

There are many reasons why we might want to log AC current data. For instance, we might want to look at how much power various appliances around the house use at different times during the day. For the purposes of this project, I want to find the answer to the following question:

How much does it cost to make a piece of toast?

Of course the answer to this question heavily depends on how much power costs, the particular toaster and settings used, and perhaps the national voltage standards in place. My answers won't apply for everyone, so if you want your own answer, you'll have to try this at home.

Setting Up the Logger and Sensor

Digilent's OpenLogger is a low cost data logging device that can be used to collect analog voltage data over time (it has a lot of other potentially interesting features not needed for this project). More information can be found at it's Crowd Supply page. In addition to the OpenLogger, I used the OpenLogger's Screw Terminal Adapter to connect a current sensor's leads to the OpenLogger's analog inputs.

For the current sensor, I used a Seeed Studio Non-invasive AC Current Sensor. This device clips around a current carrying wire and uses the magnetic field generated by the wire's current to induce a current in the sensor. This current creates a voltage difference on the sensor's output leads, which can be read and logged by the OpenLogger. I chose this particular sensor because its design, by including an internal biasing resistor, meant that I didn't need to create any additional circuitry between its leads and the OpenLogger's analog inputs. I clipped off the sensor's output jack and stripped the wires back.

In order to be able to attach the logging system to a household appliance, I modified a US standard three-prong Male-to-Female cable so that the three internal wires were exposed.

I screwed the red and white internal wires from the current sensor's output lead into the Screw Terminal Adapter's analog input #1 and analog ground headers (labeled AI1 and AGND, respectively).

I then clipped the current sensor around one of the current-carrying wires in the modified three-prong cable. Since I used the 70 Amp maximum variant of the current sensor, I had to loop the wire through the current sensor. The extra loop increases the amount of current detected by the sensor, which increases the voltage levels at the sensor output. Since I wasn't looking at currents higher than about 10 Amps, this made relatively low currents more apparent in the logged data.

The completed system can be seen below:

Collecting and Interpreting Data

I used WaveForms Live to collect data from the OpenLogger. This let me quickly configure and control the OpenLogger. Of particular note, before running the trials, I needed to configure the OpenLogger's data buffer. Toast (typically) takes less than ten minutes to make, so I picked a buffer size of 600.0 seconds. US standard AC power runs at 60 Hz, so I picked a resolution (Samples/) of 1.2K samples per second, so that I would get a good number of samples (20) in each 16 2/3 millisecond period (1/60Hz).

I could potentially capture much higher resolution data than this, but for this long of a period of time, I'd like to keep the sizes of the data files to a reasonable level - a full buffer of 1200x600 floats will take up several megabytes of space, which in Chrome will need to be stored in my laptop's RAM. If I ran my trials at the full speed of 500KS/s, I'd need 1.2 gigabytes to store all of that data.

VOLTS TO AMPS:

In addition to setting the buffer size and resolution, I also needed to set up a conversion function before capturing data. I used the "Scale" field under the Logger instrument in WaveForms Live to convert the voltage data into an approximation of the current flowing into the toaster. The equation is simple enough, v/35, in units of Amps.

Some googling turned up some information about the current sensor, namely that it uses a 26.6 Ohm load resistor and has a turn ratio of 1866:1. I could have used these numbers in place of the "70" for a bit more precision, but the conversion factor (1866/26.6=70.1) is close enough to 70 that it isn't really needed. The number of times the three-prong cable passes through the current sensor (two, for my setup) is also relevant here. The scale equation comes out to voltage, multiplied by the number of "turns" in the cable, divided by 70, hence "v/35".

DATAFEATURES:

With the scale field set up, I started streaming some data from the OpenLogger into WaveForms Live, and made some toast. Taking a look at the data collected, the current fits nicely to a sine wave, with a constant amplitude for as long as the toaster was running. It became pretty clear that the toaster's numeric setting, set to "3" for the first trial, is just the number of minutes it runs for.

I then used the MATH button in Waveforms Live to get an estimate of the amplitude and frequency of the logged wave. As expected for the United States standard, the frequency was approximately 60Hz. The amplitude of the wave came out to approximately (FIXME).

CALCULATING POWER:

A standard formula for the apparent power delivered by a source in the form of a sine wave is the product of the RMS (root mean square) voltage and the RMS current of the wave. This could be made a little more robust by measuring the voltage waveform, and calculating the phase difference between the two, but the added cosine factor only lowers the estimated power, and I don't expect that there would be much of a reactive component in the toaster. The Wikipedia article about AC power is pretty informative. Notably, the RMS voltage standard for the United States is 120V.

PROCESSING DATA:

In order to get a slightly more accurate estimate of the power consumption during any particular trial, I used WaveForms Live to export my data to CSV files and used a small python script to calculate the RMS current logged. This script can be found in the Sources section below. The script eliminates the "dead time" before the toaster is started and after it stops. It estimates the amount of time that the toaster ran for and prints the information we care about - run time, RMS current, Wattage, and Kilowatt-Hours. The last piece is what I used to put a price tag on the power consumption. On average, electric bills in Seattle run about $0.108 per Kilowatt-Hour, and the script uses this figure to estimate the cost of power used in the trial.

Results

As seen in the screenshot above, after this initial trial, I ran one more trial. I set the toaster to "6" instead of "3". Surprisingly, the numeric setting isn't exactly the number of minutes the toaster is active for: the setting 3 trial lasted for 2.7 minutes, while the setting 6 trial lasted for 4.3 minutes. The power used was consistent with these measured durations, running a bit below 800 watts on each trial. The estimated cost of power used came out to less than a cent for each trial. This is, of course, significantly less than the price of the bread used - something like 10 slices per loaf for several dollars per loaf. The fact that I can collect this data is still interesting though, and I have several ideas for other things I can collect data on that may be more useful or interesting.

Next Steps

As of time of writing, support for logging data over WiFi or to an SD card with the OpenLogger is still a week or two away. Once these features are supported, I can use the same sensor/logging system to log for significantly longer periods of time. For example, I'm thinking about trying to log data while a coworker's hybrid car is charging, a process which may take several hours.

I could also collect data on some other types of appliances, and try to see if the same mathematical expressions support estimating power for non-sinusoidal current data. For example, switching power supplies, like those used on most computers, have current graphs that look very different from those of appliances that directly consume AC power.

csv_parse.py

from sys import argv
from math import sqrt
threshold = 0.6
filename = argv[1]#'LoggerData-0.csv'

def first(the_iterable, condition = lambda x: True):
    for idx, val in enumerate(the_iterable):
        if condition(val):
            return idx

with open(filename) as csv_file:
	s = csv_file.read()
	l = s.split('\n')
	data = []
	for row in l[1:]:
		fields = row.split(',')
		if fields != ['']:
			data.append((
				float(fields[0]),
				float(fields[1])
			))
	print('Number of samples:', len(l[1:]))
	trigger_start = first(data, lambda x: x[1] >= threshold or x[1] <= -threshold)
	data.reverse()
	trigger_end = len(data) - 1 - first(data, lambda x: x[1] >= threshold or x[1] <= -threshold)
	data.reverse()
	print('buffer clipped:')
	print('    start: %d %f' % (trigger_start, data[trigger_start][0]))
	print('    end: %d %f' % (trigger_end, data[trigger_end][0]))
	duration = data[trigger_end][0] - data[trigger_start][0]
	print('trial duration: %f minutes' % (duration / 60.0))
	i_rms = 0.0
	for idx in range(trigger_start, trigger_end):
		i_rms += data[idx][1] * data[idx][1]
	i_rms /= trigger_end - trigger_start + 1
	i_rms = sqrt(i_rms)
	v_rms = 120.0
	print('RMS Current: %f Amps' % i_rms)
	print('RMS Voltage: %f Voltage' % v_rms)
	print('apparent power: %f Watts' % (i_rms * v_rms))
	print('Cost per Kilowatt-hour %f' % 0.108) # This is the average for seattle
	kwh = (i_rms * v_rms / 1000.0) * (duration / 3600.0)
	print('Kilowatt-hours: %f' % kwh)
	print('cost of trial: %f' % (kwh * 0.108))

Credits

Arthur Brown

14 projects • 30 followers

Applications engineer and digital logic geek

Sam Kristoff

35 projects • 54 followers

R&D Director at NI

Measuring Power Consumption with the Digilent OpenLogger