7 August 2026  ·  🔭 Astronomy

Second attempt at 10P/Tempel 2 – and this time it is in the frame

Yesterday I was 19 degrees off. So this morning I tried again, with everything I have learned since.

Conditions were perfect: clear sky in Texas, every system came up cleanly, nothing to troubleshoot. Only one thing was the same as yesterday.

The MPC download still does not work

My first move was to fetch the comet data this time from the Minor Planet Center rather than JPL – because only the MPC keeps the reference epoch current, and that is exactly where everything went wrong yesterday.

The same error message as yesterday. Timeout on www.minorplanetcenter.net:443.

I have since looked into why that is. In short: the MPC allows only one download per IP address per twelve hours, and at Starfront more than 900 rigs hang off one shared fibre line – so in all likelihood they share the public address as well. It cannot be proven, though: the documented consequence of the block would be an empty file, not a timeout. Either way, I did not want to get stuck on it during this session.

An aside, since this is about that very MPC file: the MPC itself lists the comet as 10P/Tempel only – without the 2. The numeral distinguishes it from 9P/Tempel 1, also discovered by Wilhelm Tempel. It is historical convention rather than part of the official designation: JPL and the literature carry it, the MPC's name field does not.

By hand, then

The route I was left with yesterday evening is also the simplest: type the real coordinates from JPL Horizons straight into N.I.N.A.'s Framing Assistant.

It was 01:04 when I started, so the values were good to the minute – the comet only moves a little over one arcminute per hour anyway, and with a 1.7° field the exact time hardly matters.

Slew, centre, done. No offset, no plugin, no sync drama.

The first frame: 900 seconds of luminance

Instead of starting a sequence right away, I took a single snapshot from the imaging tab – 900 seconds, deliberately far beyond the upper limit the plugin quotes.

The reasoning behind it:

Almost nine pixels of drift against a star width of 1.7 pixels – five times the width of a star. Enough to see at a glance.

And there is something. And it is moving. Just the other way round from what I had expected.

I had counted on a comet trail against point-like stars. What I got was the opposite: a point-like comet against star trails. So over those 900 seconds the mount had been following the comet, not the stars.

Measured across 439 stars in the frame:

All the trails point the same way, too, with a scatter of 3 degrees. That is neither a guiding error nor a coincidence – it is precisely the comet's orbital motion, written into the stars in reverse.

After yesterday, that was the moment that mattered. Not the image quality, not the tail – just the confirmation that this time the whole chain landed on the same patch of sky as the comet.

Then a proper sequence

With that settled, LRGB at 60 seconds each:

Sixty seconds is the sensible choice here: in a single frame the comet's motion amounts to 0.59 pixels – invisible.

Across the whole sequence, though, it adds up to 13.7 pixels. I stacked on the stars, so that drift stays in the finished image: the stars are round and the comet is smeared by almost fourteen pixels. The cleaner way would be to register twice – once on the stars, once on the comet – and combine the two. That is still on my list.

Last of all, plate-solved and annotated – and that is the actual proof:

What is still missing

More exposure time. Twenty-three minutes was enough for a first go. We will see whether I add more over the next few days – the comet stays well placed.

The double registration. As long as I stack on the stars, those almost fourteen pixels of comet drift stay in the image. We will see whether I get to grips with it.

The tracking question. That the mount had been following the comet was not clear to me during the night – I only saw it when I measured the star trails. Where the rate comes from is still to be worked out.

The MPC download is the one point that has been settled since: why it fails and how to work around it now has its own article. So next time I will not have to type the coordinates in by hand.