1. Home
  2. Embedded Programming
  3. Sunrise/Sunset Algorithm

Sunrise/Sunset Algorithm

I want to write an algorithm to determine sunset/sunrise from an ambient light sensor. I have a process scheduled to convert the analog value to digital at a specific rate (which needs defining). The values will then be tossed into a FIFO of some length (needs defining as well). The algorithm needs to filter large changes which might come from some other source (headlights of a car, an object temporarily passing in front of the sensor) and catch only the gradual slope (which I assume is non-linear) from the natural sunset/sunrise.

The first thing I need to do is choose a sampling rate and buffer size. I'd like to keep the buffer size around 256 bytes. The AD conversions will consume 2 bytes each (10 bit). Sunrise and sunset are slow processes so I think I should analyze over a 30 minute period. Now, if I just sample once a minute for 30 minutes I am likely to get a few anomalies which will throw the process off. So, I was thnking it might be wise to perform the conversion at say 1Hz and then average/filter 60 of these samples into a single value which is tossed in the 30 minute buffer. This 30 minute buffer is what will be analyzed for sunset/sunrise condition. I was thinking the best approach to this is to continually calculate the slope of the data, then evaluate the slope along with the current value. So, for example (using arbitrary numbers) if the slope is aprox negative 35 and the current light reading is aprox 147, then you could say it's dark enough and the slope resembles that of sunset... so let's call this a sunset.

So, those are my initial thoughts. I am not a DSP guru (and I am sure you can tell that) which is why I am here. I'd like to know...

1) Based on what I described, is this a reasonable approach? If not, how do you recommend I go about it?

2) Is a FIR filter a good approach to applying a low pass to the one minute values?

Thanks!

--------------------------------------- Posted through

formatting link

Reply to
eeboy
Loading thread data ...

[snip]

Use an astronomical relation, your (fixed) lat/lon) and a clock/calendar.

Or, would you design a "Christmas Detector" to monitor for the nocturnal presence of a fat man in a red suit in your fireplace/chimney? :-/

Reply to
D Yuniskis

True, I understand your point and I've read about using astronomical relations to determine sunset/sunrise. I do have a clock/calendar available to me, however, I can't rely on the end user knowing or inputting the lat/lon (in my case).

Furthermore, the time of sunset as calculated by the astronomical relation may not be sufficient. What I mean is that sunset is relative to the device. For example, say sunset as calculated by the astronomical relation was 6:45. However, the true value (as determined by the actual amount of light) is 6:32. So, it's not the time that's important, it's the ambient light available. It becomes an input into the system... if light is greater than X do this, else do this.... type of thing. The value of X is adjustable. The important part here is that I filter out the things I mentioned in my original post and I catch this value, X, only during a natural change in light (sunset/sunrise).

--------------------------------------- Posted through

formatting link

Reply to
eeboy

I've done this with a retic controller, and normally get better than +/- 5 mins accuracy wrt a clock, year round, although there are occasional excursions up to maybe 15 minutes, which the system can recover from by itself. FWIW, here are some details of my algorithm:

Details of sunrise / sunset time off the web for my location are set up as a lookup table. An internal clock is maintained, and the time that the light drops below a trigger point (fixed value) is compared with the expected sunset time in the table. A configurable percentage of the error is set as a bias to the clock. Typically, about 12.5% (div by 8, easy with a small micro) seems about right.

I apply a time delay of 40 minutes to the incoming light signal, ie. it needs to be 'night' for 40 minutes before the system triggers and resets the bias.

The system auto calibrates on initial setup, I tell it the actual time, it then waits for the first trigger and back calculates the bias.That negates errors from eg. the 40 minute delay.

A moving average filter for the light might be the go, but a simple exponential filter (less RAM required) would probably work more or less as well IMHO.

HTH

Reply to
Noodnik

Where do you get that short sunrise and sunset times ?

How do you define sunrise and sunset ?

Close to the equator, the sun will hit the horizon nearly vertically at 15 degrees/hour. Thus, if he period of interest is 30 minutes, then the period would start, when the sun is e.g. 4 degrees above and ends when 3.5 degrees below horizon.

However, at higher latitudes, the sun will hit the horizon at a much smaller angle and hence mich longer twilight times. The algorithm would also have to deal with situations, when the sun does not rise above -3.5 degrees for months or never sets below +4 degrees for months.

Heavy clouds just before sunset that are cleared at sunset will cause quite interesting light curves.

Reply to
Paul Keinanen

Suggest: Sample the light level at regular intervals, and buffer the last (odd) N values.

Order them by intensity (which gets rid of the outliers). Pick the middle one ("median filter"). If value below "dusk threshold", it is night. If value above "dawn threshold" (> "dusk threshold"), it is morning. Rinse/repeat. Profit!

Obviously, this requires a bit of testing/training to determine the thresholds.

--------------------------------------- Posted through

formatting link

Reply to
RCIngham

Be aware that for some applications, aviation in particular, sunrise/sunset times are legally defined and your ad-hock solution would not be acceptable.

You might find this site useful for accuracy testing...

formatting link

Reply to
Jim Stewart

le

n
n

er

I get what you are doing. I have a design where I need to distinguish between two levels of a signal which has an unknown amplitude. I use a variable threshold and toss outliers. So I actually have three thresholds. The only problem I had with this was startup. I have to use a startup mode to allow the thresholds to seek a level without tossing valid samples.

In your case, you likely need to sample fairly quickly (faster than 5 minutes per, maybe 1 minute). This will give you more points for filtering and also allow you to come up with a result a lot sooner, otherwise you might only be able to say that sunset was "30 minutes ago" rather than right now. The other thing in your favor is that you can measure the time and get an idea of when to use the data to update your level average for setting the thresholds and when to use the data to look for a threshold crossing. But it will be tricky to account for all the other variables such as weather which can change quickly.

If you allow the user to provide an input for training the device, it might be able to figure out where it is and then use a table to get a better idea of when to accept sunrise and sunset determinations.

Rick

Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.