Scheduling Relative To Sunrise/Sunset?

[(PeteCresswell)]

Per Ed Cryer:

I can't help but return to the webcam. Get one that doesn't have that
fault; because it is a fault! Cams are pretty cheap these days.

This one was close to a thousand bucks. IP-66 weatherproof,
survivability outdoors in a salt-water environment, POE, a
certain resolution..... Plus the fact that I went in to this
knowing that 640x480 was not going tb adequate - but not knowing
how high a rez we would really need.

In retrospect, it's probably a certain degree of overkill now
that I know that we could (maybe even will *have* to bco
bandwidth limitations) probably use something with lower rez, but
no way something like that is going tb cheap like the $80 640x480
FosCams I've been playing around with at home.

I think the night noise thing is a red herring of my own making.
Nobody cares what the cam is putting out at night, except for the
high-volume videos that wind up clogging the FTP que. That was
fixed in about 10 minutes with a couple of scheduled .BAT files.
The Sunrise/Sunset thing was just a nice-to-have so the process
would not require attention as the seasons change.

Finally, I still would not rule out RCI on my part. Maybe
there's a setting in the cam that would have mitigated the night
noise. There are a *lot* of settings in this thing.... -)

 

[Char Jackson]

Per Ed Cryer:

This one was close to a thousand bucks. IP-66 weatherproof,
survivability outdoors in a salt-water environment, POE, a
certain resolution..... Plus the fact that I went in to this
knowing that 640x480 was not going tb adequate - but not knowing
how high a rez we would really need.

This is a pretty nice outdoor camera for $299:
<http://gopro.com/cameras/hd-hero2-outdoor-edition/>

This feature, "Live Streaming Video and Photos to the Web", is 'coming
soon', so it's apparently not capable at the moment, unfortunately. My
son uses a camera from the GoPro series and loves it.

 

[Paul]

Per Ed Cryer:

This one was close to a thousand bucks. IP-66 weatherproof,
survivability outdoors in a salt-water environment, POE, a
certain resolution..... Plus the fact that I went in to this
knowing that 640x480 was not going tb adequate - but not knowing
how high a rez we would really need.

In retrospect, it's probably a certain degree of overkill now
that I know that we could (maybe even will *have* to bco
bandwidth limitations) probably use something with lower rez, but
no way something like that is going tb cheap like the $80 640x480
FosCams I've been playing around with at home.

I think the night noise thing is a red herring of my own making.
Nobody cares what the cam is putting out at night, except for the
high-volume videos that wind up clogging the FTP que. That was
fixed in about 10 minutes with a couple of scheduled .BAT files.
The Sunrise/Sunset thing was just a nice-to-have so the process
would not require attention as the seasons change.

Finally, I still would not rule out RCI on my part. Maybe
there's a setting in the cam that would have mitigated the night
noise. There are a *lot* of settings in this thing.... -)

At a thousand bucks, it's possible the camera has a "day/night"
IR filter, which can be switched in and out. IR filters are sometimes
"fixed" on color cameras, to improve color balance in daylight.
Surveillance cameras can have that filter set up on a shutter, so
it can be move into or out of the optical path.

When the IR filter is removed, and the user provides a LED based IR
illuminator, it's possible to improve the nighttime noise situation.
With the IR filter removed inside the camera (config setting), the IR illuminator
can light up the scene.

Cameras have a "noise floor", where you see random sparkling pixels under
low light. If the camera captures in a compressed format. the sparkling pixels
resist compression, and the file size (or streaming speed) increases. That
could be what you're seeing. If the camera captured in an uncompressed format,
then there'd be no difference between daytime and nighttime data rate.

Good camera sensors use things like HAD. I don't think Sony will sell their
HAD sensors to companies making web cams, and web cams just don't have the
same qualities as these things do. But even with a technology like this,
you still need illumination to make it work.

http://en.wikipedia.org/wiki/Hole_Accumulation_Diode

IR illuminators come in "light bulb + gel filter" type, or ones
that are based on true IR LEDs. The IR LEDs emit far enough
outside human visual range, that the illuminator would go undetected
by the naked eye. (Perhaps you could "feel" the heat, but not see the
light.) And the IR illuminator would only work well, if the IR filter
is "switched out" on the camera (such as at night).

http://www.supercircuits.com/Infrared-Illuminators/IR25

If I was a B&E specialist, and I drove to your site, I
could "preview" the site with a camcorder, as the IR
illuminator will show up in the camcorder view of the property.
It's just the human eye that can't see them, whereas silicon
sensors would be able to pick it up. And if I could detect
the IR illuminator, then I'd know there was a camera present.

Paul

 

[(PeteCresswell)]

Per Paul:

If I was a B&E specialist, and I drove to your site, I
could "preview" the site with a camcorder, as the IR
illuminator will show up in the camcorder view of the property.
It's just the human eye that can't see them, whereas silicon
sensors would be able to pick it up. And if I could detect
the IR illuminator, then I'd know there was a camera present.

Believe-it-or-not, it was early in the game when I stumbled on to
the realization that I did *not* want IR at night. Not that I
knew anything about the camcorder thing, of course....

But just from the red glow it seemed like it must be pretty
obvious to the passing crackhead that there was an object up
there worth stealing.

It kind of wonders me that the standard IR illumination gives off
that human-visible glow.

 

[Paul]

Per Paul:

Believe-it-or-not, it was early in the game when I stumbled on to
the realization that I did *not* want IR at night. Not that I
knew anything about the camcorder thing, of course....

But just from the red glow it seemed like it must be pretty
obvious to the passing crackhead that there was an object up
there worth stealing.

It kind of wonders me that the standard IR illumination gives off
that human-visible glow.

The illuminator based on a light bulb plus a gel filter, the
passband extends into the visible. This is a function of how
effective the filter is, at removing visible light.

IR LEDs on the other hand, emit at a specific wavelength (but
the spectrum analyser plot is a bump rather than a vertical line).
The center wavelength plus "shoulder" is supposed to be outside
the human visual threshold.

If you had an IR laser diode, then the spectral output of that
would be a sharper line on a spectral plot. LEDs are "sloppy"
on spectrum. (Page 3 here has an example. Central peak at 940nm
and shoulder stops at around 980nm. LED suitable for a TV remote control.
Some visible LEDs I've looked at in the past, had a 200nm wide bump.
So the spectrum on this one, is relatively tight in terms of
numbers of nm.)

http://media.digikey.com/pdf/Data Sheets/Lite-On PDFs/HSDL-4270.pdf

Infrared illuminators use large numbers of LEDs like that. When I did
a quick check, I don't see infrared LEDs available in the high power
LED families used for illumination (1 watt or 5 watt LED). So a company
making an illuminator, may need to use bunches of the small ones. That
particular LED has a max of 100mA current, and you'd want to run it at
somewhat less than that.

One of the problems with LEDs for illumination (i.e. all those LED light
bulb replacements at the store), is cooling. LEDs can't really take
an elevated junction temperature. Which is why the LED light bulbs are
shaped with cooling in mind. And putting the LED lightbulb into a
traditional "enclosure" with no cooling, is bad for it. So when
incandescent bulbs disappear, the replacement technologies are
happier to be out in the open, for cooling reasons. While that LED
in the above datasheet may have a 100mA rating, how close you
can get to applying that current (and having a long life) may
depend on the resulting junction temperature.

So imagine a surveillance application "lit by 1000 TV remote controls",
where you cannot see the light.

In terms of seeing IR with a camcorder, there is another device you
can get. Radioshack used to sell a card with an IR sensitive end on it.
276-1099. (I have one here.) You "charge" the card in visible light,
like from an ordinary lamp. Then, hold items like your TV remote
(using IR LED) next to the "brown end" of the card, then press a button
on the remote. You can see the rate that the command burst on the remote
is repeated by doing that. A "dot" of light sent by the remote, shows up
in the brown area, as a visible glow. This is effectively a kind of
"frequency shifting", and useful for testing remotes without
digging for the camcorder.

http://loisirflip.fr/Pinrepair/www.pinrepair.com/wpc/wpcopto2.jpg

The pricing on these cards is ridiculous, presumably because not many
companies make them. This one is $14.55. The Radio Shack one might have
been $5 or so, and I still considered that to be a rip-off.

http://www.mcmelectronics.com/product/DISTRIBUTED-BY-MCM-72-6771-/72-6771

Paul

 

[DanS]

An alternative to that might be to have software that
senses the state of the photocell and does a clean start
and stop of the camera program.

Luckily, I don't have to say how to do it

I *would* say it's possible. What comes to my mind is
something like this: connect the photocell to an input line
on a microcontroller, and have it communicate over USB to
the computer to trigger the action.

Talk about overkill

Yes....over kill.

On the right track, just not KISS-compliant.....

If the PC has a (RS232) serial port, you could easily connect
the photocell to the CTS input through a resistor divider, or a
pot wired as a resistor divider, and set it for the amount of
light needed to assert CTS. A very small and simple VB program
could be written to start/stop the camera program as necessary.
(There's usually some level of hysteresis on a PC serial port,
but if necessary, a logic chip w/hysteresis could be used as a
buffer.

 

[Char Jackson]

Yes....over kill.

On the right track, just not KISS-compliant.....

If the PC has a (RS232) serial port, you could easily connect
the photocell to the CTS input through a resistor divider, or a
pot wired as a resistor divider, and set it for the amount of
light needed to assert CTS. A very small and simple VB program
could be written to start/stop the camera program as necessary.
(There's usually some level of hysteresis on a PC serial port,
but if necessary, a logic chip w/hysteresis could be used as a
buffer.

Hmm, nice, but I'd still prefer to see a solution that includes a golf
ball dropping on a mouse trap. Extra points for including a series of
toppling dominoes. ;-)

Not dissing your solution, just having fun.

 

[Paul]

Yes....over kill.

On the right track, just not KISS-compliant.....

If the PC has a (RS232) serial port, you could easily connect
the photocell to the CTS input through a resistor divider, or a
pot wired as a resistor divider, and set it for the amount of
light needed to assert CTS. A very small and simple VB program
could be written to start/stop the camera program as necessary.
(There's usually some level of hysteresis on a PC serial port,
but if necessary, a logic chip w/hysteresis could be used as a
buffer.

This is an example of another way to do it. This is a
USB to byte-wide logic input chip, with synchronous and
asynchronous options. Perhaps you could cook up a logic
input with something like this (if the SDK is easy to use).

http://www.ftdichip.com/Products/ICs/FT245R.htm

Using the part number, you can find little development boards
with the chip on it. The "FT245 TinyBoard" being the first
hit in a search engine.

http://www.oxisso.com/Misc/index.html

In previous times, a PCI card with buffers might have been used
to do a similar thing. But now, there are USB devices for home
projects.

Paul

 

[J. P. Gilliver (John)]

(PeteCresswell) wrote: []

It kind of wonders me that the standard IR illumination gives off
that human-visible glow.

The illuminator based on a light bulb plus a gel filter, the
passband extends into the visible. This is a function of how
effective the filter is, at removing visible light.

IR LEDs on the other hand, emit at a specific wavelength (but
the spectrum analyser plot is a bump rather than a vertical line).
The center wavelength plus "shoulder" is supposed to be outside
the human visual threshold.

Well it isn't. Every camera I've played with that claims to have night
vision (and I'm sure does) by using IR LEDs, has ones which make a
perfectly visible red glow; as Pete says, it seems odd that they are.
[]

So imagine a surveillance application "lit by 1000 TV remote controls",
where you cannot see the light.

I'm not sure if remotes use truly non-visible ones, or just sufficiently
low power that you wouldn't anyway: a lot of them also seem to have a
filter (which looks black to us). Though I've just tried my nearest one
(which doesn't have a filter) and I can't see it at all.
[]

 

[DanS]

Hmm, nice, but I'd still prefer to see a solution that
includes a golf ball dropping on a mouse trap. Extra points
for including a series of toppling dominoes. ;-)

Not dissing your solution, just having fun.

I removed the golf ball/mouse trap and dominoes when I saw it
would take 100 times the complexity to mechanically reset all
that stuff each day, twice a day.

 

[(PeteCresswell)]

Per J. P. Gilliver (John):

. Every camera I've played with that claims to have night
vision (and I'm sure does) by using IR LEDs, has ones which make a
perfectly visible red glow; as Pete says, it seems odd that they are.

I've read references to IRs that emit on a different freq that is
not visible to the human eye. In fact, I've got a game camera
that takes still photos whose flash is not visible.

Must be some logical reason why they use the visible freq on most
surveillance cams... but what? Cost? Efficiency?

 

[Philip Herlihy]

I've got an IP camera hooked into a server at a remote location.

The server is FTP-ing a constant series to 20-second video clips
to another location. Each clip is about a meg in size.

So far, so good...

Problem is that the camera goes nuts after dark and the clips
come out to be 10-20 megs - basically of darkness with some
lights on a distant shore.

What I want to do is kill the server around sundown and start it
up after sunrise.

To that end, I'd need something to help scheduler out.

So far, all I can come up with is
http://www.risacher.org/sunwait/

Problem is that, although the developer has compiled it to a
.EXE, it has not been tested - and it seems to have problems
parsing the command line.

So, bottom line: Does anybody know of a way to schedule jobs
relative to sunrise/sunset?

Interesting puzzle. I'd need to know more about the "server" - do you
mean a software process or a lump of electronics? If s/w, is it a
custom development or are you using standard OS facilities (and is this
Windows?). Is the FTP done by a separate process? Is there any time
information in the filenames? Are the files deleted automatically once
sent? Are they sent in batches or one at a time?

I'd have thought it would be relatively straightforward to write a
VB/VBS utility which started a process at a time taken from a table of
day-number/Sunrises and, at a time taken from a table of day-
number/Sunsets, searched for a process name to kill any instances of it
(use WMI for that). You can get tables for your location from several
websites (although I haven't seen a UK one that gives more than a month
at a time).

Alternatively, you may be able to work on the files, so although they
still get created, you suppress the sending of them, or even the
receiving of them.

I wrote Windows 2000 command-line scripts to schedule ntbackup on a
customer's PC (used as a file server) a year or so ago. It runs a
"normal" backup on the first of each month, an Incremental every Friday,
and a Differential on every other day (but not Sundays). It also copies
the backup files created to another machine. A further pair of
scheduled scripts run daily on the second machine: one uses Robocopy to
select files older than x days and move them to a different folder, and
the second script deletes anything in that folder. This keeps the
procedure from filling the disk. NT scripting is hard work, as the
'language' isn't very rich, but the idea of leaving the camera barfing
files but disposing of them according to a table-driven schedule might
be a useful approach.

Depending on the lifecycle of the files, you might create a simple
table-drive VB/S or Powershell utility to schedule itself to run at the
correct times each day to toggle the destination of a junction point or
even the read or write permissions of a folder. Lots of possibilities,
but we'd need to know exactly what the existing setup is.

I've found this webservice which will return an XML file with
sunrise/sunset information:
http://www.earthtools.org/webservices.htm
.... but I think you'd need to get into something like ASP.net to use
that.

HTH

 

[Paul]

Per J. P. Gilliver (John):

I've read references to IRs that emit on a different freq that is
not visible to the human eye. In fact, I've got a game camera
that takes still photos whose flash is not visible.

Must be some logical reason why they use the visible freq on most
surveillance cams... but what? Cost? Efficiency?

Red LEDs are the cheapest you can get, because they're also a
very common color and are mass produced as indicators for
consumer goods.

*******

The silicon based detectors go down into the infrared, unlike
the human eye. But if selecting a color to illuminate with,
you don't want to go too far down. Eventually, the silicon detector
tails off. So for a LED choice, you want the one which is "just invisible"
but not much longer in wavelength. If you could get 940nm, 1300nm, and 1500nm,
and the 940nm ones are used in TV remotes and are invisible to the
naked eye, then that would be a good choice. The quantum efficiency
at the longer wavelengths, might not be as good.

The camera itself may change how it treats the pixels, in daytime
versus nighttime mode. If you use infrared illumination, the color
balance will be all off, and it may be better to treat the camera
sensors as a grayscale device.

Many cameras have a fixed IR filter inside them, as a means to
make sun-illuminated scenes look more natural. The sun has significant
infrared, and the colors wouldn't look right without the filter.
But the presence of such a filter, spoils the opportunity to
use an IR illuminator for nighttime operation (or, you need to
use a much more powerful illuminator, to compensate for the filter
which isn't perfect).

On the other hand, if you buy a monochrome camera, that would not
need an IR filter. With no color balance to worry about, the camera
can be run in day or night, with or without IR illuminator. Scenes
might still not look "natural" with IR illumination, but there
is no color information coming from a monochroms camera, so less
to upset you in terms of appearance.

I have a couple cameras here, but they're composite output and that
immediately limits their usefulness. The monochrome camera I've got,
is almost good enough to see in moonlight, but the image quality is
so poor, it's a "who cares" kinda thing :-( "What is that fuzzy blur
running across my lawn ?" For practical purposes, the webcam I bought
for a fraction of the price, does a better job.

Now, an IP camera is a better option, because it isn't limited
by the composite bandwidth (composite is good for about 640x480 or maybe
a slight bit more). You can have lots more pixels coming from the
IP camera sensor, and find a use for them. If you connected a 1600x1200
array to a composite output signal, at the recording device (VCR) the
output would still be 640x480 quality. If my camera had a "component" output,
then there wouldn't be that limit (but they don't make them that way).
And I'd also need to find a capture device capable of handling
component (like a Blackmagic card?). The IP camera, which does the
analog to digital conversion for you, makes the purchase simpler.

For $1000, you should be getting a camera with day/night mode options.
If all you got was a color camera (with fixed IR filter), then that's
not $1000 worth. Even with a 20x optical zoom, for $1000 you should be
getting a few more features.

In some cases, your average camcorder can put a surveillance camera
to shame. So when shopping for a camera, compare the specs to a camcorder,
to see whether you're getting gouged or not. For example, the noise
floor on my cameras is a lot poorer than a camcorder. To take still
photos, I take two pictures and "average" them in Photoshop or
GIMP. If you average two identical frames, the idea is, it removes
some of the random pixel noise in the image. (And that only works for
still images, as averaging two frames from a motion sequence, gives
a blur.)

Paul

 

[J. P. Gilliver (John)]

Per J. P. Gilliver (John):

I've read references to IRs that emit on a different freq that is
not visible to the human eye. In fact, I've got a game camera
that takes still photos whose flash is not visible.

Must be some logical reason why they use the visible freq on most
surveillance cams... but what? Cost? Efficiency?

Red LEDs are the cheapest you can get, because they're also a
very common color and are mass produced as indicators for
consumer goods.[/QUOTE]

I suspect the ones that provide "night" illumination on most cameras
that have it are not ordinary red ones; they just happen to have _some_
visible output.
[]

The camera itself may change how it treats the pixels, in daytime
versus nighttime mode. If you use infrared illumination, the color
balance will be all off, and it may be better to treat the camera
sensors as a grayscale device.

Most such cameras I've seen switch to a monochrome (greyscale) view when
they turn on the surrounding "IR" LEDs.
[]

In some cases, your average camcorder can put a surveillance camera

[]

 

[Gene E. Bloch]

Hmm, nice, but I'd still prefer to see a solution that includes a golf
ball dropping on a mouse trap. Extra points for including a series of
toppling dominoes. ;-)

Not dissing your solution, just having fun.

Sorry, it won't do.

All acceptable solutions include at least one bowling ball.

 

[Gene E. Bloch]

I'm not sure if remotes use truly non-visible ones, or just sufficiently
low power that you wouldn't anyway: a lot of them also seem to have a
filter (which looks black to us). Though I've just tried my nearest one
(which doesn't have a filter) and I can't see it at all.

One way I test remote controls is to view them with a digital camera
(any kind).

Most digital cameras are sensitive enough in the infrared that you can
see a flash from the remote in the camera's viewfinder. The flash
usually looks white, so I guess all three colors of the detector pick up
some light.

Some astronomical photography buffs and infrared photography buffs
remove the infrared filter (or pay to get it removed) from the cameras
to get better sensitivity than is normal.

 

[Paul]

Sorry, it won't do.

All acceptable solutions include at least one bowling ball.

The last time a bowling ball was involved in something
I was doing, I nearly lost an eardrum

So bowling balls are off my list.

Paul

 

[Gene Wirchenko]

On Thu, 17 May 2012 14:21:23 -0500, Char Jackson wrote:
[snip]

Hmm, nice, but I'd still prefer to see a solution that includes a golf
ball dropping on a mouse trap. Extra points for including a series of
toppling dominoes. ;-)

I think that toppling CD cases is much nicer. The motion and
sound appeal to me.

Sorry, it won't do.

All acceptable solutions include at least one bowling ball.

No way. That would limit Rube Goldberg devices unnecessarily.

Sincerely,

Gene Wirchenko

 

[Bill Blanton]

Interesting puzzle. I'd need to know more about the "server" - do you
mean a software process or a lump of electronics? If s/w, is it a
custom development or are you using standard OS facilities (and is this
Windows?). Is the FTP done by a separate process? Is there any time
information in the filenames? Are the files deleted automatically once
sent? Are they sent in batches or one at a time?

I'd have thought it would be relatively straightforward to write a
VB/VBS utility which started a process at a time taken from a table of
day-number/Sunrises and, at a time taken from a table of day-
number/Sunsets, searched for a process name to kill any instances of it
(use WMI for that). You can get tables for your location from several
websites (although I haven't seen a UK one that gives more than a month
at a time).

Alternatively, you may be able to work on the files, so although they
still get created, you suppress the sending of them, or even the
receiving of them.

I wrote Windows 2000 command-line scripts to schedule ntbackup on a
customer's PC (used as a file server) a year or so ago. It runs a
"normal" backup on the first of each month, an Incremental every Friday,
and a Differential on every other day (but not Sundays). It also copies
the backup files created to another machine. A further pair of
scheduled scripts run daily on the second machine: one uses Robocopy to
select files older than x days and move them to a different folder, and
the second script deletes anything in that folder. This keeps the
procedure from filling the disk. NT scripting is hard work, as the
'language' isn't very rich, but the idea of leaving the camera barfing
files but disposing of them according to a table-driven schedule might
be a useful approach.

Depending on the lifecycle of the files, you might create a simple
table-drive VB/S or Powershell utility to schedule itself to run at the
correct times each day to toggle the destination of a junction point or
even the read or write permissions of a folder. Lots of possibilities,
but we'd need to know exactly what the existing setup is.

I've found this webservice which will return an XML file with
sunrise/sunset information:
http://www.earthtools.org/webservices.htm
... but I think you'd need to get into something like ASP.net to use
that.

along those lines..

Don't know how to implement server side, but using Powershell/.NET he
could download the data from earthtools.org, and then parse the local
xml file to get the sunrise/sunset variables.

#example(Orlando, FL)

$lat=28.5381
$long=-81.3794
$mo=5
$day=20
$offUTC=-5
$DST=1

$url="http://www.earthtools.org/sun/$lat/$long/$day/$mo/$offUTC/$DST"

(New-Object System.Net.WebClient).DownloadFile( $url, "c:\earthtools.xml" )
$earthtools = [xml](get-content "c:\earthtools.xml")

$sunrise = $earthtools.sun.morning.sunrise
$sunset = $earthtools.sun.evening.sunset

write-host "Sunrise: " $sunrise
write-host "Sunset: " $sunset





Or write your own algorithm
http://williams.best.vwh.net/sunrise_sunset_algorithm.htm

 

[Philip Herlihy]

Interesting puzzle. I'd need to know more about the "server" - do you
mean a software process or a lump of electronics? If s/w, is it a
custom development or are you using standard OS facilities (and is this
Windows?). Is the FTP done by a separate process? Is there any time
information in the filenames? Are the files deleted automatically once
sent? Are they sent in batches or one at a time?

I'd have thought it would be relatively straightforward to write a
VB/VBS utility which started a process at a time taken from a table of
day-number/Sunrises and, at a time taken from a table of day-
number/Sunsets, searched for a process name to kill any instances of it
(use WMI for that). You can get tables for your location from several
websites (although I haven't seen a UK one that gives more than a month
at a time).

Alternatively, you may be able to work on the files, so although they
still get created, you suppress the sending of them, or even the
receiving of them.

I wrote Windows 2000 command-line scripts to schedule ntbackup on a
customer's PC (used as a file server) a year or so ago. It runs a
"normal" backup on the first of each month, an Incremental every Friday,
and a Differential on every other day (but not Sundays). It also copies
the backup files created to another machine. A further pair of
scheduled scripts run daily on the second machine: one uses Robocopy to
select files older than x days and move them to a different folder, and
the second script deletes anything in that folder. This keeps the
procedure from filling the disk. NT scripting is hard work, as the
'language' isn't very rich, but the idea of leaving the camera barfing
files but disposing of them according to a table-driven schedule might
be a useful approach.

Depending on the lifecycle of the files, you might create a simple
table-drive VB/S or Powershell utility to schedule itself to run at the
correct times each day to toggle the destination of a junction point or
even the read or write permissions of a folder. Lots of possibilities,
but we'd need to know exactly what the existing setup is.

I've found this webservice which will return an XML file with
sunrise/sunset information:
http://www.earthtools.org/webservices.htm
... but I think you'd need to get into something like ASP.net to use
that.

along those lines..

Don't know how to implement server side, but using Powershell/.NET he
could download the data from earthtools.org, and then parse the local
xml file to get the sunrise/sunset variables.

#example(Orlando, FL)

$lat=28.5381
$long=-81.3794
$mo=5
$day=20
$offUTC=-5
$DST=1

$url="http://www.earthtools.org/sun/$lat/$long/$day/$mo/$offUTC/$DST"

(New-Object System.Net.WebClient).DownloadFile( $url, "c:\earthtools.xml" )
$earthtools = [xml](get-content "c:\earthtools.xml")

$sunrise = $earthtools.sun.morning.sunrise
$sunset = $earthtools.sun.evening.sunset

write-host "Sunrise: " $sunrise
write-host "Sunset: " $sunset





Or write your own algorithm
http://williams.best.vwh.net/sunrise_sunset_algorithm.htm

I've been buying occasional books on Powershell and .net for years.
Your elegant solution makes me think I should try reading a few of them!