michael mccann

And since I’m shooting M74 tonight 

APCC.     01:37:53.04.  15:47:03.44

Image fits header
                  24:10:26.76.    15:47:14.64

PI image solver
                 01:36 : 41.067.   15: 47: 03:44


On Nov 2, 2021, at 22:55, michael mccann via <mmccawsprojects@...> wrote:

Thanks Linwood

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

Results : 
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, ap@... wrote:

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 faster.

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.


Join to automatically receive all group messages.