6 August 2026  ·  🔭 Astronomy

My First Comet with the N.I.N.A. Orbitals Plugin – and Why I Was 19 Degrees Off

One day after the Falcon 9 impact, again in the morning at the holiday house in Denmark, again night over Texas – but this time no appointed hour to hit. An ordinary session, but with something I had never done before: a comet. 10P/Tempel 2, to be precise, currently passing through perihelion.

N.I.N.A. has a plugin for that, called Orbitals. By the end of the night I had a handful of frames – of a patch of sky the comet was never in. 19 degrees off. I only noticed in the afternoon, while reviewing and processing them.

Why this comet, and why now

10P/Tempel 2 is going through its perihelion right now – the true anomaly in the plugin reads 0.24°, so practically exactly at the point closest to the Sun. From Earth it is 0.41 au away, a good 61 million kilometres.

The orbital elements below it looked unremarkable. Except for one number that should have stopped me: Epoch 09/19/2016. The orbital elements carry a reference epoch that is ten years old. I saw it, paused for a second – and carried on. That was the costliest glance of the evening. More on it at the end.

That I ended up with JPL at all was not a decision, incidentally: the plugin lets you switch the source between JPL and MPC, and MPC ran into a timeout. So JPL – downloaded at 01:17, five minutes before the first failed attempt. Why that in particular is a problem, I come to at the end.

Stumbling block 1: “Frame” – because there was nothing else there

In the Orbitals panel I saw exactly one row of buttons: Frame, with Set Tracking Rate and Set Offset beside it. It took me a long time to work out that there is a second row below it, holding Slew and Track – the button that actually starts things. You have to scroll down inside the window; otherwise it simply does not exist.

So, Frame. The result at 01:22:

ASTAP - Plate solve failed.

The error was right there, but the cause was somewhere else – namely in the image statistics next to it: HFR 0.00 and MAD 8.00. For comparison, my normal luminance subs have a MAD of 28. The frame was practically empty. And with no stars, no plate solver can work. So ASTAP was not the problem at all; ASTAP was simply given nothing to solve.

Why was the frame empty? The most likely reason was in the same panel – an offset I had set by accident:

Almost eighty degrees away from the target. The “Set Offset” button stores the difference between the current telescope position and the target – meant for placing a comet deliberately off-centre so the tail fits in the frame. Press it while the mount is still at its home position and it stores the difference between the home position and the comet. Nonsense, in other words.

The lesson: scroll first. The correct sequence is:

1. Slew and Track – slews to the comet and follows it
2. Frame – and inside it “Slew, Center & Image”, rather than simply letting it expose

The difference at step 2 is the decisive one: “Slew, Center & Image” slews, exposes, solves the frame and re-centres. Anyone who merely exposes is photographing wherever the telescope happens to be pointing.

Stumbling block 2: the AM5 refuses to sync

Offset cleared, next attempt. Then at 01:51 a different error – and that was progress, because the plate solving had worked this time.

ASCOM Driver Error
Failed to SyncToCoordinates, error code: The distance between the
synchronization target point and the device itself is too large

What happens here: N.I.N.A. solves the frame and then wants to tell the mount “you are actually pointing here”. The ZWO driver refuses that when the correction turns out to be too large. A known problem between the AM5 and N.I.N.A., discussed in the relevant forums for years.

The N.I.N.A. setting that fixes everything

The fix is neither on the mount nor in the ZWO driver, but in N.I.N.A. itself – a single switch:

That changes the sequence:

The result is the same centred object. The difference is that the mount is never touched at all – and the error can no longer arise.

The N.I.N.A. documentation separates the two cleanly: sync tells the mount its true position, reslew to target slews to where it ought to be, and repeat until error < repeats that until the desired accuracy is reached. Sync only makes the subsequent slews more precise – the centring itself does not need it.

And the AM5's sync problem is real. In the ZWO forum a user describes exactly this error, and ZWO replies: “Please give me run logs to help me fix the bug.” So it is a bug being worked on. There is also a documented hard limit – the driver refuses any sync closer than 5° to the pole – and a new sync replaces the previous one rather than building up a pointing model. The correction therefore only holds near the synchronised point.

So “Coordinates sync OFF” is not an improvement but a workaround. It works as long as N.I.N.A. does the centring – and that is all I am claiming for it.

The price is modest: the odd extra slew, and an RA/Dec display on the mount that stays inaccurate because it never learns about its error. Irrelevant for the automation – N.I.N.A. knows the true position from the plate solving.

Stumbling block 3: the trap right next to it

Directly below it, on the same N.I.N.A. page, sits “Location sync”, and I switched that over while I was at it – from “Sync to application” to “Sync to telescope”.

The difference is the direction: “Sync to application” means N.I.N.A. takes the location from the mount. If something wrong is stored there, everything downstream comes out wrong – and that would have been a plausible explanation for an excessive sync distance.

Careful, this is where the trap is: “Sync to telescope” reverses the direction. Now N.I.N.A. writes its own location into the mount. If that is wrong in the profile, you overwrite a correct value with a wrong one. So before connecting again, do check under Options → General → Astrometry that the observatory coordinates are actually in there – 31.5471° N and 99.3825° W in my case.

One more thing: the location sync only takes effect when you connect. Disconnect the mount once and reconnect, or nothing happens.

What I learned about the numbers

Max Exposure is not a recommendation – it is a calculation

The plugin shows Max Exposure 97.8 s. Where does that come from? From the two shift rates: 0.009 ″/s in right ascension and 0.019 ″/s in declination add up to 0.0202 ″/s of proper motion. Times 97.8 seconds that is 1.98 arcseconds – at my 2.03 ″/px, exactly one pixel.

So the plugin simply calculates: “how long may I expose before the comet has moved by one pixel?” And it knows my image scale in order to work that out.

You can also read the number the other way round, though – more on that at the end.

I do not need comet tracking at all

That was the realisation that took the most weight off. At 0.0202 ″/s the comet moves 1.2 arcseconds in a 60-second exposure – that is 0.6 pixels. You cannot see it.

So: normal sidereal tracking, normal sequence. I can simply ignore the “Set Tracking Rate” and “Set Guider Shift Rate” buttons. You need those for long subs or fast comets, not at this image scale and with this object.

That is exactly where my confusion came from: I had assumed a comet necessarily requires comet tracking, and wore myself out on buttons I do not have to press at all.

And finally: the motion as the subject

And then, while looking at all this, a thought struck me. The whole evening had revolved around avoiding the comet's motion – keep the exposure short enough for it to stay point-like, Max Exposure as the ceiling. But that motion is what is special about the object. So why not show it?

So at the end of the night I did the opposite: a single frame over 15 minutes.

The stars stay point-like – the mount tracks sidereally, after all. The comet, by contrast, should draw a trail a good five times as long as a star is wide. Not a spectacular streak across the frame, but unmissable, and a single frame would then contain the whole point of the plugin: the thing moves.

So the 97.8 seconds from the plugin are not a rule but a fork in the road: below it you get a comet, above it you get its path.

Two things have to be accepted in return. The guiding has to hold for a quarter of an hour at a stretch. And the exposure runs through the manual imaging panel, which knows nothing of dithering, autofocus or the meridian flip – and above all no plate solving and no centring. It exposes wherever the tube happens to be pointing.

So much for the plan.

The actual mistake – and it was on screen the whole time

During the night I noticed nothing. The frames ran through, the guiding held, the stars were round.

Then, that afternoon, in Siril: no comet. Nowhere. I stretched, searched, went over the whole field – nothing that looked like a diffuse smudge. So I had the frame plate-solved and annotated, at least to find out where I was.

That suddenly put three pairs of coordinates on the table:

And out of those came two mistakes that added up:

First, the plugin was wrong. Between its target and the real comet there are 9.3 degrees – the explanation follows shortly.

Second, the telescope was not even on the plugin's target. The image centre is another 17.6 degrees away from it, and almost entirely in declination: in right ascension it is right to within three arcminutes, in declination it is out by 17.6 degrees. After the failed centring attempts the mount was simply pointing somewhere – and the 15-minute exposure ran through the manual imaging panel, which knows no plate solving and no centring. It simply exposed wherever the tube was looking.

All told: 18.9 degrees between the image centre and the comet. My field of view measures 1.7° – so the comet was eleven fields away, or 38 full-Moon diameters.

Why the JPL data are “old” – even though they are current

The confusing part first: the orbital elements are correct. I checked them against the JPL Small-Body Database and they agree to every digit displayed. The solution K265/43 dates from 28 July 2026, computed from 6,347 observations over a data arc from 2003 to 2026. It does not get fresher than that.

And yet it says epoch 2016. The reason: JPL elements are starting values for a numerical integrator, not for a Kepler formula. Horizons takes that state vector and integrates it forward – with the perturbations of every planet and with an outgassing model that JPL supplies specifically for the purpose (the parameters A1 = 2.50 × 10−10 and A2 = 8.12 × 10−12 au/d² are in the same file). With a method like that, the reference epoch is allowed to be arbitrarily old.

The Orbitals plugin, however, computes a two-body solution – the Sun and the comet, nothing else. Over ten years that goes wrong, and for a Jupiter-family comet especially so.

And it can be quantified exactly. Propagate the 2016 elements forward as a Kepler orbit and perihelion falls on JD 2461258.45. In reality it was JD 2461254.62 – 3.84 days earlier. Near perihelion 10P/Tempel 2 covers 0.0179 au per day, so 0.069 au in 3.84 days. Seen from a distance of 0.409 au, that is 9.6 degrees.

Exactly the 9.3 degrees between the plugin's target and the real comet. The comet is simply running four days ahead of the plugin.

Why MPC would be the better source – and why it did not work

Which brings us back to the error message from the beginning. The MPC keeps the epoch of its comet elements up to date instead of leaving it where the orbit fit put it. The plugin would then only have to propagate over days rather than years – and two-body maths copes with that effortlessly. That is exactly why the plugin offers two sources, and for comets MPC is the right one.

Except that the update produces this – in the morning during the Texas session, and again in the afternoon while working through the results:

The MPC status page has the explanation: one download of the same file per IP address is allowed every 12 hours. Further attempts return an empty file – and here is the trap: an aborted download already triggers the block. Anyone who clicks again after a timeout is therefore locking themselves out further. On top of that, the MPC servers are known for taking their time; I tried it myself and got no file.

So the right approach is: click once, let it run, and on failure wait twelve hours. Do not click again.

And tomorrow?

I will enter the coordinates by hand. From JPL Horizons, for the coming night in Texas:

Over those hours the comet moves all of two arcminutes – so with a 1.7° field of view the choice of time is entirely uncritical. Open the framing assistant, type the numbers in, done.

Conclusion

Four mistakes in one evening:

1. Did not scroll – and therefore only spotted the other buttons much later
2. Set an offset while the mount was still at its home position
3. Kept a default setting this mount cannot cope with
4. Used a data source unsuited to the method

The first three protested loudly: error message, abort, start again. The fourth said nothing. And it would have cost the night even if everything else had run cleanly – 9.3 degrees of ephemeris error is unrecoverable with a 1.7° field.

That it even came to 19 degrees in the end, because the mount was left somewhere after the failed attempts, is almost beside the point. Either mistake was fatal on its own.

That is the real lesson: the mistakes that shout at you are the ones you find. The costly one was the one I had already seen in the table of orbital elements and dismissed as unimportant.

And there is a second point: without plate solving in Siril I would still not know what went wrong. I would have blamed the exposure time, the filter, the brightness of the comet. A single solve answered the question in ten seconds – not at the telescope, but afterwards at the desk.

What remains: at 2.03 ″/px my rig is more relaxed about comets than I thought. No special tracking, no special exposures, one more stacking step at the end. And for this one object, coordinates by hand.