Simple Calculation of Sunset Time required
tomcee
Day # Sunset (H:M):
--------- ----------
1 17:10
2 17:11
. . .
180 20:21
...
365 17:10
and plotting this data (of course converting H:M to Decimal hours), we
get a somewhat sinusoidal relationship between the Day and time of
Sunset: Sunset = f(Day); or more specifically: Sunset = f(A*sin(k*D-
P) This of course is not a pure sinusoid. Observation shows that it
has a significant 2nd harmonic component.
My application is that I have an automation controller that has a
calendar, can do calculations (including trig), but is rather memory
limited. Thus I would like to calculate time of sunset 'on the fly'
rather than store the data table.
I would like an equation that yields Sunset as a function of day
number. I would like to keep it simpler than the generic formula
given latitude and longitude. I would like the formula from the
tabular data.
It appears to have the form:
Sunset = K + A1*sin(k*D-P1) + A2*sin(2*k*D-P2) + ???
Where:
D = Day number
K, A1, A2, k, P1, P2 are constants determined by Long/Lat.
Has anyone determined the basic functions contained within this
'Sunset function'? Given the basic functions, I can then calculate the
constants.
Thanks in advance for your help,
TomCee
David White
Dave Houston
(just stay away from Cheney's house - he's been known to shoot people). You
might try 'astronomical clock' as a search term.
Here's what I use with PureBasic. I use the same basic code with an embedded
ZBasic ZX-40a - it uses less space than a lookup table. I think I originally
got it from USNO. 'Protected' is the same as 'local' in other languages.
Variables declared with .d are double precision floats; those without are
32-bit integers.
DST2 & DST4 are global variables that hold the DST start/end times in hours
since 0000 01-01-yyyy.
Procedure GetDawnDusk() ;calculates sunrise/sunset
Protected
RadiansPerDegree.d,latitude.d,longitude.d,tz.d,zone.d,lo.d,c.d,C2.d,SD.d,CD.d,sc.d,C3.d,yd,n,dawn,dusk
OpenPreferences("roZetta.prf"):PreferenceGroup("Global")
longitude=ReadPreferenceDouble("longitude",-84.56)
latitude=ReadPreferenceDouble("latitude",39.04)
tz=ReadPreferenceDouble("tz",-5.00)
ClosePreferences()
tz=tz*-1
RadiansPerDegree=0.017453293
yd=DayOfYear(Date())
If latitude=>0
If yd>=Val(DST2)/24 And yd<Val(DST4)/24
zone=tz-1.0
Else
zone=tz
EndIf
Else
If yd>=Val(DST4)/24 Or yd<Val(DST2)/24
zone=tz-1.0
Else
zone=tz
EndIf
EndIf
lo=4.8771+0.0172*(yd+0.5-longitude/360.0)
c=0.03342*Sin(lo+1.345)
C2=(1.0/RadiansPerDegree)*(ATan(Tan(lo + c))-ATan(0.9175*Tan(lo+c))-c)
SD=0.3978*Sin(lo+c)
CD=Sqr(1.0-SD*SD)
sc=(SD*Sin(latitude*RadiansPerDegree)+0.0145)/(Cos(latitude*RadiansPerDegree)*CD)
C3=(1.0/RadiansPerDegree)*ATan(sc/Sqr(1.0-sc*sc))
n=((6.0-zone-(longitude+C2+C3)/15.0)/24.0)*1440.0
dawn=(n/60)*100+(n%60)
n=((18.0-zone-(longitude+C2-C3)/15.0)/24.0)*1440.0
dusk=(n/60)*100+(n%60)
SetGadgetText(#TXT_DAWN_CFG, RSet(Str(dawn),4,"0"))
SetGadgetText(#TXT_DUSK_CFG, RSet(Str(dusk),4,"0"))
EndProcedure
tomcee <tomce...@yahoo.com> wrote:
http://davehouston.net http://davehouston.org
http://tech.groups.yahoo.com/group/roZetta/
roZetta-...@yahoogroups.com
Androcles
"tomcee" <tomce...@yahoo.com> wrote in message
news:24b3d18e-ac7f-46e9...@j28g2000hsj.googlegroups.com...
Ok, first understand the problem.
Imagine (because it isn't so, but it helps) that the Earth
has no tilt and moves in a perfect circle around the Sun
and the Sun itself is a point of light, not a ball 1/2 a degree
wide.
Sunrise and sunset will be at the same time every day,
6:00 am and 6:00 pm at the equator, earlier and later as
you move North or South. When you reach either Pole
it will not set at all, but goes around the horizon.
The function for this is the cosine of latitude, cos(90 degrees) = 0.
Now we tilt the Earth, and we do so in our imagination by 90 degrees.
The North pole faces the Sun on mid-summer's day, and
the south pole faces the Sun 6 months later. As you know,
Northern Summer is Southern Winter and vice versa.
With our 90 degree tilt the Sun doesn't rise or set at the equator
on mid-summer's day OR mid-winter's day, equal day and night
occur mid-spring and mid-autumn.
Okay, so much for latitude and tilt, next is orbital eccentricity.
We imagined that the Earth moved in a perfect circle, but it doesn't.
It is closest to the Sun on or about Jan 3rd at 91,000,000 miles
and furthest 6 months later at 94,000,000 miles, moving in
an elliptical orbit. As we did above, we again imagine an
extreme case where the Earth passes very close to our
point-like Sun and then 6 months later is way out near Pluto.
The orbit is almost a straight line. The Earth falls toward
the Sun going faster and faster (as comets do) and then
swings around the back where gravity is at its greatest,
climbs away again and slows as it gets toward Pluto's
orbit where it stops climbing and falls once again, just
as a ball thrown straight up would do. Now, when far
from the Sun the Earth turns once a day, sunset and sunrise
are about the same each day, but when close to the sun
we have a problem with that. The Earth turns on its axis
360 degrees in what is called a sidereal day
(1 sidereal day = 23.9344696 hours)
and there are 366, (not 365) sidereal days in a year.
http://en.wikipedia.org/wiki/Sidereal_day
That is when the Earth has turned not to face the sun
once a day, but to face the other stars.
You will notice that the night sky has different stars
directly overheard between Summer and Winter.
This means that when (in our imagination) the Earth
passes very close by the sun, noon, when the sun is overhead,
can last for 12 hours.
Look at the diagram at
http://en.wikipedia.org/wiki/Sidereal_day
and you'll see why.
Last and least, the Sun is NOT a point.
Now... the computation of Earth's orbit is something you
do NOT want to do.
http://mathworld.wolfram.com/KeplersEquation.html
In conclusion, a look-up table is the simplest solution for you.
OG
"tomcee" <tomce...@yahoo.com> wrote in message
news:24b3d18e-ac7f-46e9...@j28g2000hsj.googlegroups.com...
What level of accuracy are you looking for ?
oriel36
> The Earth turns on its axis
> 360 degrees in what is called a sidereal day
> (1 sidereal day = 23.9344696 hours) or 23 hours 56 minutes 04 seconds
Surely there is a sane and reasonable person around who can appreciate
how timekeeping astronomers transfered the Equation of Time corrected
natural noon cycle to the average 24 hour cycle and when axial
rotation was discovered to be the cause of the daily cycle they
exploited the human devised 24 hour cycle are transfered it from
'Average' to 'Constant' without requiring an external reference.
That value you give (sidereal day) requires the noon cycles to be
equal in order to create a solar/sidereal fiction using the axial and
orbital motions of the Earth -
http://upload.wikimedia.org/wikipedia/commons/1/1d/Tiempo_sid%C3%A9reo.en.png
To think that the work of Huygens and Harrison is in competition with
the sidereal junk is apalling,-
http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html
I cannot,cannot acount for why this most enjoyable and profound work
is set aside for destructive and cartoonlike conceptions that never
worked.You can openly promote the sidereal value without the slightest
sign of an objection when before all of you is the jewel of Huyegns
representing millenia of refinements which go into the correlation
between clocks,the daily cycle and terrestrial longitudes.
I never doubted that many people know exactly what went wrong but did
not count on the lack of courage to change matters quickly or to
intepret correctly the changing enviroment in celestial/terrestrial
studies.
tomcee
> "tomcee" <tomcees...@yahoo.com> wrote in message
>
> - Show quoted text -
OG:
Thanks for asking; I had intended to mention this in my original
post. I would like accuracy to within 5 minutes; preferably biased
towards the negative so that if anything, the lights would turn on
early, rather than late.
John J. Bengii
can point you to their own or website software to do this.
Univ or Oregon website is big into this and has lots of info.
"tomcee" <tomce...@yahoo.com> wrote in message
news:9f27799a-458e-4086...@e60g2000hsh.googlegroups.com...
Perihelion
>On Feb 16, 2:30=A0pm, "OG" <o...@gwynnefamily.org.uk> wrote:
>> "tomcee" <tomcees...@yahoo.com> wrote in message
>>
>> news:24b3d18e-ac7f-46e9...@j28g2000hsj.googlegroups.com...
>> > My application is that I have an automation controller that has a
>> > calendar, can do calculations (including trig), but is rather memory
>> > limited. =A0Thus I would like to calculate time of sunset 'on the fly'
>> > rather than store the data table.
> ...
>Thanks for asking; I had intended to mention this in my original
>post. I would like accuracy to within 5 minutes; preferably biased
>towards the negative so that if anything, the lights would turn on
>early, rather than late.
>
>Thanks in advance for your help,
>TomCee
Store monthly values and interpolate. That's likely to be the fastest
and least memory intensive technique.
Androcles
OG:
15 entries in a look-up table, each entry reused for 12 days.
12 * 15 = 180.
Day
1-12 17:10
13-24 17:25
24- 36 17:40
...
169-180 20:20
Dave Houston
to follow than the PureBasic code (which runs on a PC under
Windows/Linux/Mac) that I posted earlier.
The last 8 lines following 'dusk =' aren't directly related to
sunrise/sunset. This is accurate to a minute. The key question is whether
your embedded microcontroller can do floating point math.
Finally, I think Sky and Telescope Magazine was where I found the original
formula - they have numerous Basic language programs.
http://www.skyandtelescope.com/resources/software/3304911.html?page=1&c=y
'====================================================================
Sub NewDay()
Dim m As Byte
Dim d As Byte
Dim y As Integer
Dim n As Integer
Dim lo As Single
Dim c As Single
Dim C2 As Single
Dim SD As Single
Dim CD As Single
Dim sc As Single
Dim C3 As Single
Dim ds As Single
Dim zone As Single
Const RadiansPerDegree As Single = 0.017453293
yd = GetDayOfYear(Register.RTCDay)
ds = CSng((dstflags/2) And 1) 'DST offset
lo = 4.8771 + 0.0172 * (CSng(yd) + 0.5 - longitude / 360.0)
c = 0.03342 * Sin(lo + 1.345)
C2 = (1.0 / RadiansPerDegree) * (Atn(Tan(lo + c)) - Atn(0.9175 * Tan(lo +
c)) - c)
SD = 0.3978 * Sin(lo + c)
CD = Sqr(1.0 - SD * SD)
sc = (SD * Sin(latitude * RadiansPerDegree) + 0.0145) / _
(Cos(latitude * RadiansPerDegree) * CD) 'astronomical sunrise,
sunset
C3 = (1.0 / RadiansPerDegree) * Atn(sc / Sqr(1.0 - sc * sc))
n = CInt(((6.0 - zone -ds - (longitude + C2 + C3) / 15.0) / 24.0) *
1440.0)
dawn = (n\60)*100 + (n Mod 60)
n = CInt(((18.0 - zone -ds - (longitude + C2 - C3) / 15.0) / 24.0) *
1440.0)
dusk = (n\60)*100 + (n Mod 60)
Call GetHolidays(0)
Call GetTime(hh,mm,ss)
Now = CInt(hh) * 100 + CInt(mm)
tx = "0000" & CStr(Now)
tx = "NOW:" & Right(tx,4) & " DAY:" & CStr(yd) & " SUNRISE:0"
tx = tx & CStr(dawn) & " SUNSET:" & CStr(dusk) & " HOLIDAY:" &
CStr(holiday)
tx = tx & CrLf
Call PutStr(0, tx)
End Sub
'====================================================================
tomcee <tomce...@yahoo.com> wrote:
>Has anyone determined the basic functions contained within this
>'Sunset function'? Given the basic functions, I can then calculate the
>constants.
Dr J R Stockton
Sun, 17 Feb 2008 00:13:18, Perihelion <hate...@hatespam.com> posted:
>
>Store monthly values and interpolate. That's likely to be the fastest
>and least memory intensive technique.
Without checking and purely guessing, I'd be surprised if linear
interpolation were good to 5 minutes everywhere. For an improvement by
a factor of about 4, use fortnightly values. For a bigger improvement,
try quadratic interpolation, or even cubic interpolation.
Alternatively, use a best-fit sine wave (assuming that the machine has a
sine instruction), followed by linear interpolation in a monthly table
of corrections.
Remember that the amplitude of the sunset time shift depends on
latitude.
Remember that the phase of the shift wave varies from year to year by a
day or so (Leap Year effect); here that amounts to a couple of minutes
at equinoxes.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Brian Tung
> Without checking and purely guessing, I'd be surprised if linear
> interpolation were good to 5 minutes everywhere. For an improvement by
> a factor of about 4, use fortnightly values. For a bigger improvement,
> try quadratic interpolation, or even cubic interpolation.
Actually, I think linear interpolation should work pretty well--at least
up to about 55 or 60 degrees north or south latitude. Close to the
Arctic or Antarctic circles it gets a little dicey. You might not want
the interpolation endpoints to be evenly spaced, but I think it could be
done to within +0/-5 minutes with 10 or 15 values.
I certainly think the tabular approach is better than actual analysis.
The original poster's application seems like it's got a lot of leeway in
it.
> Alternatively, use a best-fit sine wave (assuming that the machine has a
> sine instruction), followed by linear interpolation in a monthly table
> of corrections.
The sine wave fails near the arctic regions, just where interpolation
would also fail. I don't know how bad, but I'd trust interpolation with
10 or 15 points more than I'd trust a best sine fit.
--
Brian Tung <br...@isi.edu>
The Astronomy Corner at http://astro.isi.edu/
Unofficial C5+ Home Page at http://astro.isi.edu/c5plus/
The PleiadAtlas Home Page at http://astro.isi.edu/pleiadatlas/
My Own Personal FAQ (SAA) at http://astro.isi.edu/reference/faq.html
Perihelion
>In sci.astro message <47b77b92...@news.houston.sbcglobal.net>,
>Sun, 17 Feb 2008 00:13:18, Perihelion <hate...@hatespam.com> posted:
>>
>>Store monthly values and interpolate. That's likely to be the fastest
>>and least memory intensive technique.
>
>Without checking and purely guessing, I'd be surprised if linear
>interpolation were good to 5 minutes everywhere. For an improvement by
>a factor of about 4, use fortnightly values. For a bigger improvement,
>try quadratic interpolation, or even cubic interpolation.
Pretty darn close for most latitudes. The OP can, of course, easily
check it with a simple spreadsheet and decide if it's good enough. If
not, then just add more points.
And, given the OP's assertion that memory is at a premium, I would
still go with linear interpolation. In embedded applications,
simplicity is a virtue not to be taken lightly.
And, after all, he's just trying to turn on some night lights. How
close do you really need to be for that?
Odysseus
wrote:
<snip>
> I certainly think the tabular approach is better than actual analysis.
> The original poster's application seems like it's got a lot of leeway in
> it.
It's also much easier to incorporate DST and other arbitrary adjustments
into a table than it is to model them analytically.
--
Odysseus
oriel36
> In article <fpai0f$qp...@praesepe.isi.edu>, br...@isi.edu (Brian Tung)
You are just geostationary guys who know no better,running around with
the linear calendrical convenience with not the slightest sign that
you are aware that anything is wrong,the fact that forcing a cyclical
system of 365 days 5 hours 49 minutes into a linear system of 3 years
of 365 days and 1 year of 366 days is not and never was astronomy.
It is difficult to imagine so many people go to universities and
institutions to day and work on material based on the wrong value for
the axial rotation of the Earth,not the the actual value has ever been
given but the human devised principles which keep clocks in synch
with the axial cycle and terrestrial longitudes at 24 hours/360
degrees is probably as close a value as can be possibly had.That value
is just a consequence of a remarkable transfer of average 24 hour day
to Constant axial rotation as a principle but not as an observed fact.
I am absolutely intrigued by the ability to ignore the greatest known
astronomical timekeeping mistake,the most fundamental correlation is
all timekeeping astronomy and men are off by a margin of roughly 3
minutes 56 seconds !.
Brian Tung
> It's also much easier to incorporate DST and other arbitrary adjustments
> into a table than it is to model them analytically.
Well, DST is pretty easy to account for. And I can't think of anything
else that matters at the 5-minute level. He's going to be writing a
program, presumably; it doesn't have to all fit into some single
expression.
tomcee
> Odysseus wrote:
> > It's also much easier to incorporate DST and other arbitrary adjustments
> > into a table than it is to model them analytically.
>
> Well, DST is pretty easy to account for. And I can't think of anything
> else that matters at the 5-minute level. He's going to be writing a
> program, presumably; it doesn't have to all fit into some single
> expression.
>
> --
> Brian Tung <br...@isi.edu>
> Unofficial C5+ Home Page athttp://astro.isi.edu/c5plus/
> The PleiadAtlas Home Page athttp://astro.isi.edu/pleiadatlas/
> My Own Personal FAQ (SAA) athttp://astro.isi.edu/reference/faq.html
Thank you all for your most interesting ideas and analyses.
Of course, interpolation is a good and reasonable choice - perhaps
I'll investigate the tradeoffs between program size required to do the
interpolation versus data storage requirements.
One thing that has occured to me is that the range of possible sunset
times is about 193 minutes. (earliest sunset is 17:00, latest is 20:13
here in Detroit, Michigan, USA). So, if I have the program use 1700
as a 'base' time (or time zero), then all I need is an offset from
that time.
As the maximum offset is 193, I can contain this offset data in one
byte of information. Thus to store the table for the entire use
requires only 366 bytes of data - quite minimal. While this does
require some storage, it has the advantage of being exact (as exact as
the table I've consulted), and can easily be adapted to other
tables.
Thanks again!
TomCee
Chris L Peterson
wrote:
>One thing that has occured to me is that the range of possible sunset
>times is about 193 minutes. (earliest sunset is 17:00, latest is 20:13
>here in Detroit, Michigan, USA). So, if I have the program use 1700
>as a 'base' time (or time zero), then all I need is an offset from
>that time.
Well, that raises the question of whether this is a generic application,
which needs to be portable with respect to location, or a one-off
implementation. I doubt you want to load custom tables if this thing is
going to be used in different places; for that, an analytical solution
seems better.
_________________________________________________
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com
Brian Tung
> One thing that has occured to me is that the range of possible sunset
> times is about 193 minutes. (earliest sunset is 17:00, latest is 20:13
> here in Detroit, Michigan, USA). So, if I have the program use 1700
> as a 'base' time (or time zero), then all I need is an offset from
> that time.
> As the maximum offset is 193, I can contain this offset data in one
> byte of information. Thus to store the table for the entire use
> requires only 366 bytes of data - quite minimal. While this does
> require some storage, it has the advantage of being exact (as exact as
> the table I've consulted), and can easily be adapted to other
> tables.
Even at more extreme latitudes, you can get within your five-minute
margin by taking the offset, which is bounded by 720 minutes (half a
day), and dividing it by 3, saving the result within a single byte
(octet for those pedants amongst us).
--
Brian Tung <br...@isi.edu>
The Astronomy Corner at http://astro.isi.edu/
Unofficial C5+ Home Page at http://astro.isi.edu/c5plus/
The PleiadAtlas Home Page at http://astro.isi.edu/pleiadatlas/
sylvan butler
> And, after all, he's just trying to turn on some night lights. How
> close do you really need to be for that?
Given spec was 5 minutes.
sdb
--
What's seen on your screen? http://PcScreenWatch.com
sdbuse1 on mailhost bigfoot.com
Dave Houston
>On Mon, 18 Feb 2008 10:34:41 -0800 (PST), tomcee <tomce...@yahoo.com>
>wrote:
>
>>One thing that has occured to me is that the range of possible sunset
>>times is about 193 minutes. (earliest sunset is 17:00, latest is 20:13
>>here in Detroit, Michigan, USA). So, if I have the program use 1700
>>as a 'base' time (or time zero), then all I need is an offset from
>>that time.
>
>Well, that raises the question of whether this is a generic application,
>which needs to be portable with respect to location, or a one-off
>implementation. I doubt you want to load custom tables if this thing is
>going to be used in different places; for that, an analytical solution
>seems better.
You'll have to load a new table annually, anyway, so custom tables loaded by
the user is not that big a deal, assuming there's a way for users to update
the table.
Dr J R Stockton
02:10:52, Brian Tung <br...@isi.edu> posted:
>Odysseus wrote:
>> It's also much easier to incorporate DST and other arbitrary adjustments
>> into a table than it is to model them analytically.
>
>Well, DST is pretty easy to account for. And I can't think of anything
>else that matters at the 5-minute level. He's going to be writing a
>program, presumably; it doesn't have to all fit into some single
>expression.
I don't think he wants DST; that only affects what the clocks read at
sunset, and not when the Sun actually sets. The Solar System runs, near
enough for this job, on UT.
Subtracting the DST is easy if you know that it is Summer, that the
location has DST, and if so whether or not it is LHI. Working out the
dates of DST is a little less easy for the USA, and may be quite hard
for, say, Tel Aviv. Predicting when the DST rules may change in future
is even harder.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Perihelion
>[...incoherent rant excised...]
>I am absolutely intrigued by the ability to ignore the greatest known
>astronomical timekeeping mistake,the most fundamental correlation is
>all timekeeping astronomy and men are off by a margin of roughly 3
>minutes 56 seconds !.
Not quite sure what your point is, but the OP doesn't care about the
sidereal day. To know what time the sun sets, you need care about only
the solar day; which does, indeed, have a mean value of 24 hours.
canopus56
<snip>
> It appears to have the form:
>
> Sunset = K + A1*sin(k*D-P1) + A2*sin(2*k*D-P2) + ???
> Where:
> D = Day number
> K, A1, A2, k, P1, P2 are constants determined by Long/Lat.
>
> Has anyone determined the basic functions contained within this
> 'Sunset function'? Given the basic functions, I can then calculate the
> constants.
Fourier transforms - after Meuss's _Astronomical Algorithms_ - are
used to compute the right acension and declination of the Sun for any
point in time by Julian date. Another algorithm can be found in
Allen's _Astrophysical Quantities_ at pages 688-669. Normally,
spherical trigonometry then is used to determine the time of sunset or
sunrise based on that celestial position of the Sun relative to the
observer. In general, I haven't seen a "full" Fourier transform that
goes directly from a Julian date to the time of sunrise for a given
latitude and longitude. That is probably because you would need a
unique Fourier transform for every unique latitude and longitude on
the face of the Earth. Less efficient than the generic method.
Dave Houston's excellent example is based on the mean anomaly of the
Sun with respect to a particular calendar date of the year. That is
probably less accurate than the formula found in Allen's
_Astrophysical Quantities_. The one is Allen's is accurate to within
6 arcmins or 40 seconds between 1950 and 2050. Dave's code seems
sufficiently accurate for your purposes.
You may want to try posting your question to the ALPOCS yahoo group
(the computing section of the Association of Lunar and Planetary
Observers) and see if they have a specific answer regarding a "full"
Fourier transform that goes right to the time of sunrise from a date.
http://tech.groups.yahoo.com/group/alpocs/
- Canopus56
Robert L Bass
"Chris L Peterson" <c...@alumni.caltech.edu> wrote in message
news:4tkjr3dmrncbs3f87...@4ax.com...
> On Mon, 18 Feb 2008 10:34:41 -0800 (PST), tomcee <tomce...@yahoo.com>
> wrote:
>
>>One thing that has occured to me is that the range of possible sunset
>>times is about 193 minutes. (earliest sunset is 17:00, latest is 20:13
>>here in Detroit, Michigan, USA). So, if I have the program use 1700
>>as a 'base' time (or time zero), then all I need is an offset from
>>that time.
>
> Well, that raises the question of whether this is a generic application,
> which needs to be portable with respect to location, or a one-off
> implementation. I doubt you want to load custom tables if this thing is
> going to be used in different places; for that, an analytical solution
> seems better.
The OP said he is in Detroit. From the context I assume (perhaps
erroneously?) that this is a one-up problem. If that is correct, a simple
table of 26 two-week periods will more than suffice. During any given 14-day
period the daily change in sunset varies between 3 and 25 minutes. 26 bytes
will store all the data he needs to calculate sunset on any given date within
less than a one minute error. The calculation will use only a few bytes of
code. For a home automation application that should be more than sufficient.
I agree that if the system needed to be portable the proposed method would be
inadequate.
--
Regards,
Robert L Bass
==============================>
Bass Home Electronics
4883 Fallcrest Circle
Sarasota · Florida · 34233
http://www.bassburglaralarms.com
Sales & Tech Support 941-925-8650
Customer Service 941-232-0791
Fax 941-870-3252
==============================>
Paul Schlyter
Dave Houston <nob...@whocares.com> wrote:
>Chris L Peterson <c...@alumni.caltech.edu> wrote:
>
>>On Mon, 18 Feb 2008 10:34:41 -0800 (PST), tomcee <tomce...@yahoo.com>
>>wrote:
>>
>>>One thing that has occured to me is that the range of possible sunset
>>>times is about 193 minutes. (earliest sunset is 17:00, latest is 20:13
>>>here in Detroit, Michigan, USA). So, if I have the program use 1700
>>>as a 'base' time (or time zero), then all I need is an offset from
>>>that time.
>>
>>Well, that raises the question of whether this is a generic application,
>>which needs to be portable with respect to location, or a one-off
>>implementation. I doubt you want to load custom tables if this thing is
>>going to be used in different places; for that, an analytical solution
>>seems better.
>
>You'll have to load a new table annually, anyway, so custom tables loaded by
>the user is not that big a deal, assuming there's a way for users to update
>the table.
If an accuracy of 5 minutes is enough, no new tables need to be loaded
each year. Then it's perfectly OK to use one single table for all years.
For leap years, on 29 Febr one can use the data for 28 Febr or 1 March - each
will be within 5 minutes of the actual time for 29 Febr.
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stjarnhimlen dot se
WWW: http://stjarnhimlen.se/
oriel36
Ah,the mean solar day,tell me how you get the 24 hour day and I will
even allow you tour geostationary point of view seeing that you are
iconcerned about sunrise/sunsets.Tell me how you use the Sun to
determine the difference between natural noon and clock noon.
When it is all done,I might even explain to you why your calendrically
driven sidereal day is driving everything from timekeeping astronomy
to stuctural;astrology.The chances are that you will vanish besides
the thoughts of having to explain to another programmer why he is
hopelessly lost in astronomical affairs is hardly worth the effort
As for getting the point,none of you ever do.
Dr J R Stockton
22:35:49, Dave Houston <nob...@whocares.com> posted:
>
>You'll have to load a new table annually, anyway, so custom tables loaded by
>the user is not that big a deal, assuming there's a way for users to update
>the table.
Sunset times for a given date vary little from year to year, short-term,
and the dominant cause will be the jitter of the civil date with respect
to the astronomical motions. The fastest variation at Glasgow is no
more than about 2.5 minutes per day, so the effect will be unimportant.
Assuming a product life of say 20 years, and optimising for the middle
of that, the component of drift necessitating the Gregorian Correction
will be insignificant. That necessitating quadrennial Leap Years could
be compensated by counting date from zero being the day after February
29th, mod 365.25, or something like that - but it will probably not be
necessary to do it.
Since the application appears to be for the control of lighting to
compensate for the setting of the Sun, ISTM that the difference between
a clear and a very cloudy day will be far more important. On a clear
day in winter (when the Sun sets more slowly) the amount of natural
light well after Sunset can be, or seem, as great as that during an
extended noontime thunderstorm.
To control lighting, one needs a photocell rather than a clock.
--
(c) John Stockton, nr London UK. *@merlyn.demon.co.uk/??.Stockton@physics.org
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
oriel36
> In sci.astro message <47ba0747.93905...@nntp.fuse.net>, Mon, 18 Feb 2008
> 22:35:49, Dave Houston <nob...@whocares.com> posted:
>
>
>
> >You'll have to load a new table annually, anyway, so custom tables loaded by
> >the user is not that big a deal, assuming there's a way for users to update
> >the table.
>
> Sunset times for a given date vary little from year to year, short-term,
> and the dominant cause will be the jitter of the civil date with respect
> to the astronomical motions. The fastest variation at Glasgow is no
> more than about 2.5 minutes per day, so the effect will be unimportant.
>
It is creeps like you who never discern what exactly those motions
are,why variations do not occur at the Equator in terms of daylight/
darkness yet variations occur in the total length of the natural
day,using noon as a benchmark everywhere on the planet where the Sun
is visible up to and including the Equator
There is nothing remotely close to the dull and dismal attempts of
geostationary minds tinkering around with a linear calendar system
based on 3 years of 365 days and 1 year of 366 days.
What a bunch of miserable cretins when it is simple enough to extract
the relevent motions from intepreting what is occuring with Uranus as
it orbits the central Sun -
http://asymptotia.com/wp-images/2007/08/uranus_rings.jpg
Pretension is the only thing you people have and I leave you with it.
> Assuming a product life of say 20 years, and optimising for the middle
> of that, the component of drift necessitating the Gregorian Correction
> will be insignificant. That necessitating quadrennial Leap Years could
> be compensated by counting date from zero being the day after February
> 29th, mod 365.25, or something like that - but it will probably not be
> necessary to do it.
>
> Since the application appears to be for the control of lighting to
> compensate for the setting of the Sun, ISTM that the difference between
> a clear and a very cloudy day will be far more important. On a clear
> day in winter (when the Sun sets more slowly) the amount of natural
> light well after Sunset can be, or seem, as great as that during an
> extended noontime thunderstorm.
>
> To control lighting, one needs a photocell rather than a clock.
>
> --
> (c) John Stockton, nr London UK. *...@merlyn.demon.co.uk/??.Stock...@physics.org
oriel36
> canopus56 says...
>
> > Dave Houston's excellent example is based on the mean
> > anomaly of the Sun with respect to a particular calendar
> > date of the year. That is probably less accurate than
> > the formula found in Allen's _Astrophysical Quantities_.
> > The one is Allen's is accurate to within 6 arcmins or
> > 40 seconds between 1950 and 2050. Dave's code seems
> > sufficiently accurate for your purposes.
>
> this will become invalid if the current proposal to replace
> leap seconds with leap hours is approved. I was a bit
> surprised to learn that the proposal is actually coming up
> for a vote in April. If I understand the proposal
> correctly, which I may not, it just seems screwy.
> Apparently, UTC would be allowed to get out of whack with
> "astronomical" time by an hour before it is corrected.
> Seems like that would screw up a lot of things.
This profound misintepretation of seconds and leap corrections as
applied to the Earth is appaling by any standards.A reasonably
intelligent person ,after reviewing the evidence ,will conclude there
is an error in the reasoning which applies 'leap second' corrections
based on the assumption that axial rotation can be infered by
referencing it off celestial sphere geometry.
The closest timekeeping astronomers ever got to applying the standad
pace of clocks to axial rotation was to transfer the average 24 hour
day to the axial cycle as a 'Constant' , a pragmatic maneuver that
exists as a convenience but not as an observed fact.There is no
external reference for axial rotation and a star returning to a
location at a constant 3 minutes 56 seconds earlier every 24 hours
only determines how good the old timekeeping astronomers were at
creating the calendar system.
This business of determining that the Earth's rotation represents a
'bad clock' thereby appealing to atomic clokcs to determine the
standard for the second and subsequently the minute and hour is a
product of shoddy thinking,the parent value of the 24 hour day upon
which the second is based was formatted against variations in the
natural noon cycle but exists as a human devised principle,the
authority on this is Huygens -
http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html
Maybe it is impossible for people,even highly intelligent people,to
get the idea out of their heads that the Earth's rotation represents a
'bad clock'.Make the leap second or leap hour corrections if you
must but these correction cannnot serve as a based for determining
structural astronomy where the motions of the Earth are involved and
especially not axial rotation.In exactly 10 days,between Feb 29th and
Mar 1st ,timekeepers can affirm that a star will return to the same
position 3 minutes 56 seconds earlier thus disproving that the axial
and orbital motion cannot,I repeat ,cannot be determined by this line
of reasoning unless you all wish structural astronomy to look like
this -
http://www.opencourse.info/astronomy/introduction/02.motion_stars_sun/celestial_sphere_anim.gif
The theme is to stop this nonsense of believing the rotation of the
Earth makes a bad clock for no timekeeping astronomer ever holds to
the belief that axial rotation could be linked directly to the 24 hour
cycle aqnd as for the 23 hour 56 minute 04 second value,my counsel is
to run as far away from that value as possible.It was a mistake
Flamsteed created and it will always remain a mistake.
Chris L Peterson
wrote:
>As an aside, I wonder whether virtually all formulas like
>this will become invalid if the current proposal to replace
>leap seconds with leap hours is approved. I was a bit
>surprised to learn that the proposal is actually coming up
>for a vote in April. If I understand the proposal
>correctly, which I may not, it just seems screwy.
>Apparently, UTC would be allowed to get out of whack with
>"astronomical" time by an hour before it is corrected.
>Seems like that would screw up a lot of things.
In a few cases it would require minor changes to the inputs of formulas.
It wouldn't have any practical impact on applications like what is being
discussed in this thread, since it takes hundreds of years for such big
errors to accumulate.
IMO leap anythings are silly. UT should just be the standard, and it
should drift completely free of astronomical time, with no correction
applied (but a correction factor known, of course).
J Miller
only sunset is considered!
Seems the OP wanted to use it for a Home Automation solution, and it
seems to me that sunrise may also be needed! (The OP might not see it
now, but it does come in handy!)
Something as simple as "turn porch light on at sunset, off at sunrise".
Therefore the table based solutions may actually require double the
table space being discussed...
One other thing I didn't see (may have missed it) is if the platform/OS
"knows" about DST setting, and sets it's internal clock correctly
(window/linux come to mind). If that's the case, the table will need to
vary each year, as the change doesn't occur on a specific J date, but on
one of 7 or so.
Again, for a HA solution, I'd assume this is the case - again, something
as simple as "turn on coffee maker at 6am" would be tied to "clock time"
and should know about DST.
Of course, if the OP was in AZ, DST wouldn't be an issue! (now if only
the rest of the US would take this "logical" approach! :) )
For HA, I would go with an math based solution vs table. You really
only need three things (4 if you do DST) - Lat, long, Jdate, DST mode,
and the resulting compiled code could be smaller than the table, and
more accurate!
Androcles
"J Miller" <reply@here> wrote in message
news:47bc642c$0$507$815e...@news.qwest.net...
Go on then, prove it. I'm close to London and unlike the OP,
I want one second accuracy for both sunrise and sunset.
This year is a leap year, I want that included. Show me your math.
oriel36
> On Wed, 20 Feb 2008 07:03:14 -0600, George <gh424NO824S...@cox.net>
> wrote:
>
> >As an aside, I wonder whether virtually all formulas like
> >this will become invalid if the current proposal to replace
> >leap seconds with leap hours is approved. I was a bit
> >surprised to learn that the proposal is actually coming up
> >for a vote in April. If I understand the proposal
> >correctly, which I may not, it just seems screwy.
> >Apparently, UTC would be allowed to get out of whack with
> >"astronomical" time by an hour before it is corrected.
> >Seems like that would screw up a lot of things.
>
> In a few cases it would require minor changes to the inputs of formulas.
> It wouldn't have any practical impact on applications like what is being
> discussed in this thread, since it takes hundreds of years for such big
> errors to accumulate.
>
> IMO leap anythings are silly.
Good for you,what do propose to do to replace the 86 400 second leap
correction on Feb 29th of this year where the astronomically based
annual cycle of 365 days 5 hours 49 minutes was conveniently altered
to include a calendrical linear system where one year follows the next
year.It happens to be one of the greatest and oldest achievements of
astronomical timekeeping
UT should just be the standard, and it
> should drift completely free of astronomical time, with no correction
> applied (but a correction factor known, of course).
>
Unless there is some sort of intellectual perversion,and there very
well may be,there is absolutely no reason why the error cannot be
spotted,dealt with and a clear and distinct set of proposals to stop
less than careful men from using timekeeping astronomy to dictate
structural astronomy.There is nothing remotely close in human history
to this scandal where the motions of the Earth are crafted to suit the
clock by appealing to a zodical/celestial sphere/constellational
framework ,if the Wiki article was written by some minority group it
would be funny but it is the dominant stance of everyone here and that
is something else ! -
http://en.wikipedia.org/wiki/Earth_rotation
Somebody has to ask themselves when is the nonsense going to
stop,there may be practical reasons for adding or subtracting seconds
for 21st century equipment but there is absolutely no foundation to
assigning the astronomical cause for a variation as applied to the
axial rotation of the Earth.There is a huge daily difference between
axial rotation and orbital motion using natural noon as a
benchmark,taking axial rotation to be constant,the registered
variations represent the rate of change of orbital orientation as a
location on Earth turns through 360 degrees with respect to the Sun.
The axial rotation of the Earth has never been isolated as a
motion,again,the quirks of using timekeeping astronomy to dictate
structural astronomy is not a way to proceed.Until the IERS or a
similar organisation is willing to discuss how to discriminate one
from the other,the evolution of timekeeping systems , the basis for
accurate references for the motions of the Earth and all this without
causing a major meltdown,this method of discussion will go on.
J Miller
with 5 minutes. Quite simple math really, as the first place I saw this
routine was for the TI SR51 programmable calculator 30 years ago!
Androcles
So you can't do it and are just mouthing off trying to appear smart
when you are really just another top-posting shithead with a big mouth.
Fuck off, you are useless.
"J Miller" <reply@here> wrote in message
news:47bc998b$0$3576$815e...@news.qwest.net...
Dr J R Stockton
20 Feb 2008 08:21:41, Chris L Peterson <c...@alumni.caltech.edu> posted:
>
>IMO leap anythings are silly. UT should just be the standard, and it
>should drift completely free of astronomical time, with no correction
>applied (but a correction factor known, of course).
The standard should not be UT, but it should be indistinguishable from
UT for all purposes apart from high-precision time measurement.
Aside : The Olympics, etc., should specify SI time.
Civil Time should run at a rate of one CT second for every N SI
nanoseconds, where N is an integer announced by BIPM (early in each
half-year, to apply for the following half-year) in a replacement for
Bulletin C.
Since we've been using one leap second, or not, about every 16
megaseconds, it is clear that integer SI nanoseconds per CT second gives
ample resolution. The six-month interval will be as satisfactory as the
Leap Second interval, and can be reduced in the same manner when needed.
Given disseminated SI seconds, it is easy enough to generate SI
nanoseconds locally, to count them, and to generate CT seconds
accordingly.
The exact implementation of a change of rate would need to be carefully
defined; for example whether it is done on the CT or SI half-year.
If desired, the rate-change could be spread out by changing the integer
by one unit at a time; it's only simple electronics such as I used to
build from SSI & MSI, and could easily be integrated on a single chip of
specified properties.
--
J Miller
/* The calculations are approximate and were based on an */
/* algorithm published in "Texas Instruments programmable */
/* slide rule calculator (SR-56) Applications Library" */
/* */
/* GMT = 12 - et + (longitude + x * ACOS TAN d8 TAN latitude)/15 */
/* */
/* latitude = latitude (N=+ S=-) */
/* longitude = longitude (W=+ E=-) */
/* x = -1 for Sunrise, 1 for sunset */
/* et = equation of time = */
/* 0.123 * COS (t+87) - 1/6 SIN ((t+10)/0.5) */
/* d8 = sun declination = */
/* 23.5 * COS (T+10) */
/* t = time = */
/* 0.988*(d + 30.3 * ( m - 1)) */
/* d = day of the month */
/* m = month of the year */
/* */
/* -------------------------------------------------------------- */
The code itself was written for an old 16 bit windows compiler so it's
unusable today.. It also doesn't use Julian date, and make the caller
adjust for DST. It ran on DOS 3.x.
I do have C code (gcc and VC6.x) which is maybe 30 lines long that is
accurate within about a minute a day, but it's copyrighted. You won't
understand it anyway!
Why are you being such a jerk? Seems you just top posted yourself!
Maybe you don't like this discussion 'cause your head is where the sun
don't shine!
Robert Green
> Since the application appears to be for the control of lighting to
> compensate for the setting of the Sun, ISTM that the difference between
> a clear and a very cloudy day will be far more important. On a clear
> day in winter (when the Sun sets more slowly) the amount of natural
> light well after Sunset can be, or seem, as great as that during an
> extended noontime thunderstorm.
>
> To control lighting, one needs a photocell rather than a clock.
Eureka! That's *clearly* the solution to this particular problem for a
number of reasons, including the very important one you've noted about
cloudy and clear days. A photocell will work during eclipses, darkened
skies from weather events and will automatically adjust for leap times, DST
legislation changes, immense volcanic dust clouds and even nuclear winters.
It takes very little code to implement, too, which was an important goal of
the OP. I suppose you could encode it in a single bit for night or day.
Photocells will also be immune to errors that can cause the microprocessor's
internal clock to get out of synch with real time, however you define it.
(-: More than once I've missed the AM/PM flag when setting a clock and had
timed lights come on during the day instead of at night; I am sure others
have, too.
There are, of course, reasons why the OP couldn't use a photocell to detect
true sunrise and sunset events, but I'd suspect they'd be very special
geographical cases, not likely to be found in Detroit, except, maybe for
Hell Night.
IMHO, extreme accuracy in an HA light timer is probably more of a liability
than an asset, at least in giving an impression of being "lived in" when the
house is empty. Some HA timers, like the X-10 mini-timer allow for the
selection of pseudo-random turn-on times so bad guys "casing the joint"
might not think the lights are being controlled by computer. Photocells
induce a similar randomness to on/off times, and as you point out, more
closely mirror actual natural light conditions.
The issues raised in this thread are certainly interesting, but many have no
real pertinence to the OP's original request. It's an interesting proof of
the theory: Go to a carpenter, get a hammer solution and so on.
There are a few instances where photocells could be problematic, especially
if they are not well shielded from sources of strong artificial lights, but
it really does seem they are the ideal solution for the OP's problem. FWIW,
I've often come to Usenet with solution A in mind only to be convinced that
solution B or C would be far more effective.
--
Bobby G.
Chris L Peterson
<ROBERT_G...@YAH00.COM> wrote:
>Eureka! That's *clearly* the solution to this particular problem for a
>number of reasons, including the very important one you've noted about
>cloudy and clear days.
Too little information to determine that. Yes, detecting the actual
ambient lighting is clearly a very good way to control artificial
lighting. But implementing that can be difficult if the controller is
physically far from the outside. Perhaps the controller in this case is
located in a basement housing the lighting controls? There may be good
reasons that a photocell isn't being considered here.
J Miller
by itself, might not work!
For one, what's the interface to the controller? You got a varying
resistance, and you must code for it's meaning.. (and actually interface
it!) the fact that the resistance goes high or low does not indicate
light/dark, unless you look at it over time. (ie, someone could have
walked in front of the photocell and it could be "dark" for 30 seconds..
does this indicate dark and cause all the outdoor lights to come on?
Sunrise/dawn is also another interesting time.. What does the photocell
see then? is it any different than a car passing by with it's lights
on? (need to take the value over time to see if it's "really dark" and
not something blocking the photocell..)
A photocell is the $9 home depot solution to the problem! A "smart" HA
solution can do things like only pay attention to inside motion sensors
between dusk and dawn, and not be fooled if a cloud passes by. Doesn't
mean that lights cant be turned on at other times by using the wall switch!
That's why the OP talked about +/- 5 minutes for sunset.. Doesn't need
to be exact, but "about right"
Real example.. My HA system knows sunrise/sunset/time etc.. On cloudy
days, I might hit the wall switch to turn on the lights. The lights
will stay on.. But after sunset, if there's no motion detected in the
room (yup, I left the lights on and went off to do something else..),
they'll turn off, until someone comes back into the room..
The real thing here, is the OP was looking for a SIMPLE way to determine
sunset based on Jdate and lat/long within about 5 min - yet this has
turned into a discussion about "leap seconds" and photocells!
Go back to the title of the thread "Simple Calculation of Sunset Time
required"
J Miller
You guys clearly don't really understand the application. How would you
hook a photocell to the computer on your desk? That's what the OP is
talking about. He wants his computer to know when it's dark (based on
the position of the sun) without interfacing a photocell!
If someone comes to your desk to chat, will the photocell tell the
computer it's dark? Only if they are there for more than 5 minutes?
Another real case.. I want my outside lights to come on at sunset and
stay on until 11pm. What I don't want is my outside lights to come on
at 2pm because it's cloudy, and then go off 10 minutes later because the
clouds have passed. Then come on again at 3:15 and off at 3:20, etc...
What if the photocell says "dark" at 6pm? Is that a cloud or is it past
sunset? Could be either based on the time of the year! A real HA
system will prevent the "daytime flickers" and only turn the lights on
when it is after sunset!
You guys like your leap seconds, etc, but you'll also be the first ones
on the phone to customer support if your HA system kept turning on your
outside lights during the day because it was cloudy! "but, but, a
photocell should handle it!"
oriel36
> You guys like your leap seconds, etc, but you'll also be the first ones
> on the phone to customer support if your HA system kept turning on your
> outside lights during the day because it was cloudy! "but, but, a
> photocell should handle it!"- Hide quoted text -
>
> - Show quoted text -
This thread demonstrates that the super stable system you and
everyone else here inherits from astronomical timekeeping principles
is barely understood by some and severly mangled by others,the most
cretinous example being the belief that the Earth's rotation makes a
'bad clock'.The exquisite thinking of my astronomical ancestors never
implied axial rotation could be tied to clocks as an observed
motion,they just adaprted the pre-Copernican Equation of Time
principles which create the average 24 hour day and transfered it to
axial rotation as a convenience and not as an observation.
The core principles allow as much flexibility as possible,make your
leap adjustments, geographically re-arrange the timezones boundaries
(within reason),apply DST ect but it all hinges on knowing that where
the 24 hour cycle comes from and how it was adapted to the daily cycle
and terrestrial longitudes as an inviolate correlation - 24 hours/360
Deg.This stable system never invokes a direct correlation to observed
axial rotation and to think it does is not the reasoning of an
intelligent person yet many believe it does -
"Leap seconds are necessary because time is measured using stable
atomic clocks (TAI or International Atomic Time), whereas the rotation
of Earth slows down continually, though at a slightly variable rate.
Originally, the second was defined as 1/86400 of a mean solar day (see
solar time). This is determined by the rotation of the Earth around
its axis and its orbit around the Sun; time was measured by
astronomical observations."
http://en.wikipedia.org/wiki/Leap_second
Your reasoning is intellectually insipid whereas that of 'astronomers'
here is downright toxic.Not even the treatise of Huygens appears to
remove the pretension of axial rotation tied directly to celestial
sphere geometry and while you may not understand it,it is causing
enormous problems on different fronts.
Paul Schlyter
That's not a problem. If the sky is clear, it's some 100 times darker
at sunset than at full daylight. But lights need not be turned on right
at sunset - one can wait until the Sun is some 3 degrees below the horizon,
and then th light level is some 1000 times darker than at full daylight.
A very dark cloud otoh will bring down the ambient illumination by only
a factor of 10 or so. Thus, a properly adjusted photocell which turns
on the light when the Sun is a few degrees below the horizon on a clear
day (somewhat earlier on a cloudy day) will NOT turn on the light just
because a dark cloud passes by. Unless the cloud is extremely thick and
dark (e.g. a tornado cloud), but then you might WANT the light turned
on.
>What if the photocell says "dark" at 6pm? Is that a cloud or is it past
>sunset?
If properly adjusted, the photocell should not say "dark" because a cloud
passes by, if he Sun is well above the horizon. See above.
>Could be either based on the time of the year! A real HA
>system will prevent the "daytime flickers" and only turn the lights on
>when it is after sunset!
>
>You guys like your leap seconds, etc, but you'll also be the first ones
>on the phone to customer support if your HA system kept turning on your
>outside lights during the day because it was cloudy! "but, but, a
>photocell should handle it!"
Robert Green
news:l32qr3hknssu3rs4s...@4ax.com...
> On Wed, 20 Feb 2008 23:36:42 -0500, "Robert Green"
> <ROBERT_G...@YAH00.COM> wrote:
>
> >Eureka! That's *clearly* the solution to this particular problem for a
> >number of reasons, including the very important one you've noted about
> >cloudy and clear days.
> Too little information to determine that. Yes, detecting the actual
> ambient lighting is clearly a very good way to control artificial
> lighting. But implementing that can be difficult if the controller is
> physically far from the outside. Perhaps the controller in this case is
> located in a basement housing the lighting controls? There may be good
> reasons that a photocell isn't being considered here.
When I hear hoofbeats, I tend to think horses rather than zebras. I doubt
anyone "into" home automation couldn't string two wires from their
controller to an outside window or location. That skill kind of goes with
the territory. That means I would rank the possibility of "no access to
natural light" very low in a formal requirements analysis, unless we know
for sure the OP lives in a mineshaft. Most people don't, though. I am sure
there are some automators I don't know of who can't string cable, but for
them, there are low cost RF solutions. As for the actual requirements,
TomCee told us:
<<My application is that I have an automation controller that has a
calendar, can do calculations (including trig), but is rather memory
limited. Thus I would like to calculate time of sunset 'on the fly' rather
than store the data table. . . . I would like accuracy to within 5
minutes; preferably biased towards the negative so that if anything, the
lights would turn on early, rather than late.>>
Which makes me curious as to why would you think we have too little
information to assume he wants to turn lights on and off via an automation
controller at dawn and dusk? I pulled the above information from two of
TomCee's posts, FWIW. It seems the requirements are pretty straightforward
and *very* suitable for a photocell controller.
Something as simple as an X-10 Hawkeye sensor and an X-10 transceiver can do
the job for under $30 without any wires, assuming his controller can speak
X-10. That's what I use and it works quite nicely. Implementing a wired
photocell might cost all of $10, and if you have some wire lying around,
perhaps as little as a buck.
Since he's got an automation controller, he could install and poll multiple
sensors to help insure that a single photocell isn't reacting to some
artificial light source. It may be that some bytes might have to be used to
"damp" the photocell's response so that only a true drop or rise in natural
light triggers the night/day flag, but it wouldn't be many.
I readily agree that if the underlying requirement is to have lights come on
at a precise time, then a photocell is NOT the right tool. But it seems as
if the OP (and indeed most "automators") want external lights to come on in
response to either motion or an absence of natural light so no one trips on
the stairs and fractures their skulls.
Mr. Stockton's photocell solution covers very nasty, dark days when extra
light may be very much needed. The calculator solution does not. It's not
likely someone wanting to turn lights on and off at dusk and dawn, and who
is concerned about total memory usage in his automation controller gains as
much benefit from using a dawn/dusk calculator as he might from a simple
photocell. Programmers and other technically inclined people are often so
beguiled by working out the details of a complex solution that they overlook
the simpler and far more elegant one. Sometimes simple is better.
Considering all the equipment that goes haywire in my house when DST arrives
or leaves, I'd also have to add that calculating a sunrise/sunset time is a
lot more prone to error than a photocell system. As an automator,
reliability is of the utmost importance to me and I'd rather not have to
futz with my light control code every time the Feds decided to change DST
rules or I moved. The photocell solution covers both those cases as well
as the "dark skies" case with ease. The calculator version does not. Those
factors alone made it a no-brainer for me to use a photocell. Unless the OP
lives in a concrete-walled bunker without a masonry drill, I suspect he
would realize the same benefits as I do using a photocell to control the
lights. (-:
--
Bobby G.
Robert Green
> Chris L Peterson wrote:
> > On Wed, 20 Feb 2008 23:36:42 -0500, "Robert Green"
> > <ROBERT_G...@YAH00.COM> wrote:
> >
> >> Eureka! That's *clearly* the solution to this particular problem for a
> >> number of reasons, including the very important one you've noted about
> >> cloudy and clear days.
> >
> > Too little information to determine that. Yes, detecting the actual
> > ambient lighting is clearly a very good way to control artificial
> > lighting. But implementing that can be difficult if the controller is
> > physically far from the outside. Perhaps the controller in this case is
> > located in a basement housing the lighting controls? There may be good
> > reasons that a photocell isn't being considered here.
> >
> > _________________________________________________
> >
> > Chris L Peterson
> > Cloudbait Observatory
> > http://www.cloudbait.com
>
> You guys clearly don't really understand the application. How would you
> hook a photocell to the computer on your desk? That's what the OP is
> talking about. He wants his computer to know when it's dark (based on
> the position of the sun) without interfacing a photocell!
I think you should re-read the OP's posts. TomCee was definitely discussing
an automation controller with very limited memory, not a desktop PC. He
wants to turn lights on and off based on dawn and dusk. Automation
controllers have input and output lines where you attach devices like
photocells. Common sense dictates the photocell be placed where it does NOT
get exposed to artificial light sources. Someone capable of programming the
complex equations we've seen into his automation controller wouldn't have
too much trouble figuring out how to programmatically evaluate the output of
a photocell so that it only registered long term light changes and not
"passing clouds."
--
Bobby G.
Chris L Peterson
<ROBERT_G...@YAH00.COM> wrote:
>When I hear hoofbeats, I tend to think horses rather than zebras. I doubt
>anyone "into" home automation couldn't string two wires from their
>controller to an outside window or location.
First of all, I have no idea if this is a home automation project. The
OP may be a consultant, setting up a commercial control system. And as
located, it is perfectly possible that accessing an outside sensor could
be a problem (I can tell you from personal experience that getting wires
run from inside a building to outside can be a huge problem with
facilities managers). Besides that, many industrial controllers do not
have analog inputs on them at all, which means adding external circuitry
or buying an expensive industrial module in order to detect the actual
light levels. So like I said: too little information to recommend a
photocell as the "best" solution.
Actually, we do have one very good piece of information here: the OP is
looking for a mathematical solution to the problem. I prefer to assume
that he knows the most about his own application, and has already
decided that a calculated sunset time suits his requirements best.
Androcles
| On Thu, 21 Feb 2008 05:50:32 -0500, "Robert Green"
| <ROBERT_G...@YAH00.COM> wrote:
|
| >When I hear hoofbeats, I tend to think horses rather than zebras. I
doubt
| >anyone "into" home automation couldn't string two wires from their
| >controller to an outside window or location.
|
| First of all, I have no idea if this is a home automation project. The
| OP may be a consultant, setting up a commercial control system.
Second of all, he may be a clod like you.
Rodney Blackall
something to switch on at dusk and off at dawn.
1. There is a big difference in "lighting up time" between clear evenings
/mornings and cloudy ones which will be tricky to program in.
2. There are optical sensors which will cope with the task of switching when
the ambient light level crosses a preset threshold without recourse to
correcting for leap seconds.
--
Rodney Blackall (retired meteorologist)(BSc, FRMetS, MRI)
Buckingham, ENGLAND
Using Acorn SA-RPC, OS 4.02 with ANT INS and Pluto 3.03j
Bill Kearney
> There are, of course, reasons why the OP couldn't use a photocell to
> detect
> true sunrise and sunset events
Yeah, like the device isn't exposed to the outside and there's no wiring
leading out to a photocell. Tell the device the location, the date and let
it do the calculating. Quite simple.
42
"tomcee" <tomce...@yahoo.com> wrote in message
news:24b3d18e-ac7f-46e9...@j28g2000hsj.googlegroups.com...
> Given a table of sunset times, such as:
>
> Day # Sunset (H:M):
> --------- ----------
> 1 17:10
> 2 17:11
> . . .
> 180 20:21
> ...
> 365 17:10
>
> and plotting this data (of course converting H:M to Decimal hours), we
> get a somewhat sinusoidal relationship between the Day and time of
> Sunset: Sunset = f(Day); or more specifically: Sunset = f(A*sin(k*D-
> P) This of course is not a pure sinusoid. Observation shows that it
> has a significant 2nd harmonic component.
>
> My application is that I have an automation controller that has a
> calendar, can do calculations (including trig), but is rather memory
> limited. Thus I would like to calculate time of sunset 'on the fly'
> rather than store the data table.
>
> number. I would like to keep it simpler than the generic formula
> given latitude and longitude. I would like the formula from the
> tabular data.
>
> It appears to have the form:
>
> Sunset = K + A1*sin(k*D-P1) + A2*sin(2*k*D-P2) + ???
> Where:
> D = Day number
> K, A1, A2, k, P1, P2 are constants determined by Long/Lat.
>
> Has anyone determined the basic functions contained within this
> 'Sunset function'? Given the basic functions, I can then calculate the
> constants.
> Thanks in advance for your help,
> TomCee
Do you really need to know the time of Sunset or do you just need to do
something when the Sun sets?
If it's the latter, just use a photocell.
Just my $0.02
Andrew Gabriel
tomcee <tomce...@yahoo.com> writes:
> OG:
> Thanks for asking; I had intended to mention this in my original
> post. I would like accuracy to within 5 minutes; preferably biased
> towards the negative so that if anything, the lights would turn on
> early, rather than late.
If it's for lighting, use a photocell switch.
That will compensate for cloud/clear skies, etc.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
oriel36
> > If it's for lighting, use a photocell switch.
> > That will compensate for cloud/clear skies, etc.
>
> or wiring through a facility to get one connected.
>
> Likewise useless if the software wants to introduce something like a
> randomizer that adjusts the time before full sun rise/set. As in, turn the
> lights on X random minutes before expected sunset, and vice versa off after
> sun rise.
And this,my good man,is why the topic brought in so many people
insofar as the problem may look simple but the resolution is far from
being so .The Earth does not suddenly develop a 366 day orbit every
4th year and although you may believe that software has the priority
in determining the geostationary terms of sunrise/sunset or the
heliocentric view of axial and orbital motions of the Earth,the fact
of the matter is that software will highlight that timekeeping
astronomy is not in line with structural astronomy in a serious
way,specifically with a calendrical twist.
Had anyone paid attention to what Huygens wrote,they would have
received the outlines of an answer -
"Here take notice, that the Sun or the Earth passeth the 12. Signes,
or makes an entire revolution in the Ecliptick in 365 days, 5 hours 49
min. or there about, and that those days, reckon'd from noon to noon,
are of different lenghts; as is known to all that are vers'd in
Astronomy."
AND
"In the morning then, when the Sun is just half above the Horizon,
note, what hour, min. and sec. the Watch points at, if it be going; if
not, set it a going, and put the Indexes, at what hour, min. and sec.
you please. Let them goe till Sun-set, and when the Body of the Sun is
just half under the Horizon, see, what hour, min. and sec. the Indexes
of the Watch point at......,"
http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html
The orbital motion of the Earth is referenced off a system of 365 days
5 hours 49 minutes whereas the people who have to adjust their softwae
for a leap year ( in determining sunrise/sunset) are working off a
system of 3 years of 365 days and 1 year of 366 days.Huygens
references axial rotation within the orbital period of 365 days 5
hours... therefore you can actually create a software program that
recognises the geostationary terms of sunrise/sunset and its
heliocentric equivalent of axial and orbital motions using the
central Sun and only the Sun as a eference (not the stellar
background)
I do not find fault with anyone for staying away from this particular
astronomical Gordian knot but the resolution is pretty much the same -
split timekeeping astronomy from structural astronomy and do not
allow the former to dictate the latter.
Using a photocell would require tracking the last detected time
> (and presumably storing it). A simple device might have calcuation
> abilities, but little or no storage.
Robert Green
> On Thu, 21 Feb 2008 05:50:32 -0500, "Robert Green"
> <ROBERT_G...@YAH00.COM> wrote:
>
> >When I hear hoofbeats, I tend to think horses rather than zebras. I
> > doubt anyone "into" home automation couldn't string two wires from
> > their >controller to an outside window or location.
(I came back to this thread because I woke up today to find a significant
number of clock-enabled devices to be reporting the wrong time because of
DST. That issue alone highlights the significant benefit of the photocell
method, especially if the goal is simply to turn the lights on when dark and
off when there's daylight.)
>
> First of all, I have no idea if this is a home automation project.
Well, one important clue to consider would be the cross-posting to a *home
automation* newsgroup. (-:
> The OP may be a consultant, setting up a commercial control system.
He may also be the town crier, a dawn/dusk researcher, a Druid, the clock
setter for his local church or a zebra. (-: Even if this *is* a commercial
application, the photocell would work just as well. For example, many
streetlights have operated for years and years with nothing but a photocell
controller. They're used in such applications because they are incredibly
simple (and therefore incredibly reliable), they are immune to DST law
changes and can provide light in unexpectedly dark conditions, such as a
severe thunderstorm.
When your goal is providing light only when it's dark, isn't it better to
know when it IS dark rather than what time it is?
With photocells properly pointed skyward as they are on streetlights, they
don't experience false activations from passing cars, although a hovering
helicopter with a "nightsun" searchlight might set them off. But that would
be another of those pesky zebras - a possibility so remote it requires only
passing acknowledgement, even in a thorough systems analysis.
> And as located, it is perfectly possible that accessing an outside sensor
> could be a problem (I can tell you from personal experience that getting
> wires run from inside a building to outside can be a huge problem with
> facilities managers).
Now we've moved from zebras to unicorns, an even less likely source of
hoofbeats. To rule out the photocell solution, you have to add some severe
additional caveats that are indeed possible, but just aren't likely given
what we already know. First, you have to assume that this a commercial
application. Then you have to posit a cranky facilities manager and a
windowless environment. Possible? Of course. So is a direct asteroid hit
on his house. The question still is: are those hoofbeats we're hearing
horses, zebras or unicorns?
We have the OP's introductory remarks about the severe memory limitations of
the controller. That doesn't sound like an industrial controller to me, but
yes, it's possible those hoofbeats are zebras. The "can't run a wire to the
outside" is another special case scenario because for it to be a real
concern requires the OP to live in a dark, cavernous building. More
importantly it requires believing that running a two conductor cable to a
place that receives natural light to be a Herculean task, not one that
telecom and CATV jockeys with one month's experience do every day in homes
across the world. Another zebra, if you will. I'm afraid it's not very
likely given what we know about the world in general or this particular OP.
> Besides that, many industrial controllers do not have analog inputs on
> them at all, which means adding external circuitry or buying an expensive
> industrial module in order to detect the actual light levels.
Most of your reservations thus far are predicated on the unlikely assumption
that this is a commercial operation (the zebra). Once you've got one zebra,
it's quite easy to build a corral and turn it into a herd. One unlikely
constraint path can lead to a host of limitations that seem valid, but have
little to do with the actual system requirements or operational environment.
If you've already convinced yourself "an expensive industrial module" is
needed for your industrial control system it means the zebras are breeding.
Even if this were a commercial application, there are any number of ways to
very inexpensively detect dawn and dusk and generate a contact closure that
wouldn't require an analog controller input. It would be a "no brainer" for
the home automation controllers I am most familiar with: HomeVision, the
Ocelot, and the X-10 CM15A. It might be a little harder with others. Since
we know without question the OP's controller memory is severely limited, the
photocell solution preserves that precious memory for other uses and
operations that can't be performed as elegantly as a photocell.
> So like I said: too little information to recommend a photocell as the
"best" solution.
Only if you're adding in zebraic assumptions that drastically change the
original nature of the beast. It seems that we're now automating a
commercial establishment (with a tyrannical facilities manager who harbors
profound anti-wire sentiments) when the OP, who gave us some pretty detailed
constraints, never said a word about those possibilities.
> Actually, we do have one very good piece of information here: the OP is
> looking for a mathematical solution to the problem.
We actually have many more pieces than that (see OP's quote below). But for
argument's sake, even if "the mathematical solution" were the only piece of
good information we have, does that mean that the photocell idea was
previously reviewed and discarded by the OP? Of course not. Ironically,
it's on THAT issue that we have too little information. It could just as
easily be that the OP didn't think of photocells. He might simply have
failed to consider implementation issues (the very dark and rainy sunrises
and sunsets mentioned by JR Stockton) that formula-based solutions simply
can't deal with.
I say this based on the number of times I've come to Usenet with Solution X
in mind only to find out that there were better, far easier solutions Y and
Z to be had. I recall going to a tool group and asking how to sharpen a
spade bit I was using to drill through joists only to learn that I should be
using a Forstner bit. Just today I learned that there's a NEW kind of spade
bit with cutting ears that cuts as well as a Forstner bit but is quite a bit
cheaper. That sort of stuff happens to everyone, all the time. Having one
solution in mind doesn't mean that all the bases have been covered
thoroughly. Often, it means precisely the opposite.
If I were creating a requirements document out of what we already know, I
would consider the approach the OP/client has initially chosen as a solution
far less important than the problem he wants to solve within the constraints
he's outlined. I'd also consider his memory limitations and look for the
most memory-efficient solution. That's another mark in the plus column for
a photocell. It takes very little code to implement. No code, no testing.
No code, no updating required if DST changes. Automation controllers need
reliability, not complex code subject to bugs, typos, programming errors,
controller reset issues, synchronization issues, law changes, etc.
> I prefer to assume that he knows the most about his own application, and
> has already decided that a calculated sunset time suits his requirements
best.
That's an interesting assumption, but that's all it is, and I'll explain
why. Since he hasn't commented or mentioned the photocell in any posts or
replies, it's equally valid to assume that he may not have thought about
using a photocell. It took a rather long time in this discussion before
either Mr. Stockton or I realized it might be a good idea. I prefer to
think that the OP might have done the same and simply overlooked the
photocell solution since he already had a solution in mind. That's the
infamous "go to a carpenter, get a hammer diagnosis" problem of having a
solution in mind locking out other, possibly superior solutions. Since
we're injecting our preferences into the requirements analysis, I prefer to
think he might not been aware of the many benefits of the photocell
approach.
Plenty of smart people get wrapped around the axle trying to figure out a
complex solution when a much simpler one will do. Legend has it that Ben
Franklin cut two small doors in his house to allow his two cats, one large,
one small, to enter and exit at will. When he saw both cats using the large
door, he realized his error. Examine TomCee's own words closely against the
assumptions you've made and perhaps you'll see why I think the issues raised
about commercial operations or inability to reach natural light with a pair
of wires are zebras.
<<My application is that I have an automation controller that has a
calendar, can do calculations (including trig), but is rather memory
limited. Thus I would like to calculate time of sunset 'on the fly' rather
than store the data table. . . . I would like accuracy to within 5
minutes; preferably biased towards the negative so that if anything, the
lights would turn on early, rather than late.>>
Home automation group posting, memory limits, turning lights out, preferring
lights to turn on early. These are the hoofbeats of horses, not zebras!
(-: If you want to control electric lights to be on when it's dark and off
when it's daylight, it makes lots more sense to detect actual dark and
daylight and not compute dates.
--
Bobby G.
OG
"Robert Green" <ROBERT_G...@YAH00.COM> wrote in message
news:C_qdnVArQ4su4Ena...@rcn.net...
I can see what you mean but the OP did ask for a computational solution for
a problem.
.
If I were addressing this professionally I'd write a list of requirements,
constraints and assumptions.
Amongst the requirements would be 'to compute the time of sunset'.
Amongst the constraints would be 'limitation on memory'.
I would NOT include amongst the assumptions 'the problem can be solved by a
light sensor'
I may ask for clarification of the 'requirements', but if the client states
that a computational solution is needed I would not 'assume' that (s)he is
mistaken in her/his requirements.
Chris L Peterson
<ROBERT_G...@YAH00.COM> wrote:
>(I came back to this thread because I woke up today to find a significant
>number of clock-enabled devices to be reporting the wrong time because of
>DST.
That's fine. Nobody would disagree that actually looking at the light
level will provide the best results. But the OP asked for a mathematical
approach, and that may be because monitoring the light level isn't an
option.
In fact, you can do quite well with a clock. The solution in an
automation controller is very simple: you don't worry about DST at all.
Internally, you simply maintain standard time, or even UT. Your devices
that had problems this morning were devices that were designed to
display civil time- not a requirement of a lighting controller.
_________________________________________________
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com
--
Posted via a free Usenet account from http://www.teranews.com
Marc_F_Hult
<C_qdnVArQ4su4Ena...@rcn.net>:
>"Chris L Peterson" <c...@alumni.caltech.edu> wrote in message
>news:uj3rr31pi2sv5f9u5...@4ax.com...
>> On Thu, 21 Feb 2008 05:50:32 -0500, "Robert Green"
>> <ROBERT_G...@YAH00.COM> wrote:
>>
>> >When I hear hoofbeats, I tend to think horses rather than zebras. I
>> > doubt anyone "into" home automation couldn't string two wires from
>> > their >controller to an outside window or location.
>
>(I came back to this thread because I woke up today to find a significant
>number of clock-enabled devices to be reporting the wrong time because of
>DST. That issue alone highlights the significant benefit of the photocell
>method, especially if the goal is simply to turn the lights on when dark
>and off when there's daylight.)
About eight years ago I was asked to design and install a lighting system
for an indoor native fresh-water fish stream/aquarium at an Audubon Nature
Center. To keep the organisms happy, the lighting was needed to mimic
natural daylight.
I considered using a digital microcontroller and calculated values. I
concluded that the limiting factor on accurate lifespan with a
non-networked uC or PC was going to be the long-term accuracy of the
real-time clock and, even for networked controllers, the life of the clock
battery. I didn't want to be in the business of servicing the device or to
have it "fail". So I chose an analog route.
I hooked up a Panasonic PNA4603H light sensor
http://rocky.digikey.com/WebLib/Panasonic/Web%20data/PNA4603H.pdf
to a Crydom 10PCV2450 analog-input solid-state dimmer.
http://www.crydom.com//userResources/productFamilies/50/crydom_pcv.pdf
through a simple home-brew op-amp buffer to adjust signal offset, span and
gain.
The setup was a success because it required no maintenance on the part of
the Nature Center staff. It just works. And it was (I assume!) smart enough
to 'account' for the solar eclipse in 2002 and is ready for 2012. Unless
someone paints over the sensor or causes some other situation that I would
consider 'breaking' it, the arrangement will continue working
no-fuss/no-muss as long as the lamps that the device dims are replaced when
they burn out.
HTH ... Marc
Visit my ongoing Home Automation and Electronics Internet Porch Sale at
www.ECOntrol.org/porch_sale.htm
Marc_F_Hult
www.ECOntrol.org
Robert L Bass
>
> I would NOT include amongst the assumptions 'the problem can be solved by a
> light sensor'
>
> I may ask for clarification of the 'requirements', but if the client states
> that a computational solution is needed I would not 'assume' that (s)he is
> mistaken in her/his requirements.
Then you'd miss the opportunity to discuss other possible solutions, some of
which might actually prove more useful to the client.
--
Regards,
Robert L Bass
==============================>
Bass Home Electronics
4883 Fallcrest Circle
Sarasota · Florida · 34233
http://www.bassburglaralarms.com
Sales & Tech Support 941-925-8650
Customer Service 941-232-0791
Fax 941-870-3252
==============================>
Jim Thompson
<Rober...@verizon.net> wrote:
>"OG" wrote:
>>
>> I would NOT include amongst the assumptions 'the problem can be solved by a
>> light sensor'
>>
>> I may ask for clarification of the 'requirements', but if the client states
>> that a computational solution is needed I would not 'assume' that (s)he is
>> mistaken in her/his requirements.
>
>Then you'd miss the opportunity to discuss other possible solutions, some of
>which might actually prove more useful to the client.
I'm located down in a "notch" between two hills. I use a photocell
with a collimating tube to "watch" the streetlight which has a
photocell WAY higher than I can get ;-)
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
America: Land of the Free, Because of the Brave
oriel36
wrote:
> In article
> <098282f1-920d-465d-b968-c318e2b74...@p25g2000hsf.googlegroups.com>,
> oriel36 <geraldkelle...@yahoo.com> wrote:
>
> > Ah look,a meteorologist !.
> > .Using the motions of the Earth,explain what causes hemispherical
> > weather patterns (seasons), it should be a breeze for a retired guy
> > with all those impressive titles behind his name.It is all tied up in
> > this discourse on timekeeping,geocentric observations and their
> > geomotive resolutions,namely the axial and orbital motions of the
> > Earth.
>
> Just the sort of polite greeting I should have expected! Do you mean to
> write that you don't know why it is warmer in the summer hemisphere (that's
> the one where the sun gets highest about the horizon during the day) than
> the winter one?
>
> Did you know that that it is the Earth's angular momentum that is conserved?
> If the zonal (i.e. E-W or W-E) wind component in the atmosphere gets
> seriously away from the average then the length of "the day" is changed?
>
Sounds to me that you are trying to impress others but then again they
do not seem to mind.
When you extract the lessons learned from the motions and orientations
of Uranus and apply the same principles to Earth,there is a brand new
orbital component to explain variations in daylight/darkness and
variations in the natural noon cycle.
http://asymptotia.com/wp-images/2007/08/uranus_rings.jpg
I am no longer astonished that the enjoyable logic which goes into
extracting the new orbital component is not being discussed openly,too
many old minds unable to adapt and content to remain teachind outdated
concepts.The new motion answers the question as to how the Equatorial
rings change wrt to the Sun while its axial orientation remains
pointed in one direction in space thereby prohibiting the use of
'variable axial inclination' as a means to explain the seasons.
In this era,people place great stock in technological development and
care nothing about why we experience daylight/darkness or seasonal
variations in the length of both.Judging by this thread here,not a
single response even came close to a perspective using the motions of
the Earth insofar as such things are no longer required in a souless
technological society.In your jaded mind,there is no need to leave the
idea of variable axial inclination because it would change nothing in
regard to the technological progress of humanity and as you can see
from this thread,had I said the Earth was flat it would just about
have as much impact as proposing that the Earth's has a new orbital
component where a location turns slowly through 360 degrees wrt the
Sun in 365 days 5 hours 49 minutes quite apart from axial rotation.
Spare me a jaded and predictable response.
> > Chances are that you will vanish rather than answer the simple
> > question.
>
> Chances are I shall not respond to rude remarks.
Robert Green
> On Sun, 9 Mar 2008 20:13:46 -0400, "Robert Green"
> <ROBERT_G...@YAH00.COM> wrote:
>
> >(I came back to this thread because I woke up today to find a significant
> >number of clock-enabled devices to be reporting the wrong time because of
> >DST.
>
> That's fine. Nobody would disagree that actually looking at the light
> level will provide the best results. But the OP asked for a mathematical
> approach, and that may be because monitoring the light level isn't an
> option.
I can't count the times as a database consultant, people came to me with
hopelessly overloaded spreadsheets, looking for me to produce a "better"
spreadsheet solution. The proper solution, of course, was conversion to a
database where the data and the manipulation functions were easily separated
and managed. Ironically, the evolution of this thread is pretty conclusive
proof that a "starting solution" takes on a life of its own, often to the
detriment of discovering far better solutions. I mean no insult to you or
the OP. I'm describing something I often find myself guilty of: getting
locked into a particular approach too early on in the process.
We can wonder why the OP chose a mathematical approach, but when those "may
be's" become probablistically unlikely, it should immediately trigger
recall of the med school chestnut: "When you hear hoofbeats, think horses,
not zebras."
Whether it's called the principle of parsimony or Occam's Razor or
methodological reductionism, the bottom line is to "make no more assumptions
than needed to solve the problem." What number would you assign to the
probability that the OP can't reach daylight easily?
In the case, the reason to dismiss photocells needs to be compelling since a
light sensor is so much better suited for determining light levels than a
calendar. If the OP had made an overwhelmingly strong statement such as "I
have to use a clock system because I live in a mineshaft" I might seriously
entertain the "can't reach daylight easily" scenario. The problem is that
when I follow the mineshaft exception more closely, I find myself asking:
"If the OP lives so far removed from natural light that he can't see or
reach it, why is he worried about turning those far away outside lights on
and off?" It doesn't make a lot of sense and so it becomes a zebra.
Plenty of people go to their doctor hoping herbs or a special diet will cure
their prostate cancer. However, a responsible specialist probably would not
assume herbal remedies to be the best treatment simply because the patient
asked for it.
Client-directed outcomes are usually not as successful as solution-focused
ones because clients *typically* don't have a large knowledgebase of
alternate solutions to draw from. Just as often, they have not done the
detailed, essential environmental surveys beforehand. I have seen that
happen so many times I assume it to be the norm, not the exception.
I once had an otherwise intelligent research library director insist that
books should be recorded in their new relational database with all the
information about a book in one big free-form field. This person believed
that their "Ask Sam" database program would be able to produce a monthly
overdue list or an acquisitions report from such a contraption. However
unrealistic the request, it gave me some clues about what a final solution
shout look like. It told me that the director wanted the freedom to add a
lot of notes to each record in a free-form style and they were looking for
system that was structured in a way similar to the database program
mentioned previously. No matter how much the director wanted that "one
field" solution, it was so unworkable that no caveat could justify its
implementation.
Our current case is obviously not as clear cut. Still, there was a great
deal of discourse concerning some very tangential issues before better
information emerged. The initial direction of the thread and subsequent
discussion bypassed the essential constraints of the task. The clock
solution to "sensing" light and dark is wrong for so many reasons that the
OP's asking for it doesn't overcome its many negatives. It's far more
reasonable to assume that he chose it without realizing other, better
options that than he previously reviewed and discarded the photocell
solution, especially in light of how long it took the whole group to reach
its two "AHA!" experiences.
> In fact, you can do quite well with a clock. The solution in an
> automation controller is very simple: you don't worry about DST at all.
> Internally, you simply maintain standard time, or even UT.
That's an excellent observation, Chris, and it makes my point about the
possibility of very bright people quite regularly missing very obvious and
simple solutions. How long did it take for a group of obviously quite
intelligent people to note that DST "know how" isn't even required for this
app? You've made the case that it's much more likely the OP just overlooked
photocells. The probability that he considered and discarded that idea, at
least to me, seems much less likely. This isn't a slam at anyone, it's just
how "things be." There are some problems with UT - the programmer has to
remember to use UT and not "civil time" when setting up the light controls
and the UT system is not immune to clock drift or failure.
Look at all the explanations people have for how the Easter Islanders got
their giant moai to the beaches from their quarries.
http://www.pbs.org/wgbh/nova/easter/move/past.html
Once a solution path is defined, it takes on a life of its own. Doctors,
allegedly the best and brightest among us, are just as prone to locking in
solutions too early. It took a bulldog Aussie research team to break the
incredible resistance to the idea the Heliobacter caused ulcers, not stress.
http://nobelprize.org/nobel_prizes/medicine/laureates/2005/press.html
How much discussion has there been here about DST compensation and
programming issues when, as you've shown us, it really was virtually
irrelevant to the problem? Smart people often get lost in the weeds. As a
result, it frequently takes some "quiet time" and conversational exchange
before the proper solution emerges. IMHO, that's one of the greatest
strengths of the WWW: allowing this sort of interaction and collaboration.
Just last week, as a friend was helping me drill holes for some new cable,
he got out his fancy laser level that projects bright laser lines to lay out
the job. However, a recent thread in CHA reminded me of a much easier way
to do it. By the time he had gotten his laser tool unpacked and powered up,
I had tacked a length of clothesline along the joists and in 30 seconds we
were done. The high tech solution would have take 10 times as long because
the line is not very long so we would have to move it along the joists one
at a time. Worse, yet, that sort of method would be far inferior because
the multiple small measurements would magnify any drift errors. But the
laser light level is SO fascinated my friend that he made a very cogent case
for using it while I finished marking off the lines on the joist. Sometimes
higher tech solutions are a lot of fun, but when reliability is required,
simple is almost always better.
> Your devices
> that had problems this morning were devices that were designed to
> display civil time- not a requirement of a lighting controller.
My devices were suffering from some of the many maladies that can strike
clock-based control systems. My experience tells me that a simple photocell
will be several orders of magnitude more reliable than any of the code
examples we saw, just based on standard program reliability metrics (which I
believe is something like 25 bugs per 1000 lines of code). Anyway, there
are some remarkable cases of very simple program errors creating serious
problems here:
http://www5.in.tum.de/~huckle/bugse.html
worth considering when comparing the reliability of X number of lines of
micro-controller code for a calendar solution to the simplicity of a
photocell solution. Clocks can (and do) get out of synch with real time,
sidereal, solar or however you define it. Photocells can't.
A photocell solution saves much more memory than a calendar system, and we
know that's a very clear goal of the OP. But the most important difference
between solutions is that a photocell provides actual information about real
light and darkness. That's a fundamental goal in automating lights. You
want the electric lights on when it's dark, off when it's light. Even a UT
solution, as ingenious as it is(!), can't match the reliability and utility
of using a light sensor to determine light and dark. Clocks get out of
synch for many, many reasons. Photocells don't. Clocks can't tell when
environmental conditions warrant an earlier "ON" or "OFF" time. Photocells
can.
--
Bobby G.
Chris L Peterson
<ROBERT_G...@YAH00.COM> wrote:
>Whether it's called the principle of parsimony or Occam's Razor or
>methodological reductionism, the bottom line is to "make no more assumptions
>than needed to solve the problem." What number would you assign to the
>probability that the OP can't reach daylight easily?
There's no way to know. Anything would be just a guess. In a home
situation, reaching daylight is probably fairly easy. In a commercial
environment, it could be very difficult (the controller could easily be
installed in a control room, and there could be many restrictions on
running wires).
Another possibility is that the OP already has a controller, and it
doesn't have any kind of input supporting a light sensor. Many
controllers can't accept that sort of input.
In the end, my interpretation of parsimony is that the OP asked for a
particular solution to the problem (and got some good answers).
Paul Schlyter
However:
In article <g5CdnfAIbv7bG0fa...@rcn.net>,
Robert Green <ROBERT_G...@YAH00.COM> wrote:
>How much discussion has there been here about DST compensation and
>programming issues when, as you've shown us, it really was virtually
>irrelevant to the problem? Smart people often get lost in the weeds. As a
>result, it frequently takes some "quiet time" and conversational exchange
>before the proper solution emerges. IMHO, that's one of the greatest
>strengths of the WWW: allowing this sort of interaction and collaboration.
This isn't the WWW, it's Usenet! Usenet predated the WWW by several
decades....
Robert Green
news:63jermF...@mid.individual.net...
>
> "Robert Green" <ROBERT_G...@YAH00.COM> wrote in message
> news:C_qdnVArQ4su4Ena...@rcn.net...
>
> I can see what you mean but the OP did ask for a computational solution
for
> a problem.
I thought it obvious from the way two solutions developed (the photocell
posited by Mr. Stockton and the realization that DST is irrelevant by Mr.
Peterson) that it's often very easy to start out with an approach to a
problem that eventually turns out to be unsuitable. The OP may have
suggested a calendar/computational based approach but his real requirements
were stated within the discussion, and those were simply to turn the lights
on at dusk and off at dawn.
Based on how slowly the photocell and UT approaches emerged from a rather
large group of people, many with profound home automation experience, I
believe it's very likely the OP picked the solution he was most familiar
with and ran with it. Client-directed solutions are almost never as good as
problem-based solutions. To that end, a photocell is a better light sensor
than a calendar and lots simpler, too. It doesn't seem good science to lock
oneself into a single approach and then ride it out to the bitter end simply
because that was where you chose to start.
> If I were addressing this professionally I'd write a list of requirements,
> constraints and assumptions.
Ah, but Usenet hardly ever gets that far, and worse, still, the requirements
are often added to by follow-on posters in ways that the OP never intended
until people are offering suggestions totally unrelated to the OP's initial
post. For example, someone in this thread began talking about the OP
turning on lights via his PC when no such requirement had appeared before.
I think the best we can hope for is that even with the wrong starting
vector, the discussion eventually gets around to the range of solutions
available and an analysis of the pros and cons of each.
As for this discussion, I was responding to the contention that we didn't
have enough facts to solve the problem, which I believed to be incorrect.
The constraints that have been raised (i.e. inability to run a sensor to
daylight or that the OP *only* wants a computational solution) are not
terribly likely. Why? Well, because anyone who wants to control lights
around his home is not likely living in a bunker or a mine shaft. Based on
experience, most home automators want the simplest, most reliable light
control method available.
Certainly there could be reasons the OP does not want to solve the problem
effectively, reliably or simply. Perhaps he enjoys tinkering with his
processor and writing code for it and that's the major reason for this
undertaking. But if the real problem is what he's described: "lights on
when dark, off at dawn" a photocell out-performs a calendar solution in
nearly every dimension. It's a solution used commercially because it's so
simple and reliable. It's immune to:
1) synchronization problems
2) relocation problems (moving north or south changes the problem
parameters)
3) errors working in UT as opposed to civil time
4) programming errors
and more importantly, it's able to turn the lights on early when weather
conditions substantially reduce daylight.
These "pluses" make the universe of people who absolutely *must* use a
calendar or lookup table very small indeed. The reasons suggested why the
OP must stick with his original computational approach begin to look very
much like the zebras I've been yammering about. (-"
> Amongst the requirements would be 'to compute the time of sunset'.
Why compute it if you can sense it? I think you've already fallen into the
"first solution looked at" trap if you believe that there's truly a
computational requirement to turning on the lights when its dark out. I can
imagine *some* applications where the computation of exact values for
sunrise and sunset might be required, but the "specs" the OP gave us clearly
say he wants to turn on the lights at dusk and off at sunrise. The only
computational requirement for such a task is a single logical variable that
can tell the controller: "is it day or night out?"
> Amongst the constraints would be 'limitation on memory'.
We agree on that, and that's another area where a photocell excels. A
single logical variable of Day or Night has to be several orders of
magnitude more reliable and memory efficient than 100 lines of program code
and dozens of variables for a microcontroller.
> I would NOT include amongst the assumptions 'the problem can be solved by
a
> light sensor'
Then I think you'd be short-changing your client in the mode of "when the
only tool a carpenter owns is a hammer, everything looks like a nail"
instead of getting the best fit for the job. I can only go by my own
experiences but many more times than I can count I came to Usenet with one
solution in mind only to find out after my initial post I was way off base.
More experienced people were able to convince me to abandon a solution I had
a lot of psyche invested in and implement the correct one.
So far, no one has presented a case for calendars much stronger than "it's
what the OP wants" or the even more unpersuasive "he may be unable to reach
daylight." I contend it's just as likely the calculation solution was simply
the first one he thought of. I don't see how that imparts a great sanctity
to that approach, particularly considering how badly a calendar light
control compares to a sensor that can read actual light levels.
If someone presented some strong and probable reasons why a clock/calendar
based solution is superior to one that measures the actual light levels, I
might change my opinion. So far, I remain pretty unmoved by the suggestions
that someone who's programming their own home automation system is unable to
string two wires to a place that "sees" natural light.
I'm even less impressed by claims that since this is the approach the OP
chose to open discussion of the issue, it has to be respected above the far
simpler, more reliable and more functional photocell solution. It almost
seems as if you're saying that if the OP starts with a bad choice, he's
somehow constrained to stay with it, even after learning of solutions that
are superior in many respects.
> I may ask for clarification of the 'requirements', but if the client
states
> that a computational solution is needed I would not 'assume' that (s)he is
> mistaken in her/his requirements.
"Mistaken" is a pejorative sort of word and implies that the client made an
error by simply choosing to start somewhere. I've prefer to think that he
was merely unaware of the much simpler photocell solution, as were many
people here for many days (myself included) until Mr. Stockton suggested it.
The additional "AHA!" experience that Chris provided of the controller only
needing to work with UT and not DST was another example of how good
solutions often evolve away from the original specifications.
--
Bobby G.
OG
Sorry Bobby,
Your post makes so many assumptions as to 'what the user wants' that it
makes me wince.
Look at the cases where the OP responded
- once to my post which asked about precision required
- once when discussing the lookup table to give the time using just 366
bytes.
Don't you think that the OP's lack of response to the AHA! 'experience' to
the UT/DST issue might be significant?
Don't you think that the OP's lack of response to the 'photocell '
solutions might be significant?
I think it's just about possible that the OP want's a solution for 'Sunset
Time' just like the OP stated in the OP.
OG
> "Chris L Peterson" <c...@alumni.caltech.edu> wrote in message
> news:du69t3do37dq3sea0...@4ax.com...
>
>> level will provide the best results. But the OP asked for a mathematical
>> approach, and that may be because monitoring the light level isn't an
>> option.
>
> I can't count the times as a database consultant, people came to me with
> hopelessly overloaded spreadsheets, looking for me to produce a "better"
bloody professionals -
>
> We can wonder why the OP chose a mathematical approach, but when those
> "may
> be's" become probablistically unlikely,
It would be interesting to know from where you derived these "may be"
factors, they weren't in the OP's posts, nor in his responses. Maybe the
'maybe's' were in other people's posts.
> it should immediately trigger
> recall of the med school chestnut: "When you hear hoofbeats, think horses,
> not zebras."
There's a whole continent where this is a bloody stupid chestnut - but US
and Europoean med school students tend to be 'conventionally clever' rather
than truly intelligent thinkers.
> Whether it's called the principle of parsimony or Occam's Razor or
> methodological reductionism, the bottom line is to "make no more
> assumptions
> than needed to solve the problem." What number would you assign to the
> probability that the OP can't reach daylight easily?
What on earth makes you think the OP wants anything other than the Time of
Sunset? It's what he asked for.
As for the rest of your post - forgive me, I started scanning it, but it
kinda assumed that what you wrote at such length was actually worth reading.
If you want to write a synopsis, I'll have a go at that.
Paul Schlyter
Robert Green <ROBERT_G...@YAH00.COM> wrote:
>So far, no one has presented a case for calendars much stronger than "it's
>what the OP wants"
So what DOES the OP want?
Does the OP still read this discussion? If so, OP, what do you want,
and why? Please tell us....
If the OP no longer follows the discussion, why do we even still discuss
this ?????
Robert Green
message
<stuff snipped>
> I'm located down in a "notch" between two hills. I use a photocell
> with a collimating tube to "watch" the streetlight which has a
> photocell WAY higher than I can get ;-)
I would think a diffused dome reflector like those used on photographic
light meters pointed straight up would work in your situation, but your
solution is still a lot simpler than calculating dates. It also provides
light whenever the streetlamp controller decides to provide light, so it's
probably going to compensate for extremely overcast and rainy days.
I've been examining the nightly log of controller events and its very clear
that a photocell is no slave to absolute sunrise and sunset times. Rainy,
cloudy skies affect the total ambient illumination quite noticeably.
The X-10 Hawkeyes may not be good for much, but they do a very reliable job
of sensing sunrise and sunset. Better still, I didn't have to run any wires
because it's RF. I just have to remember to change batteries every two
years. Pretty good deal considering most of my Hawkeyes came free during
the great "X-10 Voucher" days.
--
Bobby G.
Robert Green
news:TgjBj.20622$Ls6.12913@trnddc01...
> "OG" wrote:
> >
> > I would NOT include amongst the assumptions 'the problem can be solved
by a
> > light sensor'
> >
> > I may ask for clarification of the 'requirements', but if the client
states
> > that a computational solution is needed I would not 'assume' that (s)he
is
> > mistaken in her/his requirements.
>
> Then you'd miss the opportunity to discuss other possible solutions, some
of
> which might actually prove more useful to the client.
Precisely. If a client came to you worried about burglars breaking in
through the windows and wanted to apply window foil to all of them, how much
weight should you give his particular approach to the problem as opposed to
the correct solution: glass break dectors?
Of course, he might very possibly have have good reasons to want to foil
every window in his house. He might like the appearance, or believe visible
foil to be a deterren. He might have cases of foil on hand or he may want a
glass break sensor that consumes very little standby power. But most likely
it was the first solution that came to mind.
The reasons I've suggested for needing foil would be those mythical zebras
because they are not very likely be the reason for his spec'ing foil. A
good consultant would immediately see the client's taken a bad initial
approach and remind him of all the problems that come with window foil
technology while explaining the many benefits of the newer technology.
--
Bobby G.
oriel36
wrote:
> Based on how slowly the photocell and UT approaches emerged from a rather
> large group of people, many with profound home automation experience, I
> believe it's very likely the OP picked the solution he was most familiar
> with and ran with it. Client-directed solutions are almost never as good as
> problem-based solutions. To that end, a photocell is a better light sensor
> than a calendar and lots simpler, too. It doesn't seem good science to lock
> oneself into a single approach and then ride it out to the bitter end simply
> because that was where you chose to start.
>
Funny,funny,funny !.
52000 years ago,my astronomical timekeeping ancestors were building
monuments representing knowledge of the 365 day 5 hour 49 minute
annual; cycle
http://www.mythicalireland.com/ancientsites/newgrange/illumination.html
Today,5200 years later, I watch all the participants here dither
around with the calendrical cycle of 3 years of 365 days and 1 year
of 366 days and not know the difference between the core system based
on the difference between the axial daily cycle and the aorbital
annual cycle.
The great men of antiquity could reason out the components needed to
light up the internal chamber based on fixing the annual cycle to Dec
21st and developing a monument to reflect it,Later civilisations
created the core structure which creates the 24 hour cycle out of
variations in the natural noon cycles but today,my fellow human beings
refuse to recognise the core structure which keeps cl;ocks in sync
with the daily cycle at 24 hours/360 degrees -
http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html
What have you done to yourselves when the proposed value is shifted to
an unbelievable value of 23 hours 56 minutes 04 seconds insofar as
nobody bother to check Flamsteed's proof for the assertion .I am
absolutely bewidered that this technologically advanced race cannot
grasp the most basic tenets of timekeeping and structural astronomy
making this generation,which extends from the late 17th century to the
present,as the most uncivilised group ever to set foot on the
planet,the bulk of the errors can be expressed in a single and awful
graphic -
http://upload.wikimedia.org/wikipedia/commons/1/1d/Tiempo_sid%C3%A9reo.en.png
The fact is that none of you could build a monument like Newgrange
owing to your adherence to a calendrically based perspective and as
Newgrange is one of the oldest known building on the planet,it tell
everyone here just how far we have descended as a race.
Robert Green
> <ROBERT_G...@YAH00.COM> wrote in message
> >"Chris L Peterson" <c...@alumni.caltech.edu> wrote in message
> >news:uj3rr31pi2sv5f9u5...@4ax.com...
> >> On Thu, 21 Feb 2008 05:50:32 -0500, "Robert Green"
> >> <ROBERT_G...@YAH00.COM> wrote:
> >>
> >> >When I hear hoofbeats, I tend to think horses rather than zebras. I
> >> > doubt anyone "into" home automation couldn't string two wires from
> >> > their >controller to an outside window or location.
> >
> >(I came back to this thread because I woke up today to find a significant
> >number of clock-enabled devices to be reporting the wrong time because of
> >DST. That issue alone highlights the significant benefit of the
photocell
> >method, especially if the goal is simply to turn the lights on when dark
> >and off when there's daylight.)
>
> About eight years ago I was asked to design and install a lighting system
> for an indoor native fresh-water fish stream/aquarium at an Audubon Nature
> Center. To keep the organisms happy, the lighting was needed to mimic
> natural daylight.
>
> I considered using a digital microcontroller and calculated values. I
> concluded that the limiting factor on accurate lifespan with a
> non-networked uC or PC was going to be the long-term accuracy of the
> real-time clock and, even for networked controllers, the life of the clock
> battery. I didn't want to be in the business of servicing the device or to
> have it "fail". So I chose an analog route.
If reliability is an essential requirement, simpler solutions almost always
trump the more complex. In your application, as in the OP's, precise on and
off times are not required so the calculated value method doesn't provide
enough benefit to outweigh the potential problems you've described.
I had been scratching my head trying to think of lighting applications that
demanded a calculated approach and your example brought to mind one of the
few cases where a photocell won't do. If you had been asked to mimic the
lighting requirements of an animal from near the North or South Poles, the
calculated method would really be your only option.
When it's simply a matter of "lights on when it's dark, off at sunrise" I
believe as you do: a photocell will likely prove to be exceptionally more
reliable than a calculated solution. That's in addition to its ability to
provide light when it's unusually dark out because of heavy cloud cover.
--
Bobby G.
oriel36
wrote:> > <ROBERT_GREEN1...@YAH00.COM> wrote in message
I like exposing squirming pretension.
The answer to this 'problem' is found in Huygens by reworking the
sunrise/sunset observation which centralises natural noon in order for
the Equation of Time correction to be applied or indeed,as Huygens
notes, can be used to determine central natural midnight (as opposed
to the convenience of civil midnight).
http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html
The thread was specifically an astronomical solution,albeit a
geocentric sunsrise/sunset one and it shows just how limited
astronomical timekeeping knowledge is among this present
generation,almost astrological in its flavor.Go ahead and vanish,a
technologically advanced race is hardly the be all and end all
considering what it chooses to believe where matters of intutive
intelligence or 'wisdom' is required.You can get away with pretension
in a forum which displays more of the same but ultimately this thread
has exposed exactly what we have become as a species.
Astronomy is still there for people who are genuine and sincere
despite the pretension which now surrounds it from all sides,it is
there for those who have outgrown the gadgets of modern society and
wish to venture into the arena where astronomers once travelled in
timekeeping and structural astronomy based on the Earth's motions or
even further back to the great timekeeping astronomers.
Good thread this one,it shows the standard between intutive and
inventive intelligence is probably at its widest point ,the former in
a wretched state while the latter fairly advanced.
> I had been scratching my head trying to think of lighting applications that
> demanded a calculated approach and your example brought to mind one of the
> few cases where a photocell won't do. If you had been asked to mimic the
> lighting requirements of an animal from near the North or South Poles, the
> calculated method would really be your only option.
>
> When it's simply a matter of "lights on when it's dark, off at sunrise" I
> believe as you do: a photocell will likely prove to be exceptionally more
> reliable than a calculated solution. That's in addition to its ability to
> provide light when it's unusually dark out because of heavy cloud cover.
>
> --
> Bobby G.- Hide quoted text -
>
> - Show quoted text -
Chris L Peterson
<ROBERT_G...@YAH00.COM> wrote:
>I had been scratching my head trying to think of lighting applications that
>demanded a calculated approach and your example brought to mind one of the
>few cases where a photocell won't do.
This isn't a lighting application, but I use the calculated times of
civil twilight to determine when to automatically start and stop my
meteor cameras. The conditions that would cause differences in actual
light levels for a given time aren't important in my case: if it gets
dark earlier because of clouds, there's generally no advantage to
starting an allsky camera earlier!
Mxsmanic
> Precisely. If a client came to you worried about burglars breaking in
> through the windows and wanted to apply window foil to all of them, how much
> weight should you give his particular approach to the problem as opposed to
> the correct solution: glass break dectors?
HUH?
Non breakable windows maybe?
--
____________________
Alric Knebel
http://www.ironeyefortress.com/C-SPAN_loon.html
http://www.ironeyefortress.com
Robert L Bass
>
> Today,5200 years later, I watch all the participants here dither around
> with the calendrical cycle of 3 years of 365 days and 1 year of 366 days
> and not know the difference between the core system based on the difference
> between the axial daily cycle and the aorbital annual cycle.
Do you think any of that really matters to the person who asked for help with
his home automation system?
--
Regards,
Robert L Bass
==============================>
Bass Home Electronics
4883 Fallcrest Circle
Sarasota · Florida · 34233
http://www.bassburglaralarms.com
Sales & Tech Support 941-925-8650
Customer Service 941-870-2310
Fax 941-870-3252
==============================>
John J. Bengii
collision and as long as they do not experience a microwave or other noise
and as long as they actually sense something (half mine (6) were garbage on
arrival)
"Robert Green" <ROBERT_G...@YAH00.COM> wrote in message
news:AMydncv0IdFOLUba...@rcn.net...
oriel36
> oriel36 <geraldkelle...@yahoo.com> wrote:
> >[...incoherent rant excised...]
> >I am absolutely intrigued by the ability to ignore the greatest known
> >astronomical timekeeping mistake,the most fundamental correlation is
> >all timekeeping astronomy and men are off by a margin of roughly 3
> >minutes 56 seconds !.
>
> Not quite sure what your point is,
Of course you are not sure what my point is because you have an
illness,a genuine disability to grasp basic astronomical principles
such as the unequal natural noon cycle.You get the point of the
following graphic which affirms your illness -
http://upload.wikimedia.org/wikipedia/commons/1/1d/Tiempo_sid%C3%A9reo.en.png
Alter any component is that graphical fiction and it disintegrates
including your belief that the noon cycles are 24 hours exactly.
but the OP doesn't care about the
> sidereal day. To know what time the sun sets, you need care about only
> the solar day; which does, indeed, have a mean value of 24 hours.
The calculations of sunrise/sunset are based on the Ra/Dec calendrical
offshoot which means you are using the sidereal day framework
anyway.The system which creates the average 24 hour cycle and keeps
these cycles elapsing seamlessly into the next cycle is based on a 365
day 5 hours 49 minute system while you creatures work off a 3years of
365 days and 1 year oif 366 days.
You do not know what my point is,indeed !,a bunch of cretins who
cannot turn on a porchlight using an easy to understand Equation of
Time system ebvven with the whole treatise by Huygens in front of you
-
"Here take notice, that the Sun or the Earth passeth the 12. Signes,
or makes an entire revolution in the Ecliptick in 365 days, 5 hours 49
min. or there about, and that those days, reckon'd from noon to noon,
are of different lenghts; as is known to all that are vers'd in
Astronomy. Now between the longest and the shortest of those days, a
day may be taken of such a length, as 365 such days, 5. hours &c. (the
same numbers as before) make up, or are equall to that revolution: And
this is call'd the Equal or Mean day, according to which the Watches
are to be set; and therefore the Hour or Minute shew'd by the Watches,
though they be perfectly Iust and equal, must needs differ almost
continually from those that are shew'd by the Sun, or are reckon'd
according to its Motion."
http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html
I have to suffer a cretinous viewpoint ,even in its geocentric
form,where the Sun has an actual motion corresponding to 24 hours
exactly in order to justify axial rotation in 23 hours 56 minutes 04
seconds,a perspective that is so chronically bad that only a person
with an illness could not get the point.
Do you get this point?, the most stupid,the most ridiculous group of
people ever to set foot on the planet in astronomical matters can
justify axial rotation through 360 degrees in 23 hours 56 minutes 04
seconds,not even the creationists reach that level of stupidity.I
would prefer to believe that you have a severe inte;llectual
disability because the other option is unthinkable.
Robert L Bass
>
> Of course you are not sure what my point is...
Oh, that one is easy. You're a troll.
[plonk]
oriel36
> "oriel36" wrote:
>
> > Of course you are not sure what my point is...
>
> Oh, that one is easy. You're a troll.
>
> [plonk]
>
> --
>
> Regards,
> Robert L Bass
>
Being roughly 3 minutes and 56 seconds off for the value of axial
rotation through 360 degrees is no joke and the fact that there is an
organisation (IERS) in existence to maintain that terrible error makes
it even worse.This is what happens when a technologically advanced
society loses touch with the intutive intelligence needed to
appreciate timekeeping and structural astronomical principles.
How difficult is it to acknowledge that the 24 hour cycle is a product
of the natural noon cycle via a correction known as the Equation of
Time which keeps the 24 hour day fixed to natural noon and
subsequently is the reason why the 24 hours of Monday elapse into the
24 hours of Tuesday.This is basic stuff that nobody should dispute
unless they suffer from a severe intellectual disability.
The next part is even easier to grasp.When Copernicus discovered that
axial rotation is the cause of the daily cycle,they adapted the
Equation of Time creation of the 24 hour day and transfered it to
axial rotation as a 'constant' thereby allowing 4 minutes of clock
time to represent 1 degree of longitudinal/geographical seperation
making 24 hours/360 degrees.They never needed an external reference
for keeping clocks in sync with terrestrial longitudes and the daily
cycle at 24 hours/360 degrees ,it was just assumed that axial rotation
is constant as a convenient principle rather than a direct
observation.
Then Flamsteed came along and adopted a strange position of tying
axial rotation directly to the return of a star in 23 hours 56 minutes
04 seconds obligating an explanation for where the missing 3 minutes
56 seconds goes\.They came up with this monstrosity which has the
natural noon cycles at 24 hours exactly -
http://upload.wikimedia.org/wikipedia/commons/1/1d/Tiempo_sid%C3%A9reo.en.png
It is though an enormous joke has been played on humanity and it is no
longer funny.I could understand it if the actual principles which
create the 24 hour cycle out of the natural noon cycle were difficult
to understand but they are a joy to behold as seen in the treatise of
Huygens.The intricate transfer of the 'average' 24 hour cycle to
'constant' axial rotation is probably the only intricate point where
people can get lost but a little familiarity demonstrates the genius
of the timekeeping astronomers.
The framework Newton built on is of course the 'sidereal time' one
borrowed from Flamsteed which has an astrological core and exists
only in the imagination.I don't know how long people intend to keep
the proper principles which link clocks to terrestrial longitudes and
the daily cycle at 24 hours/360 degrees but being roughly 3 minutes
56 seconds off is perhaps the worse condition a person can find
themselves in and really unhealthy.
Easy to rip Newton's agenda asunder but that is not the point,a lot of
productive work is going unattended while that monstrosity of a
framework prevails.It is as much for the benefit of dynamicists as
anyone else but so far all they do so far is cling to the coatails of
the late 17th century numbskull who never spotted the error in
Flamsteed's reasoning.
> ==============================>
> Bass Home Electronics
> 4883 Fallcrest Circle
> Sarasota · Florida · 34233http://www.bassburglaralarms.com
Marc_F_Hult
<ROBERT_G...@YAH00.COM> wrote in message
<LqednXNW3IMqIkba...@rcn.net>:
>"Marc_F_Hult" <MFH...@nothydrologistnot.com> wrote in message >
>> About eight years ago I was asked to design and install a lighting system
>> for an indoor native fresh-water fish stream/aquarium at an Audubon Nature
>> Center. To keep the organisms happy, the lighting was needed to mimic
>> natural daylight.
>>
>> I considered using a digital microcontroller and calculated values. I
>> concluded that the limiting factor on accurate lifespan with a
>> non-networked uC or PC was going to be the long-term accuracy of the
>> real-time clock and, even for networked controllers, the life of the clock
>> battery. I didn't want to be in the business of servicing the device or to
>> have it "fail". So I chose an analog route.
>> I hooked up a Panasonic PNA4603H light sensor
>> http://rocky.digikey.com/WebLib/Panasonic/Web%20data/PNA4603H.pdf
>> to a Crydom 10PCV2450 analog-input solid-state dimmer.
>> http://www.crydom.com//userResources/productFamilies/50/crydom_pcv.pdf
>> through a simple home-brew op-amp buffer to adjust signal offset, span and
>> gain.
>> The setup was a success because it required no maintenance on the part of
>> the Nature Center staff. It just works. And it was (I assume!) smart
>> enough to 'account' for the solar eclipse in 2002 and is ready for 2012.
>> Unless someone paints over the sensor or causes some other situation that
>> I would consider 'breaking' it, the arrangement will continue working
>> no-fuss/no-muss as long as the lamps that the device dims are replaced
>> when they burn out.
>If reliability is an essential requirement, simpler solutions almost always
>trump the more complex. In your application, as in the OP's, precise on and
>off times are not required so the calculated value method doesn't provide
>enough benefit to outweigh the potential problems you've described.
>
>I had been scratching my head trying to think of lighting applications that
>demanded a calculated approach and your example brought to mind one of the
>few cases where a photocell won't do. If you had been asked to mimic the
>lighting requirements of an animal from near the North or South Poles, the
>calculated method would really be your only option.
>
>When it's simply a matter of "lights on when it's dark, off at sunrise" I
>believe as you do: a photocell will likely prove to be exceptionally more
>reliable than a calculated solution. That's in addition to its ability to
>provide light when it's unusually dark out because of heavy cloud cover.
Note that the analog installation I settled on was not ON-OFF, because that
would not have met the requirements. The light incident on the stream table
ramps up imperceptibly from OFF in the morning and dims to OFF in the
evening. Heavy cloud cover can cause the light to dim during daylight hours.
The latter cannot be calculated based on time alone because it depends on
weather, not time. In that sense, it is 'better' than a calculated solution,
not just an expedient substitute.
Your point about mimicking a non-local environment is well taken. Doing this
as well as a with the local analog solution I outlined would a hybrid
approach, perhaps substituting local for remote weather effects, or using a
statistical/stochastic (not deterministic) component. There are also other
approaches for remote simulation with rapidly increasing complexity. (A
remote webcam comes to mind.)
Robert Green
> On Fri, 14 Mar 2008 09:55:58 -0400, "Robert Green"
> <ROBERT_G...@YAH00.COM> wrote:
>
> >Whether it's called the principle of parsimony or Occam's Razor or
> >methodological reductionism, the bottom line is to "make no more
assumptions
> >than needed to solve the problem." What number would you assign to the
> >probability that the OP can't reach daylight easily?
>
> There's no way to know. Anything would be just a guess. In a home
> situation, reaching daylight is probably fairly easy. In a commercial
> environment, it could be very difficult (the controller could easily be
> installed in a control room, and there could be many restrictions on
> running wires).
There are clues in what he's told us. There's a clue in his choice to also
post his question in the computer.home.automation group. I'm sorry but I
don't see any reason to assume he's a automating a commercial establishment.
I think those are biases being injected that really have no basis in the
facts we already know. You've heard hoofbeats and interpret them as zebras.
I say that because the OP never gave us any reason to believe he was
automating a store or factory with what he's already described as an
under-powered automation controller. He has, however, given us good reason
to believe this a "home automation" project by posting in the home
automation group. When you don't have a lot of facts, you have to make
reasonable use of the ones you do have. The principle of parsimony.
But all of that is irrelevant, really, because the photocell solution is so
far superior to the calculated version in so many dimensions. You would use
a calculated method only if you wanted to emulate a different diurnal cycle
than your current location or you lived in a mineshaft. We know the first
is not true because of the OP's own words. The second not being true is
just a damn good guess because few of us know *anyone* who lives in a crypt
that can't reach daylight with a pair of wires. In other words, you're
hearing hoofbeats and thinking zebras.
> Another possibility is that the OP already has a controller, and it
> doesn't have any kind of input supporting a light sensor. Many
> controllers can't accept that sort of input.
Name two. No home automation controller I am familiar with is so limited in
its abilities (especially those that can do trig functions, which we know
the OP's can perform), that they can't accept a simple binary input, even if
it means multiplexing an existing input. Once again, it's a zebra because
it's so unlikely to be the case that he can talk to all his household lights
(with X-10 or some other HA protocol, one must assume) but be unable to
accept any inputs. It's a near perfect example of hearing hoofbeats and
thinking zebras. The fact that the OP never returned might easily be
because after Mr. Stockton made his photocell post, the OP realized he was
on the wrong track and spent $20 on an X-10 Sundowner controller or a X-10
Hawkeye motion sensor with a built in photocell. No wires required, either!
> In the end, my interpretation of parsimony is that the OP asked for a
> particular solution to the problem (and got some good answers).
But not the best answers, and that's the primary issue here. He
artificially narrowed his solution universe prematurely by asking for too
specific a solution. He also asked it of a group that would be predisposed
to give an astronomically related answer. Go to a carpenter, get a hammer
solution, go to an astronomer, get an astronomical solution. That's what I
am trying, somewhat unsuccessfully, to get across. I found myself surprised
at how long it took for someone like me, with an HA predisposition, to
realize that the calculated solution had some serious drawbacks. It's easy
to get drawn into the flow of the discussion, even if it's going in the
wrong direction. (-:
Are you sure you are not injecting your own preferences here? Is it really
logical to assume that someone asking for help doing something he has
(apparently) never done before (automating lights to dawn/dusk) would have
the correct answer right out of the starting gate? These are all questions
of probabilities and I believe we can logically assume from what the OP has
told us that:
1) He's not automating a commercial establishment
2) He does not live in a windowless mineshaft, crypt or bunker
3) He was probably unaware of the superiority of the photocell solution over
the calculated one when he first posted.
It's obvious that I put more weight in the correct solution to the problem
than I do in the OP's proposed solution. I base that assumption on the OP
needing help solving the problem in the first place. If he knew all
solution paths beforehand, he probably wouldn't be asking about calculated
solutions. I also believe that he innately knew that the solution universe
could be larger than his particular calculated approach and that's why he
hedged his bets by cross-posting in to CHA.
A lot of unlikely constraints have to align in order for the calculated
solution to even come up equal to the photocell for this task, let alone
surpass it. I'm not the OP, but I am always thankful when someone points
out the best solution to a problem and not just the one I asked for. In
CHA, that happens quite frequently because the technology changes so
rapidly.
--
Bobby G.
Robert Green
news:fregbc$1vld$1...@merope.saaf.se...
> Thanks for your long and illuminating post!
You're welcome. (-: If I wanted to make people <groan> I'd add "I hoped I
shed some light on the problem!" <groan!>
> However:
>
> In article <g5CdnfAIbv7bG0fa...@rcn.net>,
> Robert Green <ROBERT_G...@YAH00.COM> wrote:
>
> >How much discussion has there been here about DST compensation and
> >programming issues when, as you've shown us, it really was virtually
> >irrelevant to the problem? Smart people often get lost in the weeds. As
a
> >result, it frequently takes some "quiet time" and conversational exchange
> >before the proper solution emerges. IMHO, that's one of the greatest
> >strengths of the WWW: allowing this sort of interaction and
collaboration.
>
> This isn't the WWW, it's Usenet! Usenet predated the WWW by several
> decades....
Yes, this particular exchange is occurring on Usenet, but the collaboration
of people around the world takes place in many other venues as well. That's
why I thought the more inclusive term WWW was appropriate. Perhaps the term
"internet" would have been more taxonomically accurate.
Last month I learned about adhesive-filled (a.k.a. dual wall) heat shrink
tubing from a Yahoo HomeVision automation controller group user. It's great
for anyone who needs to install solder-type sensors in outdoor environments.
I imagine that includes astronomer/engineer types with their own
observatories. Now I wouldn't use anything else for even general soldering
because it adds a extra layer of protection.
Pardon that excursion but the point is that Yahoo certainly isn't Usenet by
any stretch of the imagination yet it serves a similar, collaborative
function. For me, that group and a number of others form a part of my
"team" of specialists that I can call on when I get stuck and who advance my
knowledge of the world on a daily basis.
Now, granted, I'm not fond of writing things that Yahoo owns, I much prefer
Usenet for a variety of reasons except one: net psychos. The sad truth is
that unmoderated Usenet groups have notoriously poor psycho control
mechanisms. As a result, a lot of people who don't want to put up with
random abuse by anonymous nimrods, pimple-faced pizzwits and troglodyte
trolls chose other venues. So places like Yahoo and web-based "interaction"
mechanisms are beginning to proliferate. The biggest problem I've found
with those lately is that organizations like MS apparently pay employees to
talk up their products so the information found there is likely to be more
suspect than what survives in the fiery crucible of Usenet.
So maybe I should have said 'Internet' instead of 'WWW,' but I think you get
the drift. Collaborative efforts abound, from IM to mailing lists to web
based forums and not just on Usenet.
--
Bobby G.
oriel36
> But not the best answers, and that's the primary issue here. He
> artificially narrowed his solution universe prematurely by asking for too
> specific a solution. He also asked it of a group that would be predisposed
> to give an astronomically related answer. Go to a carpenter, get a hammer
> solution, go to an astronomer, get an astronomical solution. That's what I
> am trying, somewhat unsuccessfully, to get across. I found myself surprised
> at how long it took for someone like me, with an HA predisposition, to
> realize that the calculated solution had some serious drawbacks. It's easy
> to get drawn into the flow of the discussion, even if it's going in the
> wrong direction. (-:
>
> Are you sure you are not injecting your own preferences here? Is it really
> logical to assume that someone asking for help doing something he has
> (apparently) never done before (automating lights to dawn/dusk) would have
> the correct answer right out of the starting gate? These are all questions
> of probabilities and I believe we can logically assume from what the OP has
> told us that:
> Bobby G.
This squirming pretension and dribbling about hoofbeats has only
exposed that you can't even get a geocentric sunrise/sunset solution
let alone its equivalent based on the axial and orbital motions of the
Earth.
You want to talk like a child then I will treat you like one.I will
even reduce it to geocentric terms.
The solution is latitude dependent meaning that the values for
sunrise/sunset differ North and South of the Equator and subsequently
differ for any given location.There is no one-size-fits-all
astronomical solution,it must be adapted for each latitudinal
situation.Civil timekeeping does not take this into account.
The next component is the unequal length of the total day using the
natural noon cycle as a benchmark,it is a totally different
astronomical conception to variations in daylight/darkness yet is
linked using the same mechanism based on the relationship between
axial rotation and the change in orbital orientation with respect to
the Sun.
To turn on a porchlight using calaculated values based on sunrise/
sunset,the opposite procedure of creating the 24 hour cycle is
required as Huygens describes -
"In the morning then, when the Sun is just half above the Horizon,
note, what hour, min. and sec. the Watch points at, if it be going; if
not, set it a going, and put the Indexes, at what hour, min. and sec.
you please. Let them goe till Sun-set, and when the Body of the Sun is
just half under the Horizon, see, what hour, min. and sec. the Indexes
of the Watch point at, and note them too; and reckon, how many houres
&c. are Pass'd by the Watch between the one and the other: which is
done by adding to the Evening-Observation the hours, &c. that the
morning-Observation wanted of 12. or 24. in case the Hour-hand hath in
the mean time pass'd that hour once or twice; otherwise the difference
only gives the time. Then take the half of that number, and add it to
the hours, &c. of the morning-Observation, and you shall have the
hours, &c. which the Watch did show, when the Sun was in the South;
whereunto add the Aequation in the Table belonging to that day, and
note the summe. Then some days being pass'd (the more the better) you
are to doe Iust the same: And if the hour of the last day be the same,
that was noted before, your Watch is well adjusted; but if it be more
or less, the difference divided by the number, elapsed between the two
Observations, will give the daily difference."
http://www.xs4all.nl/~adcs/Huygens/06/kort-E.html
Substitute porchlight for 'clock' in the last sentence and you get
what you want even without having to delve into what is occuring to
produce the effects via the axial and orbital motions of the Earth
using the Sun as a benchmark.
No doubt you will hear hoofbeats running away from the astronomical
solution but I am certain that you will be among them.
Robert Green
<much stuff snipped>
> Sorry Bobby,
> Your post makes so many assumptions as to 'what the user wants' that it
> makes me wince.
Well quoting 1578 words of text to add a dozen lines of comment made me
wince. Does that make us even? (-:
> Look at the cases where the OP responded
> - once to my post which asked about precision required
> - once when discussing the lookup table to give the time using just 366
> bytes.
That's not surprising. At that point he was still locked into, and debating
the nuances of the wrong solution and no one but Mr. Stockton ever thought
to question otherwise. Groupthink at its very best. Ask yourself why he
wanted to know when the sun rose and set. Not to set a watch, not to aim a
celestial camera, not to brush his bleeding gums but to turn on the lights
when it got dark, and off when it was light.
If I felt threatened by my assessment of his needs, I'd quote him again, but
I'm not. Re-read with a view as to the most elemental of his "system
requirements" and you'll discover it's really simply to turn his lights on
at night and off during the daytime. The precision you're talking about is
simply what happens in a "solution lock." People proceed to the details
without exploring all possible options. Remarkably common in its
occurrence. Military history abounds with examples. Ask Admiral Yamaguchi
about his boss, Admiral Nagumo and his staff decision to change armament
from bombs to torpedoes, exposing his planes to attack. Wait, not possible.
He's at the FBOTO with the crabs now crewing his sunken ghost ship, the
Hiryu, "groupthunked" to death. (That's "*Frigid* Bottom of the Ocean" in
case you're wondering). (-:
http://en.wikipedia.org/wiki/Tamon_Yamaguchi
An even better example of groupthink was the Maginot line, which the Germans
just went around. All the French generals thought it was a great idea, and
rejected any comments to the contrary. Wiki's got a very good paragraph
about groupthink that I'll just quote a part of:
<<A mindset, in decision theory and general systems theory, refers to a set
of assumptions, methods or notations held by one or more people or groups of
people which is so established that it creates a powerful incentive within
these people or groups to continue to adopt or accept prior behaviours,
choices, or tools. This phenomenon of cognitive bias is also sometimes
described as mental inertia, "groupthink", or a "paradigm", and it is often
difficult to counteract its effects upon analysis and decision making
processes.>>
http://en.wikipedia.org/wiki/Mindset
Sounds pretty much where we're at in this stage of the game.
I'm sorry, but there's just no arguing that it's far more efficient and
reliable to use a light detector to detect light, not a calendar. The
calculated method has so many liabilities a compelling case has to be made
for its use because it's so inferior for this particular task. There has to
be something the calculated version does that the photocell can't do for it
to be the preferred solution. The OP's requirements were to turn lights on
and off. No compelling case was made for the calculated solution.
The OP may have a reason to require the computed time; I believe Orthodox
Jews have a religious requirement relating to sunrise and sunset, and other
religions may as well. Like any number of other theories, it *could* be
true, but we certainly can't ascertain it from any of the simpler, given
facts. So I would consider it a zebra, as I would most of the assumptions
proffered so far as to why the photocell is not the ideal solution.
> Don't you think that the OP's lack of response to the AHA! 'experience' to
> the UT/DST issue might be significant?
No, not at all. When people arrive at the correct solution on Usenet they
are very often never heard from again. I take it that when he discovered
the photocell, he was done. Were he to use the calculated method, I would
expect him to be back to discuss fine tuning or the various computational
methods he could use or how compact he made the code. I'm assuming the
silence was "Aha, why fool around writing code when I can install a
photocell and forget about it?" Or, it could have been more like "Sidereal
time? What planet am I on? I just want to turn the lights on when it's
dark!" and then pfffft!
> Don't you think that the OP's lack of response to the 'photocell '
> solutions might be significant?
Don't you think you just asked basically the same question question twice
twice? (-: He didn't respond to anything else either, so who's making
assumption based on pretty thin evidence now? I think it's probably far
more rational to assume that when the subject matter began careening like
cars in Catskill ice storm, tempers flared and the discussion no longer had
anything to do with his requirements that he simply did the rational thing
and boogied and bought a photocell. (-:
I find it hard to understand the reluctance of some to the idea that
photocells are the proper solution to the "lights on at night, off during
the day problem" in all but the most exceptional cases of day/night light
control.
> I think it's just about possible that the OP want's a solution for 'Sunset
> Time' just like the OP stated in the OP.
I suggest reading a little more critically to distill out his true system
requirements. They've already been somewhat corrupted by following the
wrong solution set, but he's stated rather clearly that he wants to turn
lights on and off. Calculating when to do it is a means to an end, not the
basic requirement. Do you think he really wants the precise value of the
sunrise and sunset for Druidical (or other) religious ceremonies or that
he's trying to turn lights on when it's dark outside and off when it's not?
How can a calendar tell you that the skies are incredibly overcast and
artificial light might be needed? I've seen some pretty 'dark' daylight,
haven't you? If not, consult the historical record, notably:
http://en.wikipedia.org/wiki/View_of_Toledo (a.k.a Toledo in a Storm)
I believe someone already expressed the light levels involved in bright
sunlight, twilight and heavily overcast twilight. Those lights levels are
different enough to invalidate the calculated method. It offers no way of
adjustment or compensation for such events. Those factors alone make it the
simple and obvious solution to the OP defined task. It's so simple - unless
you have premature solution lock.
This is just a small example of a remarkably serious problem in large tech
companies. One team champions one approach and won't relinquish their bias
even when management decides otherwise. Anyone working in a high tech
environment for more than a year or so has already seen it. In those cases
("what language do we develop in?" is one of many perennial problems) the
choice is not as clear cut as it is here. So, unless you:
1) live in cave, with no access to the sun,
2) have a religious, technical or vampirical need to know the precise time
of the sun's rising or setting,
3) are trying to emulate the light cycle of another geographical latitude
4) or are using a home automation controller that has no available inputs or
even any that are sharable
5) can't string a low voltage two wire cable to a window
then select the photocell option.
If you want long term reliability with no chance of a clock getting out of
synch, select the photocell option.
If you want to provide light when it's actually dark, and not just when a
lookup table tells you it is, select the photocell option.
If you want to know if it's dark or light outside, a photocell, not a
calculation, is almost always the optimal solution. When it's not, it's
because of highly unusual reasons, which we might reasonably expect the OP
to mention if they existed. He didn't. He actually gave us a reason to
implement photocells: he needs to conserve memory. For this application a
photocell would take far fewer bytes to implement in the controller
languages I know.
--
Bobby G.
Paul Schlyter
>> Robert Green <ROBERT_G...@YAH00.COM> wrote:
>>
>> >How much discussion has there been here about DST compensation and
>> >programming issues when, as you've shown us, it really was virtually
>> >irrelevant to the problem? Smart people often get lost in the weeds. As
>a
>> >result, it frequently takes some "quiet time" and conversational exchange
>> >before the proper solution emerges. IMHO, that's one of the greatest
>> >strengths of the WWW: allowing this sort of interaction and
>collaboration.
>>
>> This isn't the WWW, it's Usenet! Usenet predated the WWW by several
>> decades....
>
>Yes, this particular exchange is occurring on Usenet, but the collaboration
>of people around the world takes place in many other venues as well. That's
>why I thought the more inclusive term WWW was appropriate. Perhaps the term
>"internet" would have been more taxonomically accurate.
>So maybe I should have said 'Internet' instead of 'WWW,'
In particular when you were having a conversaion outside the WWW .... ;-)
Btw the taxonomically correct term would be "Internet", starting with
a capital "I". An "internet" is a somewhat different thing, not at all
likely to have large volumes of conversation.....
However, back in the pre-WWW days, Usenet often spanned outside the
Internet. But nowadays the parts of Usenet which aren't also on the
Internet are practically nonexistent.
>but I think you get
>the drift. Collaborative efforts abound, from IM to mailing lists to web
>based forums and not just on Usenet.
>
>--
>Bobby G.
>
>
>
oriel36
> > I think it's just about possible that the OP want's a solution for 'Sunset
> > Time' just like the OP stated in the OP.
>
> I suggest reading a little more critically to distill out his true system
> requirements. They've already been somewhat corrupted by following the
> wrong solution set, but he's stated rather clearly that he wants to turn
> lights on and off. Calculating when to do it is a means to an end, not the
> basic requirement. Do you think he really wants the precise value of the
> sunrise and sunset for Druidical (or other) religious ceremonies or that
> he's trying to turn lights on when it's dark outside and off when it's not?
> How can a calendar tell you that the skies are incredibly overcast and
> artificial light might be needed? I've seen some pretty 'dark' daylight,
> haven't you? If not, consult the historical record, notably:
>
> Bobby G.
The next time a misty eyed physicist appears on tv and dictates to the
viewers about the deep insights of the Universe in large and tiny
scales known to scientists,perhaps yuo will smile that they can't even
give you san astronomical solution to when to turn on a porchlight
using geocentric terms of sunrise/sunset.
There were no druids around 5 200 years ago when they constructed a
monument which turns the natural lights on on a specific day and at a
specific time,there were just keen observers who were familiar with
the annual cycle -
http://www.iol.ie/~geniet/eng/newgrang.htm
How it came to be that 5 200 years later that you concede the problem
to a photocell solution can only highlight that something went
drastically wrong somewhere and it most certainl;y did -
http://upload.wikimedia.org/wikipedia/commons/1/1d/Tiempo_sid%C3%A9reo.en.png
You could not build a monument like Newgrange and its solstice marker
with such a cretinous view of the Earth's motions,not even its
geocentric equivalent is correct.It is as though men have lost their
minds in the most bewildering sort of way where intelligence is
entirely absent,They even have an organisation to maintain the phony
23 hour 56 minute 04 second value assigned to axial rotation through
360 degrees -
http://hypertextbook.com/facts/1999/JennyChen.shtml
Groupthink !,you have no idea just how bad it is,none !.
Robert Green
That's not entirely true. For many, many readers, Usenet is accessed
through Google Groups, formerly Deja Vu, so the lines are not very clearly
drawn anymore. At least one participant in this thread is posting via
Google, FWIW.
> Btw the taxonomically correct term would be "Internet", starting with
> a capital "I". An "internet" is a somewhat different thing, not at all
> likely to have large volumes of conversation.....
Which is why "the WWW" may be correct after all because it can never be
mistaken for a company internet. This can happen when someone starts a
sentence with the word and the upper/lower case distinction is lost.
"Internet readers," for example, could be either those of some company,
organization or other "network of computers" or they could be people reading
information from the WWW. (-:
> However, back in the pre-WWW days, Usenet often spanned outside the
> Internet. But nowadays the parts of Usenet which aren't also on the
> Internet are practically nonexistent.
But the parts of Usenet that are accessed via a WWW front end are
significant and seem to be growing. I do all my searching through Google
Groups, I suspect many others do, too. On the other hand, I hate it for
posting. Many don't, though.
Bobby G.
Robert Green
> On Sat, 15 Mar 2008 08:22:51 -0400, "Robert Green"
> <ROBERT_G...@YAH00.COM> wrote:
>
> >I had been scratching my head trying to think of lighting applications
that
> >demanded a calculated approach and your example brought to mind one of
the
> >few cases where a photocell won't do.
>
> This isn't a lighting application, but I use the calculated times of
> civil twilight to determine when to automatically start and stop my
> meteor cameras. The conditions that would cause differences in actual
> light levels for a given time aren't important in my case: if it gets
> dark earlier because of clouds, there's generally no advantage to
> starting an allsky camera earlier!
I agree except for those rare times when a surveillance or research camera
has ended up an accidental witness to history or crime. There are certainly
application where true dawn/dusk times are incredibly important.
Photographers and cinematographers need to know when and where the sun will
cross the horizon. They usually cheat and show up a day ahead and take a
few digital photos rather than bothering to calculate anything. Some films,
like Excalibur and Days of Heaven have most of their principle outdoor
scenes shot at twilight for the dramatic lighting effect it imparts.
http://www.imdb.com/title/tt0077405/trivia
There's a great series of photos of the New York City streets on the day the
sun sets exactly parallel to the street grid alignment. Easy to see why our
ancestors were so impressed by solstices and equinoxes:
http://newyorkdailyphoto.blogspot.com/2007/05/manhattanhenge.html
I suppose one of the reasons for some of the "hubbub" about photocells here
is that in the automation world, turning lights on and off is a fundamental
task. It's well studied in terms of what most people want to do with
lights. I'd say a majority of home automators begin with lighting control.
I know I did. In the astronomical world, it's far more likely that someone
would want to know precise times of sunrise and sunset, hence the wide
difference in basic assumptions about the lighting question.
--
Bobby G.
TR Oltrogge
"tomcee" <tomce...@yahoo.com> wrote in message
news:24b3d18e-ac7f-46e9...@j28g2000hsj.googlegroups.com...
> Given a table of sunset times, such as:
<snip>
> Has anyone determined the basic functions contained within this
> 'Sunset function'? Given the basic functions, I can then calculate the
> constants.
> Thanks in advance for your help,
> TomCee
My reply is going to infuriate everyone because of its horrendous
complexity, but I thought I would brush up on my vector algebra and solve
this problem by...
(1) considering the earth's orbit as an ellipse
(2) using Kepler's "equal area for equal time" rule of orbit speed
(3) general mapping of 3D coordinates from one basis (Earth's lat/lon grid)
to another (Earth's orbital plane 23.5 degrees oblique)
(4) the astronomer's publishing of GMT for perihelion and summer solstice
(5) looking iteratively for when the vector from the sun to the observer is
basically perpendicular to the vector from the earth's center to the
observer
Well, after working almost a month I've got a 'C' program that seems to get
within 6 minutes of the U.S. Navy's published times. I actually learned a
lot about vector operations. For now I'm going to put this thing to rest,
but here's the code...
=============================================================================================================
/*
SUNSET.C a program to calculate the time of sunset for any given latitude
and longitude, year, and day
of the year. It uses vector algebra as much as possible.
Sunset occurs when a line from the sun (considered a point source) runs
tangent to the earth and touches
earth exactly at the point of the observer's latitude and longitude.
Consider this to basically be a problem
in 3D coordinate space using rectangular coordinates (although polar
coordinates are used initially to compute
the earth's orbit).
The 3D coordinate space has the sun at the origin. The earth's orbit is an
ellipse in the X-Y plane with the
sun at one of the foci. When the earth is at perihelion, or closest to the
sun, it is on the positive X-axis
with Y=0.
We need two equations. One will determine the earth's center as a vector
from the sun as a function of time.
Call it the 'sun-earth' vector. The second will determine the distance and
direction from the center of the
earth to the observer's position on the surface as a function of time.
Call it the 'earth-observer' vector.
The sum of these two vectors will be a vector that goes from the sun to
the observer's position on the surface
of the earth. This third, computed, vector is called the 'sun-observer'
vector. When the 'sun-observer' vector
is perpendicular to the 'earth-observer' vector then the sun is sitting
on the horizon and it's either sunrise
or sunset. Perpendicular is tested for by taking the dot-product of the
two vectors 'earth-observer' and
'sun-observer' and testing for zero.
CALCULATING THE sun-earth VECTOR AS A FUNCTION OF TIME t
Using polar coordinates with the sun at the origin and zero degrees being
perihelion Kepler devised the
following two equations...
(1) M = 2 * PI * t / T
where 'M' is the "mean" anomaly, 't' is the time since perihelion, and
'T' is the orbital period
(2) M = E - e * sin (E)
where 'E' is the "eccentric" anomaly, and 'e' is the eccentricity of
the ellipse
The goal here is to first calculate 'M' from 't'. 'T' is 365 days 5 hours
49 minutes, or 31556940 seconds. Then
we use the second equation to solve for 'E'. Unfortunately, equation (2)
cannot be solved via algebra. But a
formula involving an infinite series will get it accurately enough with
about three terms...
E = M + (e - 1/8 * e^3) * sin (M) + 1/2 * e^2 * sin (2 * M) + 3/8 * e^3
* sin(3 * M) + ...
Once we get 'E' we substitute this value into the following equation to get
'v' (angle of the earth from the
sun)...
(3) v = arctan ( sqrt ((1 + e) / (1 - e)) * tan ( E / 2) ) * 2
where 'v' is the polar coordinate angle (from the sun) for the earth at
time 't'
Then we simply plug 'v' into the equation for an ellipse (in polar
coordinates) to get 'r' (the distance from
the sun)...
(4) r = a * (1 - e^2) / (1 + e * cos (v) )
where 'a' is the semi-major axis
A final conversion of 'v' and 'r' into cartesian coordinates is made by
x = r * cos ( v )
y = r * sin ( v )
VISUALIZING THE EARTH'S SPHERICAL SHAPE, AXIS OF ROTATION, AND
SEASON-CREATING TILT OF THE AXIS
Next we have to compute the vector 'earth_observer' based on any time
't'. This vector represents the direction
and distance of travel from the center of the earth to the observer's
location on the surface. This
'earth_observer' vector, expressed in the basis unit vectors of our
earth-orbit coordinate system, is computed
based on three new factors...
(1) Latitude and Longitude
The observer is on the surface of a sphere with an approximately 4000
mile radius. Using the observer's
latitude and longitude will allow us to compute the surface
coordinates and, thus, a basic 'observer'
vector from the earth's center to the observer. To simplify this
calculation we will invoke a new,
secondary, coordinate system aligned with the latitude and longitude
grid. The X-axis of this new system
starts from the earth's center and leaves the earth where the prime
meridian intersects with the equator.
The Z-axis of this new system is the axis of rotation of the earth and
starts at the earth's center and
leaves the earth through the north pole. The Y-axis of this new system is
now determined by the other two
axes. It starts at the earth's center and leaves the earth where the 90
degree east longitude meridian
intersects the equator. Using this secondary coordinate system we compute
the observer's location with
the three equations...
Z= 4000*sin(lat)
Y=(4000*cos(lat))*sin(lon)
X=(4000*cos(lat))*cos(lon)
Notice that the familiar notation of east and west longitude designation
has been replaced with the
mathematical requirement that east longitude is used as-is (a positive
number from 0 to 180) but west
longitude is negated in sign (so 0 to 180 west longitude becomes 0
to -180 degrees).
(2) Elapsed Time
The earth rotates on its own axis approximately every 23 hours 56
minutes 4 seconds (a sidereal day). So
even though the observer is fixed in geographic latitude and longitude
his effective longitude increases
by 360 degrees every 23h56m4s. Therefore, an incremented longitude
computed from the time 't' is added to
the basic longitude specified in factor (1) to give a correct computation
of the 'earth_observer' vector
including both factors (1) and (2). At this point the 'earth_observer'
vector is still relative to the
secondary coordinate system. The equations now become...
Z= 4000*sin(lat)
Y=(4000*cos(lat))*sin(lon+t/SIDEREAL_DAY*360)
X=(4000*cos(lat))*cos(lon+t/SIDEREAL_DAY*360)
(3) Coordinate Conversion from Secondary to Primary Coordinate System for
Earth's Axial Tilt
Because the earth's axis of rotation is "tilted" at an angle of 23.5
degrees with respect to the orbital
plane the basic calculation of the 'earth_observer' vector done by
using factors (1) and (2) with respect
to a secondary coordinate system based on latitude and longitude will
have to be converted to a vector based
on the original coordinate system that was used to describe the earth's
elliptical orbit before we can
use it in an algebraic solution for the time of sunset.
Returning to the original coordinate system the earth's north pole is
above the X-Y plane, always in
positive Z space and "roughly" near the top of the sphere that is the
earth. Due to the earth's tilt a
line from the earth's center through the north pole will always make an
angle of 23.45 degrees with the
Z-axis of the original coordinate system. The direction of this line in
the original coordinate system is
called the 'tilt' vector. It is a constant vector and does not change
over time. It never changes its
direction. Its specific X, Y, and Z components can only be determined by
researching astronomers' analysis
of earth's orbit. This 'tilt' vector the astronomers give us is the
Z-axis of our secondary coordinate
system. What are the X and Y axes? Astronomers will also have to give us
those since they determine the
orientation of the prime meridian to the original coordinate system at
time t=0. Once we have all three
of these secondary coordinate system axes defined *as components of the
original coordinate system* then we
use the transformation that follows for any coordinate system
conversion. Thus, the astronomers give us
three vectors aligned with the axes of our secondary coordinate system
but using the original coordinate
system's basis vectors. We call them 'tilt_x', 'tilt_y', and 'tilt_z'.
'tilt_z' is calulated by examining the earth's axis of rotation at the
time of summer solstice. 'tilt_x' is
also computed by noting where the prime meridian is positioned at the
time of summer solstice and then
"unwinding" it around the earth's axis of rotation back to the time t=0.
'tilt_y' is simply the cross
product of 'tilt_z' and 'tilt_x'. The rotation of the initial 'tilt_x'
vector constructed from the geometry
at summer solstice back to time t=0 is done using Rodrigues' solution for
rotating vector X around vector U
by angle theta...
_ _ _ _ _ _ _
X' = X * cos(theta) + U * (U . X)(1 - cos(theta)) + (U x X) *
sin(theta) //dot-prod, cross-prod, respectively
CONVERSION OF COORDINATES BETWEEN TWO COORDINATE SYSTEMS
The coordinate conversion from the secondary system to the original
system is accomplished via the
general-purpose linear transformation algebraic solution found on the top
of page 534 of my VNR book.
This solution handles the general case of both a translation of the
origin and a rotation of the axes for
two distinct coordinate systems. It requires the calculation of
"direction cosines" for each of nine angles.
Given any vectors aligned with the three axes for the two coordinate
systems these nine direction cosines
can be computed by using the dot-product relationship of two vectors.
Because the dot-product of two
vectors is the product of the magnitudes of both vectors multiplied by
the cosine of the angle between them
the cosine itself is the dot-product divided by the product of the
magnitudes of both vectors. The
calculation of the nine direction cosines follows:
a11 = dot-product(unit_x,tilt_x) / ( |unit_x|*|tilt_x| )
a12 = dot-product(unit_x,tilt_y) / ( |unit_x|*|tilt_y| )
a13 = dot-product(unit_x,tilt_z) / ( |unit_x|*|tilt_z| )
a21 = dot-product(unit_y,tilt_x) / ( |unit_y|*|tilt_x| )
a22 = dot-product(unit_y,tilt_y) / ( |unit_y|*|tilt_y| )
a23 = dot-product(unit_y,tilt_z) / ( |unit_y|*|tilt_z| )
a31 = dot-product(unit_z,tilt_x) / ( |unit_z|*|tilt_x| )
a32 = dot-product(unit_z,tilt_y) / ( |unit_z|*|tilt_y| )
a33 = dot-product(unit_z,tilt_z) / ( |unit_z|*|tilt_z| )
The direction cosines are the 'Amn' coefficients in the following
equations. The translational distance
between the origins of the two coordinate systems are the 'An'
constants.
The equations for converting a coordinate in the 'prime' coordinate
system to a coordinate in the 'non-prime'
coordinate system are on the left-hand side. The equations for
converting a coordinate in the 'non-prime'
coordinate system to a coordinate in the 'prime' coordinate system are
on the right-hand side.
x = a1 + a11 * x' + a12 * y' + a13 * z' | x' = a11 * (x - a1) +
a21 * (y - a2) + a31 * (z - a3)
y = a2 + a21 * x' + a22 * y' + a23 * z' | y' = a12 * (x - a1) +
a22 * (y - a3) + a32 * (z - a3)
z = a3 + a31 * x' + a32 * y' + a33 * z' | z' = a13 * (x - a1) +
a23 * (y - a3) + a33 * (z - a3)
In both sets of equations a1, a2, and a3 are the coordinates (x, y, and
z) of the origin of the 'prime'
system with respect to the 'non-prime' system. That is, the origin point
{0', 0', 0'} of the 'prime' system
is at location {a1, a2, a3} in the 'non-prime' system.
In both sets of equations the 'Amn' direction cosines refer to the
cosine of the angle between axis 'm' of
the 'non-prime' system and axis 'n' of the 'prime' system (where m=1 is
the X-axis of the 'non-prime' system,
m=2 is the Y-axis of the 'non-prime' system, and m=3 is the Z-axis of
the 'non-prime' system; where n=1 is
the X-axis of the 'prime' system, n=2 is the Y-axis of the 'prime'
system, and n=3 is the Z-axis of the
'prime' system). Notice that because of the symmetry of the cosine
function about the zero angle it makes no
difference whether the angle is rotated through according to a
right-handed orientation or a left-handed
orientation since cos(theta)=cos(360-theta). However, each of the nine
angles rotated through must all be
determined by choosing representative vectors of the axes of each
coordinate system that have the same
orientation to those axes with regard to positive (or negative)
direction.
Since we are dealing with vectors and not actual coordinates there is no
translation of the origin of our
two systems to be considered. a1, a2, and a3 are all zero. We will have
coordinates in the secondary system
that need to be converted to the primary system and the equations on the
left will be used.
*/
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include "VCTRSUPPORT.h"
//SOME USEFUL CONSTANTS
#define PI 3.141592653589793
#define SIDEREAL_DAY (23*3600.0+56*60.0+4) //Number of seconds in
a sidereal day
#define SUN_RISE_SET_ANGLE 89.167 //Angle between
'sun_earth' & 'earth_observer' at sunrise/sunset
#define SEMI_MAJOR_AXIS 92955807.0 //Semi-major axis of
earth's orbit ellipse
double secs_per_orbit=365*86400+6*3600+13*60+53; //Number of seconds in
a true orbit (anomalistic) of the sun
double e=0.0167; //Earth's elliptical
orbit eccentricity
#define ECCENTRICITY 0.0167 //Earth's elliptical
orbit eccentricity
double a=92955807.0; //Semi-major axis of
earth's orbit ellipse
double obs_lat=40.267; //Observer's latitude (positive is northern
hemispere, negative is southern hemisphere)
double obs_lon=-80.117; //Observer's longitude (positive is east of
Greenwich, negative is west of Greenwich)
//double obs_lat=0.0; //Observer's latitude (positive is northern
hemispere, negative is southern hemisphere)
//double obs_lon=0.0; //Observer's longitude (positive is east of
Greenwich, negative is west of Greenwich)
typedef struct {
int yr; //2008, 2009, 2010, etc
int mo; //1=JAN, 2=FEB, etc
int da; //1-31
int hh; //0-23
int mm; //0-59
int ss; //0-59
int tzone; //0=GMT -5=EST, etc
} datim;
// YYYY MM DD HH MM SS Z
datim perihelion={2008, 1, 3, 0, 0, 0,0}; //Date/time (GMT) of perihelion
(earth closest to sun, t=0)
datim sp_equinox={2008, 3,20, 5,48, 0,0}; //Date/time (GMT) of spring
equinox (sun_earth perpend to tilt_z)
datim s_solstice={2008, 6,20,23,59, 0,0}; //Date/time (GMT) of summer
solstice (tilt_z leans toward sun)
datim aphelion ={2008, 7, 4, 8, 0, 0,0}; //Date/time (GMT) of aphelion
(earth farthest from sun)
datim fa_equinox={2008, 9,22,15,44, 0,0}; //Date/time (GMT) of fall
equinox (sun_earth perpend to tilt_z again)
datim w_solstice={2008,12,21,12, 4, 0,0}; //Date/time (GMT) of winter
solstice (tilt_z leans away from sun)
datim current_date;
POINT sun={0,0,0}; //Fixed position of the sun def'd in *primary
coords*. It never moves.
//The three vectors for the secondary coord system (described in primary
coord system components)
VECTOR tilt_z; //Z-axis of secondary coord syst def'd in *primary
coords* (earth's rotation axis)
VECTOR tilt_x; //X-axis of secondary coord syst def'd in *primary
coords* (prime meridian at t=0)
VECTOR tilt_y; //Y-axis of secondary coord syst def'd in *primary
coords* (90 degrees east longitude)
//Three unit vectors described in the primary coord system used for
computing direction cosines
VECTOR unit_x={1,0,0};
VECTOR unit_y={0,1,0};
VECTOR unit_z={0,0,1};
//The nine direction cosines
double a11,a12,a13,a21,a22,a23,a31,a32,a33;
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
//Function prototypes
int time_to_date(int t,datim *d); //Not coded yet. Not needed.
int date_to_time(datim *d,long *t);
int adjust_date (datim *dt,long time);
int calc_angle (datim *dt,double *angle);
int print_vec (VECTOR *v);
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
int main() {
int it; //Time 't' as an integer
double t; //Time in seconds from initial position of earth
double M; //The "mean" anomaly angle
double E; //The "eccentric" anomaly angle
double v; //Angle, in radians, of earth in its orbit from
its initial position
double r; //Polar coordinate 'radius' of earth
VECTOR sun_earth; //Vector from sun to earth's center
VECTOR normal; //Computed vector normal to orbital plane
through the sun
VECTOR earth_observer; //Vector from earth's center to the observer at
given latitude, longitude, and time
POINT obs; //Coordinates of observer's point (after time
rotations) in *secondary coordinates*
VECTOR obs_vec; //Vector from earth's center to observer's point
on surface in *secondary coordinates*
double lat,lon;
VECTOR sun_observer; //Vector from sun to the observer's tangent
point
double dp,angle;
double dangle;
long delta_t;
double temp;
VECTOR tempu,tempx,tempv1,tempv2;
double theta;
/*
OK, let's get started! First, calculate the constant 'tilt_z' vector (the
earth's axis of rotation) in the
primary coordinate system based on the fact that at summer solstice the
axis of the earth (which always forms
an angle of 23.45 degrees with the normal to the orbital plane) is, at that
moment, pointing *directly* at the
sun. Another way to put it is that the normal vector to the orbital
plane, passing through the sun, will
intersect the earth's extended axis at some point in the positive Z
direction. Thus, a right triangle is formed
by the earth, the sun, and that point of intersection in positive Z
space. (This condition also happens at
winter solstice, but then the intersection is in negative Z space.) The
'sun_earth' vector at time
t=summer_solstice is the short leg of this right triangle. The normal
vector to the earth's orbital plane and
passing through the sun is the long leg of this triangle. The hypotenuse
is the 'tilt_z' vector for the earth.
The tangent of 23.45 degrees (0.4337751161) is the ratio of the
'sun_earth' vector's length to the length of the
normal vector. So the length of the normal vector is computed by dividing
the length of the 'sun_earth' vector
by the tangent of 23.45 degrees.
*/
if (date_to_time(&s_solstice,&it)) { //Convert summer solstice
date/time to seconds since perihelion
printf("s_solstice conversion error to basic time\n");
goto bad_exit;
}
t=it; //Make it floating point
// printf("time (t) of summer solstice is %.1f\n",t);
//Now solve for the X and Y coordinates of the earth at summer solstice to
get 'sun_earth' vector
M=2*PI*t/secs_per_orbit; //Compute Kepler's 'Mean' anomaly
E=M //Compute Kepler's 'Eccentric'
anomaly (approximately)
+(e-1.0/8.0*pow(e,3.0))*sin(1.0*M) //using the first three terms of an
infinite series
+ 1.0/2.0*pow(e,2.0) *sin(2.0*M) // "
+ 3.0/8.0*pow(e,3.0) *sin(3.0*M); // "
v=atan(sqrt((1.0+e)/(1.0-e))*tan(E/2.0))*2.0; //Use 'Eccentric' anomaly
to solve for polar coord angle from sun
r=a*(1.0-pow(e,2.0))/(1.0+e*cos(v)); //Equation for ellipse
gives radius from polar coord angle
sun_earth.x=r*cos(v); //Convert polar coord angle
and radius to cartesian coords
sun_earth.y=r*sin(v); // "
sun_earth.z=0.0; // "
// printf("sun_earth="); print_vec(&sun_earth); printf("\n");
//OK, now have 'sun_earth' vector. Solve for normal vector's length from
right triangle relationship.
normal.x=0.0; //Normal vector has no X
component
normal.y=0.0; //Normal vector has no Y
component
normal.z=vector_length(&sun_earth)/tan(23.45*PI/180); //Z length is
'sun_earth' length divided by tan(23.45)
// printf("normal(+Z)="); print_vec(&normal); printf("\n");
//The 'tilt_z' vector is the sum of the 'sun_earth' vector (negated) and the
'normal' vector
tilt_z.x=-sun_earth.x+normal.x; //Add 'em
tilt_z.y=-sun_earth.y+normal.y; // "
tilt_z.z=-sun_earth.z+normal.z; // "
// printf("tilt_z="); print_vec(&tilt_z); printf("\n");
/*
OK, now have 'tilt_z' vector described in primary coordinates. We now
need the 'tilt_x' and 'tilt_y' vectors.
These are both perpendicular to the 'tilt_z' vector and the 3 of them are
the axes for the secondary coordinate
system. 'tilt_x' points from the earth's center through the earth's
equator at the longitude of the prime
meridian at time t=0. It will also be constant, not changing as the earth
orbits or rotates. 'tilt_x' will tell
us the exact orientation of the earth in its rotation about its axis at
t=0. 'tilt_y' is nothing more than the
vector from the earth's center through the equator at longitude east 90
degrees. It will be calculated via a
cross product of 'tilt_z' and 'tilt_x' once 'tilt_x' has been
ascertained.
Working with the summer solstice again, this time let's make a right
triangle using the 'sun_earth' vector as
the long leg. The normal vector to the earth's orbital plane going
through the sun and going in the *negative*
Z direction is the short leg. The hypotenuse is the 'tilt_x' vector at
12:00AM at the beginning of the date of
summer solstice. If we then back out all the rotations of this 'tilt_x'
vector that have happened since the
date/time of perihelion then we will have the correct 'tilt_x' vector value
we want. Now the tangent of 23.45
degrees is the ratio of the length of this negative-going normal vector to
the 'sun_earth' vector's length. So
the length of this negative-going normal vector is the product of the
'sun_earth' vector's length and the
tangent of 23.45 degrees.
*/
normal.x=0.0;
normal.y=0.0;
normal.z=-vector_length(&sun_earth)*tan(23.45*PI/180);
// printf("normal(-Z)="); print_vec(&normal); printf("\n");
//The 'tilt_x' vector (as a starting point) is the sum of the 'sun_earth'
vector and the 'normal' vector (negated)
tilt_x.x=sun_earth.x-normal.x;
tilt_x.y=sun_earth.y-normal.y;
tilt_x.z=sun_earth.z-normal.z;
// printf("tilt_x(12:00AM sum_solstice)="); print_vec(&tilt_x);
printf("\n");
//Unwind tilt_x vector to its position at perihelion (find the angle of
clockwise rotation needed)
current_date.yr=s_solstice.yr;
current_date.mo=s_solstice.mo;
current_date.da=s_solstice.da;
current_date.hh=0;
current_date.mm=0;
current_date.ss=0;
current_date.tzone=0;
if (date_to_time(¤t_date,&it)) { //Convert 12:00AM on summer
solstice to 't' secs since perihelion
printf("error converting date to time\n");
goto bad_exit;
}
t=it; //Convert time to float
// printf("time (t) of *midnight* on day of summer solstice is %.1f\n",t);
theta=-t/SIDEREAL_DAY*2*PI; //Get angle to unwind
// printf("angle to unwind=%.1f\n",theta);
//Use rotation of vector around a vector to get the unwound 'tilt_x' vector
at t=0
/*
The rotation of vector X around *unit* vector U by an angle 'theta' is
given by...
_ _ _ _ _ _ _
X' = X * cos(theta) + U * (U . X)(1 - cos(theta)) + (U x X) * sin(theta)
//dot-prod & cross-prod, respectively
*/
tempu=tilt_z; //Vector U is our tilt_z (earth's
axis of rotation). Make a copy of it.
vector_resize(&tempu,1.0); //Make it a unit vector for the
following calculations
tempx=tilt_x; //Make copy of X to begin with
vector_mpy(&tempx,cos(theta)); //Now have X*cos(theta)
temp=dot_product(&tempu,&tilt_x)*(1.0-cos(theta)); //Now have
(U.X)(1-cos(theta))
tempv1=tempu; //Prepare to multiply U by result in
previous line
vector_mpy(&tempv1,temp); //Now have U*(U.X)(1-cos(theta))
cross_product(&tempu,&tilt_x,&tempv2); //Now have (UxX)
vector_mpy(&tempv2,sin(theta)); //Now have (UxX)*sin(theta)
vector_add(&tempv1,&tempv2,&tilt_x); //Now have
U*(U.X)(1-cos(theta))+(UxX)*sin(theta)
vector_add(&tilt_x,&tempx,&tilt_x); //Now have
X*cos(theta)+U*(U.X)(1-cos(theta))+(UxX)*sin(theta)
// printf("tilt_x(final, at t=0)="); print_vec(&tilt_x); printf("\n");
//Take cross product of 'tilt_z' with 'tilt_x' to generate our 'tilt_y'
perpendicular to both
cross_product(&tilt_z,&tilt_x,&tilt_y);
//Compute the nine direction cosines for secondary to primary axes
conversion
a11=dot_product(&unit_x,&tilt_x)/(vector_length(&unit_x)*vector_length(&tilt_x)); a12=dot_product(&unit_x,&tilt_y)/(vector_length(&unit_x)*vector_length(&tilt_y)); a13=dot_product(&unit_x,&tilt_z)/(vector_length(&unit_x)*vector_length(&tilt_z)); a21=dot_product(&unit_y,&tilt_x)/(vector_length(&unit_y)*vector_length(&tilt_x)); a22=dot_product(&unit_y,&tilt_y)/(vector_length(&unit_y)*vector_length(&tilt_y)); a23=dot_product(&unit_y,&tilt_z)/(vector_length(&unit_y)*vector_length(&tilt_z)); a31=dot_product(&unit_z,&tilt_x)/(vector_length(&unit_z)*vector_length(&tilt_x)); a32=dot_product(&unit_z,&tilt_y)/(vector_length(&unit_z)*vector_length(&tilt_y)); a33=dot_product(&unit_z,&tilt_z)/(vector_length(&unit_z)*vector_length(&tilt_z));/* OK, now test all our logic by choosing some date/time values and thencalculating the 'sun_earth' vector, the 'earth_observer' vector, the 'sun_observer' vector, and the angle betweenthe 'sun_observer' and 'earth_observer' vectors. When the angle is close to 90 degrees then wehave a sunrise or sunset.*//* current_date.yr=2008; current_date.mo=4; current_date.da=3; current_date.hh=0; current_date.mm=0; current_date.ss=0; current_date.tzone=-5; for (;current_date.hh<24;current_date.hh++) { if (date_to_time(¤t_date,&it)) { //Convert current_date to a time't' in seconds since perihelion printf("error converting date to time\n"); goto bad_exit; } t=it; //Convert time to float//First calculate sun_earth vector M=2*PI*t/secs_per_orbit; //Mean anomaly E=M+(e-1.0/8.0*pow(e,3.0))*sin(M)+1.0/2.0*pow(e,2.0)*sin(2.0*M)+3.0/8.0*pow(e,3.0)*sin(3.0*M); //Approx v=atan(sqrt((1.0+e)/(1.0-e))*tan(E/2.0))*2.0; //Solved for polar anglefrom sun r=a*(1.0-pow(e,2.0))/(1.0+e*cos(v)); //Equation for ellipse gives radiusas funtion of polar angle sun_earth.x=r*cos(v); //Convert polar to cartesian sun_earth.y=r*sin(v); // " sun_earth.z=0.0; // " lon=obs_lon+t/SIDEREAL_DAY*360.0; //Compute longitude with timerotation done lat=obs_lat ; //Latitude always stays the same obs.z= 4000.0*sin(lat*PI/180.0); //Observer'scoords in secondary system at time 't' obs.y=(4000.0*cos(lat*PI/180.0))*sin(lon*PI/180.0); //Observer'scoords in secondary system at time 't' obs.x=(4000.0*cos(lat*PI/180.0))*cos(lon*PI/180.0); //Observer'scoords in secondary system at time 't'//Change coords in secondary system to vector in secondary system (trivial) obs_vec.x=obs.x; obs_vec.y=obs.y; obs_vec.z=obs.z; earth_observer.x = a11 * obs_vec.x + a12 * obs_vec.y + a13 * obs_vec.z;//Now transform to primary system earth_observer.y = a21 * obs_vec.x + a22 * obs_vec.y + a23 * obs_vec.z;// " earth_observer.z = a31 * obs_vec.x + a32 * obs_vec.y + a33 * obs_vec.z;// "//Vector from sun to observer is sum of vector from sun to earth plusobserver's vector from earth center sun_observer.x=sun_earth.x+earth_observer.x; sun_observer.y=sun_earth.y+earth_observer.y; sun_observer.z=sun_earth.z+earth_observer.z;//The dot-product of the 'observer' vector and 'sun_tangent' vector must bezero since they are at right angles dp=dot_product(&sun_observer,&earth_observer); angle=acos(dp/(vector_length(&sun_observer)*vector_length(&earth_observer))); printf("%8.1f %4d/%02d/%02d %02dh %02dm %02ds%5.1f\n",t,current_date.yr,current_date.mo,current_date.da, current_date.hh,current_date.mm,current_date.ss, angle*180.0/PI); }*//* Given a date/time determine the time of sunrise and sunset for that date.Do this by iterating times during the date and check that the angle of the sun is close enough toSUN_RISE_SET_ANGLE.*/ for (current_date.da=1;current_date.da<=30;current_date.da++) { current_date.yr=2008; current_date.mo=4;// current_date.da=3; current_date.hh=12; //First use noon - sun isdefinitely up! current_date.mm=0; current_date.ss=0; current_date.tzone=-5;//First, work earlier in the day looking for sunrise if (calc_angle(¤t_date,&dangle)) { //Get the angle for noon printf("bad return from 'calc_angle'\n"); goto bad_exit; } if (dangle<SUN_RISE_SET_ANGLE) { //If sun is below the horizonat noon (!) printf("error: sun below horizon at noon!\n"); goto bad_exit; } for (delta_t=-3600;abs(delta_t)>0;) { //Iterate to earlier timestarting with one hour movement adjust_date(¤t_date,delta_t); //Use 'delta_t' to getanother date/time to look at if (calc_angle(¤t_date,&dangle)) { //Get the angle for this new time printf("bad return from 'calc_angle'\n"); goto bad_exit; } if (dangle<SUN_RISE_SET_ANGLE) { //If we're earlier than sunrise if (delta_t<0) //If we were moving toward earliertimes delta_t/=-2; //Halve the time increment andreverse its direction continue; //Stay in the iteration } if (dangle>SUN_RISE_SET_ANGLE) { //If we're later than sunrise if (delta_t>0) //If we were moving toward latertimes delta_t/=-2; //Halve the time increment andreverse its direction continue; //Stay in the iteration } break; //If we're right (exactly) atsunrise, then stop the iteration } printf("%4d/%02d/%02d - %02d:%02d:%02d ", current_date.yr,current_date.mo,current_date.da, current_date.hh,current_date.mm,current_date.ss); current_date.hh=12; //Reset starting date/time tonoon again current_date.mm=0; current_date.ss=0; for (delta_t=3600;abs(delta_t)>0;) { //Iterate to later timestarting with one hour movement adjust_date(¤t_date,delta_t); //Use 'delta_t' to getanother date/time if (calc_angle(¤t_date,&dangle)) { //Get the angle for this new time printf("bad return from 'calc_angle'\n"); goto bad_exit; } if (dangle>SUN_RISE_SET_ANGLE) { //If we're earlier than sunset if (delta_t<0) //If we were moving toward earliertimes delta_t/=-2; //Halve the time increment andreverse its direction continue; //Stay in the iteration } if (dangle<SUN_RISE_SET_ANGLE) { //If we're later than sunset if (delta_t>0) //If we were moving toward latertimes delta_t/=-2; //Halve the time increment andreverse its direction continue; //Stay in the iteration } break; //If we're right (exactly) atsunset, then stop the iteration } printf("%02d:%02d:%02d\n",current_date.hh,current_date.mm,current_date.ss); } return(0);bad_exit: return(1);}//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -/* Convert a date and time-of-day value to the time elapsed since t=0*/int days_in_month[12]={31,28,31,30, 31, 30, 31, 31, 30, 31, 30, 31};int cum_days[12] ={ 0,31,59,90,120,151,181,212,242,273,303,334};int date_to_time(datim *d,long *t) {int max_days,cum_d,cum_sec_perihelion,cum_sec_input,cum_sec_intervening,y; if (d->yr < 1901 || d->yr > 2099) goto bad_datim; //Century years notleap unless divisible by 400 if (d->mo < 1 || d->mo > 12) goto bad_datim; //Month in range? max_days=days_in_month[d->mo-1]+((!(d->yr%4) && d->mo==2) ? 1 : 0);//Account for Feb in leap year if (d->da < 1 || d->da > max_days) goto bad_datim; //Day in range? if (d->hh < 0 || d->hh > 23) goto bad_datim; //Hour in range? if (d->mm < 0 || d->mm > 59) goto bad_datim; //Minute inrange? if (d->ss < 0 || d->ss > 59) goto bad_datim; //Second inrange? if (d->tzone < -12 || d->tzone > 11) goto bad_datim; //Time zone inrange?//Calc # seconds perihelion date/time is into its own year cum_d=cum_days[perihelion.mo-1]+((!(perihelion.yr%4) && perihelion.mo>2)? 1 : 0); //Add 1 beyond Feb in leap yr cum_d+=perihelion.da-1;//Add # days into month cum_sec_perihelion=cum_d*86400 //Cum secs totalstarts w/secs in prior days +(perihelion.hh-perihelion.tzone)*3600 //Plus secs inprior hrs of day (adj for tzone) +perihelion.mm*60 //Plus secs in prior mins +perihelion.ss; //Plus secs into current min//Calc # seconds input date/time is into its own year cum_d=cum_days[d->mo-1]+((!(d->yr%4) && d->mo>2) ? 1 : 0); //Add 1 beyondFeb in leap yr cum_d+=d->da-1; //Add # days intomonth cum_sec_input=cum_d*86400 //Cum secs totalstarts w/secs in prior days +(d->hh-d->tzone)*3600 //Plus secs inprior hrs of day (adj for tzone) +d->mm*60 //Plus secs in prior mins +d->ss; //Plus secs into currentmin//Calc # seconds in intervening years starting at beginning of perihelionyear for (cum_sec_intervening=0,y=perihelion.yr;y<d->yr;y++) //For allintervening years cum_sec_intervening+=(365*86400)+(!(y%4) ? 86400 : 0); //Add # secs inyear, accounting for leap *t=cum_sec_intervening-cum_sec_perihelion+cum_sec_input; //Subtperihelion start fract, add input start fract return(0);bad_datim: return(1);}//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -int adjust_date(datim *dt,long t_sec) {/* Take a date/time in 'dt' and adjust it forward (t_sec positive) orbackward (t_sec negative) and construct a new value for 'dt'. Do not move beyond midnight if movingbackward or 23:59:59 if moving forward. Return 0 as a normal status. Return 1 if a limit for themovement was reached, but otherwise set the value to the limit.*/long adj_hh,adj_mm,adj_ss; adj_hh=t_sec/3600; adj_mm=(t_sec-adj_hh*3600)/60; adj_ss=t_sec-adj_hh*3600-adj_mm*60; dt->ss+=adj_ss; dt->mm+=adj_mm; dt->hh+=adj_hh; if (dt->ss > 59) { dt->ss-=60; dt->mm++; } if (dt->ss < 0) { dt->ss+=60; dt->mm--; } if (dt->mm > 59) { dt->mm-=60; dt->hh++; } if (dt->mm < 0) { dt->mm+=60; dt->hh--; } if (dt->hh > 23) { dt->hh=23; dt->mm=59; dt->ss=59; goto bad_exit; } if (dt->hh < 0) { dt->hh=0; dt->mm=0; dt->ss=0; goto bad_exit; } return(0);bad_exit: return(1);}//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -int calc_angle(datim *dt,double *angle) {/* Given a date/time in 'dt' and using the observer's position ('obs_lat'and 'obs_lon') compute the angle between the 'earth_observer' vector and the 'sun_observer' vector.Return its value in degrees. Return 0 if no error. Return 1 if an error is found in the input date/time'dt'.*/long it;double t,M,E,v,r,lon,lat,dp;VECTOR sun_earth,obs,earth_observer,sun_observer; if (date_to_time(dt,&it)) { //Convert date/time structure to a time't' in seconds since perihelion printf("error converting date to time\n"); goto bad_exit; } t=it; //Convert time to float//First calculate sun_earth vector based on the time 't' M=2*PI*t/secs_per_orbit; //CalculateKepler's "Mean" anomaly E=M //ComputeKepler's "Eccentric" anomaly (approximately) +(ECCENTRICITY-1.0/8.0*pow(ECCENTRICITY,3.0))*sin(1.0*M) //using thefirst three terms of an infinite series + 1.0/2.0*pow(ECCENTRICITY,2.0) *sin(2.0*M) // " + 3.0/8.0*pow(ECCENTRICITY,3.0) *sin(3.0*M); // " v=atan(sqrt((1.0+ECCENTRICITY)/(1.0-ECCENTRICITY))*tan(E/2.0))*2.0;//"Eccentric" anomaly gives polar coord angle r=SEMI_MAJOR_AXIS*(1.0-pow(ECCENTRICITY,2.0))/(1.0+ECCENTRICITY*cos(v));//Eq for ellipse gives radius from angle sun_earth.x=r*cos(v); //Convert polar to cartesian sun_earth.y=r*sin(v); // " sun_earth.z=0.0; // "//Second calculate observer's latitude/longitude in secondary coords withelapsed time increasing longitude lon=obs_lon+t/SIDEREAL_DAY*360.0; //Compute longitude with time rotationdone lat=obs_lat ; //Latitude always stays the same obs.z= 4000.0*sin(lat*PI/180.0); //Observer's vectorfrom earth's center (secondary coords) obs.y=(4000.0*cos(lat*PI/180.0))*sin(lon*PI/180.0); // " obs.x=(4000.0*cos(lat*PI/180.0))*cos(lon*PI/180.0); // "//Change vector in secondary system to vector in primary system coords earth_observer.x = a11 * obs.x + a12 * obs.y + a13 * obs.z; //Nowtransform to primary system earth_observer.y = a21 * obs.x + a22 * obs.y + a23 * obs.z; // " earth_observer.z = a31 * obs.x + a32 * obs.y + a33 * obs.z; // "//Vector from sun to observer is sum of vector from sun to earth plusobserver's vector from earth center sun_observer.x=sun_earth.x+earth_observer.x; sun_observer.y=sun_earth.y+earth_observer.y; sun_observer.z=sun_earth.z+earth_observer.z;//The dot-product of the 'earth_observer' vector and 'sun_observer' vectorallows us to calculate the angle dp=dot_product(&sun_observer,&earth_observer); *angle=acos(dp/(vector_length(&sun_observer)*vector_length(&earth_observer))); *angle*=180.0/PI; //Convert radians to degrees return(0);bad_exit: return(1);}//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -int print_vec(VECTOR *v) { printf("%.1fx %.1fy %.1fz",v->x,v->y,v->z); return(0);}//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -======================================================================================================
oriel36
> "tomcee" <tomcees...@yahoo.com> wrote in message
>
> news:24b3d18e-ac7f-46e9...@j28g2000hsj.googlegroups.com...
>
> > Given a table of sunset times, such as:
> <snip>
> > Has anyone determined the basic functions contained within this
> > 'Sunset function'? Given the basic functions, I can then calculate the
> > constants.
> > Thanks in advance for your help,
> > TomCee
>
> My reply is going to infuriate everyone because of its horrendous
> complexity,
I think the words you are looking for is either 'convoluted' or
'contrived', instead of complicated you repeat the same old
falsehoods with no central theme jumping all over the place from Ra/
Dec terns to geocentric ones or using celestial sphere geometry. to
justIify heliocentric and axial rotational motions.In lieu of any real
astronomical authority in existence to seperate the terms and untangle
the contrived mess created in the late 17th century,here are the basic
working principles -
Geocentric - The Earth centered solar system (Antiquity to the
Copernican discovery)
Many assume an Earth centered Universe however any astronomer worthy
of the name would simply look at how the original heliocentric
astronomers viewed the precepts of their antecent geocentric
counterparts -
"With regard to Venus and Mercury, however, differences of opinion are
found. For, these planets do not pass through every elongation from
the sun, as the other planets do. Hence Venus and Mercury are located
above the sun by some authorities, like Plato's Timaeus [38 D], but
below the sun by others, like Ptolemy [Syntaxis, IX, 1] and many of
the modems. Al-Bitruji places Venus above the sun, and Mercury below
it. " COPERNICUS
http://webexhibits.org/calendars/yea...opernicus.html
Heliocentric system (Copernicus to present) - the orbital motion of
the Earth between Venus and Mars by using orbital motion to resolve
the observed behavior of the other planets ,their periodic times to
resolve the placement of the Earth between the 225 day orbital period
of Venus and the 687 day period of Mars with axial rotation as a means
to resolve the observed daily cycle.
Ra/Dec or celestial sphere approach (Flamsteed to present) - the
practice of using celestial sphere geometry to justify axial and
orbital motions of the Earth where the stars have an undefined
equidistant geometry to the Earth.It was originally created to resolve
determination of terrstrial longitudes for marine navigational
purposes by Flamsteed but was extended by Newton to heliocentric
reasoning.
Many are inclined to use bluster which others mistake for confidence
or authority however there is always hope that there are actually
genuine people who are not afraid of the unfamiliarity with the
difference between geocentric and heliocentric reasoning as it was
orginally understood,the actual principles which keep clocks in sync
with the daily cycle at 24 hours/360 degrees,the observational
convenience of the Ra/Dec system,the actual principles which
distinguish timekeeping and structural astronomy from the
observational convenience ,the modifications required to bring
perceptions up to speed with modern observations and many,many more
realistic approaches to honor human reasoning.
but I thought I would brush up on my vector algebra and solve
> this problem by...
>
> (1) considering the earth's orbit as an ellipse
> (2) using Kepler's "equal area for equal time" rule of orbit speed
> (3) general mapping of 3D coordinates from one basis (Earth's lat/lon grid)
> to another (Earth's orbital plane 23.5 degrees oblique)
> (4) the astronomer's publishing of GMT for perihelion and summer solstice
> (5) looking iteratively for when the vector from the sun to the observer is
> basically perpendicular to the vector from the earth's center to the
> observer
>
> Well, after working almost a month I've got a 'C' program that seems to get
> within 6 minutes of the U.S. Navy's published times. I actually learned a
> lot about vector operations. For now I'm going to put this thing to rest,
> but here's the code...
>
> =============================================================================================================
> system is ...
>
> read more »
Andrew Gabriel
"TR Oltrogge" <trolt...@verizon.net> writes:
>
> Well, after working almost a month I've got a 'C' program that seems to get
> within 6 minutes of the U.S. Navy's published times. I actually learned a
> lot about vector operations. For now I'm going to put this thing to rest,
> but here's the code...
Could you post it again without losing all the line breaks
in the second half?
Thanks
--
Andrew
TR Oltrogge
"Andrew Gabriel" <and...@cucumber.demon.co.uk> wrote in message
news:480bcdd8$0$638$5a6a...@news.aaisp.net.uk...
In the almost three weeks since I posted this 'C' program I cleaned it up a
little but kept the same logic. I moved some code into subroutines since it
was used several times from different places. Also, my first posting didn't
include the source for the cross-product and dot-product of vectors since
these were pulled from a VCTRSUPPORT.h file I had previously developed. I am
still at a loss to figure out why I've got about 6 minutes of error (seems
to vary from about 5 to 7 depending on the time of year) but am not willing
"fudge" any of my geometrically accurate analysis to eliminate it.
Anyway, I've moved the tidied source code for the SUNSET program and its
support VCTRSUPPORT header to my web site where you can download them. I
wish I had a nice drawing to show the geometry that I'm solving, but it's
all in my head! If you have questions I can give references to the web sites
that showed me how to solve Kepler's ellipitical orbit calculation. My
source files are located at...
mysite.verizon.net/troltrogge/sunset.c
and
TR Oltrogge
> a little but kept the same logic. I moved some code into subroutines since
> it was used several times from different places. Also, my first posting
> didn't include the source for the cross-product and dot-product of vectors
> since these were pulled from a VCTRSUPPORT.h file I had previously
> developed. I am still at a loss to figure out why I've got about 6 minutes
> of error (seems to vary from about 5 to 7 depending on the time of year)
> but am not willing "fudge" any of my geometrically accurate analysis to
> eliminate it.
>
> Anyway, I've moved the tidied source code for the SUNSET program and its
> support VCTRSUPPORT header to my web site where you can download them. I
> wish I had a nice drawing to show the geometry that I'm solving, but it's
> all in my head! If you have questions I can give references to the web
> sites that showed me how to solve Kepler's ellipitical orbit calculation.
> My source files are located at...
>
> mysite.verizon.net/troltrogge/sunset.c
>
> and
>
> mysite.verizon.net/troltrogge/VCTRSUPPORT.h
>
following two equations in solving the mathematics of elliptical
orbits...
(1) M = 2 * PI * t / T
where 'M' is the "mean" anomaly, 't' is the time since perihelion, and
'T' is the orbital period
(2) M = E - e * sin (E)
where 'E' is the "eccentric" anomaly, and 'e' is the eccentricity of
the ellipse
The goal here is to first calculate 'M' from 't'. 'T' is 365 days 6 hours
13 minutes and 53 seconds, the time
in an "anomalistic" orbit (perihelion to perihelion). This is 31558433
seconds. Then we use the second
equation to solve for 'E' since we now know 'M' and 'e'. Unfortunately,
equation (2) cannot be solved via
algebra. But a formula involving an infinite series will get it
accurately enough with about three terms...
E = M + (e - 1/8 * e^3) * sin (M) + 1/2 * e^2 * sin (2 * M) + 3/8 *
e^3 * sin(3 * M) + ...
Once we get 'E' we substitute this value into the following equation to
get 'v' (angle of the earth from the
sun, where v=0 at perihelion)...
(3) v = arctan ( sqrt ((1 + e) / (1 - e)) * tan ( E / 2) ) * 2
where 'v' is the polar coordinate angle (from the sun) for the earth
at time 't'
Then we simply plug 'v' into the equation for an ellipse (in polar
coordinates) to get 'r' (the distance from
the sun)...
(4) r = a * (1 - e^2) / (1 + e * cos (v) )
where 'a' is the semi-major axis
A final conversion of 'v' and 'r' into cartesian coordinates is made by
x = r * cos ( v )
y = r * sin ( v )
The 'sun-earth' X coordinate and Y coordinate are now known as a function
of time 't'. The Z coordinate is
always zero since the orbit is in the X-Y plane.
(1) Latitude and Longitude
Z= 4000*sin(lat)
Y=(4000*cos(lat))*sin(lon)
X=(4000*cos(lat))*cos(lon)
(2) Elapsed Time
Z= 4000*sin(lat)
Y=(4000*cos(lat))*sin(lon+t/SIDEREAL_DAY*360)
X=(4000*cos(lat))*cos(lon+t/SIDEREAL_DAY*360)
an angle of 23.5 degrees with the
CONVERSION OF COORDINATES BETWEEN TWO COORDINATE SYSTEMS
#define SECONDS_PER_ORBIT (365*86400+6*3600+13*60+53) //Number of seconds in
a true orbit (anomalistic) of the sun
#define ECCENTRICITY 0.0167 //Earth's elliptical
orbit eccentricity
#define AXIS_TILT 23.45 //Number of degrees of
tilt in the earth's axis
double obs_lat=40.267; //Observer's latitude (positive is northern
hemispere, negative is southern hemisphere)
double obs_lon=-80.117; //Observer's longitude (positive is east of
Greenwich, negative is west of Greenwich)
//double obs_lat=45.0; //Observer's latitude (positive is northern
hemispere, negative is southern hemisphere)
//double obs_lon=-120.0; //Observer's longitude (positive is east of
Greenwich, negative is west of Greenwich)
typedef struct {
int yr; //2008, 2009, 2010, etc
int mo; //1=JAN, 2=FEB, etc
int da; //1-31
int hh; //0-23
int mm; //0-59
int ss; //0-59
int tzone; //0=GMT -5=EST, etc
} datim;
// YYYY MM DD HH MM SS Z
datim perihelion={2008, 1, 3, 0, 0, 0,0}; //Date/time (GMT) of perihelion
(earth closest to sun, our t=0)
datim s_solstice={2008, 6,20,23,59, 0,0}; //Date/time (GMT) of summer
solstice (tilt_z leans toward sun)
//Other interesting, but unneeded, dates
//datim sp_equinox={2008, 3,20, 5,48, 0,0}; //Date/time (GMT) of spring
equinox (sun_earth perpend to tilt_z)
//datim aphelion ={2008, 7, 4, 8, 0, 0,0}; //Date/time (GMT) of aphelion
(earth farthest from sun)
//datim fa_equinox={2008, 9,22,15,44, 0,0}; //Date/time (GMT) of fall
equinox (sun_earth perpend to tilt_z again)
//datim w_solstice={2008,12,21,12, 4, 0,0}; //Date/time (GMT) of winter
solstice (tilt_z leans away from sun)
//The three vectors for the secondary coord system (described in primary
coord system components)
VECTOR tilt_z; //Z-axis of secondary coord syst def'd in *primary
coords* (earth's rotation axis)
VECTOR tilt_x; //X-axis of secondary coord syst def'd in *primary
coords* (prime meridian at t=0)
VECTOR tilt_y; //Y-axis of secondary coord syst def'd in *primary
coords* (90 degrees east longitude)
//Three unit vectors described in the primary coord system used for
computing direction cosines
VECTOR unit_x={1,0,0};
VECTOR unit_y={0,1,0};
VECTOR unit_z={0,0,1};
//The nine direction cosines
double a11,a12,a13,a21,a22,a23,a31,a32,a33;
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
//Function prototypes
int date_to_time (datim *d,long *t);
int adjust_date (datim *dt,long time);
int calc_angle (datim *dt,double *angle);
int calc_sun_earth_vector (datim *dt,VECTOR *se);
int print_vec (VECTOR *v); //Debug support
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
/*
Convert a date and time-of-day value to the time elapsed since perihelion
(t=0)
*/
int days_in_month[12]={31,28,31,30, 31, 30, 31, 31, 30, 31, 30, 31};
int cum_days[12] ={ 0,31,59,90,120,151,181,212,242,273,303,334};
int date_to_time(datim *d,long *t) {
int max_days;
long cum_d,cum_sec_perihelion,cum_sec_input,cum_sec_intervening,y;
if (d->yr < 1901 || d->yr > 2099) goto bad_datim; //Century
years not leap unless divisible by 400
if (d->mo < 1 || d->mo > 12) goto bad_datim; //Month in
range?
max_days=days_in_month[d->mo-1]+((!(d->yr%4) && d->mo==2) ? 1 : 0);
//Account for Feb in leap year
if (d->da < 1 || d->da > max_days) goto bad_datim; //Day in
range?
if (d->hh < 0 || d->hh > 23) goto bad_datim; //Hour in
range?
if (d->mm < 0 || d->mm > 59) goto bad_datim; //Minute in
range?
if (d->ss < 0 || d->ss > 59) goto bad_datim; //Second in
range?
if (d->tzone < -12 || d->tzone > 11) goto bad_datim; //Time zone in
range?
//Calc # seconds perihelion date/time is into its own year
cum_d=cum_days[perihelion.mo-1] //Start with #
days in prior months
+((!(perihelion.yr%4) && perihelion.mo>2) ? 1 : 0); //Add 1 if
beyond Feb in leap yr
cum_d+=perihelion.da-1; //Add # days
into month
cum_sec_perihelion=cum_d*86400 //Cum secs
total starts w/secs in prior days
+(perihelion.hh-perihelion.tzone)*3600 //Plus secs in
prior hrs of day (adj for tzone)
+perihelion.mm*60 //Plus secs in
prior mins
+perihelion.ss; //Plus secs
into current min
//Calc # seconds input date/time is into its own year
cum_d=cum_days[d->mo-1] //Start with #
days in prior months
+((!(d->yr%4) && d->mo>2) ? 1 : 0); //Add 1 if
beyond Feb in leap yr
cum_d+=d->da-1; //Add # days
into month
cum_sec_input=cum_d*86400 //Cum secs
total starts w/secs in prior days
+(d->hh-d->tzone)*3600 //Plus secs in
prior hrs of day (adj for tzone)
+d->mm*60 //Plus secs in
prior mins
+d->ss; //Plus secs
into current min
//Calc # seconds in intervening years starting at beginning of perihelion
year
for (cum_sec_intervening=0,y=perihelion.yr;y<d->yr;y++) //For all
intervening years
cum_sec_intervening+=(365*86400)+(!(y%4) ? 86400 : 0); //Add # secs
in year, accounting for leap
*t=cum_sec_intervening-cum_sec_perihelion+cum_sec_input; //Subt
perihelion start fract, add input start fract
return(0);
bad_datim:
printf("date_to_time: invalid datim structure (%d/%d/%d %d:%d:%d
tZone:%d\n)\n",
d->yr,d->mo,d->da,d->hh,d->mm,d->ss,d->tzone);
return(1);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
int main() {
int it; //Time 't' as an integer
double t; //Time in seconds from initial position of earth
VECTOR sun_earth; //Vector from sun to earth's center
VECTOR normal; //Computed vector normal to orbital plane through the
sun
datim current_date; //Work area for constructing dates to be analyzed
double angle;
long delta_t;
double theta;
/*
OK, let's get started! First, calculate the constant 'tilt_z' vector (the
earth's axis of rotation) in the
primary coordinate system based on the fact that at summer solstice the
axis of the earth is, at that moment,
pointing *directly* at the sun. Another way to put it is that the normal
vector to the orbital plane, passing
through the sun, will intersect the earth's extended axis at some point
in the positive Z direction. Thus, a
right triangle is formed by the earth, the sun, and that point of
intersection in positive Z space. (This
condition also happens at winter solstice, but then the intersection is
in negative Z space.) The 'sun_earth'
vector at time of summer_solstice is the short leg of this right
triangle. The normal vector to the earth's
orbital plane and passing through the sun is the long leg of this
triangle. The hypotenuse is the 'tilt_z'
vector for the earth. The tangent of 23.45 degrees (0.4337751161) is the
ratio of the 'sun_earth' vector's
length to the length of the normal vector. So the length of the normal
vector is computed by dividing the length
of the 'sun_earth' vector by the tangent of 23.45 degrees.
*/
if (calc_sun_earth_vector(&s_solstice,&sun_earth)) {
printf("sunset: cannot use summer solstice date/time\n");
goto bad_exit;
}
// printf("sun_earth="); print_vec(&sun_earth); printf("\n"); //Debug
//OK, now have 'sun_earth' vector. Solve for normal vector's length from
right triangle relationship.
normal.x=0.0; //Normal vector has
no X component
normal.y=0.0; //Normal vector has
no Y component
normal.z=vector_length(&sun_earth)/tan(AXIS_TILT*PI/180); //Z length is
'sun_earth' length divided by tan(23.45)
// printf("normal="); print_vec(&normal); printf("\n"); //Debug
//The 'tilt_z' vector is the sum of the 'sun_earth' vector (negated) and the
'normal' vector
tilt_z.x=-sun_earth.x+normal.x; //Add 'em
tilt_z.y=-sun_earth.y+normal.y; // "
tilt_z.z=-sun_earth.z+normal.z; // "
// printf("tilt_z="); print_vec(&tilt_z); printf("\n"); //Debug
/*
OK, now have 'tilt_z' vector described in primary coordinates. We now
need the 'tilt_x' and 'tilt_y' vectors.
These are both perpendicular to the 'tilt_z' vector and the 3 of them are
the axes for the secondary coordinate
system. 'tilt_x' points from the earth's center through the earth's
equator at the longitude of the prime
meridian at time t=0. It will also be constant, not changing as the earth
orbits or rotates. 'tilt_x' will tell
us the exact orientation of the earth in its rotation about its axis at
t=0. 'tilt_y' is nothing more than the
vector from the earth's center through the equator at longitude east 90
degrees. It will be calculated via a
cross product of 'tilt_z' and 'tilt_x' once 'tilt_x' has been
ascertained.
Working with the summer solstice again, this time let's make a right
triangle using the 'sun_earth' vector as
the long leg. The normal vector to the earth's orbital plane going
through the sun and going in the *negative*
Z direction is the short leg. The hypotenuse is related to the 'tilt_x'
vector since it goes from the earth's
center out the equator but at a longitude that is *not* the prime
meridian. *If* the prime meridian were
aligned exactly with this hypotenuse at the time of summer solstice then
it would be exactly noon GMT at the
summer solstice. But, instead, it is some other time (GMT) at summer
solstice (23:59 for 2008, not 12:00) and so
we know the prime meridian is rotated (on the 'tilt_z' axis) an angle of
(23:59-12:00)/SIDEREAL_DAY*360) degrees
from the orientation of the hypotenuse of our right triangle. But this is
all we need to know in order to "back
out" all the rotations of the prime meridian (which is the 'tilt_x'
vector) that have happened since the
date/time of perihelion. Then we will have the correct 'tilt_x' vector
value we want. Back to our second right
triangle. The tangent of 23.45 degrees is the ratio of the length of the
negative-Z-going normal vector to the
'sun_earth' vector's length. So the length of this negative-Z-going
normal vector is the product of the
'sun_earth' vector's length and the tangent of 23.45 degrees.
*/
normal.x=0.0; //There's no X component of any vector normal to the
orbital plane
normal.y=0.0; //Also, no Y component
normal.z=-vector_length(&sun_earth)*tan(AXIS_TILT*PI/180); //Z component
from right triangle relationship
// printf("normal(-Z)="); print_vec(&normal); printf("\n");
//The 'tilt_x' vector (as a starting point) is the sum of the 'sun_earth'
vector and the 'normal' vector (negated)
tilt_x.x=sun_earth.x-normal.x;
tilt_x.y=sun_earth.y-normal.y;
tilt_x.z=sun_earth.z-normal.z;
// printf("tilt_x(start)="); print_vec(&tilt_x); printf("\n");
//The prime meridian is (Time at GMT)/SIDEREAL_DAY*360 degrees
counterclockwise from the "midnight" vector
it=s_solstice.hh*3600+s_solstice.mm*60+s_solstice.ss;
t=it; //Convert time to float
theta=t/SIDEREAL_DAY*2*PI;
vector_rotate(&tilt_x,&tilt_z,theta); //Rotate small amt to get prime
meridian at GMT of summer solstice
// printf("tilt_x(at GMT)="); print_vec(&tilt_x); printf("\n");
//Unwind tilt_x vector to its position at perihelion (find the angle of
clockwise rotation needed)
if (date_to_time(&s_solstice,&it)) { //Convert summer solstice date/time
to secs since perihelion
printf("sunset: unable to convert summer solstice date/time to
seconds\n");
goto bad_exit;
}
t=it; //Convert time to float
theta=-t/SIDEREAL_DAY*2*PI; //This is angle to unwind *for the specific
meridian* aligned with 'sun-earth' vector
vector_rotate(&tilt_x,&tilt_z,theta); //Unwind 'tilt_x' vector until t=0
// printf("tilt_x(final, at t=0)="); print_vec(&tilt_x); printf("\n");
//Take cross product of 'tilt_z' with 'tilt_x' to generate our 'tilt_y'
perpendicular to both
cross_product(&tilt_z,&tilt_x,&tilt_y);
//Compute the nine direction cosines for secondary to primary axes
conversion
a11=dot_product(&unit_x,&tilt_x)/(vector_length(&unit_x)*vector_length(&tilt_x));
a12=dot_product(&unit_x,&tilt_y)/(vector_length(&unit_x)*vector_length(&tilt_y));
a13=dot_product(&unit_x,&tilt_z)/(vector_length(&unit_x)*vector_length(&tilt_z));
a21=dot_product(&unit_y,&tilt_x)/(vector_length(&unit_y)*vector_length(&tilt_x));
a22=dot_product(&unit_y,&tilt_y)/(vector_length(&unit_y)*vector_length(&tilt_y));
a23=dot_product(&unit_y,&tilt_z)/(vector_length(&unit_y)*vector_length(&tilt_z));
a31=dot_product(&unit_z,&tilt_x)/(vector_length(&unit_z)*vector_length(&tilt_x));
a32=dot_product(&unit_z,&tilt_y)/(vector_length(&unit_z)*vector_length(&tilt_y));
a33=dot_product(&unit_z,&tilt_z)/(vector_length(&unit_z)*vector_length(&tilt_z));
/*
OK, now test all our logic by choosing some date/time values and then
calculating the 'sun_earth' vector, the
'earth_observer' vector, the 'sun_observer' vector, and the angle between
the 'sun_observer' and
'earth_observer' vectors. When the angle is close to 90 degrees then we
have a sunrise or sunset.
Given a date/time determine the time of sunrise and sunset for that date.
Do this by iterating times during
the date and check that the angle of the sun is close enough to
SUN_RISE_SET_ANGLE.
*/
for (current_date.yr=2008;current_date.yr<=2008;current_date.yr++)
{ //Do several years, if wanted
printf("YEAR %d\n\n",current_date.yr);
printf(" JAN FEB MAR APR MAY
JUN JUL AUG SEP OCT NOV DEC\n");
printf(" --------- --------- --------- --------- --------- ---------
--------- --------- --------- --------- --------- ---------\n");
for (current_date.da=1;current_date.da<=31;current_date.da++)
{ //Consider 31 days in each month
printf("%2d ",current_date.da);
//Print line starts with the day #
for (current_date.mo=1;current_date.mo<=12;current_date.mo++)
{ //Consider 12 months in the year
if (current_date.da>(days_in_month[current_date.mo-1]
//If day-of-month beyond max for the month
+((!(current_date.yr%4) && current_date.mo==2) ? 1 : 0)))
{ //Account for Feb in leap year
printf(" ");
//Issue blanks for non-existent date
continue;
//But keep going
}
// current_date.yr=2008;
// current_date.mo=1;
// current_date.da=1;
current_date.hh=12; //Start iterative time search at noon - sun
should be definitely up!
current_date.mm=0;
current_date.ss=0;
current_date.tzone=-5;
//First, work earlier in the day looking for sunrise
if (calc_angle(¤t_date,&angle)) { //Get the angle for noon
printf("bad return from 'calc_angle'\n");
goto bad_exit;
}
if (angle<SUN_RISE_SET_ANGLE) { //If sun is below the horizon
at noon (!)
printf("error: sun below horizon at noon!\n");
goto bad_exit;
}
for (delta_t=-3600;abs(delta_t)>0;) { //Iterate to earlier time
starting with one hour movement
adjust_date(¤t_date,delta_t); //Use 'delta_t' to get
another date/time to look at
if (calc_angle(¤t_date,&angle)) { //Get the angle for this new
time
printf("bad return from 'calc_angle'\n");
goto bad_exit;
}
// printf("trying %02d:%02d:%02d gives %.3f
degrees\n",current_date.hh,current_date.mm,current_date.ss,angle);
if (angle<SUN_RISE_SET_ANGLE) { //If we're earlier than
sunrise
if (delta_t<0) //If we were moving toward
earlier times
delta_t/=-2; //Halve the time increment
and reverse its direction
continue; //Stay in the iteration
}
if (angle>SUN_RISE_SET_ANGLE) { //If we're later than sunrise
if (delta_t>0) //If we were moving toward
later times
delta_t/=-2; //Halve the time increment
and reverse its direction
continue; //Stay in the iteration
}
break; //If we're right (exactly) at
sunrise, then stop the iteration
}
printf("%02d%02d ",current_date.hh,current_date.mm);
current_date.hh=12; //Reset starting date/time to
noon again
current_date.mm=0;
current_date.ss=0;
for (delta_t=3600;abs(delta_t)>0;) { //Iterate to later time
starting with one hour movement
adjust_date(¤t_date,delta_t); //Use 'delta_t' to get
another date/time
if (calc_angle(¤t_date,&angle)) { //Get the angle for this new
time
printf("bad return from 'calc_angle'\n");
goto bad_exit;
}
// printf("trying %02d:%02d:%02d gives %.3f
degrees\n",current_date.hh,current_date.mm,current_date.ss,angle);
if (angle>SUN_RISE_SET_ANGLE) { //If we're earlier than
sunset
if (delta_t<0) //If we were moving toward
earlier times
delta_t/=-2; //Halve the time increment
and reverse its direction
continue; //Stay in the iteration
}
if (angle<SUN_RISE_SET_ANGLE) { //If we're later than sunset
if (delta_t>0) //If we were moving toward
later times
delta_t/=-2; //Halve the time increment
and reverse its direction
continue; //Stay in the iteration
}
break; //If we're right (exactly) at
sunset, then stop the iteration
}
printf("%02d%02d ",current_date.hh,current_date.mm);
}
printf("\n");
}
}
return(0);
bad_exit:
return(1);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
double t,lon,lat,dp;
VECTOR sun_earth; //Vector from sun to earth's center
VECTOR earth_observer; //Vector from earth's center to the observer at given
latitude, longitude, and time
VECTOR obs; //Vector from earth's center to observer's point
(after time rotation) in *secondary coords*
VECTOR sun_observer; //Vector from sun to the observer's tangent point
if (calc_sun_earth_vector(dt,&sun_earth)) {
printf("calc_angle: unable to calculate sun_earth vector\n");
goto bad_exit;
}
if (date_to_time(dt,&it)) { //Convert date/time structure to a time
't' in seconds since perihelion
printf("calc_angle: cannot use input date/time\n");
goto bad_exit;
}
t=it; //Convert time to
float
//Second calculate observer's latitude/longitude in secondary coords with
elapsed time increasing longitude
lon=obs_lon+t/SIDEREAL_DAY*360.0; //Compute longitude
with time rotation done
lat=obs_lat ; //Latitude always
stays the same
obs.z= 4000.0*sin(lat*PI/180.0); //Observer's vector
from earth's center (secondary coords)
obs.y=(4000.0*cos(lat*PI/180.0))*sin(lon*PI/180.0); // "
obs.x=(4000.0*cos(lat*PI/180.0))*cos(lon*PI/180.0); // "
//Change vector in secondary system to vector in primary system coords
earth_observer.x=a11*obs.x+a12*obs.y+a13*obs.z; //Now transform to
primary system
earth_observer.y=a21*obs.x+a22*obs.y+a23*obs.z; // "
earth_observer.z=a31*obs.x+a32*obs.y+a33*obs.z; // "
//Vector from sun to observer is sum of vector from sun to earth plus
observer's vector from earth center
sun_observer.x=sun_earth.x+earth_observer.x;
sun_observer.y=sun_earth.y+earth_observer.y;
sun_observer.z=sun_earth.z+earth_observer.z;
//The dot-product of the 'earth_observer' vector and 'sun_observer' vector
allows us to calculate the angle
dp=dot_product(&sun_observer,&earth_observer);
*angle=acos(dp/(vector_length(&sun_observer)*vector_length(&earth_observer)));
*angle*=180.0/PI; //Convert radians to
degrees
return(0);
bad_exit:
return(1);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
int calc_sun_earth_vector(datim *dt,VECTOR *se) {
long it; //Time in seconds past perihelion (integer)
double t; //Time in seconds past perihelion (floating
point)
double M; //The "mean" anomaly angle
double E; //The "eccentric" anomaly angle
double v; //Angle, in radians, of earth in its orbit from
its initial position
double r; //Polar coordinate 'radius' of earth
int i;
if (date_to_time(dt,&it)) { //Convert date/time structure to a time
't' in seconds since perihelion
printf("calc_sun_earth_vector: cannot use input date/time\n");
goto bad_exit;
}
t=it; //Convert time
to float
M=2*PI*t/SECONDS_PER_ORBIT; //Calculate
Kepler's "Mean" anomaly
/*
The following equation solves for E, given M, using the first 3 terms of
an infinite series. The equation
that it's solving is Kepler's relationship between the Mean anomaly M and
the Eccentric anomaly E...
E = M - e * sin E
*/
E=M //Compute
Kepler's "Eccentric" anomaly (approximately)
+(ECCENTRICITY-1.0/8.0*pow(ECCENTRICITY,3.0))*sin(1.0*M) //using the
first three terms of an infinite series
+ 1.0/2.0*pow(ECCENTRICITY,2.0) *sin(2.0*M) // "
+ 3.0/8.0*pow(ECCENTRICITY,3.0) *sin(3.0*M); // "
/*
Another way to solve for E is iteratively using the conditions...
E[0] = M
E[i+1] = M + e * sin( E[i] )
E=M;
for (i=0;i<5;i++) { //Here's 5 iterations
E=M+ECCENTRICITY*sin(E);
}
But I've found the three terms of the infinite series works fine.
*/
v=atan(sqrt((1.0+ECCENTRICITY)/(1.0-ECCENTRICITY))*tan(E/2.0))*2.0;
//"Eccentric" anomaly gives polar coord angle
r=SEMI_MAJOR_AXIS*(1.0-pow(ECCENTRICITY,2.0))/(1.0+ECCENTRICITY*cos(v));
//Eq for ellipse gives radius from angle
se->x=r*cos(v); //Convert polar to cartesian
se->y=r*sin(v); // "
se->z=0.0; //There's never any Z component for earth's center
return(0);
bad_exit:
return(1);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
int print_vec(VECTOR *v) {
printf("%.1fx %.1fy %.1fz",v->x,v->y,v->z);
return(0);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
// VCTRSUPPORT.h
//= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =
//= = = = = = = = = = = = = = = 3D VECTOR AND GEOMETRIC PROCESSING ROUTINES
= = = = = = = = = = = = = = = = = = = =
//= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =
/*
Minimum angle to call lines parallel or perpendicular is arbitrarily set
to 0.1 degrees. The sine of 0.1 degrees is 0.001745.
*/
#define MIN_SINE 0.001745
#define MIN_COSINE 0.001745
//- - - - - - - - - DEFINE GEOMETRIC TYPES (POINT, VECTOR, LINE, PLANE,
TRIANGLE, etc) - - - - - - - - - - - - - -
typedef struct { //A POINT has a single definition and is
defined by...
double x,y,z; //Its 3 orthogonal (x,y,z) coords rel to
the origin
} POINT;
typedef struct { //A VECTOR has a single definition and is
defined by...
double x,y,z; //Its 3 orthogonal (x,y,z) composite vector
lengths
} VECTOR;
typedef struct { //A LINE's preferred
definition is...
POINT lp; //Any arbitrary POINT on
the line
VECTOR lv; //And a direction
VECTOR
} LINE;
/*
Note: In geometry a line has no inherit "direction" but in our "vector"
description
the VECTOR will allow us to consider the LINE to be "flowing" in one of
two directions
as well as to distinguish between the 'left' and 'right' sides of the
LINE.
*/
typedef struct { //A line may also be
defined by...
POINT lp1; //Any two
points
POINT lp2; //On
the line
} line_2pt;
typedef struct { //A PLANE's preferred definition is in Hessian
form...
VECTOR pn; //A (possibly unit) VECTOR normal to
the plane
double d; //And d, the distance of the plane from
the origin
} PLANE;
typedef struct { //Or, in pure scalar (coordinate) terms, as...
double A,B,C,D; //The general equation
Ax+By+Cz+D=0
} plane_coord;
typedef struct { //Or, as...
POINT pp; //Any point on
the plane
VECTOR pv1,pv2; //And 2 non-parallel direction
vectors
} plane_pt2v;
typedef struct { //A TRIANGLE is defined
preferably by...
POINT tp;
//A POINT
VECTOR tv1,tv2; //And 2 non-parallel VECTORs which define the other two
corners
} TRIANGLE;
typedef struct { //A TRIANGLE may also be
defined by...
POINT tp1,tp2,tp3; //Three distinct non-colinear
POINTs
} triangle_3pt;
//- - - - - - - - - - - - FUNCTION PROTOTYPES OF BASIC GEOMETRIC
OPERATIONS - - - - - - - - - - -
int vector_1_point (POINT *p,VECTOR *v);
int vector_2_points (POINT *p1,POINT *p2,VECTOR *v);
double distance_2_points (POINT *p1,POINT *p2);
double vector_length (VECTOR *v);
int vector_add (VECTOR *v1,VECTOR *v2,VECTOR *v3);
int vector_sub (VECTOR *v1,VECTOR *v2,VECTOR *v3);
int vector_mpy (VECTOR *v,double scale);
int vector_resize (VECTOR *v,double vector_len);
double dot_product (VECTOR *v1,VECTOR *v2);
int cross_product (VECTOR *v1,VECTOR *v2,VECTOR *v3);
int plane_3_points (POINT *a,POINT *b,POINT *c,PLANE *pl);
int intersect_line_plane (LINE *l,PLANE *pl,POINT *p);
int plane_from_pt_2v (POINT *p,VECTOR *v1,VECTOR *v2,PLANE *pl);
int lines_2_closest_points (LINE *l1,LINE *l2,POINT *pa,POINT *pb);
double distance_2_lines (LINE *l1,LINE *l2,LINE *l3);
int intersect_2_planes (PLANE *pl1,PLANE *pl2,LINE *l);
int triangle_from_3pt (POINT *p1,POINT *p2,POINT *p3,TRIANGLE *t);
int line_2_points (POINT *p1,POINT *p2,LINE *l);
int vector_rotate (VECTOR *X,VECTOR *U,double theta);
//- - - - - - - - - - - - - FUNCTION CODE FOR BASIC GEOMETRIC
OPERATIONS - - - - - - - - - - -
/*
A VECTOR is constructed from the origin to a POINT. If the point is the
origin itself a null
vector will result, but this is not a problem. Zero is always returned.
*/
int vector_1_point(POINT *p,VECTOR *v) {
v->x=p->x;
v->y=p->y;
v->z=p->z;
return(0);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
A VECTOR is constructed from two POINTs. If the two points are the same
then a null vector
will result, but this is not a problem. Zero is always returned.
*/
int vector_2_points(POINT *p1,POINT *p2,VECTOR *v) {
v->x=p2->x-p1->x;
v->y=p2->y-p1->y;
v->z=p2->z-p1->z;
return(0);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
The distance between two points is calculated via the Pythagorean
theorem. If the points are
identical the value 0.0 will be returned so no check is needed.
*/
double distance_2_points(POINT *p1,POINT *p2) {
return sqrt((p2->x - p1->x) * (p2->x - p1->x) +
(p2->y - p1->y) * (p2->y - p1->y) +
(p2->z - p1->z) * (p2->z - p1->z));
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
The length of a VECTOR is returned. No check for a null vector is needed.
*/
double vector_length(VECTOR *v) {
return sqrt(v->x * v->x + v->y * v->y + v->z * v->z);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
Add two VECTORs v1 and v2, giving a third VECTOR v3. No check for null
vectors is needed.
Zero is always returned.
*/
int vector_add(VECTOR *v1,VECTOR *v2,VECTOR *v3) {
v3->x=v1->x+v2->x;
v3->y=v1->y+v2->y;
v3->z=v1->z+v2->z;
return(0);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
Subtract VECTOR v2 from v1, giving a third VECTOR v3. No check for null
vectors is needed.
Zero is always returned.
*/
int vector_sub(VECTOR *v1,VECTOR *v2,VECTOR *v3) {
v3->x=v1->x-v2->x;
v3->y=v1->y-v2->y;
v3->z=v1->z-v2->z;
return(0);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
Multiply the lengths of each of the three components of a VECTOR 'v' by
'scale'. The vector
'v' is modified as a result. 'scale' may be 0.0 resulting in 'v' becoming
the null vector.
This is not a problem. Zero is always returned.
*/
int vector_mpy(VECTOR *v,double scale) {
v->x*=scale;
v->y*=scale;
v->z*=scale;
return(0);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
Resize the VECTOR 'v' so its length is 'vector_len'. The vector 'v' is
modified as a result.
'vector_len' may be 0.0 resulting in 'v' becoming the null vector. This
is not a problem.
If 'vector_len' is less than zero then the direction of 'v' will be
reversed because the
sign of each of its component vectors will be reversed. In this case the
length of 'v' will
be set to the absolute value of 'vector_len'. Again, this is not a
problem.
*/
int vector_resize(VECTOR *v,double vector_len) {
double factor;
/* if (vector_len<=0.0) return(0); Old logic forbidding 'vector_len' to be
negative */
factor=vector_length(v); //Get
original length of 'v'
if (factor==0.0)
{ //If it's zero
if (vector_len==0.0) { //But caller actually wants
final length zero
v->x=0.0; v->y=0.0; v->z=0.0; //Then make sure they really
are absolute zero
}
else { //Otherwise, caller wants a non-zero final length, but
that's impossible
return(1);
//So return failure
}
}
else { //Otherwise, original
length was not zero
factor=vector_len/factor; //So calc scale factor (may be zero if
'vector_len' is zero)
v->x*=factor; v->y*=factor; v->z*=factor; //And apply it to
all the components
}
return(0);
//Return success
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
The dot product of the two vectors v1 and v2 is returned. If the two
vectors are *essentially* perpendicular return 0.0.
*/
double dot_product(VECTOR *v1,VECTOR *v2) {
double temp,dp;
if (v1->x==0.0 && v1->y==0.0 && v1->z==0.0 || //If
either
v2->x==0.0 && v2->y==0.0 && v2->z==0.0) { //vector is
NULL
/* printf("v=null "); */
return(0.0); //Pretend they are perpendicular and
return 0.0
}
dp=v1->x * v2->x + v1->y * v2->y + v1->z * v2->z; //Compute dot
product
if (dp==0.0) { //If dot product has gone to
zero
/* printf("dp=0.0 "); */
return(0.0); //Vectors must be perpendicular so
return 0.0
}
/*
Since the magnitude of the dot product of two vectors is the product of
their magnitudes times the cosine of the angle between them I can solve
for the cosine of the angle between them by dividing the already computed
dot product's magnitude by the product of their individual magnitudes. If
this cosine is close to zero then the angle must be close to 90 degrees.
If so, the vectors are 'essentially' perpendicular.
*/
temp=vector_length(v1)*vector_length(v2); //Get product of vector
lengths
if (temp==0.0) { //If product of vector lengths has gone to
zero
/* printf("v*v=null "); */
return(0.0); //Vectors must be
perpendicular
}
if (fabs(dp)/temp<MIN_COSINE) //If cosine of angle close to
zero
return(0.0); //Vectors must be
perpendicular
return(dp); //Otherwise, return normal dot
product
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
The cross product of the two VECTORS v1 and v2 is returned as a VECTOR in
v3. If either of the
two vectors are null *or* the two vectors are essentially parallel return
1 (since there is no
cross product), otherwise return 0.
*/
int cross_product(VECTOR *v1,VECTOR *v2,VECTOR *v3) {
double divisor;
if (v1->x==0.0 && v1->y==0.0 && v1->z==0.0 ||
//If either
v2->x==0.0 && v2->y==0.0 && v2->z==0.0) {
//vector is null
v3->x=0.0; //Set the output
vector to null
v3->y=0.0;
v3->z=0.0;
return(1); //Pretend
parallel and return 1
}
v3->x=v1->y * v2->z - v2->y * v1->z;
v3->y=v1->z * v2->x - v2->z * v1->x;
v3->z=v1->x * v2->y - v2->x * v1->y;
if (v3->x==0.0 && v3->y==0.0 && v3->z==0.0) { //If computed
vector is null
return(1); //The inputs must have been
parallel, return 1
}
/*
THIS OPTIONAL CODE IMPLEMENTS THE "ESSENTIALLY PARALLEL" LOGIC IF YOU
WANT IT
Since the magnitude of the cross product of two vectors is the product of
their magnitudes
times the sine of the angle between them I can solve for the sine of the
angle between
them by dividing the already computed cross product's magnitude by the
product of their
individual magnitudes. If this sine is close to zero then the angle must
be close to zero
degrees. If so, the vectors are 'essentially' parallel.
divisor=vector_length(v1)*vector_length(v2); //Calc product of
input magnitudes
if (divisor==0.0) //If divisor has gone to zero input vectors too
small to work with
return(1); //Return the result
as if parallel
if ((vector_length(v3)/divisor)<MIN_SINE) //If sine of angle
is below minimum
return(1); //Return 'essentially'
parallel result
*/
return(0);
//Return normal result
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
Find the plane formed by three POINTs via function for finding a plane
from one POINT
and two VECTORS.
*/
int plane_3_points(POINT *a,POINT *b,POINT *c,PLANE *pl) {
VECTOR temp_v1,temp_v2;
temp_v1.x = b->x - a->x; //Create a VECTOR from
POINT 'a' to POINT 'b'
temp_v1.y = b->y - a->y;
temp_v1.z = b->z - a->z;
temp_v2.x = c->x - a->x; //Create a VECTOR from
POINT 'a' to POINT 'c'
temp_v2.y = c->y - a->y;
temp_v2.z = c->z - a->z;
if (plane_from_pt_2v(a,&temp_v1,&temp_v2,pl)==0)
//Transform to a PLANE
return(0); //If
subcontract went OK return 0
else //Otherwise, something's wrong with our input
(two points same?)
return(1);
//So return error
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
To calculate the intersection of a line and a plane use the vector
definitions of each...
_ _
n . p = d (normal vector and distance def. of PLANE)
_ _ _
p = p1 + t * l (point and vector def. of LINE)
_ _ _ _ _ _
n . (p1 + t * l) = d (subst p1 + t * l for p in PLANE equation)
_ _ _ _
n . p1 + t * n . l = d (using distributive law)
_ _ _ _
t = (d - n . p1) / (n . l) (solve for t)
_
Plug value for t into LINE eq. to get p
*/
int intersect_line_plane(LINE *l,PLANE *pl,POINT *p) {
double t,temp;
VECTOR p1v;
if ((temp=dot_product(&l->lv,&pl->pn))==0.0) //If line and plane parallel
return(1); //Return bad status 1
p1v.x=l->lp.x; p1v.y=l->lp.y; p1v.z=l->lp.z;
t=(pl->d-dot_product(&pl->pn,&p1v))/temp;
p->x = l->lp.x + t * l->lv.x;
p->y = l->lp.y + t * l->lv.y;
p->z = l->lp.z + t * l->lv.z;
return(0); //Return normal status 0
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/* Compute the Hessian form of the plane from the 2-vectors-and-point form.
_ _
n . p = d (normal vector and distance def. of
PLANE)
_ _ _ _ _
n = (v1 X v2) / |v1 X v2| (def. of unit normal vector to PLANE)
_ _ _ _ _
d = ((v1 X v2) / |v1 X v2|) . p (solve for d)
*/
int plane_from_pt_2v(POINT *p,VECTOR *v1,VECTOR *v2,PLANE *pl) {
double temp;
VECTOR tempv;
if (cross_product(v1,v2,&pl->pn)==1) //If 2 vectors parallel
return(1); //Return error
temp=vector_length(&pl->pn);
pl->pn.x/=temp; pl->pn.y/=temp; pl->pn.z/=temp; //Make norm vector unit
tempv.x=p->x; tempv.y=p->y; tempv.z=p->z;
pl->d=dot_product(&pl->pn,&tempv);
return(0); //Normal return
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -
/*
Given two lines 'l1' and 'l2' determine the point 'pa' on line 'l1' and
the
point 'pb' on line 'l2' that are the two closest points between the
lines.
The normal return is the value 0. This occurs even when the two lines
intersect and, therefore, 'pa' and 'pb' are the same point. This is not
an
error. If the given lines are parallel then there are no unique points
you
can call 'closest'. In that case a 1 is returned as an error indication
and
the resulting values for 'pa' and 'pb' are undefined.
*/
int lines_2_closest_points(LINE *l1,LINE *l2,POINT *pa,POINT *pb) {
VECTOR c;
PLANE pl1,pl2;
if (cross_product(&l1->lv,&l2->lv,&c)==1) { /* If lines are parallel
*/
return(1);
}
/*
In the next 4 function calls (plane_from_pt_2v and intersect_line_plane)
the
check for an error '1' return is for safety only. Because the two input
lines
have already been shown to be non-parallel these calculations *should*
return
a normal result. If, though, for any reason these functions *do* return
an
error result it might be because of precision problems and so we must
then
return error '1' just as if our first test for parallel lines had been
true.
It should never happen if we get this far.
*/
/* form plane containing line l1, parallel to vector c
*/
if (plane_from_pt_2v(&l1->lp,&l1->lv,&c,&pl1)==1)
return(1);
/* form plane containing line l2, parallel to vector c
*/
if (plane_from_pt_2v(&l2->lp,&l2->lv,&c,&pl2)==1)
return(1);
/* closest point on l1 is where l1 intersects pl2
*/
if (intersect_line_plane(l1,&pl2,pa)==1)
return(1);
/* closest point on l2 is where l2 intersects pl1
*/
if (intersect_line_plane(l2,&pl1,pb)==1)
return(1);
/*
Interesting, but not necessary, code for distinguishing between
intersecting
or skew lines.
if (distance_2_points(pa,pb)==0.0) //Intersecting
else //Skew
*/
return(0); //Normal return
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -
double distance_2_lines(LINE *l1,LINE *l2,LINE *l3) {
POINT p1,p2;
if (lines_2_closest_points(l1,l2,&p1,&p2)==1) //If the lines are parallel
return(-1.0); //Return an error (in future could return singular
value)
l3->lp.x=p1.x; l3->lp.y=p1.y; l3->lp.z=p1.z;
l3->lv.x=p2.x-p1.x;
l3->lv.y=p2.y-p1.y;
l3->lv.z=p2.z-p1.z;
return(distance_2_points(&p1,&p2));
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -
/*
The intersection of the two planes pl1 and pl2 is returned as a line in
point-vector format in 'l'. If the planes are parallel 1 is returned.
Otherwise, 0.
*/
int intersect_2_planes(PLANE *pl1,PLANE *pl2,LINE *l) {
VECTOR *v1,*v2;
double determinant,c1,c2,d1,d2;
if (cross_product(&pl1->pn,&pl2->pn,&l->lv)==1)
return(1);
/* OK, they're not parallel, use Paul Bourke algorithm. */
v1=&pl1->pn; d1=pl1->d;
v2=&pl2->pn; d2=pl2->d;
determinant=dot_product(v1,v1)*dot_product(v2,v2)
-dot_product(v1,v2)*dot_product(v1,v2);
/* Next check catches boundary condition where cross product not zero but
determinant is, so must still call the planes parallel. */
if (determinant==0.0)
return(1);
c1=(d1*dot_product(v2,v2)-d2*dot_product(v1,v2))/determinant;
c2=(d2*dot_product(v1,v1)-d1*dot_product(v1,v2))/determinant;
l->lp.x=c1*v1->x+c2*v2->x;
l->lp.y=c1*v1->x+c2*v2->y;
l->lp.z=c1*v1->x+c2*v2->z;
return(0);
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -
int triangle_from_3pt(POINT *p1,POINT *p2,POINT *p3,TRIANGLE *t) {
VECTOR temp;
t->tp.x = p1->x;
t->tp.y = p1->y;
t->tp.z = p1->z;
t->tv1.x = p2->x - p1->x;
t->tv1.y = p2->y - p1->y;
t->tv1.z = p2->z - p1->z;
t->tv2.x = p3->x - p1->x;
t->tv2.y = p3->y - p1->y;
t->tv2.z = p3->z - p1->z;
if (cross_product(&t->tv1,&t->tv2,&temp)==1) //If vector from p1->p2
parallel to vector from p1->p3
return(1); //Return error, points are colinear
or two points are the same
else //Otherwise
return(0); //Normal return
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -
/*
Return the preferred 'point-vector' definition of a line given two points
on the line. This routine always returns POINT p1 as the 'point' and the
directed vector going from POINT p1 to POINT p2 as the 'vector'. A check
is made, however, to ensure that both p1 and p2 are not the same POINT.
*/
int line_2_points(POINT *p1,POINT *p2,LINE *l) {
l->lp.x=p1->x; l->lp.y=p1->y; l->lp.z=p1->z; //LINE 'l'
defined by POINT 'p1'
l->lv.x=p2->x-p1->x; l->lv.y=p2->y-p1->y; l->lv.z=p2->z-p1->z; //And
vector p1->p2
if (l->lv.x==0.0 && l->lv.y==0.0 && l->lv.z==0.0) //If the vector is
null, points were the same
return(1); //So return bad status
else //Otherwise, points
were not the same
return(0); //Return normal status
}
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
/*
Rotate the VECTOR X about the VECTOR U through an angle of 'theta'
radians. Note that if X and U
are pointing in the same direction their cross product returns the null
vector. This is not a problem
because it simply causes X to be returned unchanged as it ought to.
*/
int vector_rotate(VECTOR *X,VECTOR *U,double theta) {
VECTOR temp_u,temp_x,temp_v1,temp_v2;
double temp;
temp_u=*U; //Make a copy of U so we can
resize it
vector_resize(&temp_u,1.0); //Make it a unit vector for
the following calculations
temp_x=*X; //Make a copy of X to work
with
vector_mpy(&temp_x,cos(theta)); //Now have X*cos(theta)
[in temp_x]
temp=dot_product(&temp_u,&temp_x)*(1.0-cos(theta)); //Now have
(U.X)(1-cos(theta)) [in temp]
temp_v1=temp_u; //Prepare to multiply U by
result of previous line
vector_mpy(&temp_v1,temp); //Now have
U*(U.X)(1-cos(theta)) [in temp_v1]
cross_product(&temp_u,X,&temp_v2); //Now have (UxX)
vector_mpy(&temp_v2,sin(theta)); //Now have (UxX)*sin(theta)
[in temp_v2]
vector_add(&temp_v1,&temp_v2,X); //Now have
U*(U.X)(1-cos(theta))+(UxX)*sin(theta) [in X]
vector_add(&temp_x,X,X); //Now have
X*cos(theta)+U*(U.X)(1-cos(theta))+(UxX)*sin(theta) [in X]
return(0);
}
//= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =
//= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =
TR Oltrogge
oriel36
> (2) Elapsed Time
>
> The earth rotates on its own axis approximately every 23 hours 56 minutes 4 seconds (a sidereal day). So
> even though the observer is fixed in geographic latitude and longitude his effective longitude increases
> by 360 degrees every 23h56m4s.
I still think it is remarkable that there is a large section of people
who have actually found a way to believe the nonsense of a
correlation between the Earth's rotation through 360 degrees and the
value of 23 hours 56 min 04 seconds.If axial rotation is constant,and
it has not being isolated as an independent motion to be checked ,the
value will almost certainly be 24 hours or,in other words,it will
nowhere near 23 hours 56 minutes 04 seconds.
Surely somebody has an interest in how clocks were used to determine
location on the planet through theiolate inv correlation of 4
minutes of clock time for each degree of geographical seperation
making precisely 24 hours/360 degrees.
As latitude on the planet is easy enough to determine,a specific value
in miles was assigned to each degree depending how far from the
equator or poles a person determined his position to be -
http://www.alexmorgan.com/miles.jpg
It was East to West that was so difficult to determine which is why it
was important to have accurate clocks which could maintain a standard
pace and not run fast or slow .Using natural noon as a benchmark,and
using the correction which equalises variations in natural noon to an
average 24 hours and keeps the 24 hour cycles elapsing into each
other,great men exploited this principle and overlayed it on
terrestrial geometry.when they created the system after Copernicus
discovered axial rotation to be the cause of the daily cycle ,they did
not know why the natural noon cycles were unequal and it was
irrelevent for the principles on which the correlation between
clocks,the axial cycle and longitudes are dependent.
Is it so difficult to see how the natural noon benchmark provides the
basis for the Equation of Time tranfer of the average 24 hour day to
the axial cycle as a 'constant',not as an observed occurence but
simply as a convenient assumption used to allow clocks to measure
distance,the still the basis of the GPS system.Even allowing that the
vast majority here subscribe to the Piltdown man syndrome where
proponents were allowed to die off peacefully (took 40 years to do
it),I find it hard to believe that not one individual has intelligence
to admire what our ancestors achieved and how they achieved it,first
the creation of the 24 hour day and then the heliocentric adaption to
longitudes and terrestrial geography.
There is so much junk in what you wrote,the unfortunate thing is that
everyone will applaud you.
David Weinshenker
>
> On Apr 21, 6:18 pm, "TR Oltrogge" <troltro...@verizon.net> wrote:
>
> > (2) Elapsed Time
> >
> > The earth rotates on its own axis approximately every 23 hours 56 minutes 4 seconds (a sidereal day). So
> > even though the observer is fixed in geographic latitude and longitude his effective longitude increases
> > by 360 degrees every 23h56m4s.
>
> I still think it is remarkable that there is a large section of people
> who have actually found a way to believe the nonsense of a
> correlation between the Earth's rotation through 360 degrees and the
> value of 23 hours 56 min 04 seconds.If axial rotation is constant,and
> it has not being isolated as an independent motion to be checked ,the
> value will almost certainly be 24 hours or,in other words,it will
> nowhere near 23 hours 56 minutes 04 seconds.
How would you measure the rotation: suppose you landed on this planet
from outer space, with your own time-measuring devices (that were marked
in some totally alien units, independent of Earthlings' "hours"), and
were wondering what the rotation period of the planet was. By what
observation would you take that measurement? (Observing the apparent
position of distant stars? Observing the position of sun? Using a
Foucault pendulum at the pole?)
-dave w
Chris L Peterson
<daz...@earthlink.net> wrote:
>How would you measure the rotation: suppose you landed on this planet
>from outer space, with your own time-measuring devices (that were marked
>in some totally alien units, independent of Earthlings' "hours"), and
>were wondering what the rotation period of the planet was. By what
>observation would you take that measurement? (Observing the apparent
>position of distant stars? Observing the position of sun? Using a
>Foucault pendulum at the pole?)
Which is very much the situation with us as the "aliens" when we measure
the rotation period of every other body in the Solar System. We specify
the period with respect to the stars (which is exactly what you would
get with an inertial measurement, of course). In some cases, we
_measure_ with respect to something else, such as an orbiting
spacecraft. But then we convert to the inertial (sidereal) value.
David Weinshenker
>
> On Mon, 21 Apr 2008 10:48:09 -0700, David Weinshenker
> <daz...@earthlink.net> wrote:
>
> >How would you measure the rotation: suppose you landed on this planet
> >from outer space, with your own time-measuring devices (that were marked
> >in some totally alien units, independent of Earthlings' "hours"), and
> >were wondering what the rotation period of the planet was. By what
> >observation would you take that measurement? (Observing the apparent
> >position of distant stars? Observing the position of sun? Using a
> >Foucault pendulum at the pole?)
>
> Which is very much the situation with us as the "aliens" when we measure
> the rotation period of every other body in the Solar System. We specify
> the period with respect to the stars (which is exactly what you would
> get with an inertial measurement, of course). In some cases, we
> _measure_ with respect to something else, such as an orbiting
> spacecraft. But then we convert to the inertial (sidereal) value.
Yeah, it seems that such distinctions are lost on "oriel36", who
seems to believe that there is something inherent or absolute about
the "24 hours = 360 degrees of rotation" relationship (independent
of how that rotation is measured), appears to be unaware that the
observation of stellar transits -is- a way of "isolating axial
rotation as an independent motion to be checked". and appears
not to have spent enough time observing the night sky to note
that particular stars do in fact rise "earlier" (relative to
the solar day of terrestrial timekeeping) each night.
-dave w