23rd
Analysis
final blog in a series of 5
There is still quite a bit of detective work to be done. A cursory look at our graphs shows we are using on average 40kWatts (the equivalent of 400, 100 Watt, light bulbs) during nights/weekends and about 120kWatts peak during normal business hours.
From the below graph we can see that during business hours something is causing large spikes. Since this only happens during typical work hours we could probably attribute this behavior to the power hungry tools in our awesome Models Shop, or maybe the elevator. The spikes are probably due to the inductive load introduced when a motor such as a saw or compressor is turned on.
The chart below is a display of power use over a ten day period. You can see the reduced power consumption over the weekends and holidays. I would gather that since there is a small amount of power consumption on Monday May 25th (Memorial Day) some Continuumites are workaholics!
What’s Next
Possible improvements
Migrate data server applications to a proper web server
Add multi client capabilities so we can host data from other users.
Tie in real time power cost metrics
Carbon footprint tie in
Tie in weather parameters such as outside temperature and humidity.
Contribute
If you find this design intriguing and would like to contribute in some way, or if you have any questions feel free to email me at mcosta@dcontinuum.com
I am curious how you tracked the office energy usage. Did you gather the data yourself? Was it taken from the power meter or power company?
I’d be quite curious to try something like this in my own home to see what power-patterns I create.
http://www.conalldempsey.com
Hi Conall,
You can see my earlier posts about the design here. http://www.trackchanges.net/category/sustainability/
The implementation I used would not work in a typical American home but there are other ways to do it. Eventually I will put together a writeup for the average home user.
[...] page gives some more context on the data. Check out more about the project’s impact on the Analysis page. The data can be sent to any device as long as the device has internet access and can read a [...]
[...] page gives some more context on the data. Check out more about the project’s impact on the Analysis page. The data can be sent to any device as long as the device has internet access and can read a [...]
[...] page gives some more context on the data. Check out more about the project’s impact on the Analysis page. The data can be sent to any device as long as the device has internet access and can read a [...]
[...] a little some-more context on the data. Check out some-more about the project’s stroke on the Analysis page. The interpretation can be sent to any device as prolonged as the device has internet [...]
Mike, have you guys ever used LabVIEW and NI hardware for experiments like this? Have any of you ever worked with graphical programming before?
-Jonathan
Jonathan
Yes we have used LabView a number of times on various projects, but our software dept normally avoids it if possible. It would not have been appropriate for this project since I wanted an embedded device, not a windows based machine.
Hey Mike,
Tell them they can’t resist labview… it’s like programming with crayons
Labview is not appropriate when one intends to migrate to an embedded system, since the ‘code’ is completely discarded. We tend to build prototypes in languages that are directly applicable to development. Experience has shown that this is the more efficient path for an embedded engineer.
However, if one is not a programmer, then Labview can surely be the only course available.