Astrolabe Follow-Up: Apparently “Accurate Enough” Wasn't
From Twilight to Tenths of an Arcsecond
Down the Accuracy Rabbit Hole
A little follow-up to my earlier Astrolabe post.
When I first wrote about the plugin, the astronomy engine was already considerably more elaborate than anything HomeSeer really needs in order to turn lights on at sunset.
It calculated twilight, lunar events, planets, eclipses, occultations, satellite passes, and a growing collection of other things.
And the accuracy was already quite good.
Which should probably have been the end of that particular discussion.
Instead, I made the mistake of asking:
“How much better could it be?”
That has gone about as expected.
If I'm going to calculate it, why knowingly use the older model?
The original implementation used several astronomical models that were entirely adequate for home automation and, frankly, quite a bit beyond adequate.
But once I started looking carefully at where the remaining errors came from, I found myself making a different decision.
If a modern model is available, practical to implement, and measurably more accurate, there is not much reason to knowingly stay with the older approximation.
So Astrolabe is getting an accuracy overhaul.
Not because HomeSeer events require sub-arcsecond astronomy.
They emphatically do not.
Mostly because now I know I can.
The planetary engine is getting the full treatment
The planetary calculations are moving to the full VSOP87D series rather than a reduced set of terms.
The original reduced implementation was already good.
The full series pushes the analytical results much closer to the arcsecond range while remaining entirely local and deterministic.
Fortunately, I had already written the coefficient generator in a body-independent way.
So expanding the planetary data is less:
Rewrite the astronomy engine
and more:
Apparently we are feeding it several thousand more numbers now.
The tables are generated from the published data rather than entered manually.
I enjoy astronomy.
I do not enjoy manually transcribing thousands of floating-point coefficients enough to test how accurate I could be at that.
The Moon is getting considerably more attention
The Moon is a much less forgiving target.
It is nearby.
It moves quickly.
Topocentric parallax is large.
And small errors become particularly visible when you start doing things such as:
Occultations.
Eclipses.
Close approaches.
Rise and set calculations.
So the lunar model is getting upgraded as well, using a modern high-accuracy analytical treatment rather than the simpler approximation that was there originally.
This is probably the most substantial part of the upgrade.
Naturally, it is also the part I find most interesting.
The reference-frame machinery is being modernized too
Rather than adding little corrections separately to each astronomical feature, I am also moving the underlying coordinate system onto the modern framework:
IAU 2006 precession
with:
IAU 2000A nutation
That means planets, the Moon, stars, twilight calculations, altitude/azimuth, and the other features can all use the same transformation machinery.
That may be the most important part of the work architecturally.
The goal is not merely:
Make Jupiter more accurate.
It is:
Make the entire astronomical engine agree with itself about what coordinate system it is using.
That tends to be healthier.
Then Earth had to become a moving target
Of course, once you start chasing fractions of an arcsecond, Earth itself becomes inconvenient.
Its rotation rate is not perfectly uniform.
Its pole wanders.
The actual celestial pole does not sit exactly where the theoretical model predicts.
Normally, these are extremely small effects.
Normally, that would be an excellent reason to ignore them.
We have apparently left “normally” behind.
So when Internet access is allowed, Astrolabe will be able to obtain current Earth Orientation Parameters from IERS data, including things such as:
UT1−UTC
polar motion
and:
celestial-pole offsets
That lets it refine the theoretical Earth-orientation model with actual observational data.
If that data is unavailable?
Nothing breaks.
It simply falls back to the best locally available values and continues.
That is becoming a very important rule throughout Astrolabe.
Connected data is an enhancement, never a requirement
I still want Astrolabe to function completely without depending on an outside service.
The astronomy belongs in the plugin.
So the fundamental calculations remain local:
Planetary positions.
Lunar positions.
Precession and nutation.
Twilight.
Coordinate transformations.
Eclipse geometry.
Occultations.
Satellite propagation.
All of that still works with Internet access disabled.
But if the user permits Internet access, Astrolabe can improve certain calculations with information that genuinely benefits from being current.
The distinction is:
Models live locally.
Observations can be refreshed.
And if the observation is unavailable, the model keeps going.
In other words:
Connectivity can improve the answer. It is never permission to produce one.
I rather like that rule.
The atmosphere is getting involved now too
Atmospheric refraction was another obvious accuracy improvement.
Astrolabe will publish both:
geometric altitude
and:
apparent altitude.
Those are not the same thing.
Near the horizon, refraction can move an object by roughly half a degree.
That rather dwarfs the arcseconds I have been enthusiastically chasing elsewhere.
A standard atmosphere gives a perfectly reasonable approximation.
But if Internet access is allowed, Astrolabe can now use current weather data to improve that calculation.
In particular:
temperature
surface atmospheric pressure
and:
relative humidity
The important one there is surface pressure, not pressure corrected to sea level.
The atmosphere affecting refraction is the atmosphere where the observer is actually standing.
So if the weather service says it is 31°C with a surface pressure of 968 hPa, Astrolabe can use those actual conditions instead of pretending it is 10°C at standard sea-level pressure.
If the weather feed is unavailable?
Standard atmosphere.
Calculation continues.
No drama.
Weather becomes useful for more than refraction
Once the weather data is available, it can also help answer the more practical observing question.
Astrolabe already knows things such as:
Is it astronomically dark?
Where is the Moon?
How bright is it?
Which planets are above the horizon?
Is a satellite pass occurring?
Is the satellite illuminated?
Now it can also know things such as:
Cloud cover.
Visibility.
Current atmospheric conditions.
So eventually the plugin can distinguish:
“Saturn is beautifully placed tonight.”
from:
“Saturn is beautifully placed behind several thousand feet of cloud.”
Both statements are astronomically true.
Only one is useful.
Local weather may eventually be even better
Because this is HomeSeer, there is another possibility I want to leave open.
If the user already has:
A weather station.
A barometer.
An outdoor temperature sensor.
Or other trustworthy environmental sensors connected to HomeSeer...
...those may be even better inputs than a regional weather feed.
So I am keeping the atmospheric-data layer separate from the source.
Astrolabe should ask:
What is the temperature and pressure at the observer?
It should not fundamentally care whether the answer came from:
A local HomeSeer sensor.
A weather-data service.
Or a standard-atmosphere fallback.
That also means it can eventually report where the value came from.
Which brings me to another thing I am adding.
Accuracy should have provenance
Once the calculations get this detailed, I do not want Astrolabe merely presenting a number with six decimal places and silently implying absolute authority.
I want it to know how it arrived there.
Something like:
Atmospheric refraction Temperature: 31.4°C Surface pressure: 968.2 hPa Humidity: 21% Source: current weather feed
Or:
Earth orientation UT1−UTC: current IERS value Polar motion: current observation/prediction Data age: 6 hours
Or, when offline:
Atmospheric model: standard fallback
That makes troubleshooting far more meaningful.
It also helps distinguish:
the astronomical model is wrong
from:
the current observational input is stale
from:
the atmosphere is simply doing something interesting today.
Those are very different problems.
And then there is validation
The other change I am making is methodological.
I do not want to rely solely on statements such as:
“This theory should be accurate to approximately one arcsecond.”
I want to measure it.
So the planetary and lunar engines are being tested against modern numerical ephemeris data over many epochs.
The coordinate machinery can be checked against authoritative reference implementations.
That means the eventual accuracy claims can be based on actual test distributions:
Average error.
Maximum error.
95th percentile.
Performance over time.
Different objects.
Different coordinate stages.
That is much more useful than simply repeating the nominal accuracy quoted for an algorithm.
If I am going to obsess over arcseconds, I may as well collect receipts.
Proper motion made the list too
I also realized that the handful of bright stars used for lunar occultation work were still effectively being treated as though their catalog coordinates never changed.
They do.
Slowly.
But if we have reached the point where tenths of an arcsecond are interesting, ignoring years of proper motion becomes rather inconsistent.
So those stars are getting proper-motion propagation as well.
There are only a handful of them.
The computational burden is effectively zero.
At this point leaving the error there would require more explanation than removing it.
There are still limits
None of this means Astrolabe is going to claim it can predict the exact visible instant of sunrise to a fraction of a second.
That would confuse mathematical precision with physical predictability.
Atmospheric refraction varies.
Temperature gradients matter.
Pressure matters.
The actual horizon matters.
Mountains have opinions.
So the goal is not:
Every astronomical event is now exact to 0.1 arcsecond.
It is:
Use the best practical modern model for the part we can calculate, use current observations where they improve it, and be honest about what remains uncertain.
I like that definition of accuracy much better.
This still does not require the Internet
I keep coming back to this because it matters to me.
If Internet access is disabled:
Astrolabe still works.
It calculates the sky locally.
If Internet access is enabled:
Astrolabe may refine those calculations with current Earth-orientation data, atmospheric measurements, satellite elements, weather conditions, and eventually things such as space weather.
If any one of those sources disappears:
Astrolabe falls back gracefully.
No external service becomes a single point of failure for the astronomy engine.
The plugin should never respond to:
“Where is Jupiter?”
with:
“Unable to connect to weather server.”
That would be an architectural failure of a fairly spectacular kind.
So this has escalated slightly
The original goal was basically:
Give HomeSeer better astronomical information than sunrise and sunset.
The current development list now includes:
Full planetary series.
Modern lunar theory.
IAU precession and nutation.
Measured Earth orientation.
Polar motion.
Topocentric geometry.
Atmospheric refraction using current pressure and temperature.
Proper stellar motion.
Ephemeris validation.
Live satellite elements.
And weather-aware observing advice.
There was probably a perfectly reasonable point somewhere in that progression where I could have stopped.
I have not identified it.
And I am increasingly okay with that.
The nice thing is that none of this complexity has to leak into normal use.
HomeSeer can still simply ask:
Is it dark?
Is the Moon up?
Is Saturn visible?
Is there a satellite pass tonight?
The fact that the answer may quietly involve Earth’s current polar motion and the actual barometric pressure outside is Astrolabe’s problem.
That is exactly where the complexity belongs.
So, why?
Because apparently:
“Good enough for home automation”
and:
“As accurate as I can reasonably make it”
are two very different design goals.
Astrolabe started with the first one.
I seem to be enjoying the second one more.
The underlying philosophy has become pretty simple:
Use modern models.
Use live observational data when Internet access is allowed and it genuinely improves the result.
Fall back gracefully when it is not available.
Keep the fundamental astronomy local.
And measure the accuracy rather than merely claiming it.
Is all of this necessary to turn on the porch lights at civil dusk?
Absolutely not.
But I already knew how to do that.
This is considerably more fun. 🔭