Scheduling Relative To Sunrise/Sunset?

[(PeteCresswell)]

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?

 

[Ed Cryer]

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?

It looks as if that sunwait.exe has been abandoned for some time. But it
should be easy enough to test: download it, get your local
longitude/latitude co-ordinates, set it up and load, interface an event
with it, pick that up in task scheduler.

Until it's fully approved I'd set up my own weekly task manually from
the mid-week time obtained from this website;
http://www.timeanddate.com/astronomy/

Good luck,

Ed

 

[(PeteCresswell)]

Per Ed Cryer:

It looks as if that sunwait.exe has been abandoned for some time. But it
should be easy enough to test: download it, get your local
longitude/latitude co-ordinates, set it up and load, interface an event
with it, pick that up in task scheduler.

Been there, done that. THe Windows executable seems to have a
problem parsing the command line. Linux probably works bc
that's what the developer uses it on.

But it's such an obviously-useful function that I was hoping
somebody else had duplicated it under Windows.

 

[Dave-UK]

Per Ed Cryer:

Been there, done that. THe Windows executable seems to have a
problem parsing the command line. Linux probably works bc
that's what the developer uses it on.

But it's such an obviously-useful function that I was hoping
somebody else had duplicated it under Windows.

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

 

[(PeteCresswell)]

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!

 

[Nil]

Until it's fully approved I'd set up my own weekly task manually
from the mid-week time obtained from this website;
http://www.timeanddate.com/astronomy/

That's what I'd probably do, to. And if this was going to be a long-
term thing, I might try writing a batch file or script to create the
tasks via the command line. That might be easier than creating, say 104
separate tasks with the Task Scheduler GUI.

http://msdn.microsoft.com/en-us/library/bb736357(v=vs.85).aspx

 

[Gene E. Bloch]

Per Dave-UK:

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

 

[richard]

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?

Just thought of a solution.
Get one of those light controllers that turn the ligths on at dusk and off
at dawn.
Setup a relay so that the camera stops working at dusk and turns on at
dawn.
Light on = camera off.
Light off = camera on.

 

[Peter Jason]

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?

Just schedule in the sunset/sunrise times on a
weekly basis for your latitude. There are only 52
of them.

 

[richard]

Just schedule in the sunset/sunrise times on a
weekly basis for your latitude. There are only 52
of them.

Accroding to Obama, that would be 60. Or maybe 63?

 

[(PeteCresswell)]

Per Gene E. Bloch:

Talk about overkill

For now, I'm arbitrarily killing the camera server at 20:30 and
re-starting it at 05:30.

The reason for killing it before dark is that the camera goes
nuts on the bits per frame and the size of the 20-second clips
that are being FTP'd to another computer jumps from 1-1.5 megs to
10-20 megs creating major gridlock over night.

So the exact time isn't all that big an issue - just a
nice-to-have from the perspective of not having to change
anything as the seasons pass.

SunWait is written in C. I think I'll get the source code and
see if there is any hope of my understanding it for a rewrite in
VB6.

 

[Char Jackson]

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

Let's Rube Goldberg it!

 

[Gene E. Bloch]

Per Gene E. Bloch:

For now, I'm arbitrarily killing the camera server at 20:30 and
re-starting it at 05:30.

The reason for killing it before dark is that the camera goes
nuts on the bits per frame and the size of the 20-second clips
that are being FTP'd to another computer jumps from 1-1.5 megs to
10-20 megs creating major gridlock over night.

So the exact time isn't all that big an issue - just a
nice-to-have from the perspective of not having to change
anything as the seasons pass.

SunWait is written in C. I think I'll get the source code and
see if there is any hope of my understanding it for a rewrite in
VB6.

I hope you realize that my overkill comment was about my own suggested
solution.

I did understand the problem - you described it clearly in your OP - and
so far I like the idea about just obtaining an ephemeris online and
setting up schedules on a weekly basis. Except a series of schedules
like that can't be very easy to accomplish :-(

If it's true that the sunwait program is not robust in Windows, maybe
it's possible to get the source and rejigger it in Java, if you don't
have a C compiler.

Or how about this: make a table of sunrise/sunset times on a weekly
basis, then run a scheduled program at midnight. Have it pick up the
current sunrise, then sleep until that time, then start the camera.

Do the same with a second program for sunset, except stop the camera.

Since sleep uses seconds or milliseconds, the table would have its times
expressed in those units.

Or, for sanity's sake, just ignore what I wrote above

 

[Ed Cryer]

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?

I've been hit by a wise thought while pondering on this matter. It is
this. A problem has arisen, and we're all racking our brains for a
solution, but we're drifting from the actual cause of the problem into
its symptoms and offering solutions for those.

Now then, the cause is quote "the camera goes nuts after dark.......".
Solve that and the problem goes away.
Is that the norm for this make? Can it be cured? Why does it take more
space to deal with a dark world? Flash?
My own digital cameras use less space when I take a snap in the dark.

Ed

 

[(PeteCresswell)]

Per Ed Cryer:

Is that the norm for this make? Can it be cured? Why does it take more
space to deal with a dark world? Flash?
My own digital cameras use less space when I take a snap in the dark.

Can't speak to "norm", but another Sony reported a similar
experience. He called it "Pixel Noise", as in "I have a few
Sony cams that at night will generate a ton of pixel noise..."

viz: http://www.cam-it.org/index.php?topic=2702.0

 

[Ed Cryer]

Per Ed Cryer:

Can't speak to "norm", but another Sony reported a similar
experience. He called it "Pixel Noise", as in "I have a few
Sony cams that at night will generate a ton of pixel noise..."

viz: http://www.cam-it.org/index.php?topic=2702.0

Yes, and I see the test results you got from sunwait.exe.

You've got a camera that generates a ton of pixel noise; a possible
solution that requires a program to predict sunrise/set which doesn't
work; a workaround whereby you input your timings manually each week.

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.

Ed

 

[Gene E. Bloch]

If it's true that the sunwait program is not robust in Windows, maybe
it's possible to get the source and rejigger it in Java, if you don't
have a C compiler.

Here are some other programs that I found in Google.

http://unix.stackexchange.com/quest...other-astronomical-data-from-the-command-line
http://sidstation.loudet.org/suntimes-en.xhtml
http://sidstation.loudet.org/sunazimuth-en.xhtml
http://unix.stackexchange.com/quest...other-astronomical-data-from-the-command-line
http://stenarson.com/projects/suncron/
http://ptaff.ca/crepyscule/api/public/crepyscule-module.html

Several are for *nix; the first two are for Windows and seem to be the
same thing with different names (or vames

I tried the first one. It works, but its use and output are, IMO,
clumsy. Also, the results are in UTC, so you'd have to convert the times
(or use a fake longitude), if you could even extract them from the
output...

Given the large number of hits I saw for *nix, maybe you should consider
using a server running some flavor of that.

Now I'll go away before you get annoyed at all this stuff I keep
throwing at you

 

[Gene E. Bloch]

Let's Rube Goldberg it!

Great idea! Although I think I got pretty close already.

 

[Gene E. Bloch]

I've been hit by a wise thought while pondering on this matter. It is
this. A problem has arisen, and we're all racking our brains for a
solution, but we're drifting from the actual cause of the problem into
its symptoms and offering solutions for those.

Now then, the cause is quote "the camera goes nuts after dark.......".
Solve that and the problem goes away.
Is that the norm for this make? Can it be cured? Why does it take more
space to deal with a dark world? Flash?
My own digital cameras use less space when I take a snap in the dark.

Ed

In addition to what (PeteCresswell) said, consider that a dark and noisy
signal is very random, so it won't compress well (no pun is intended on
your name, Pete).

That said, I thoroughly agree with what you said. To me, the best
solution would be a camera that stops sending data when there isn't any
useful stuff, or a camera that can be turned on & off by a photocell
without disturbing the link-up. Or maybe some infrared lamps that are
turned on when its dark, and provide enough light to solve the noise
problem.

Geez - I just promised Pete that I'd go away, and here I am again. Bad
boy...

 

[J. P. Gilliver (John)]

In message <[email protected]>, Gene E. Bloch

In addition to what (PeteCresswell) said, consider that a dark and noisy
signal is very random, so it won't compress well (no pun is intended on
your name, Pete).

That said, I thoroughly agree with what you said. To me, the best
solution would be a camera that stops sending data when there isn't any
useful stuff, or a camera that can be turned on & off by a photocell
without disturbing the link-up. Or maybe some infrared lamps that are
turned on when its dark, and provide enough light to solve the noise
problem.

[]
Or just turn off the camera's AGC - if it _can_ be turned off. I would
be surprised if it _actually_ produces any more noise in the dark - it's
just that the gain gets turned up. (Though these days I suspect the AGC
is built in, and may not be disable-able.)