Scheduling Relative To Sunrise/Sunset?

In article , lid
says...

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


--

Phil, London

(PeteCresswell) wrote:
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?

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

In message , Paul
writes:
(PeteCresswell) wrote:
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?

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.

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
[]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

Sarcasm: Barbed ire

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

On Thu, 17 May 2012 13:43:22 -0500, DanS
wrote:

"Gene E. Bloch" wrote in
:

On Tue, 15 May 2012 13:26:00 -0400, (PeteCresswell) wrote:

Per Dave-UK:

Could you not switch the camera on/off with a
light-sensitive switch ?

Sounds like a good fallback position - assuming the server
handles the camera's going offline/online gracefully.

It's powered via POE, so it would just be a matter of
turning the POE switch off/on.

Thanks!

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.

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 (Stumbling Bloch)

On Thu, 17 May 2012 20:58:42 +0100, J. P. Gilliver (John) wrote:

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.

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.

--
Gene E. Bloch (Stumbling Bloch)

Gene E. Bloch wrote:

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.


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

On Thu, 17 May 2012 20:01:47 -0700, "Gene E. Bloch"
wrote:

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.

Not dissing your solution, just having fun.

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

On 5/17/2012 17:54, Philip Herlihy wrote:
In , lid
says...

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.


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..._algorithm.htm

In article om,
says...

On 5/17/2012 17:54, Philip Herlihy wrote:
In , lid
says...

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.


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..._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!

--

Phil, London

Evan Platt wrote in
:

On Tue, 22 May 2012 08:59:50 -0500, DanS
wrote:

No cite on this?

I couldn't find one.

And you won't.

I didn't think so.

'richard' is an ignorant troll.....

.......and has a tendency to just repeat things he's heard
because it fits some his twisted/warped opinion, no matter how
far-fetched and ridiculous, whatever it is, is?


(Note: I support no political parties, but do have a belief in
accuracy of information, no matter who/what/where/when.)