Sunrise/set calculation algorithm (cadge!)

[DanielF]

I have a need (for an illumination purpose; nothing to do with weather!) for an program algorithm to calculate the time of sunrise and sunset at my location (within 5-10 minutes is sufficient). I Googled for it and found many sites with different equations, but they mostly required the input of 'local noon' (or 'solar noon') - the local time at which the sun is actually 'overhead', usually not 12noon). So then I went looking for a local noon algorithm, and that was just as confusing!

I know it's not going to be 'easy', but I'm wondering if anyone can steer me to an 'all-in-one' algorithm that (roughly) calculates sunset time per my local clock, based (of course) on my lat and long and time zone. Maybe the one Steve uses in Cumulus (which seems pretty accurate!)?

Any help greatly appreciated!

[DanielF]

It's OK! After much more searching I eventually found SUNRISET.C, which looks like it will do what I want.

Sorry to have bothered you!

[AllyCat]

Hi Daniel,

Yes the "movement" of noon (and of course sunrise/sunset) is called the "Equation Of Time" and amounts to just over +/- 15 minutes through two cycles (not simple sine waves) each year. It's due to the elliptical orbit of the Earth around the Sun so the maths is quite complicated. Most calculations/spreadsheets seem to trace back to some routines published by NOAA.

You haven't said on what platform/language you want to do the calculation, but for only +/- 5 minutes accuracy, interpolating between values from the addition of two lookup tables (for daily SR/SS and EOT) may be the simplest. It is possible to calculate even using integer maths in Basic, however not recommended (I know I've done it, but the code is not "finalised" yet).

Cheers, Alan.

[DanielF]

You haven't said on what platform/language you want to do the calculation, but for only +/- 5 minutes accuracy, interpolating between values from the addition of two lookup tables (for daily SR/SS and EOT) may be the simplest.

Alan,

Thanks for your comments. As you can see, I've already found a solution in the C language. I would have looked at an algorithm in almost any language, but C or assembler are ideal.

Just for your interest, this is going into a touch-screen 'industrial' PC running MS-DOS 6.22, which provides the user interface for my hi-fi controller, and I programmed in C and assembler. The 'real' control is done by a 'Switch-Box' that I designed and programmed, also in C. That box has a 2-line backlit LCD for control info display. I want to dim the LCD backlight according to day/night (also active/idle), which is why I want to calculate sunrise/set times.

The touch-PC will (when I've incorporated SUNRISET.C) send a command to the Switch-Box to tell it whether it's 'day' or 'night', so the LCD backlight can be dimmed accordingly (it's just below my TV, so I don't want it distractingly bright! ).

[beteljuice]

I want to dim the LCD backlight according to day/night (also active/idle), which is why I want to calculate sunrise/set times.

Just because it's sunrise (or midday) doesn't mean it is bright, why not a simple sensor ?

[DanielF]

Just because it's sunrise (or midday) doesn't mean it is bright, why not a simple sensor ?

Good suggestion. And yes, I had previously thought about a sensor (when designing the Switch-Box), but it's not quite 'simple'! If it's going to be better than a simple sunrise/sunset algorithm it would need to be analogue, to provide varying levels of backlight. So would have been extra hardware design and cost.

It's never darker than night in the middle of the day (this is Australia, mate, not gloomy London! ), and the difference overcast weather makes to the twilight/dark transistion is not worth worrying about. As a rule I don't watch TV until after sunset anyway (though it's borderline during daylight saving), so if the display dimming is later than it could be (with a sensor), it's no big deal.