Platesolve is wrong?

james474789

I have uncovered a rather weird issue that keeps catching me out. I use telescopius/SGPro etc to frame my targets and then create a custom object on the ASIAir with the resulting coordinates. However, I am noticing the ASIAir is not matching my desired framing and it looks like the platesolve calculation is off.

Last night I was imaging around the veil area the platesolve coordinates calculated by the ASIAir do not match any other application.

SGPro, Pixinsight and astrometry.net all calculate the centre of my image as having RA/DEC of:

RA-20, DEC-30

ASIAir calculates the centre as:

RA-20, DEC-30

This is a small but significant difference and I cannot work out how this is happening.

Some screenshots showing the issue:

2020-08-09 (3).png

2020-08-09.png

james474789

Link to source file:

https://1drv.ms/u/s!AtooZYq7lKxzgWnwX8TDM9MaKIFt?e=c29CbQ

w7ay

If you take 52 Cygni (in the Cygnus loop) as a reference star, since it is in the region you were looking at, its J2000 coordinates (according to SkySafari) is:

RA = 20h 46m 30s, DEC = +30º 47' 39.9"

Again, according to SkySafari (with nutation and precession), JNOW (right at this moment :-) is

RA = 20h 45m 39s, DEC = +30º 43' 11.6"

The difference from J2000.0 and JNOW is about 1m (15 arc minutes) different in RA, and about 4.5 arc minutes different in DEC.

Your numbers show pretty much the same difference between Astrometry.net and ASIAIR. (Another source of error could be how atmospheric refraction is estimated -- not knowing your latitude and observing time, I can't venture to guess if that is an additional source of error).

From the RA and DEC of stars in its database, we know that ASIAIR must use JNOW, since that is where the objects are when you are trying to point to them tonight, and not in January 2000 AD. Otherwise when we execute a GOTO in ASIAIR, we won't land on the correct spot. I think I have also seen ZWO folks confirm that the ASIAIR uses JNOW.

Astrometry.net uses J2000.0 according to this:

http://www.astro.umontreal.ca/atelieretudiant/Documents/JG_astrometrynet_manual.pdf

The difference between J2000.0 and JNOW appears to be consistent with the numbers you have obtained, so there is likely no error in plate solving by ASIAIR (at least not to the magnitude that you saw). It is probably just simply the case that ASIAIR is solving for the position your telescope is pointed to tonight, while Astrometry.net is solving for the position of stars as if it were January 2000 AD.

For what its worth, I had used the Hipparcos catalog (HYG 3.0) in my mount simulator (http://www.w7ay.net/site/Applications/MountSim/), which gives star coordinates referenced to J2000.0, and I had used nutation and precession (precession has quite a bit less delta than nutation, by the way) to convert J2000.0 to JNOW, so that the simulator displays what we see in the sky right now. When I tested ASIAIR's plate solve to estimate the center of my simulator's display, I usually came up with no more than a few arc seconds of error.

Chen

james474789

I came to the same conclusion, however the use of jnow seems problematic if I want to return to the same location over and over.

james474789

Following up on this. The use of jnow is incredibly frustrating and at odds with almost all other acquisition/planning software. I typically plan my targets using telescopius and as a result of this I then need to convert everything from j2000 to jnow.

Telescopius
Stellarium
Cartes Du Ciel
SGPro
Nina Astro
Ekos

Is there any intention of standardising this so it is consistent with other software?

igblaar

+1 to all the points above — and I’d also like to thank the ZWO team for the improvement introduced in ASIAIR 2.4 beta: it's now possible to enter coordinates in either J2000 or JNOW in Preview mode, which is a very welcome and much-needed step forward. Great work!

However, to truly complete the update and solve the internal consistency issue, it would be ideal if the Custom Object Catalog also allowed users to input coordinates in J2000. As of now, it seems to only accept JNOW coordinates, which creates the same old problem when planning sessions offline.

Why is this important?

When preparing sessions at home, especially for targets not in the default catalog (e.g., specific galaxies, IFN patches, custom framing), being able to input J2000 coordinates is essential for compatibility with tools like Aladin, SkySafari, Telescopius, or catalogs based on J2000 (which is still the standard in most astronomy tools and databases).

So, my request to the ZWO team:

Please allow Custom Catalog entries to be defined using J2000 coordinates, or at the very least let users specify the epoch (just like in Preview mode).

Also, a visible indicator of the epoch in each module would really help reduce confusion and avoid small but frustrating misalignments.

Thanks again for your ongoing work — ASIAIR is evolving beautifully, and this small detail would really improve both offline planning and interoperability with other platforms.