Date   

Re: TPoint vs. APPM -- Translation Possible?

Ray Gralak
 

Hi Marty,

Since you mention TPoint, does that mean you have SkyX?

If so, have you tried plate-solving any of your images with SkyX's image link? If needed, there is a much deeper stellar database available:

https://www.bisque.com/product/theskyx-pro-database-add-on/

-Ray

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


Re: APCC meridian limits warning

Ray Gralak
 

Hi Geoff,

In the APCC documentation the following warning appears frequently:
"The Meridian Limits, are primarily tracking limits in the west,
and counterweight-up slewing guides for APCC's advanced
slew logic in the east. They will NOT prevent you from
slewing into your pier with an incorrect slew, or from running
into the pier with direction buttons."
So I get that using the direction buttons can run the telescope into the pier. However, if the meridian limits are
set up correctly, what else constitutes an "incorrect" slew?
That part of the documentation could be better worded. "Slew" was meant to be a move either by button presses or setting the move rate to a fast speed in APCC or the ASCOM driver and just letting it go. But if you have an encoder mount, there is a way to protect the mount even under those conditions, and that is by setting up the Home/limits.

-Ray


Re: APPM and ASTAP #APCC

Ray Gralak
 

Hi Brian,

As far as I know, APPM can only use ASCOM drivers to connect a camera.
APPM can also use NINA, SGPro, SkyX, CCDSoftV5, and MaximDL to take images through their automation interfaces.

-Ray


Re: VPort2 / Fault / Sync Target: Valid Alt/Az, RA/Dec, HA/Dec has not been received!"

Ray Gralak
 

Hi Aygen,

I'm glad that the new driver works in your setup! Thanks for letting us know!

Best regards,

-Ray

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


Preventing Pier Crashes

Bruce Donzanti
 

I've been using NINA to image with my AP1100 (no encoders) in my observatory.  I connect NINA to the AP driver and everything is working fine.  The only thing I have not done is to set up safety limits to avoid any potential pier crashes should things go awry.  I have not used APCC.  So, can someone provide some direction as to what steps I need to take to set these up in APCC?   

Thx
Bruce


Re: TPoint vs. APPM -- Translation Possible?

mjb87@...
 

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.


Re: NINA or APCC

michael mccann
 

You’re right, and I’m seeing that there’s a conversion factor I hadn’t take into account.  Thanks for being persistent.  

Cheers 


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







 


Re: NINA or APCC

ap@CaptivePhotons.com
 

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







 


APCC meridian limits warning

Geoff Smith
 

In the APCC documentation the following warning appears frequently:
"The Meridian Limits, are primarily tracking limits in the west,
and counterweight-up slewing guides for APCC's advanced
slew logic in the east. They will NOT prevent you from
slewing into your pier with an incorrect slew, or from running
into the pier with direction buttons."
So I get that using the direction buttons can run the telescope into the pier. However, if the meridian limits are set up correctly, what else constitutes an "incorrect" slew?
Geoff


Re: NINA or APCC

michael mccann
 

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






 


Re: NINA or APCC

ap@CaptivePhotons.com
 

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






 


Re: NINA or APCC

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

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








Re: APPM and ASTAP #APCC

Worsel
 

Thanks, Ray!

You said

"Regarding the 70 Mpix image not loading, I assume you are using the camera’s ASCOM Camera driver?  There are some VERY inefficient ASCOM drivers that require over 1 GB of ram for a 40 mpixel image. The maximum memory for APPM is 1GB so the image fails to load. If the manufacturers would create efficient ASCOM camera drivers then APPM would not have a problem. Binning or using a subframe will reduce memory size below 1GB and thus APPM can use the image."

You are correct.  As far as I know, APPM can only use ASCOM drivers to connect a camera.  However, for me, point is moot, since I crop and get a smaller size file that APPM solves well!  The addition of ASTAP is a great time-saver for model builds.

Bryan


Re: NINA or APCC

michael mccann
 

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








Re: APCC Pro Error FindFreeQacindex: no free entries!

Ray Gralak
 

This can happen when messages are getting queued up and cannot be sent out to the mount.

Does this not happen when you disconnect from the ASCOM conditions hub?

-Ray

-----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,



Re: New AP1100 Guiding Great on Very Windy Night

Christopher M
 

Nice.  Thanks for the comments Mark.  Let me/us know when you put a longer package on the 1100.
Myself I'm working with a new Stowaway on an old G11 Digital mount and waiting until I can swing an 1100.  It too is windy here on the prairies.  My friend put his RedCat w ST-8300/FW8 package on his AP900QMD and it is a rock, which is no surprise.
C


APCC Pro Error FindFreeQacindex: no free entries!

Chris White
 

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,


Re: Keypad 4.19.5 unsuccessful upload

Peter Nagy
 

Hi Howard,

The button rates for directional buttons are minor and not terribly an issue for me. I have a bit of OCD and I always like to install the latest and greatest software/firmware. :-)

I cannot find the Java loader log file. Does the Java loader log file get erased after I closed the Java loader program?

In my case, it always hangs after 20% completion of uploading even after 4 hours running the Java uploader program. That's the best clue I can give you.

Thank you for looking into it.

Peter


Re: #WiFi SkySafari Pro won't connect to GTOCP4 #WiFi

Sébastien Doré
 

Not 100% sure about this but IIRC, the last byte (digit) of the mount's IP address when using the access-point mode should correspond to your CP's serial number, (if you have not changed the default value).
Please disregard my previous message. After trying it out, It seems your IP configuration is correct. Sorry for any confusion.

That said, once you have joined the GTOCP4_NET_XXX, can you ping the address 172.31.0.1 from a command prompt ? If not, can you post a screenshot of what you get ?

Sébastien


Re: #WiFi SkySafari Pro won't connect to GTOCP4 #WiFi

Howard Hedlund
 

Port #23 is correct for IP connections with a CP4

Is the error being thrown by SkySafari 6 Pro for iOS?  Or for Mac OSX?  Or for both?

 

I need to reconfigure things for Access Point mode, but I will check on my iMac and my iPhone.  I am suspicious of the IP address in your Mac Settings window.  The CP4’s IP address should end in   .1     not    .101

 

Mag. 7 or Better Skies!

 

Howard Hedlund

Astro-Physics, Inc.

AP Phone: 815-282-1513

Direct Phone:  815-315-7015

www.astro-physics.com

Please include this e-mail with your response.

 

P Consider the environment before printing this e-mail.

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Brian Valente
Sent: Tuesday, November 2, 2021 14:29
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] #WiFi SkySafari Pro won't connect to GTOCP4

 

is that the correct port number?

 

mine is set to 4030 but that is for a different mount. 

 

On Tue, Nov 2, 2021 at 12:21 PM Tom Zepf <tjzcos@...> wrote:

I'm trying to get SkySafari on iOS (and MacOS) to work with the builtin wifi on a AP1100GTO. I've got the network configured to connect to the GTOCP4 wifi, and verified the connection by visiting http://172.31.0.1 and seeing the configuration pages. Network setting look like:



SkySafari settings look like:



But I get an error:



Is there something wrong with this configuration?

Thanks,

    Tom


 

--

Brian 

 

 

 

Brian Valente

5521 - 5540 of 88094