Taos TCS3414

November, so soon!  I kind of had to put this one down for awhile and work on things that were not laptop-centric, I just was spending too much time in front of a computer screen.  Luckily, Tiuri De Jong was on the case, and he has developed the proof-of-concept code I posted earlier into a fully-working demonstration.

I uploaded it to my Arduino, and I’m getting stable results with an apparently linear response, although the specific numerical values themselves aren’t particularly meaningful.    For example, under my workbench lamp that I metered at about 40fc and has a CCT of 5000K, it measured 290fc at 3500K.  I get that the part would require calibration before it would be useful, but it’s strange to me that it would be off by 1500K color temperature and a factor of 5 for illuminance, out of the box?  I’d be interested to know if anyone else has a similar experience.

What I’m working on now is measuring the values given by the TCS3414 vs. a known accurate illuminance and color temperature meter, to tell if the deviation from true value is a constant, or a linear function, or what.  I’ve verified that the calculations are done correctly in the code per the datasheet.

But in the meantime, it seems like a shame to deprive everyone else of Tiuri De Jong’s complete and, might I add, lucidly written code, so it may be downloaded here:

2012-11-18 Light Meter Code Rev5

I’ve also posted the code in full after the jump.

Some helpful hints on hardware:  It turns out that as long as you have only one 3.3V device on the i2c bus, you don’t have to have the level shifter circuit I was using, you can connect it directly to the i2c pins (but power it via 3.3V supply, not 5V).  So that’s simpler.  Also, Taos recommends a .1μF decoupling capacitor between the 3.3V supply and ground, located adjacent to the unit, to reduce fluctuations due to logic level shifting:

From page 32 of the datasheet.

The interrupt functionality is not implemented in the current code, so you can leave that pin unconnected, and omit R_PI.

And, the code.  As always, I recommend downloading the zip file rather than copying-and-pasting, sometimes the WordPress monster eats semicolons.


// TCS3414 receiver code rev 5
// Developed by Tiuri de Jong, with contributions by Max Pierson
// This software is released under WTFPL, although credit and share-alike are appreciated.
// 18 November 2012

//include the library for i2c
#include

unsigned int TCS3414values[4]; // [Clear,Red,Green,Blue]
float TCS3414medium[4]; // [Clear,Red,Green,Blue]
float TCS3414mediate[4]; // [Clear,Red,Green,Blue]
float ColorTemperature = 0;

// SET the integration time here. Higher times allow for higher values with better precicion.
int integrationtime = 400; //12 == 12ms, 100 = 100ms, 400 = 400ms. Other values are note accepted
int loopdelay = integrationtime; //loop delay depends on the integration time

boolean debug = false; //change to true if you want to see the various debug serial output bits
boolean percentageEnabled = false; //enable/disable the percentage mode
boolean compensateEnabled = false; //enable/disable color compensation of the sensor sensitivity per color

void setup(){
Wire.begin();// join i2c bus (address optional for master)
Serial.begin(9600);//115200
while (!Serial) {
; // wait for serial port to connect. This while loop is needed for the Arduino Leonardo only
}
CMD(0);
TCS3414Start(14,2000);
}

//The main function.. This repeats itself forever!
void loop() {
getSerialCommands(); //to be able to receive commands

//gets the raw values from the sensors and writes it to TCS3414values[]
TSC3414All(TCS3414values);

//compensate based on the filter characteristics of the TCS3414
if(compensateEnabled)
colorCompensator(TCS3414values);

//keeps a running average from the last 4 values per color.
calculateMedium(TCS3414mediate,TCS3414values,4.0);

//calculates the color temperature, using the algorithm in the TCS3414 datasheet
ColorTemperature = CCTCalc(TCS3414values);

//displays percentage values, if enabled.
if(percentageEnabled){
makePercentage(TCS3414values, TCS3414medium);
}

Serial.print(“Clear: “);
Serial.print(TCS3414values[0]);
if(percentageEnabled)
Serial.print(“%”);
Serial.print(“\tRed: “);
Serial.print(TCS3414values[1]);
if(percentageEnabled)
Serial.print(“%”);
Serial.print(” \tGreen: “);
Serial.print(TCS3414values[2]);
if(percentageEnabled)
Serial.print(“%”);
Serial.print(“\tBlue: “);
if(percentageEnabled){
Serial.print(TCS3414values[3]);
Serial.println(“%”);
}else{
Serial.println(TCS3414values[3]);
}

delay(loopdelay); //delays by the integration time between measurements

}//end loop()

/*
* ======================================================
* Calculation functions
* ======================================================
*/

/*** takes the raw values from the sensors and converts them to
Correlated Color Temperature. Returns a float with CCT ***/
float CCTCalc(unsigned int allcolors[]){
float TCS3414tristimulus[3]; // [tri X, tri Y, tri Z]
float TCS3414chromaticityCoordinates[2]; //chromaticity coordinates // [x, y]

//calculate tristimulus values (chromaticity coordinates)
//The tristimulus Y value represents the illuminance of our source
TCS3414tristimulus[0] = (-0.14282 * allcolors[1]) + (1.54924 * allcolors[2]) + (-0.95641 * allcolors[3]); //X
TCS3414tristimulus[1] = (-0.32466 * allcolors[1]) + (1.57837 * allcolors[2]) + (-0.73191 * allcolors[3]); //Y // = Illuminance
TCS3414tristimulus[2] = (-0.68202 * allcolors[1]) + (0.77073 * allcolors[2]) + (0.56332 * allcolors[3]); //Z

float XYZ = TCS3414tristimulus[0] + TCS3414tristimulus[1] + TCS3414tristimulus[2];

//calculate the chromaticiy coordinates
TCS3414chromaticityCoordinates[0] = TCS3414tristimulus[0] / XYZ; //x
TCS3414chromaticityCoordinates[1] = TCS3414tristimulus[1] / XYZ; //y

float n = (TCS3414chromaticityCoordinates[0] – 0.3320) / (0.1858 – TCS3414chromaticityCoordinates[1]);

float CCT = ( (449*pow(n,3)) + (3525*pow(n,2)) + (6823.3 * n) + 5520.33 );

Serial.print(“Illuminance: “);
Serial.print(TCS3414tristimulus[1]);
Serial.print(“\tx: “);
Serial.print(TCS3414chromaticityCoordinates[0]);
Serial.print(” \ty: “);
Serial.print(TCS3414chromaticityCoordinates[1]);
Serial.print(” \tCCT: “);
Serial.print(CCT);
Serial.print(“K\t — \t”);

return CCT;
}

/*** Keeps a running average of 4 values per color. ***/
void calculateMedium(float med[], unsigned int value[], float divider){
for(int i = 0; i < 4; i++){
med[i] = ( (med[i]*(divider-1.0)) + value[i] ) / divider;
}
}

/*** calculates percentages for R,G,B channels, if enabled. ***/
void makePercentage(unsigned int allcolors[], float allmedium[]){ //makes every color a percentage, 100% is the average of the previous 4 values before this is entered.
for(int i=0; i 0){
int receive_command = Serial.read();
if(receive_command == 49){//49 == 1
Serial.println(“Percentage enabled, max value (100%) set to current medium”);
percentageEnabled = true;//enables/disables percentage mode.
for(int o = 0; o < 4; o++){
TCS3414medium[o] = TCS3414mediate[o];
}
}else if(receive_command == 48){//48 == 0
Serial.println(“Percentage disabled”);
percentageEnabled = false;//enables/disables percentage mode.
}else if(receive_command == 63){//63 == ?
CMD(2000);
}else if(receive_command == 112){//112 == p
Serial.println(“pausing for 5 seconds (stackable)…”);
delay(5000);
getSerialCommands();
}else if(receive_command == 99){//99 == c
Serial.println(“Color compensation enabled”);
compensateEnabled = true;
}else if(receive_command == 110){//110 == n
Serial.println(“Color compensation disabled”);
compensateEnabled = false;
}else{
Serial.print(“The command entered ( “);
Serial.print(receive_command);
Serial.println(” ) was NOT found in the command list”);
}
}
}

void CMD(int delayTime){
Serial.println(“=========== Command list ===========”);
Serial.println(“\’ \’”);
Serial.println(” ? == Show this command list”);
Serial.println(“”);
Serial.println(” p == pause for 5 seconds (stackable)”);
Serial.println(“”);
Serial.println(” 1 == Enable Percentage mode”);
Serial.println(” 0 == Disable Percentage mode”);
Serial.print(” Percentage mode is currently: “);
if(percentageEnabled){
Serial.println(“ON”);
}else{
Serial.println(“OFF”);
}
Serial.println(“”);
Serial.println(” c == Enable Color compensation mode”);
Serial.println(” n == Disable Color compensation mode”);
Serial.print(” Color compensation mode is currently: “);
if(compensateEnabled){
Serial.println(“ON”);
}else{
Serial.println(“OFF”);
}
Serial.println(“\’ \’”);
Serial.println(“====================================”);
delay(delayTime);
}

So, my inimiatable Aunt Carol rented a house on the Indiana Dunes National Lakeshore.  That’s her above, in red.  I took the pinhole camera I posted about earlier along for the week.  It was the last week of summer, and the days were still just warm enough to swim.

We wandered on the lakeshore,

Decomposing fish.

And visited friends:

Tom, McKalen (sp?), my Mom

We also drove around Gary, IN:

Burned out library, Gary, IN

Double exposure, library interior with U.S. Steel plant.

Not to represent the place as a wasteland or something, the library just had too many great angles not to photograph.  As it happens there is a larger, modern library nearby.

We also went into Chicago for a day.

We also ate lots of things:

The Indiana/Michigan sky was nonstop amazing.

Sunset, false color provided by my scanner firmware freaking out.

Sunset, last day of the trip.

Left: Sequoias. Right: My apartment

Travel+Photography: I took the pinhole camera I made backpacking in Yosemite National Park.

Ostrander Lake, headwaters of Bridalveil Creek.

Pine cones on the forest floor.

Ghost town near the park entrance.

Sunset reflecting in the lake.

And some back in San Francisco:

Double exposure with rainbow and night scenes.

Open shutter, 10 minute exposure while walking.

Coming whenever I get around to scanning them:  Chicago!

haha, oh god.  So I just started a new job, and I’m the incoming treasurer for the IES SF section, and I’m in submittals on the library project, and I’m taking my LC exam this fall, and I’ve been dating some, and my D&D campaign has started up again so I’ve got that prep time every week in addition to game night…  things are going really, really well for me right now but I don’t have a lot of time for personal artistic pursuits, and also everything I’ve been working on has been pretty laptopy lately.  So I decided what I really needed was some immediate gratification, in a project I could finish in a weekend with a minimum of planning.

Test-fitting the film, before the film advance mechanism was finished, and the whole thing was painted flat black inside.

I went shopping for the cookie tin that became the camera body Saturday morning, and was scrambled to finish it up before I ran out of light on Sunday.  I finished about 45 minutes before dusk, loaded up a roll of film, and started walking East, through Union Square and down to the Embarcadero.  The shot at the top of the post is the last one on the roll, the Bay Bridge and Treasure Island, with the fogline rolling into the East Bay.

And above is the first picture I took.  A selfie!  I spent some time today building a smaller aperture, which should fix the blurry problem.  I also need a better attachment to the tripod, the one I tried first is pretty wobbly.   I’d kind of stopped taking pictures of things because I’m just kind of burned out on digital photography right now, but this has been really fun and creative.

Oh, hey, if you have any tips about how to get a nice round hole .29 mm in diameter, leave me a comment!

Sunday at Cup a’ Joes, one of the enduring loves in my life.

‘

Well, this was a productive night:  I’ve been working with the Taos TCS3414, which is a light and RGB color sensor.  It’s a tiny little guy, about 2.5 x 3.5 mm I would guess, and shown above is mounted on breakout boards.  I just had a breakthrough night with it, getting it to correctly return values from the sensors, so I thought I’d share my preliminary code for the benefit of all.

Update: better code here!

Helpful tips:

• The TCS3414 is I²C, whereas the TCS3404 uses the similar SMBus.  The Atmega 328 can do both, but I²C is easier for reasons of both hardware and libraries, so get the TCS3414.
• I²C is on analog pins 4 and 5, not digital pins 4 and 5.
• It’s a 3.3V device, so make sure you power it via the 3V output on the Arduino, not the 5V output.  It draws 9ma max, so the 50ma capacity via Arduino is plenty.
• Similarly, you’ll need to level shift 5V bidirectionally to 3V from the Arduino to the sensor, so google logic level converters.  I used a pair of NTE491 MOSFETs.

Here’s what my hardware looks like (note, my breakout board pins aren’t the same layout as the sensor):

That all being said, here’s my (working concept only) code!:

delay(500);
}


If you’ve done it right, it should start spitting out meaningless numbers, that decrease when you hold your hand over the sensor!  More to come on this topic soon!

A visualization of Continuous Daylight Autonomy (cDA)

Why Daylighting: As an (electrical) lighting designer, daylighting is exciting to me for a lot of reasons.  There are energy conservation reasons, of course–40% of the electricity consumption in commercial spaces is lighting, and daylight harvesting is a mostly untapped method of reducing that sum.  There is evidence that a connection to the outside world is beneficial to the happiness and productivity of the occupants, such as the research conducted by the Heschong Mahone Group on classrooms and commercial office spaces.  And, artistically, there’s a tremendous potential to create dynamic sculptures using the sun and building form, and to contribute to the narrative of the architecture.

Know your sDA from your aSE: I just got back from attending the Daylighting Institute at the 2012 Lightfair, which if you have a chance to go is really worth your time.  As the LEED sustainable building program becomes the default for high-profile projects, it is pushing daylighting design from the provenance of academic research and a few specialty firms out into the mainstream of standard architectural practice.

Many of the seminars this year revolved around the various daylighting metrics available, whether moment-in-time based metrics such as that found in LEED 2.2, to dynamic metrics such as daylight autonomy (DA), useful daylight illuminace (UDI), and spatial daylight autonomy (sDA).  I thought a quick reference guide to the various ways of measuring daylight within the space, with examples, might come in handy for people like myself that are trying to get a handle on all this.  The metrics are in approximate order of how established they are within the design community, with metrics that are still under active development like Spatial Daylight Autonomy towards the end.  I’ve also created a generic example space to help explain the concepts.

The example space, rendered in AGI

For purposes of visualization, the above space a 32′x32′ classroom, with a large window along one wall.  While I’ll be referring to this as a classroom, I wanted results that are generally applicable as a basis of comparison, so I have excluded federal holidays from the occupancy profile, but not the summer and winter holidays and the like.  Maybe a lot of kids get detention in this particular class :)

The Focal Point Verve IV, used for the electric lighting

The reflectances are the typical 80% ceiling, 50% walls, and 20% floors.  I am using the Focal Point Verve IV with two outboard up/down lamps and a center downlight lamp for multimedia presentations, along the line of what the Collaborative for High Performing Schools (CHPS) recommends (only the outboard lamps are on for purposes of calculations).  In other words, it’s a typical classroom lighting setup.

Graphic of Daylight Factor, calculated in Daysim

Daylight Factor (DF): The ratio of internal illuminances to exterior illuminances, under a CIE overcast sky.  For example, if you have 2,000 fc exterior, and 20fc average interior, that’s a 2% DF.  This is the earliest standard of daylighting, developed as a legal basis in 19th century Britain for determining when a new structure would intrude on the daylighting of another.  A DF greater than 2% is considered adequate, 2-5% is considered well daylit.

Pros:

• It actually works pretty well if you are somewhere with prevailing foggy or cloudy conditions, such as, well, London for example.
• Simple to calculate and can be generated without any additional effort in AGI32.

Cons:

• DF gives the same results independent of orientation, time of day, and climate.  So for a north-facing window in a foggy climate, it would be of some use, whereas for a western exposure in Phoenix, it would give *very* inaccurate results.

Our example:  Daysim unfortunately doesn’t give calculation summaries, but AGI gives us 2% total for the space.  You can see the distribution above.  So that would be considered acceptably daylit.  However, looking at the distribution of daylight factor percentage from Daysim above, supplementary electric lighting would be needed for the row of fixtures furthest from the window on almost every day.

LEED 2009, Prescriptive Method: Calculate the ratio of window area (above 30″) to floor area and multiply by the visible light transmittance (VLT).  Achieve a value between .150 and .180.

.150 < VLT * WFR < .180

I mention this only in passing because it’s not really a design tool so much as a LEED compliance metric, but our floor area is 32×32 = 1120 sq. ft., the window surface area is 96 sq. ft., giving a Window to Floor ratio (WFR) of .087.  So unless there is a glass type that will transmit more light that it receives, this space would not qualify for LEED credits via the prescriptive method.

The classroom at 9am on the equinox. Values below 25fc are highlighted in blue.

LEED 2009, Simulation Method:  ”Demonstrate through computer simulations that 75% or more of all regularly occupied spaces areas achieve daylight illuminance levels of a minimum of 25 footcandles (fc) and a maximum of 500 fc in a clear sky condition on September 21 at 9 a.m. and 3 p.m. Areas with illuminance levels below or above the range do not comply. However, designs that incorporate view-preserving automated shades for glare control may demonstrate compliance for only the minimum 25 fc illuminance level.”

Pros:

• I think if you want a pass-fail metric, this gives a lot of value relative to its fairly simple nature. There are a lot of high-performing daylit spaces that would not meet this metric, but you are probably doing more right than wrong if you do.

Cons:

• For most spaces, it’s very unlikely that you can get this LEED point without skylights.
• Automated shades, which would be necessary for most buildings with windows, are expensive and fussy to get working correctly.
• Since this is run under clear sky conditions, it’s more of a worst case scenario than typical of conditions at a given project site.

Our example:  Calculated values for the different orientations (in AGI32) are as follows:

So this space would not qualify for LEED points using either method.

Dynamic Metrics: the metrics after this point are dynamic, i.e. rather than simulating a few scenarios as typical, they take a weather file with hourly measurements of solar irradiances, and attempt to return a comprehensive result for the performance of the building over the course of a typical year.

For more on this subject, I highly recommend “Dynamic daylight performance metrics for sustainable building design” by Reinhart, Mardaljevic, and Rogers.  This is probably a good time to say that this article does not represent original research on my part, I’m just summarizing notes from lectures I’ve attended on the subject along with other reading I’ve done.

Daylight Autonomy (DA): an annual analysis of the fraction of occupied time that the daylight levels exceed a specified target illuminance.   So for every point in the space, what fraction of the time could an occupant work without supplemental electric lighting?  Put another way, DA as a metric has three inputs: climate-based daylighting levels over an entire year, the actual hours of operation of the facility, and the specific desired lighting level.

Pros:

• DA gives an intuitive look at how well daylight will penetrate into the space.
• Good for determining which fixtures would benefit from automatic daylight harvesting.
• Takes into account the hours of actual operation and real weather conditions at the site.

Cons:

• Since there’s no upper limit on the allowed illuminance levels, poorly performing spaces with direct sunlight could do quite well on this metric.  To put it another way, a glass box would have a DA of 1.0, but that wouldn’t be a very comfortable space to be in, as it would essentially be a greenhouse.

Our example:  Daylighting is present under the first row of fixtures often enough that it might make sense to put them on a switching control as they’ll likely be off during all daylight hours and on during all occupied night hours.  For the second row, it would appear that supplemental electric lighting would be needed during most of the day.

Continuous Daylight Autonomy (cDA): As per above, but partial credit is given for daylighting that is less than the target illuminance.  For example, if your threshold value is 30fc, and you (somehow) have 15fc at a specific point 100% of operating hours, your cDA for that point would be .500

Pros:

• I think cDA is intended for use as a compliance metric more than a design tool.  While a space that has enough daylight to reduce electric lighting loads would do pretty well on cDA, problem times and climate scenarios would not necessarily be apparent.

Cons:

• cDA is less suited for comparing two potential designs, because if you have .100 for an area, it’s not clear whether that’s because there were 30 fc 10% of the time, or 3fc 100% of the time, or what proportion in between.

Our example:  We can resolve that ambiguity above by comparing the cDA map against the DA map in the prior section.   For example, in the side of the room nearest to the windows, the map looks about the same from DA to cDA, so when there *is* daylight, it’s sufficient for task lighting.  Conversely, for the lower half away from the windows, there’s hardly ever light above 30fc as the DA map is solid blue, but there is pretty consistently a fraction of the necessary light, so dimming controls would be advantageous for that row of lighting.

Useful Daylight Illuminance (UDI): Another variation on Daylight Autonomy, UDI attempts to penalize for direct sunlight that falls into the space, on the theory that people will find this glary and distracting.  UDI is a set of three numbers for every point in the space, the percentage of time that a point was below a minimum threshold, between a useful minimum and maximum value, and above a maximum value, which could result in glare or thermal discomfort.  Often 10fc is used as the lower bound of useful illuminance, and 250fc on the upper bound.

Pros:

• Most of the advantages of DA, but an additional dimension for glare and thermal discomfort.
• Good for comparing the performance of two design variations.

Direct sun exposure causing veiling glare on the whiteboard (window faces West in this simulation).

Daylight Glare Probability (DGP): Glare is when the ratio of luminances within the field of view of an observer exceeds the comfortable dynamic range of the eye, such that the highlights appear blindingly white, and details are obscured by stray light bouncing around in the eye.  It’s a hard metric to quantify because it’s very dependent on the observer (personal preference and age), the position relative to sources and the specific task being performed, and can arise in a number of ways such as reflections from the sun or luminance ratios between windows and adjacent surfaces.

The reference method for glare assessment calculations is to generate an HDR image for the position in question for every daylight hour of the year, and then compare the luminance ratios and adjacencies to come up with a probability that an average observer at that point would find it objectionable.  But, doing this for even a simple space with one observer position entails thousands of hours of calculation, so in practice a simpler method is necessary. Daysim is capable of assessing an optimized algorithm DGP for a defined viewpoint.

This is very much an area of active research, but a proposed metric for DGP in Wienold 2009, Dynamic Daylight Glare Evaluation, is below.

Pros:

• Predicts potential glare issues directly by evaluating luminance ratios, rather than a proxy metric such as aSE.

Cons:

• Even with the simplified/optimized algorithm used in Daysim, it’s a very time-consuming calculation.
• The optimized algorithm does not incorporate peak glare  from sources such as specular reflection or direct sunlight exposure on reflective surfaces, if I understand it right.
• Results are only for the location and orientation tested.
• Conceptually opaque, i.e. it’s hard to make a correspondence between the DGP number and what the specific qualitative problem is.

Our example:  I wanted to try orienting the classroom to a west-facing window, and then run DGP for a ‘student’ position and a ‘teacher’ position in front of the whiteboard, but I couldn’t get Daysim to return a DGP in a reasonable amount of time.  The computer ran for a full day without finishing (3.0 GHz dual-core processor, although it appears to only use one core for this calculation).  I think that any metric that takes longer than 24 hours to calculate has a severely limited utility as a design tool.

Slide from a recent lecture by Lisa Heschong and Kevin Van Den Wymelenberg

Annual Sunlight Exposure (aSE): is the number of hours per year at a given point where direct sun is incident on the surface.  It has a great deal of import generally for heating and cooling, and is well-established in use for displaying artwork that the sun would damage.  There are IES recommendations for how much annual light exposure artwork of various types may tolerate, in lux-hours.

In the forthcoming IES LM-83, aSE is defined as the percentage of square footage that has direct sunlight for more than 250 hours a year.  Direct sunlight is abstracted as >100fc incorporating glazing materials, but not sky light, bounce light (radiosity), and not incorporating operable shades.

Pros:

• Fast to calculate, since it doesn’t require radiosity solutions or luminance maps for an observer point.
• Useful as a design tool, since it gives a good handle on where the problem areas might be of a design.
• Incorporates potential issues of thermal discomfort.

Cons:

• Does not address issues of glare due to specular reflections or veiling glare from high luminance ratios.  aSE not, strictly speaking, a glare metric at all, it’s just a proxy that has been found to predict glare discomfort in many cases.

Our example: Since this standard is still under development, it’s not surprising that neither Daysim nor AGI has a pre-built configuration for it.  For the north-facing window, the aSE would be 0 of course, since no direct light from the sun (not sky) would pass through the window.  But, above is a slide from a recent lecture I attended with a similar space, at least in the sense that it has large north-facing windows.  The A-B-C classification is a field study of how highly the occupants rate the quality of the daylight in the space vs. predicted quality via sDA and aSE, somehow?  There were 150 slides, so some of it went by before I could really absorb it.

Spatial Daylight Autonomy (sDA): is another metric that is under active development, but it will described in IES LM-83, which is expected to be released later this year (2012).  sDA is the percentage of area that is above 30fc 50% of the time or more during business hours.

Pros:

• Unlike Daylight Autonomy which returns an array of data points for every location in the space, it returns a single number for the space.
• Experimentally verified to predict occupant satisfaction, using a large study of 61 sites (forthcoming study by HMG group).

Cons:

• I don’t know if this is a drawback since it’s by design, but it’s worth pointing out that sDA does not incorporate glare or direct sun exposure– it is intended that aSE would be evaluated separately.

 In Conclusion:

There are a number of discrete tasks that the daylighting consultant has to perform, such as comparing design variants for performance, selection of glazing and operable shading materials, and communication of the impact of design choices to other members of the design team.  All of these metrics can contribute to some of those tasks, and which metric is optimal can depend greatly on the project geometry and location.

It’s an exciting time to be working in this field, because due to voluntary sustainable building initiatives such as LEED, there is a great deal of visibility for the benefits of daylighting, and I think we’re on the cusp of it becoming a design fundamental for most projects.  Already, daylighting contribution is routinely considered in some project types, such as classrooms and airport concourses.

While my expertise is in electric lighting, I’ve been working on learning about this subject, because I think that the next generation of lighting designers will also be daylight consultants– the interactions between daylight and electric lighting are profound, and lighting designers are or at any rate should be already comfortable with running photometric simulations.  I hope this was interesting and useful to you, please do drop me a line or comment if there’s anything you’d like to add!  (or correct, of course)

Here are some pictures from a production of Fool for Love that I designed with Boxcar Theater Company.  What’s notable about this production is that I made all of the lighting fixtures.  As a site-specific piece, we didn’t want to introduce anything into the performance space that didn’t belong there, such as theatrical lighting equipment.  So I modified practical lighting fixtures to work for theatrical purposes.  The result was a performance that was truly without a proscenium frame, more raw and intimate than theater, even good theater, is usually.  Additional pictures after the break.

The purpose-built theater as it appeared in preshow

Click to enlarge.

Here is something you can do on Friday:  Now playing at the Hyde Street Studios with Boxcar Theater company, True West by Sam Shepard.  This is the first of two plays I’m designing with Boxcar Theater company, and it’s a great show, and I’m very happy with the design.  I’ll do a writeup for it on my portfolio site.

True West runs through April 7 and I hope you can make it.  More information here.