Date   

Re: AP1100 Newbie Question

George
 

Mark,

 

The slight offset is due to ReCals that may have been done during the course of the night.   The next night when you resume from Last Parked, your GoTo to the first object will be more accurate.    Not to be concerned…you’re fine.   <G>

 

Regards,

 

George

 

George Whitney

Astro-Physics, Inc.

Phone:  815-222-6538 (direct line)

Phone:  815-282-1513 (office)

Email:  george@...

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Mark Lamb
Sent: Wednesday, November 3, 2021 1:50 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] AP1100 Newbie Question

 

A couple of weeks ago I received my new AP1100, and I am familiarizing myself with it.  The only other mount I have had is a G11, which has a simple, straight-forward operation, with integrated levels on the RA and Dec Saddle and only 1 Park position, which would be the equivalent of Park 3.  With the G11, the 1st thing I would always do (with G11 parked) is adjust the RA and Dec so that both levels were in the middle.  At this NCP pointing position, I would adjust the rotation of my camera to what I wanted for the night's target, using either the BuckeyeStarGazer's triple camera rotation levels or an angle finder with level.

The AP1100 does not have any built in RA and Dec levels, but has very nice alignment notches at 90deg increments on both RA and Dec.  I leveled my Losmandy FHD tripod (though not dead perfect) and the tripod is on a concrete patio.  The AP1100's single bubble level in totally inside the circle, but not in the dead center.  Polar alignment is done every night, even though the mount has NOT been moved, using a Polemaster.  (Aside: it seems that the night to night variability in PA on the AP1100 is noticeable less than the G11.)  I perfectly align the AP1100's RA and Dec alignment notches (loosen clutches) while at Park 3, and then set my camera's rotation, just like I would with my G11 and its levels.

At the end of the night's imaging run, NINA parks the AP1100 to Park 3.  I notice that the alignment notches are slightly offset.  The next night, I will again perfectly align the AP1100's RA and Dec alignment notches (loosen clutches) while at Park 3 before unparking, and then make sure the camera rotation is correct.

I have notice that the most recent night's are slightly rotated from earlier night's subs by a few degrees.  The earlier subs were taken in a side-by-side arrangement, but the Dec notches were aligned (though 90deg rotated).

I am wondering if I am doing things right.  I assume the slight misalignment of the notches at the end of the night's park is due to pointing corrections with plate-solving.  I have NOT built any APPM models yet.

Should I re-align the notches when parked?  Should this be avoiding during the night's imaging, if parked before the end of imaging?  Should this only be done at the beginning of the night's session?

Is my intuition right that the RA and Dec alignment notches need to be matched at Park 3 for setting proper camera rotation?


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

Donald Rudny
 

Hi Tom,

No, the Mount doesn’t need to be initialized.  I was out with my 1100 with CP4 last night.  I hadn’t used it for a while and had the same problem as you, SkySafari wouldn’t connect with my iPad. The Wi-Fi connection showed the CP4, but every time I hit connect it said it wasn’t communicating with the Mount.  It also said to check to make sure the local network tab was on.  I never heard of that but went into “settings” and selected the app.  Sure enough, there was a local network tab and it was off.  Turned it on and it connected fine.  The updated SkySafari will connect at several positions now.  The local network thing must have crept in on the update.  No need to initialize first.  I run the 1100 solely with SkySafari.

Hope this is your problem, too.

Don

Don Rudny
Pepeekeo, HI 96783-0106


On Nov 3, 2021, at 7:59 AM, Tom Zepf <tjzcos@...> wrote:

Thanks for checking Howard. That .101 is the address the CP4 gave to my Mac/iPad, indeed the .1 is for the CP4 itself. At one time I had both the iPad and the Mac connected, and the first one got .100 and the next one got .101.

I read on some other thread that the mount needed to be initialized before it would work. Is that what might be happening here?


Re: AP1100 Newbie Question

 

Hi Mark

in my experience, that slight offset is normal and results from the more accurate axis positioning from the plate solving that happens with NINA (I use SGP and it's the same). 

Assuming the difference is relatively minor, I would leave it where it's parked (slightly off angle). It just means when you use it the next time, your first plate solve will be more accurate. I don't think there's any harm in re-centering it on the marks, but your first goto/solve will be off by that much. You can experiment on two different nights and see if my notion holds true. 

On Wed, Nov 3, 2021 at 11:50 AM Mark Lamb <lamb_mark@...> wrote:
A couple of weeks ago I received my new AP1100, and I am familiarizing myself with it.  The only other mount I have had is a G11, which has a simple, straight-forward operation, with integrated levels on the RA and Dec Saddle and only 1 Park position, which would be the equivalent of Park 3.  With the G11, the 1st thing I would always do (with G11 parked) is adjust the RA and Dec so that both levels were in the middle.  At this NCP pointing position, I would adjust the rotation of my camera to what I wanted for the night's target, using either the BuckeyeStarGazer's triple camera rotation levels or an angle finder with level.

The AP1100 does not have any built in RA and Dec levels, but has very nice alignment notches at 90deg increments on both RA and Dec.  I leveled my Losmandy FHD tripod (though not dead perfect) and the tripod is on a concrete patio.  The AP1100's single bubble level in totally inside the circle, but not in the dead center.  Polar alignment is done every night, even though the mount has NOT been moved, using a Polemaster.  (Aside: it seems that the night to night variability in PA on the AP1100 is noticeable less than the G11.)  I perfectly align the AP1100's RA and Dec alignment notches (loosen clutches) while at Park 3, and then set my camera's rotation, just like I would with my G11 and its levels.

At the end of the night's imaging run, NINA parks the AP1100 to Park 3.  I notice that the alignment notches are slightly offset.  The next night, I will again perfectly align the AP1100's RA and Dec alignment notches (loosen clutches) while at Park 3 before unparking, and then make sure the camera rotation is correct.

I have notice that the most recent night's are slightly rotated from earlier night's subs by a few degrees.  The earlier subs were taken in a side-by-side arrangement, but the Dec notches were aligned (though 90deg rotated).

I am wondering if I am doing things right.  I assume the slight misalignment of the notches at the end of the night's park is due to pointing corrections with plate-solving.  I have NOT built any APPM models yet.

Should I re-align the notches when parked?  Should this be avoiding during the night's imaging, if parked before the end of imaging?  Should this only be done at the beginning of the night's session?

Is my intuition right that the RA and Dec alignment notches need to be matched at Park 3 for setting proper camera rotation?



--
Brian 



Brian Valente


AP1100 Newbie Question

Mark Lamb
 

A couple of weeks ago I received my new AP1100, and I am familiarizing myself with it.  The only other mount I have had is a G11, which has a simple, straight-forward operation, with integrated levels on the RA and Dec Saddle and only 1 Park position, which would be the equivalent of Park 3.  With the G11, the 1st thing I would always do (with G11 parked) is adjust the RA and Dec so that both levels were in the middle.  At this NCP pointing position, I would adjust the rotation of my camera to what I wanted for the night's target, using either the BuckeyeStarGazer's triple camera rotation levels or an angle finder with level.

The AP1100 does not have any built in RA and Dec levels, but has very nice alignment notches at 90deg increments on both RA and Dec.  I leveled my Losmandy FHD tripod (though not dead perfect) and the tripod is on a concrete patio.  The AP1100's single bubble level in totally inside the circle, but not in the dead center.  Polar alignment is done every night, even though the mount has NOT been moved, using a Polemaster.  (Aside: it seems that the night to night variability in PA on the AP1100 is noticeable less than the G11.)  I perfectly align the AP1100's RA and Dec alignment notches (loosen clutches) while at Park 3, and then set my camera's rotation, just like I would with my G11 and its levels.

At the end of the night's imaging run, NINA parks the AP1100 to Park 3.  I notice that the alignment notches are slightly offset.  The next night, I will again perfectly align the AP1100's RA and Dec alignment notches (loosen clutches) while at Park 3 before unparking, and then make sure the camera rotation is correct.

I have notice that the most recent night's are slightly rotated from earlier night's subs by a few degrees.  The earlier subs were taken in a side-by-side arrangement, but the Dec notches were aligned (though 90deg rotated).

I am wondering if I am doing things right.  I assume the slight misalignment of the notches at the end of the night's park is due to pointing corrections with plate-solving.  I have NOT built any APPM models yet.

Should I re-align the notches when parked?  Should this be avoiding during the night's imaging, if parked before the end of imaging?  Should this only be done at the beginning of the night's session?

Is my intuition right that the RA and Dec alignment notches need to be matched at Park 3 for setting proper camera rotation?


Re: APCC download - malware detection

Ray Gralak
 

Hi David,

I'm sure it's a false alarm by Kaspersky. All of the other utilities show it's okay:

https://www.virustotal.com/gui/url/21dfcf4a058ecdf0e919e45ec8da57bfd34b4fefcbe5b338ad5f9c79ae321771?nocache=1

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Garrett
Sent: Wednesday, November 3, 2021 10:06 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] APCC download - malware detection

My Kaspersky Internet security is detecting malware in the latest download of Apccstandardlatest.exe and
requiring a disinfect/restart of WIN10 Pro.

UDS:trojan.win32.generic

Questioning if this is an actual APCC malware/known infection or a design routine embedded with APCC?

David Garrett


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

Tom Zepf
 

Thanks for checking Howard. That .101 is the address the CP4 gave to my Mac/iPad, indeed the .1 is for the CP4 itself. At one time I had both the iPad and the Mac connected, and the first one got .100 and the next one got .101.

I read on some other thread that the mount needed to be initialized before it would work. Is that what might be happening here?


APCC download - malware detection

David Garrett
 

My Kaspersky Internet security is detecting malware in the latest download of Apccstandardlatest.exe and requiring a disinfect/restart of WIN10 Pro.

UDS:trojan.win32.generic

Questioning if this is an actual APCC malware/known infection or a design routine embedded with APCC? 

David Garrett


Re: Keypad 4.19.5 unsuccessful upload

Howard Hedlund
 

Contact me off-group, Peter, and let me make sure you have the very latest loader and program files.

 

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 Peter Nagy
Sent: Tuesday, November 2, 2021 17:50
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Keypad 4.19.5 unsuccessful upload

 

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: Preventing Pier Crashes

Bruce Donzanti
 

Thanks much, Ray.  Greatly appreciate the info.


Re: NINA or APCC

ap@CaptivePhotons.com
 

michael mccann wrote:

 

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

 

You are most welcome. 

 

I am pretty sure that astronomers in the past who set the standards followed some ancient tradition of "make it complicated enough that most people cannot understand it", so they just switch units of measure around randomly, from hour angles to RA angles to RA degrees, then throw in minutes and seconds that mean different things (arc seconds vs RA seconds), and if that is not enough they move them around by changing coordinate systems from Jnow to J2000 randomly in various places. Except of course went they use LSR, Alt/Az.  How far away is something?  Well, if you figure it out in light years, I'll use parsecs.  And don't get me started on DC wiring connectors, but your 5.5/2.5 is going to disconnect randomly occasionally from your 5.5/2.1 that looks nearly identical, so throw in power poles, cigarette lighters, and a few RCA connectors.   Just when you think it's all coming clear someone starts describing how pierside really should work vs they way your particular driver interprets it, naturally explaining it for a target transiting under the pole.

 

And we tackle all this for fun.  😊

 

I wonder if "hobby astrophotographer" is a diagnosis in the DSM of psychiatry.  😊

 


Re: Preventing Pier Crashes

Ray Gralak
 

Hi Bruce,

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?
Dale Ghent did a great writeup on using NINA with A-P mounts. If you haven't read this yet, please take a look:

https://daleghent.com/nina-and-astro-physics-mounts

If you do not desire to have the scope image in counterweight-up positions, you can just enable meridian and horizon limits in APCC and set the limit actions for each to "Stop Tracking. You don't even need to configure the limits. This will protect the mount from pier collisions.

If you want to delve more into setting limits, take a look at the sections in the APCC help for Meridian and Horizon limits. At first, setting up meridian limits may seem complicated, but it will become easy once you have done it once.

-Ray


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

4241 - 4260 of 86825