# Simple Calculation of Sunset Time required

• posted

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) + ??? Where: 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

• posted

Perhaps here somewhere?

• posted

I think you can find this on the web. Try the US Naval Observatory Site (just stay away from Cheney's house - he's been known to shoot people). You might try 'astronomical clock' as a search term.

Here's what I use with PureBasic. I use the same basic code with an embedded ZBasic ZX-40a - it uses less space than a lookup table. I think I originally got it from USNO. 'Protected' is the same as 'local' in other languages. Variables declared with .d are double precision floats; those without are

32-bit integers.

DST2 & DST4 are global variables that hold the DST start/end times in hours since 0000 01-01-yyyy.

Procedure GetDawnDusk() ;calculates sunrise/sunset Protected RadiansPerDegree.d,latitude.d,longitude.d,tz.d,zone.d,lo.d,c.d,C2.d,SD.d,CD.d,sc.d,C3.d,yd,n,dawn,dusk OpenPreferences("roZetta.prf"):PreferenceGroup("Global") longitude=ReadPreferenceDouble("longitude",-84.56) latitude=ReadPreferenceDouble("latitude",39.04) tz=ReadPreferenceDouble("tz",-5.00) ClosePreferences() tz=tz*-1 RadiansPerDegree=0.017453293 yd=DayOfYear(Date()) If latitude=>0 If yd>=Val(DST2)/24 And yd=Val(DST4)/24 Or ydGiven a table of sunset times, such as:

snipped-for-privacy@yahoogroups.com

• posted

Ok, first understand the problem. Imagine (because it isn't so, but it helps) that the Earth has no tilt and moves in a perfect circle around the Sun and the Sun itself is a point of light, not a ball 1/2 a degree wide. Sunrise and sunset will be at the same time every day,

6:00 am and 6:00 pm at the equator, earlier and later as you move North or South. When you reach either Pole it will not set at all, but goes around the horizon. The function for this is the cosine of latitude, cos(90 degrees) = 0. Now we tilt the Earth, and we do so in our imagination by 90 degrees. The North pole faces the Sun on mid-summer's day, and the south pole faces the Sun 6 months later. As you know, Northern Summer is Southern Winter and vice versa. With our 90 degree tilt the Sun doesn't rise or set at the equator on mid-summer's day OR mid-winter's day, equal day and night occur mid-spring and mid-autumn.

Okay, so much for latitude and tilt, next is orbital eccentricity. We imagined that the Earth moved in a perfect circle, but it doesn't. It is closest to the Sun on or about Jan 3rd at 91,000,000 miles and furthest 6 months later at 94,000,000 miles, moving in an elliptical orbit. As we did above, we again imagine an extreme case where the Earth passes very close to our point-like Sun and then 6 months later is way out near Pluto. The orbit is almost a straight line. The Earth falls toward the Sun going faster and faster (as comets do) and then swings around the back where gravity is at its greatest, climbs away again and slows as it gets toward Pluto's orbit where it stops climbing and falls once again, just as a ball thrown straight up would do. Now, when far from the Sun the Earth turns once a day, sunset and sunrise are about the same each day, but when close to the sun we have a problem with that. The Earth turns on its axis

360 degrees in what is called a sidereal day (1 sidereal day = 23.9344696 hours) and there are 366, (not 365) sidereal days in a year.
is when the Earth has turned not to face the sun once a day, but to face the other stars. You will notice that the night sky has different stars directly overheard between Summer and Winter. This means that when (in our imagination) the Earth passes very close by the sun, noon, when the sun is overhead, can last for 12 hours. Look at the diagram at
you'll see why. Last and least, the Sun is NOT a point. Now... the computation of Earth's orbit is something you do NOT want to do.
In conclusion, a look-up table is the simplest solution for you.
• posted

What level of accuracy are you looking for ?

• posted

Surely there is a sane and reasonable person around who can appreciate how timekeeping astronomers transfered the Equation of Time corrected natural noon cycle to the average 24 hour cycle and when axial rotation was discovered to be the cause of the daily cycle they exploited the human devised 24 hour cycle are transfered it from 'Average' to 'Constant' without requiring an external reference.

That value you give (sidereal day) requires the noon cycles to be equal in order to create a solar/sidereal fiction using the axial and orbital motions of the Earth -

To think that the work of Huygens and Harrison is in competition with the sidereal junk is apalling,-

I cannot,cannot acount for why this most enjoyable and profound work is set aside for destructive and cartoonlike conceptions that never worked.You can openly promote the sidereal value without the slightest sign of an objection when before all of you is the jewel of Huyegns representing millenia of refinements which go into the correlation between clocks,the daily cycle and terrestrial longitudes.

I never doubted that many people know exactly what went wrong but did not count on the lack of courage to change matters quickly or to intepret correctly the changing enviroment in celestial/terrestrial studies.

• posted

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.

• posted

Ask in alt.solar.photovoltaic. I know there are several people that can point you to their own or website software to do this.

Univ or Oregon website is big into this and has lots of info.

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.

• posted

Store monthly values and interpolate. That's likely to be the fastest and least memory intensive technique.

• posted

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.

15 entries in a look-up table, each entry reused for 12 days. 12 * 15 = 180.

Day 1-12 17:10 13-24 17:25 24- 36 17:40 ...

169-180 20:20
• posted

Here's my ZBasic code which runs in the embedded hardware. It may be easier to follow than the PureBasic code (which runs on a PC under Windows/Linux/Mac) that I posted earlier.

The last 8 lines following 'dusk =' aren't directly related to sunrise/sunset. This is accurate to a minute. The key question is whether your embedded microcontroller can do floating point math.

Finally, I think Sky and Telescope Magazine was where I found the original formula - they have numerous Basic language programs.

'====================================================================Sub NewDay()

Dim m As Byte Dim d As Byte Dim y As Integer Dim n As Integer Dim lo As Single Dim c As Single Dim C2 As Single Dim SD As Single Dim CD As Single Dim sc As Single Dim C3 As Single Dim ds As Single Dim zone As Single Const RadiansPerDegree As Single = 0.017453293 yd = GetDayOfYear(Register.RTCDay) ds = CSng((dstflags/2) And 1) 'DST offset lo = 4.8771 + 0.0172 * (CSng(yd) + 0.5 - longitude / 360.0) c = 0.03342 * Sin(lo + 1.345) C2 = (1.0 / RadiansPerDegree) * (Atn(Tan(lo + c)) - Atn(0.9175 * Tan(lo + c)) - c) SD = 0.3978 * Sin(lo + c) CD = Sqr(1.0 - SD * SD) sc = (SD * Sin(latitude * RadiansPerDegree) + 0.0145) / _ (Cos(latitude * RadiansPerDegree) * CD) 'astronomical sunrise, sunset C3 = (1.0 / RadiansPerDegree) * Atn(sc / Sqr(1.0 - sc * sc)) n = CInt(((6.0 - zone -ds - (longitude + C2 + C3) / 15.0) / 24.0) *

1440.0) dawn = (n\\60)*100 + (n Mod 60) n = CInt(((18.0 - zone -ds - (longitude + C2 - C3) / 15.0) / 24.0) * 1440.0) dusk = (n\\60)*100 + (n Mod 60) Call GetHolidays(0) Call GetTime(hh,mm,ss) Now = C>Has anyone determined the basic functions contained within this

snipped-for-privacy@yahoogroups.com

• posted

In sci.astro message , Sun, 17 Feb 2008 00:13:18, Perihelion posted:

Without checking and purely guessing, I'd be surprised if linear interpolation were good to 5 minutes everywhere. For an improvement by a factor of about 4, use fortnightly values. For a bigger improvement, try quadratic interpolation, or even cubic interpolation.

Alternatively, use a best-fit sine wave (assuming that the machine has a sine instruction), followed by linear interpolation in a monthly table of corrections.

Remember that the amplitude of the sunset time shift depends on latitude.

Remember that the phase of the shift wave varies from year to year by a day or so (Leap Year effect); here that amounts to a couple of minutes at equinoxes.

• posted

Actually, I think linear interpolation should work pretty well--at least up to about 55 or 60 degrees north or south latitude. Close to the Arctic or Antarctic circles it gets a little dicey. You might not want the interpolation endpoints to be evenly spaced, but I think it could be done to within +0/-5 minutes with 10 or 15 values.

I certainly think the tabular approach is better than actual analysis. The original poster's application seems like it's got a lot of leeway in it.

The sine wave fails near the arctic regions, just where interpolation would also fail. I don't know how bad, but I'd trust interpolation with

10 or 15 points more than I'd trust a best sine fit.
• posted

Pretty darn close for most latitudes. The OP can, of course, easily check it with a simple spreadsheet and decide if it's good enough. If not, then just add more points.

And, given the OP's assertion that memory is at a premium, I would still go with linear interpolation. In embedded applications, simplicity is a virtue not to be taken lightly.

And, after all, he's just trying to turn on some night lights. How close do you really need to be for that?

• posted

It's also much easier to incorporate DST and other arbitrary adjustments into a table than it is to model them analytically.

• posted

Well, DST is pretty easy to account for. And I can't think of anything else that matters at the 5-minute level. He's going to be writing a program, presumably; it doesn't have to all fit into some single expression.

• posted

You are just geostationary guys who know no better,running around with the linear calendrical convenience with not the slightest sign that you are aware that anything is wrong,the fact that forcing a cyclical system of 365 days 5 hours 49 minutes into a linear system of 3 years of 365 days and 1 year of 366 days is not and never was astronomy.

It is difficult to imagine so many people go to universities and institutions to day and work on material based on the wrong value for the axial rotation of the Earth,not the the actual value has ever been given but the human devised principles which keep clocks in synch with the axial cycle and terrestrial longitudes at 24 hours/360 degrees is probably as close a value as can be possibly had.That value is just a consequence of a remarkable transfer of average 24 hour day to Constant axial rotation as a principle but not as an observed fact.

I am absolutely intrigued by the ability to ignore the greatest known astronomical timekeeping mistake,the most fundamental correlation is all timekeeping astronomy and men are off by a margin of roughly 3 minutes 56 seconds !.

• posted

Thank you all for your most interesting ideas and analyses.

Of course, interpolation is a good and reasonable choice - perhaps I'll investigate the tradeoffs between program size required to do the interpolation versus data storage requirements.

One thing that has occured to me is that the range of possible sunset times is about 193 minutes. (earliest sunset is 17:00, latest is 20:13 here in Detroit, Michigan, USA). So, if I have the program use 1700 as a 'base' time (or time zero), then all I need is an offset from that time. As the maximum offset is 193, I can contain this offset data in one byte of information. Thus to store the table for the entire use requires only 366 bytes of data - quite minimal. While this does require some storage, it has the advantage of being exact (as exact as the table I've consulted), and can easily be adapted to other tables.

Thanks again! TomCee

• posted

Even at more extreme latitudes, you can get within your five-minute margin by taking the offset, which is bounded by 720 minutes (half a day), and dividing it by 3, saving the result within a single byte (octet for those pedants amongst us).

• posted

Well, that raises the question of whether this is a generic application, which needs to be portable with respect to location, or a one-off implementation. I doubt you want to load custom tables if this thing is going to be used in different places; for that, an analytical solution seems better.

_________________________________________________

Chris L Peterson Cloudbait Observatory