Tracking the Sun

Last week we figured out how to keep the mirror pointed in the right direction... as long as we know where the Sun is. This week we'll solve that part of the problem.

One way we could attempt this would be to use an infrared receiver to track the actual Sun. That's a very direct method, and Lego does produce IR receivers. But I'm going to skip that option for now, for reasons similar to why we decided not to use light detectors to keep the mirrors pointed: we'll lose tracking during cloud cover or an eclipse.

The other way is to use astronomical knowledge. The Sun and Earth move in predictable ways, predictable enough that we know to within fractions of a second of time and milliseconds of arc of location where the Sun will be in the sky for the next several centuries. That's far more accuracy than we need for this project.

Small aside: how much accuracy do we need, anyway? Suppose our estimate of the Sun's location is off by 1 minute of arc. Then the image will be off by the same amount, and we can apply the formula from a few posts ago to determine how far this is in linear distance. However, for small angles, `2 tan(1/2 theta) ~= theta`, and 1 minute of arc is 0.00029 radians, so the error will be very close to `30m * 0.00029 = 8.7mm`. That might be enough to see. Let's work backwards instead: if we want the linear error to be `< 1mm`, then the maximum angular error `theta < 1mm` `/ 30m = 3.3xx10^-5` radians = 0.113 minutes of arc. It's useful to know this value because it will help constrain the Sun-tracking method we choose.

The simplest - and probably most accurate - method is to use NASA JPL's HORIZONS system, which has a Web interface that allows the calculation of ephemerides for any specific location on Earth in a variety of coordinate systems, for most of the bodies in the Solar System, including the Sun. The output is specific locations for a given range of times. We can, for example, get an ephemeris for the Sun, at 1-minute intervals, from the perspective of Dallas, TX, on the eclipse date of April 8, 2024. Problem solved?

Sort of, but it's not ideal. One drawback of this method is that it's limited to a specific range of dates and a specific viewpoint. I'd like to test the Sun viewer in my backyard in California this year, so I'll need to generate a new ephemeris for that, and then remember to load up the correct one when the eclipse arrives. Also, anyone else who wants to copy my work will have to generate an ephemeris for their own location. I could provide instructions, but doing this work is inconvenient. Can we do better?

One possibility is to use a geocentric ephemeris rather than a topocentric one. This gives us Sun position relative to the center of the Earth, from which we can do a little vector algebra to find the topocentric coordinates from any point on Earth. So there's more math involved, but the method is more general and should be about as accurate. I did a little Googling around and found this paper, which combines all of this math into one method (the PSA algorithm) for calculating the Sun vector for any date/time and location on Earth. I implementation this in Java and tested it against HORIZONS data: it's quite accurate, to at least 4 decimal places. According to the paper, the PSA algorithm almost never has an error `> 0.4` minutes of arc, but quite often has an error `> 0.113` minutes. However, as discussed last week, we actually don't care about the exact Sun vector: we just care about the first derivative of the vector. As long as the error is a smooth function of time, the error in the first derivative should be very small indeed.

Next week, we'll discuss how to build a mirror pointer out of Lego...