Simple Calculation of Sunset Time required

"Chris L Peterson" wrote in message
...
| On Thu, 21 Feb 2008 05:50:32 -0500, "Robert Green"
| wrote:
|
| When I hear hoofbeats, I tend to think horses rather than zebras. I
doubt
| anyone "into" home automation couldn't string two wires from their
| controller to an outside window or location.
|
| First of all, I have no idea if this is a home automation project. The
| OP may be a consultant, setting up a commercial control system.

Second of all, he may be a clod like you.

On Feb 21, 11:42*am, (Paul Schlyter) wrote:
In article ,

Steve Willner wrote:
In article ,
Chris L Peterson writes:
IMO leap anythings are silly. UT should just be the standard, and it
should drift completely free of astronomical time, with no correction
applied (but a correction factor known, of course).

If that's what you want, what's wrong with TAI?

It's different from TT ...... :-)


All these fine gentlemen here and all completely detached from the
flawed reasoning which assigns an incorrect value for axial
rotation,not a tiny value but in the region of 3 minutes 56 seconds.So
much for precision timekeeping !!.

Don't forget the other uncivilised precepts such as detaching the
second from the 24 hour cycle via determining that the return of a
star to a meridian constitutes constant axial rotation with a value
of 23 hours 56 minutes 04 seconds -

http://upload.wikimedia.org/wikipedi...3%A9reo.en.png

I would have found it difficult to believe with the treatise of
Huygens before men along with the known history of the development of
an accurate clock by Harrison to match the principles would have
stirred men to rectify an appaling situation where these blizzard of
acronyms relating to cycles is based on very poor reasoning.Looking at
the fictional relationship created between the solar/sidereal day
using the motions of the Earth it is difficult to imagine what kind of
person could affirm it notwithstanding that all the major institutions
on the planet follow the reasoning of Flamsteed who created it.

The noon cycle is not 24 hours,the Earth does not rotate through 360
degrees in 23 hours 56 minutes 04 seconds or fractions .Maybe there
are no longer people who value the stability of the original system
but one thing is for certain at the end of this thread, in my
astronomical heritage,they never,ever toed axial rotation to an
external reference,they simply applied the Equation of Time principles
which create the 24 hour day and applied it to axial rotation as a
'constant'.They could not do otherwise because it all hinges on a bais
observed fact -

"...the Earth passeth the 12. Signes, or makes an entire revolution in
the Ecliptick in 365 days, 5 hours 49 min. or there about, and that
those days, reckon'd from noon to noon, are of different lenghts; as
is known to all that are vers'd in Astronomy"

http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html

I cannot tell you enough,what you people are doing is not wrong,it is
dangerous .To allow timekeeping astronomy to dictate structural
astronomy is destroying the ability to move ahead in multiple
directions,in climate,in geology,in astronomy proper and even to make
the nessecary changes to clocks for modern applications.For whatever
reasons, you would rather see astronomy rot than take the required
steps to recover a heritage that is almost lost to humanity and in the
hands of people who have no feel for it.












--
Steve Willner * * * * * *Phone 617-495-7123 * *
Cambridge, MA 02138 USA * * * * * * * *
(Please email your reply if you want to be sure I see it; include a
valid Reply-To address to receive an acknowledgement. *Commercial
email may be sent to your ISP.)

--
----------------------------------------------------------------
Paul Schlyter, *Grev Turegatan 40, *SE-114 38 Stockholm, *SWEDEN
e-mail: *pausch at stjarnhimlen dot se
WWW: * *http://stjarnhimlen.se/

Fascintating as this has been, can you take this conversation OUT of the
c.h.a newgroup please?

"J Miller" reply@here wrote in message
...
Here's the logic - it was actually an TI SR 56:

/* The calculations are approximate and were based on an */
/* algorithm published in "Texas Instruments programmable */
/* slide rule calculator (SR-56) Applications Library" */
/* */
/* GMT = 12 - et + (longitude + x * ACOS TAN d8 TAN latitude)/15 */
/* */
/* latitude = latitude (N=+ S=-) */
/* longitude = longitude (W=+ E=-) */
/* x = -1 for Sunrise, 1 for sunset */
/* et = equation of time = */
/* 0.123 * COS (t+87) - 1/6 SIN ((t+10)/0.5) */
/* d8 = sun declination = */
/* 23.5 * COS (T+10) */
/* t = time = */
/* 0.988*(d + 30.3 * ( m - 1)) */
/* d = day of the month */
/* m = month of the year */
/* */
/* -------------------------------------------------------------- */

The code itself was written for an old 16 bit windows compiler so it's
unusable today.. It also doesn't use Julian date, and make the caller
adjust for DST. It ran on DOS 3.x.

I do have C code (gcc and VC6.x) which is maybe 30 lines long that is
accurate within about a minute a day, but it's copyrighted. You won't
understand it anyway!

Why are you being such a jerk? Seems you just top posted yourself! Maybe
you don't like this discussion 'cause your head is where the sun don't
shine!



Androcles wrote:
So you can't do it and are just mouthing off trying to appear smart
when you are really just another top-posting ****head with a big mouth.
**** off, you are useless.


"J Miller" reply@here wrote in message
...
| Your requirements are different than the original poster's.. His was
| with 5 minutes.
| Quite simple math really, as the first place I saw this
| routine was for the TI SR51 programmable calculator 30 years ago!

|
| Androcles wrote:
| "J Miller" reply@here wrote in message
| ...
| | One thing that kind of surprises me about this entire thread is
that
| | only sunset is considered!
| |
| | Seems the OP wanted to use it for a Home Automation solution, and
it
| | seems to me that sunrise may also be needed! (The OP might not see
it
| | now, but it does come in handy!)
| |
| | Something as simple as "turn porch light on at sunset, off at
sunrise".
| |
| | Therefore the table based solutions may actually require double the
| | table space being discussed...
| |
| | One other thing I didn't see (may have missed it) is if the
platform/OS
| | "knows" about DST setting, and sets it's internal clock correctly
| | (window/linux come to mind). If that's the case, the table will
need
to
| | vary each year, as the change doesn't occur on a specific J date,
but
on
| | one of 7 or so.
| |
| | Again, for a HA solution, I'd assume this is the case - again,
something
| | as simple as "turn on coffee maker at 6am" would be tied to "clock
time"
| | and should know about DST.
| |
| | Of course, if the OP was in AZ, DST wouldn't be an issue! (now if
only
| | the rest of the US would take this "logical" approach! )
| |
| | For HA, I would go with an math based solution vs table. You
really
| | only need three things (4 if you do DST) - Lat, long, Jdate, DST
mode,
| | and the resulting compiled code could be smaller than the table,
and
| | more accurate!
|
| Go on then, prove it. I'm close to London and unlike the OP,
| I want one second accuracy for both sunrise and sunset.
| This year is a leap year, I want that included. Show me your math.
|
|
|
|
|

"tomcee" wrote in message
...
Given a table of sunset times, such as:

Day # Sunset (H:M):
--------- ----------
1 17:10
2 17:11
. . .
180 20:21
...
365 17:10

and plotting this data (of course converting H:M to Decimal hours), we
get a somewhat sinusoidal relationship between the Day and time of
Sunset: Sunset = f(Day); or more specifically: Sunset = f(A*sin(k*D-
P) This of course is not a pure sinusoid. Observation shows that it
has a significant 2nd harmonic component.

My application is that I have an automation controller that has a
calendar, can do calculations (including trig), but is rather memory
limited. Thus I would like to calculate time of sunset 'on the fly'
rather than store the data table.

I would like an equation that yields Sunset as a function of day
number. I would like to keep it simpler than the generic formula
given latitude and longitude. I would like the formula from the
tabular data.

It appears to have the form:

Sunset = K + A1*sin(k*D-P1) + A2*sin(2*k*D-P2) + ???
Whe
D = Day number
K, A1, A2, k, P1, P2 are constants determined by Long/Lat.

Has anyone determined the basic functions contained within this
'Sunset function'? Given the basic functions, I can then calculate the
constants.
Thanks in advance for your help,
TomCee

Do you really need to know the time of Sunset or do you just need to do
something when the Sun sets?
If it's the latter, just use a photocell.
Just my $0.02

In article ,
tomcee writes:
OG:
Thanks for asking; I had intended to mention this in my original
post. I would like accuracy to within 5 minutes; preferably biased
towards the negative so that if anything, the lights would turn on
early, rather than late.
Thanks in advance for your help,

If it's for lighting, use a photocell switch.
That will compensate for cloud/clear skies, etc.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

If it's for lighting, use a photocell switch.
That will compensate for cloud/clear skies, etc.

Which is USELESS if the machine in question doesn't have access to the sky,
or wiring through a facility to get one connected.

Likewise useless if the software wants to introduce something like a
randomizer that adjusts the time before full sun rise/set. As in, turn the
lights on X random minutes before expected sunset, and vice versa off after
sun rise. Using a photocell would require tracking the last detected time
(and presumably storing it). A simple device might have calcuation
abilities, but little or no storage.

"Bill Kearney" wrote in message
t...
| If it's for lighting, use a photocell switch.
| That will compensate for cloud/clear skies, etc.
|
| Which is USELESS if the machine in question doesn't have access to the
sky,
| or wiring through a facility to get one connected.
|
| Likewise useless if the software wants to introduce something like a
| randomizer that adjusts the time before full sun rise/set. As in, turn
the
| lights on X random minutes before expected sunset, and vice versa off
after
| sun rise. Using a photocell would require tracking the last detected time
| (and presumably storing it). A simple device might have calcuation
| abilities, but little or no storage.
|
The guy wants to operate his lights to within 5 minutes
of sunset, doesn't have 100 frigging bytes of RAM to store
a table yet supposedly has a programmable calculator. Street lights
have worked on solar time switches since before computers.
http://tinyurl.com/2p36jg
You lot are full of ****in' ****.

On Feb 23, 6:57*pm, "Bill Kearney" wrote:
If it's for lighting, use a photocell switch.
That will compensate for cloud/clear skies, etc.

Which is USELESS if the machine in question doesn't have access to the sky,
or wiring through a facility to get one connected.

Likewise useless if the software wants to introduce something like a
randomizer that adjusts the time before full sun rise/set. *As in, turn the
lights on X random minutes before expected sunset, and vice versa off after
sun rise. *

And this,my good man,is why the topic brought in so many people
insofar as the problem may look simple but the resolution is far from
being so .The Earth does not suddenly develop a 366 day orbit every
4th year and although you may believe that software has the priority
in determining the geostationary terms of sunrise/sunset or the
heliocentric view of axial and orbital motions of the Earth,the fact
of the matter is that software will highlight that timekeeping
astronomy is not in line with structural astronomy in a serious
way,specifically with a calendrical twist.

Had anyone paid attention to what Huygens wrote,they would have
received the outlines of an answer -

"Here take notice, that the Sun or the Earth passeth the 12. Signes,
or makes an entire revolution in the Ecliptick in 365 days, 5 hours 49
min. or there about, and that those days, reckon'd from noon to noon,
are of different lenghts; as is known to all that are vers'd in
Astronomy."

AND

"In the morning then, when the Sun is just half above the Horizon,
note, what hour, min. and sec. the Watch points at, if it be going; if
not, set it a going, and put the Indexes, at what hour, min. and sec.
you please. Let them goe till Sun-set, and when the Body of the Sun is
just half under the Horizon, see, what hour, min. and sec. the Indexes
of the Watch point at......,"

http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html

The orbital motion of the Earth is referenced off a system of 365 days
5 hours 49 minutes whereas the people who have to adjust their softwae
for a leap year ( in determining sunrise/sunset) are working off a
system of 3 years of 365 days and 1 year of 366 days.Huygens
references axial rotation within the orbital period of 365 days 5
hours... therefore you can actually create a software program that
recognises the geostationary terms of sunrise/sunset and its
heliocentric equivalent of axial and orbital motions using the
central Sun and only the Sun as a eference (not the stellar
background)

I do not find fault with anyone for staying away from this particular
astronomical Gordian knot but the resolution is pretty much the same -
split timekeeping astronomy from structural astronomy and do not
allow the former to dictate the latter.














Using a photocell would require tracking the last detected time
(and presumably storing it). *A simple device might have calcuation
abilities, but little or no storage.

"Chris L Peterson" wrote in message
...
On Thu, 21 Feb 2008 05:50:32 -0500, "Robert Green"
wrote:

When I hear hoofbeats, I tend to think horses rather than zebras. I
doubt anyone "into" home automation couldn't string two wires from
their controller to an outside window or location.

(I came back to this thread because I woke up today to find a significant
number of clock-enabled devices to be reporting the wrong time because of
DST. That issue alone highlights the significant benefit of the photocell
method, especially if the goal is simply to turn the lights on when dark and
off when there's daylight.)


First of all, I have no idea if this is a home automation project.

Well, one important clue to consider would be the cross-posting to a *home
automation* newsgroup. (-:

The OP may be a consultant, setting up a commercial control system.

He may also be the town crier, a dawn/dusk researcher, a Druid, the clock
setter for his local church or a zebra. (-: Even if this *is* a commercial
application, the photocell would work just as well. For example, many
streetlights have operated for years and years with nothing but a photocell
controller. They're used in such applications because they are incredibly
simple (and therefore incredibly reliable), they are immune to DST law
changes and can provide light in unexpectedly dark conditions, such as a
severe thunderstorm.

When your goal is providing light only when it's dark, isn't it better to
know when it IS dark rather than what time it is?

With photocells properly pointed skyward as they are on streetlights, they
don't experience false activations from passing cars, although a hovering
helicopter with a "nightsun" searchlight might set them off. But that would
be another of those pesky zebras - a possibility so remote it requires only
passing acknowledgement, even in a thorough systems analysis.

And as located, it is perfectly possible that accessing an outside sensor
could be a problem (I can tell you from personal experience that getting
wires run from inside a building to outside can be a huge problem with
facilities managers).

Now we've moved from zebras to unicorns, an even less likely source of
hoofbeats. To rule out the photocell solution, you have to add some severe
additional caveats that are indeed possible, but just aren't likely given
what we already know. First, you have to assume that this a commercial
application. Then you have to posit a cranky facilities manager and a
windowless environment. Possible? Of course. So is a direct asteroid hit
on his house. The question still is: are those hoofbeats we're hearing
horses, zebras or unicorns?

We have the OP's introductory remarks about the severe memory limitations of
the controller. That doesn't sound like an industrial controller to me, but
yes, it's possible those hoofbeats are zebras. The "can't run a wire to the
outside" is another special case scenario because for it to be a real
concern requires the OP to live in a dark, cavernous building. More
importantly it requires believing that running a two conductor cable to a
place that receives natural light to be a Herculean task, not one that
telecom and CATV jockeys with one month's experience do every day in homes
across the world. Another zebra, if you will. I'm afraid it's not very
likely given what we know about the world in general or this particular OP.

Besides that, many industrial controllers do not have analog inputs on
them at all, which means adding external circuitry or buying an expensive
industrial module in order to detect the actual light levels.

Most of your reservations thus far are predicated on the unlikely assumption
that this is a commercial operation (the zebra). Once you've got one zebra,
it's quite easy to build a corral and turn it into a herd. One unlikely
constraint path can lead to a host of limitations that seem valid, but have
little to do with the actual system requirements or operational environment.
If you've already convinced yourself "an expensive industrial module" is
needed for your industrial control system it means the zebras are breeding.

Even if this were a commercial application, there are any number of ways to
very inexpensively detect dawn and dusk and generate a contact closure that
wouldn't require an analog controller input. It would be a "no brainer" for
the home automation controllers I am most familiar with: HomeVision, the
Ocelot, and the X-10 CM15A. It might be a little harder with others. Since
we know without question the OP's controller memory is severely limited, the
photocell solution preserves that precious memory for other uses and
operations that can't be performed as elegantly as a photocell.

So like I said: too little information to recommend a photocell as the
"best" solution.

Only if you're adding in zebraic assumptions that drastically change the
original nature of the beast. It seems that we're now automating a
commercial establishment (with a tyrannical facilities manager who harbors
profound anti-wire sentiments) when the OP, who gave us some pretty detailed
constraints, never said a word about those possibilities.

Actually, we do have one very good piece of information he the OP is
looking for a mathematical solution to the problem.

We actually have many more pieces than that (see OP's quote below). But for
argument's sake, even if "the mathematical solution" were the only piece of
good information we have, does that mean that the photocell idea was
previously reviewed and discarded by the OP? Of course not. Ironically,
it's on THAT issue that we have too little information. It could just as
easily be that the OP didn't think of photocells. He might simply have
failed to consider implementation issues (the very dark and rainy sunrises
and sunsets mentioned by JR Stockton) that formula-based solutions simply
can't deal with.

I say this based on the number of times I've come to Usenet with Solution X
in mind only to find out that there were better, far easier solutions Y and
Z to be had. I recall going to a tool group and asking how to sharpen a
spade bit I was using to drill through joists only to learn that I should be
using a Forstner bit. Just today I learned that there's a NEW kind of spade
bit with cutting ears that cuts as well as a Forstner bit but is quite a bit
cheaper. That sort of stuff happens to everyone, all the time. Having one
solution in mind doesn't mean that all the bases have been covered
thoroughly. Often, it means precisely the opposite.

If I were creating a requirements document out of what we already know, I
would consider the approach the OP/client has initially chosen as a solution
far less important than the problem he wants to solve within the constraints
he's outlined. I'd also consider his memory limitations and look for the
most memory-efficient solution. That's another mark in the plus column for
a photocell. It takes very little code to implement. No code, no testing.
No code, no updating required if DST changes. Automation controllers need
reliability, not complex code subject to bugs, typos, programming errors,
controller reset issues, synchronization issues, law changes, etc.

I prefer to assume that he knows the most about his own application, and
has already decided that a calculated sunset time suits his requirements
best.

That's an interesting assumption, but that's all it is, and I'll explain
why. Since he hasn't commented or mentioned the photocell in any posts or
replies, it's equally valid to assume that he may not have thought about
using a photocell. It took a rather long time in this discussion before
either Mr. Stockton or I realized it might be a good idea. I prefer to
think that the OP might have done the same and simply overlooked the
photocell solution since he already had a solution in mind. That's the
infamous "go to a carpenter, get a hammer diagnosis" problem of having a
solution in mind locking out other, possibly superior solutions. Since
we're injecting our preferences into the requirements analysis, I prefer to
think he might not been aware of the many benefits of the photocell
approach.

Plenty of smart people get wrapped around the axle trying to figure out a
complex solution when a much simpler one will do. Legend has it that Ben
Franklin cut two small doors in his house to allow his two cats, one large,
one small, to enter and exit at will. When he saw both cats using the large
door, he realized his error. Examine TomCee's own words closely against the
assumptions you've made and perhaps you'll see why I think the issues raised
about commercial operations or inability to reach natural light with a pair
of wires are zebras.

My application is that I have an automation controller that has a
calendar, can do calculations (including trig), but is rather memory
limited. Thus I would like to calculate time of sunset 'on the fly' rather
than store the data table. . . . I would like accuracy to within 5
minutes; preferably biased towards the negative so that if anything, the
lights would turn on early, rather than late.

Home automation group posting, memory limits, turning lights out, preferring
lights to turn on early. These are the hoofbeats of horses, not zebras!
(-: If you want to control electric lights to be on when it's dark and off
when it's daylight, it makes lots more sense to detect actual dark and
daylight and not compute dates.

--
Bobby G.

"Robert Green" wrote in message
...

I can see what you mean but the OP did ask for a computational solution for
a problem.
..
If I were addressing this professionally I'd write a list of requirements,
constraints and assumptions.

Amongst the requirements would be 'to compute the time of sunset'.

Amongst the constraints would be 'limitation on memory'.

I would NOT include amongst the assumptions 'the problem can be solved by a
light sensor'

I may ask for clarification of the 'requirements', but if the client states
that a computational solution is needed I would not 'assume' that (s)he is
mistaken in her/his requirements.