openLuup email server

[a-lurker]

On the solar coords. Yes I have my lat lng set. Now please reassure me that all these values are in decimal degrees plus and minus from north except the Altitude, which is up & down (elevation).

[akbooer]

Well yes, degrees, apart from the RA, as explained above. However, the coordinate reference for RA and DEC is not Earth-bound coordinates, but celestial ones..., hence don't correspond to N S E, or W, in any simple way. (Tilted coordinate system because of Earth's axis, etc.)

[akbooer]

Love that link, by the way! That's a lot of work. How did you do it?

[a-lurker]

@akbooer said in GetSolarCoords - correct results?:

That's a lot of work. How did you do it.

Well I edited all your posts & the manual. It uses docsify. It's probably got lots of errors.

[akbooer]

I could add that link to the documentation section in the ABOUT openLuup menu page.

[a-lurker]

You can add a link if you like or you could take over the whole lot in GitHub. I'm still adding stuff from time to time. Main purpose is to advertise. It needs lots of screen captures including from AltUi. Color & movement!

I sorted out the GetSolarCoords() problem. Line 189 in timers.lua in the dev repo:

local J2000 = os.time {year = 2000, month=1, day=1, hour = 12}  -- Julian 2000.0 epoch

-- prints 946728000 in the Greenwich time zone
print(J2000)

In the Greenwich time zone this equals 946728000 ie exactly thirty Julian years where a year is 365.25 Julian days.

Now in my timezone I don't get that value. I have to add (my_timezone_hours * 3600) to get the correct value. Consequently I get incorrect results from GetSolarCoords().

It's weird because I thought Epoch time is the same for every timezone. Maybe anyone reading this post could try this in their time zone.

Now the value is constant, so it's easier to say:

-- exactly thirty Julian years where a year is 365.25 Julian days
local J2000 = 946728000

It would be good if the function returned both Greenwich & local Sidereal time in decimal hours (not degrees). Then it's easy to check against an online Sidereal time clock. Not so sure if access to the hour angle variable is of much use.

  -- see: theta0 in local_sidereal_time()
  local GreenwichSiderealTimeHrs = (theta0 % 360)/15
  local LocalSiderealTimeHrs = ((theta0 + lng) % 360)/15

Living in Greenwich makes it tricky to code!

[a-lurker]

Another quick one -the Historian doesn't seem to know about "Solar".

[akbooer]

There’s very little point in storing the history of a variable for which there is a specific formula??

An historian rule for variables of the solar service type, is easily added.

[a-lurker]

Not convinced - I have learnt a lot by looking at how these values change during the day or over the year. As an example! My preference is not to set them up myself.

[a-lurker]

Great - variables AZ & ALT are now all good. I've written about them here.