-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of mjb87 via groups.io
Sent: Wednesday, November 3, 2021 5:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] TPoint vs. APPM -- Translation Possible?

I've tried four cameras, all coupled to a focal reducer. I've tried binning from 1x1 to 3x3.

Sensor data (microns and arcminutes):
Sensor 1: Pixel = 5.9 and FOV = 1.4x0.9; unbinned image scale = 0.40 (Mono)
Sensor 2: Pixel = 3.8 and FOV = 3.5x2.6; unbinned image scale = 0.26 (OSC)
Sensor 3: Pixel = 3.8 and FOV = 4.7x3.1; unbinned image scale = 0.26 (OSC)
Sensor 4: Pixel = 2.4 and FOV = 2.3x1.6; unbinned image scale = 0.16 (OSC)

I am targeting scale at about 0.9 to 2.1 and binning appropriately.

However, my seeing isn't great and I'm probably at 1.5 arcsec FWHM. I can easily manually align a star (e.g.,
using TPoint) and I can do lucky imaging but I'm having a problem with platesolving.

Again -- my primary concern is pointing, not unquided tracking, so the dual-axis tracking is a "nice to have" for
this installation. I'm mainly interested in pointing accuracy.

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Erkaslan Aygen
Sent: Tuesday, November 2, 2021 8:59 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] VPort2 / Fault / Sync Target: Valid Alt/Az, RA/Dec, HA/Dec has not been received!"

Hi Ray and AP community,

As promised, I had the chance to test the new version. It seems to work like a charm ! I did only a couple of
slew / center / syncs and I haven't received a sigle warning / error messages. In case something goes wrong, I
will let you know anyway.

In the meantime, thanks again for your 5 stars support !

Best regards,
Aygen

On Nov 3, 2021, at 03:55, ap@... wrote:



I'm sorry, somewhere in here I have gotten lost.   Which number is 20+ degrees off.  In all cases it looked to me like you did a conversion from decimal degrees to degrees/minutes/seconds when you meant to do decimal degrees to hours/minutes/seconds, but perhaps I got lost.

 

Example:

 

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

 

Image fits header

                  24:10:26.76.    15:47:14.64

 

24:10:26.76 was, I think in the header as 24.1741, is that right?  The "24:10:26.76" was your conversion?   24.1741 degrees is an RA of 1 hour 36 m 41.7s, different from 1 hour 37 minutes 53 seconds by a minute or so, not 20 degrees.

 

Any chance, if I am still misunderstanding, of getting the actual fits file, or a screen shot of the complete FITS headers with astrometric solution from the plate solve?

 

All this begs the question why RA is shown different ways, but that's a FITS standards issue, not a NINA question.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of michael mccann via groups.io
Sent: Wednesday, November 3, 2021 4:56 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] NINA or APCC

 

So I don’t have a way to grab an exact coordinate reading from three processes that run serial. So I don’t expect ASCOM, APCC, NINA Equipment->Telescope RA/DEC values to be all exact. Obviously the odd man out is the image’s RA value.  So are you saying the RA value is correct but recorded in a different format?  The values in the fits header are in decimal format. I added the H:M:S format to show the conversion. Sorry that’s confusing 

The issue is why is the fits header giving a position 20+ degrees off and the Dec value is essentially correlates with the mount and other NINA values.

 

On Nov 3, 2021, at 01:50, ap@... wrote:



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?

 

Sorry, confused.

 

Linwood

 

 

 

From: main@ap-gto.groups.io main@ap-gto.groups.io On Behalf Of michael mccann via groups.io
Sent: Wednesday, November 3, 2021 1:21 AM
To: main@ap-gto.groups.io
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

                  24:10:26.76.    15:47:14.64

 

PI image solver

                 01:36 : 41.067.   15: 47: 03:44

 

Cheers 

 

On Nov 2, 2021, at 22:55, michael mccann via groups.io <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

PixInsight 

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?

 

 

Cheers 

 

 

 

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.

Linwood

 



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?

 

Sorry, confused.

 

Linwood

 

 

 

From: main@ap-gto.groups.io main@ap-gto.groups.io On Behalf Of michael mccann via groups.io
Sent: Wednesday, November 3, 2021 1:21 AM
To: main@ap-gto.groups.io
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

                  24:10:26.76.    15:47:14.64

 

PI image solver

                 01:36 : 41.067.   15: 47: 03:44

 

Cheers 

 

On Nov 2, 2021, at 22:55, michael mccann via groups.io <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

PixInsight 

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?

 

 

Cheers 

 

 

 

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.

Linwood

 

On Nov 3, 2021, at 01:50, ap@... wrote:



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?

 

Sorry, confused.

 

Linwood

 

 

 

From: main@ap-gto.groups.io main@ap-gto.groups.io On Behalf Of michael mccann via groups.io
Sent: Wednesday, November 3, 2021 1:21 AM
To: main@ap-gto.groups.io
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

                  24:10:26.76.    15:47:14.64

 

PI image solver

                 01:36 : 41.067.   15: 47: 03:44

 

Cheers 

 

On Nov 2, 2021, at 22:55, michael mccann via groups.io <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

PixInsight 

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?

 

 

Cheers 

 

 

 

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.

Linwood

 

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

Cheers 

On Nov 2, 2021, at 22:55, michael mccann via groups.io <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

PixInsight 

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?

Cheers 

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.

Linwood

On Nov 2, 2021, at 22:55, michael mccann via groups.io <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

PixInsight 

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?

Cheers 

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.

Linwood

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.

Linwood

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Chris White
Sent: Tuesday, November 2, 2021 4:46 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APCC Pro Error FindFreeQacindex: no free entries!

I have no idea what this error means. I just changed my weather monitoring from using ASCOM Conditions
Hub using a combination of Pegasus Sensors and API's to using a Lunatico Rain Sensor which has Rain,
Clouds, Temperature, Sky Temp, Barometer, Relative Humidity... I'm still using the ASCOM conditions hub,
but with this new gear list. Now I'm getting this error and not sure how to resolve it.

Thank you,