Do we have a difference in format.
Let's start with your first case, where for RA you had almost identical values except the fits header. You showed a conversion of 23.461914 to 23:27:42.89 but that is d:m:s and should be h:m:s, which converts to 1h33m50.8s, which is almost
identical to the plate solve (1h33m49s or 48.91).
Second case is similar, the fits header you had is 24:10:26.76 but I think you have as d:m:s, which is 24.1741d which is 1h36m41.7s which is what the PI solver appeared to give.
I'm also not sure if these are all J2000. NINA's display is, solvers are, not sure on APCC's status (or ascom's status), as I know the goto page does both, never checked and do not have it set up tonight (and a quick browse of the manual
did not say, though it was addressed for APPM).
But is this just a D:M:S vs H:M:S issue?
Or are you concerned about the small difference (a couple arc minutes or so)? That's more than I would expect, which is one reason I wonder about the JNOW vs J2000, as that's the right order of magnitude. I could not find any documentation
for whether the RA/DEC in the FITS header is JNOW or J2000 (I am pretty sure the astrometric solution is J2000), and I think APCC is J200 but not really sure (NINA should be J2000).
But a couple arc minutes should not keep PI's image solver from working, isn't that how we got onto this?
firstname.lastname@example.org On Behalf Of
michael mccann via groups.io
Sent: Wednesday, November 3, 2021 1:21 AM
Subject: Re: [ap-gto] NINA or APCC
And since I’m shooting M74 tonight
APCC. 01:37:53.04. 15:47:03.44
Image fits header
PI image solver
01:36 : 41.067. 15: 47: 03:44
On Nov 2, 2021, at 22:55, michael mccann via groups.io <mmccawsprojects@...> wrote:
So I reset park position 3 then used NINA Framing to sleep and center on M 33. I then RA/Dec values from ASCOM, APCC, NINA->Equipment->Telescope RA/Dec, NINA plate-solve routine, the image fits header, and PixInsight’s Image Solver
Source: RA. Dec
APCC: 01:35:05.15 30:46:21.2
NiNA Plate Solve. 01:33:49. 30:39:20
Nina>Eq>Tele. 01:35:0.05 30:46:21
ASCOM. 01: 35:05. 30:46:20
M33: Fits header :23.461914 30.6598
>23:27:42.89 > 30:39:35.28
Image Solver. 01: 33 : 48.91
DEC 30: 39:18.82
So I have no idea where the image that Is captured by NINA get the RA value used in the image’s fits header.
Where do I go from here. Does anybody else notice a discrepancy?
On Nov 1, 2021, at 12:28,
michael mccann wrote:
I learned there was a problem while I was learning PI PhotometricColorCalibration process and the tool kept failing on my M33 image. I resolved the coordinates and found my fits header’s RA and DEC values were a degree off in RA and a few
minutes in DEC. so where does NINA obtain the values in the Fits heading, from Ascom driver or the Framing, or plate solving? Or is there some other process involved.
The slew and center using plate solves to align the mount to the target works great. However I notice some over-shoot, often more than 5°. I suspect that understanding where the fits RA/DEC values comes from then I’ll isolate the issue
My understanding is that NINA records the FITS headers from what the mount is reporting at that time. You can double check by looking in the equipment tab while taking a specific image, then check the headers.
The center functionality with plate solving will adjust pointing, again as I understand, irrespective of the telescopes reported position. So if it slews to RA/DEC and finds the target 1 degree off, it will tell the telescope to move 1 degree until the plate
solve centers, leaving the telescope reported position (absent a sync) off by 1 degree from the target's actual position. Then when imaged, the target may be centered, but the fits header will show the 1 degree off.
In NINA in the Options, Equipment tab, for telescope, there is a "Do not sync" option normally set to Off. Se if yours is On. With TSX and MyT (which I used before) "on" is correct as TSX is supposedly already running a full tPoint model recalibrated for
that night's session, so you do not want syncs to upset it. With APPM that may or may not be true, and I think the proper setting is Off. This will cause the first live plate solve to sync, which in your Ascom V2 driver is probably set to a recal, and should
make the coordinates align.
Another option you have that might fix it is (assuming you are using APPM at all) is to go into APPM and on some representative part of the sky (is it better toward the equator?) do a plate-solve-and-recal. This should have a similar effect. You can check
its reported dec/ra and see if it changes when you do.
I discovered this issue (with my sync in NINA to On) because of meridian flip timing. Some nights NINA and APPC would be off by a few minutes of time in what time transit was. This was because APPM was not actually synced to the sky, its coordinates were
wrong because after assembling the mount and polar aligning I never did a sync (recal) at all.