Nick,<div><br></div><div>I just came across the same question recently, here's what I've discovered.  In my case, I was looking at the difference between using photosensors or simply using the BAS to control exterior lighting.  </div>
<div><br></div><div>This was part of a larger eQUEST project, but I also created a spreadsheet to look at the difference between operational hours.  For the BAS, we were assuming monthly schedules, but these could actually be different by each day.  A simple algorithm can be created on an hourly basis to calculate sunrise and sunset, but the BAS works on an hourly resolution.  This means that if sunrise is at 5:30, you'll have to leave the lights on until 6:00.  In addition, to be conservative for safety sake, we let the BAS keep the lights on shortly through sunrise and before sunset.  The spreadsheet shows that using a photocell can reduce hours vs an average-ly programmed BAS.</div>
<div><br></div><div>In the spreadsheet, I assumed a horizontal flat plate collector surface for the photosensor, which I believe is also what eQUEST assumes.  Consequently, there's no need to worry about cloud data or any other miscellaneous solar data, which are only used to calculate the irradiation on a tilted surface given the irradiation on a horizontal one.  Global horizontal radiation (diffuse plus beam) and diffuse horizontal radiation are actually measured at the TMY3 stations.  It's also important to remember that the TMY files are not averaged data, but each month is a "typical" month, and two of the primary parameters in determining a typical month are global horizontal and diffuse horizontal radiation.  So the solar radiation data in TMY file should pick up regularities such as "June Gloom" in Southern California for instance.</div>
<div><br></div><div>The major weakness in the spreadsheet is how to determine the efficacy (Lumens/watt) of sunlight.  In fact, I resorted to using 93 Lumens/Watt for direct sunlight, which I got from Wikipedia.  For the diffuse radiation, I assumed 10% the efficacy of direct radiation.  I have no idea if this is close to valid, but I'm fairly certain that the atmosphere reflects/absorbs visible light at a higher proportion to IR radiation.  The efficacy of beam radiation should be fairly constant, but the efficacy of the diffuse radiation gets very complicated.  In theory, it should depend on the particulate properties of the atmosphere.  At best, I think we could hope for an efficacy model which depends on solar geometry and cloud cover.  This wouldn't be able to account for things such as smog in a dense city.</div>
<div><br></div><div>Anyway, if you were to do an hourly report in eQUEST with global horizontal radiation and an on/off flag for the photosensor, I think you'll see that it's simply on and off with this value.  According to the spreadsheet attachment, this misses approximately 163 hours of operation in Memphis, which you may or may not consider significant.</div>
<div><br></div><div>Interestingly, the product that was chosen for the final design included a photosensor/motion sensor combination.  The lights were to remain off for all hours unless it was night time and motion was detected.  The lights will remain on for 15 min after motion is detected.  Now, tell me how you would model this with hundreds of lights across a campus?  I thought about using a probability distribution to model motion detection at different areas and finally decided that the eQUEST PHOTOCELL-CTRL is good enough!!</div>
<div><br></div><div>Aaron<br clear="all"><div><br></div>-- <br>Sent from my DynaTAC 8000x<br>
<div><br></div><div><div>Hey all!</div><div> </div><div>Something new occurred to me recently triggered by a photocell scheduling question. </div><div> </div><div>To ground and set up this idea – first check out this interesting online visual explaining how annual day/night hours vary based on latitude… play around a bit with the bars to see how daylight hours vary based on latitude and time of year: <a href="http://astro.unl.edu/classaction/animations/coordsmotion/daylighthoursexplorer.html">http://astro.unl.edu/classaction/animations/coordsmotion/daylighthoursexplorer.html</a></div>
<div>Note that regardless of location, the yearly average on a daily basis always works out to 12 hours.</div><div> </div><div>Now take the typical case of a simple ON/OFF photocell control for exterior lighting.  From an exterior lighting control standpoint, the model linked above is simplified from reality in that the effects of cloud cover/weather are not accounted for.   While the sun on a given day may officially set at 6PM, for example, overcast cloud cover, rain, smog, fog and similar conditions may cause a photocell to turn on the exterior lights hours earlier, by reducing the daylight illumination reaching the photocell/ground. </div>
<div> </div><div>Based on some explorations – the current PHOTOCELL-CTRL schedule appears to demonstrate something like a  “simplified” model per the above link, assuming clear skies.  I’m observing approximately 12 hrs of photocell operation per day averaged over the year for different locations’ TMY weather files (slightly less, actually… ~11.95).  I would assume by extension it’s using a function based on the location’s latitude or perhaps referencing something like the “sun up flag” in the weather files.  Does this jive with what anyone knows to be going on under the hood?</div>
<div> </div><div>If my understanding is correct, I would like to suggest a few improvements for present discussion and future development:</div><div>1)      First I think it’s worthwhile to retain the “clear sky” PHOTOCELL-CTRL function as it currently exists – I can conceive applications where a simplified “on when the sun sets” model could be both desirable & useful, such as in comparing output with simple daylight simulation models.  It could also perhaps be more specifically named “ASTRONOMICAL-CTRL” in reference to mechanical/digital astronomical timeclocks which calculate daily on/off times very much like the animated model linked above.</div>
<div>2)      An improved PHOTOCELL-CTRL scheduling function could be defined working around the following:</div><div>a.       It’s my understanding that weather files may contain hourly measured illuminance readings that inherently account for cloud cover and other weather conditions.  </div>
<div>b.      Actual photocell systems will turn on and off at prescribed, sometimes different levels.  For example, here’s a link to a product which turns fixtures on at 3fc and off at 8fc, with a nominal delay to minimize nuisance cycling:  LINK.  The equipment literature I’ve checked cite values from 1fc to 10fc.  </div>
<div>c.       Per the above, an improved PHOTOCELL-CTRL scheduling option could accept inputs for one (possibly two) exterior footcandle levels to define on/off behavior.  Hourly ON/OFF behavior could then be determined directly referencing the exterior hourly horizontal ground illuminance measurement from the weather file used, switching lights when the appropriate threshold is crossed.</div>
<div>d.      Such a scheduling option could more accurately  gauge the full impact of exterior lighting retrofit and controls upgrades.  This is often relatively low-hanging fruit, in my experience.</div><div> </div><div>
A related query for the weather gurus:  I’m uncertain whether TMY weather files, representing averaged data over many years, would be particularly constructive or not for representing the effects of cloud cover and so forth… Growing up in FL, I recall a definite “rain-season” mid-summer which I expect would be captured in the daylight measurements of any FL weather station… but where weather/cloud cover is much less regular (such as here in KS), perhaps the effects would be lost in averaging?</div>
<div> </div><div>Thoughts?</div><div> </div><div>~Nick</div><div> </div><div><br></div><div> </div><div>NICK CATON, P.E.</div><div>SENIOR ENGINEER</div><div> </div><div>Smith & Boucher Engineers</div><div>25501 west valley parkway, suite 200</div>
<div>olathe, ks 66061</div><div>direct 913.344.0036</div><div>fax 913.345.0617</div><div><a href="http://www.smithboucher.com">www.smithboucher.com</a> </div></div></div>