1. Ap-Gto | Main
  2. Topics

NINA fails to sync AP900 and sometimes causes random slew

Wenhan Chang
 

Hi Horia,

Thank you for helping me clarify my question.

I should have mentioned that I usually do plate-solve/sync after slewing away from the pole. The only reason I tested near Park 3 position is to confirm that NINA's failure to sync after plate-solving is not due to conflicts with the mount's "Recal/Sync" system; I "Recal" there was a discussion mentioning that "Recal/Sync" mainly differs by the existence a coordinate already in mount's memory (https://ap-gto.groups.io/g/main/message/75265).

In either case (near/away from the pole), I found NINA fail to sync the mount's coordiante and "mistakenly" thought it has done so.

Best,
Wenhan
Horia
 

Hi Wenhan,

 

>> I initiated the mount from Park 3 position, unparked the mount and connected AP V2 driver through APCC, and started NINA.

>> I then plate-solved through NINA, …

 

I may be wrong but from your description it looks like you tried to plate solve and sync the mount while the scope was very close to Park3.  This will never go well as the plate solver will have a very hard time to distinguish between camera rotation and RA position. You should first slew the mount away from the pole.

 

Kind regards,

Horia

 

 

Von: main@ap-gto.groups.io <main@ap-gto.groups.io> Im Auftrag von Wenhan Chang
Gesendet: Donnerstag, 17. Februar 2022 19:16
An: main@ap-gto.groups.io
Betreff: [ap-gto] NINA fails to sync AP900 and sometimes causes random slew

 

Hello,

I just used my AP900 (CP3 V2) for the first time, controlled by APCC (version 1.9.3) and NINA (version 1.10). The mount performed great, but I had trouble using NINA to sync the coordinates to APCC/mount after plate-solving. No APPM/PEM was used.

I initiated the mount from Park 3 position, unparked the mount and connected AP V2 driver through APCC, and started NINA. I then plate-solved through NINA, which has the "sync" function on but "reslew to target" function off. After this, NINA produced conflicting behavior: on the one hand it "should know" the sync faild, because NINA's telescope section was still showing the RA and DEC coordinates before plate-solving (i.e. consistent with APCC's coordiantes); but on the other hand it "thought" the sync succeeded, because if I immediated do another plate-solve in NINA, it thinks the RA and DEC error was basically 0. APCC's coordiantes remained unchanged during this process.

What puzzles me more is that sometimes NINA's sync function will cause the mount to start slewing, about 2-3 seconds after plate-solving/syncing, even though I turned off the "reslew to target" function in NINA. I don't know if the slew was initiated by NINA or APCC. After this, the mount would lost track of its position (e.g. can't go back to the original park position; thought it was on CW up position though it wasn't etc.), so I think this messed up with the pointing model CP3 had.

My workaround was to turn off both "sync" and "reslew to target" function in NINA, and then I manually put the plate-solved coordinates in APCC and used APCC's "sync" function. Then the coordiates were updated on both APCC and NINA, and would center my target by having another GoTo.

The above behavior existed both right after initialization from Park 3, or after a slew/GoTo from NINA/APCC.

PS: sometimes if the plate-solved coordinates were too distant from what the mount thinks (greater than 5 arcmin I remember), then APCC's sync function will produce an error message saying the new coordiates were too distant and refuse to sync. My workaround was to slew the mount as close to Park 3 position as possible, (in APCC) park it to current position but then unpark it from Park 3 position. After that, the plate-solved coordinates would be closer and APCC would sync.

Please let me know if you need any further information or have any suggestions. Thank you very much!

Best regards,
Wenhan
Wenhan Chang
 

Hi Dale,

Thank you very much for the suggestions! I really appreciate it. I will test it out when Chicago sky clears up next time and keep you updated.

Best,
Wenhan
Dale Ghent
 

It may be that the coordinates that your mount thinks it is at, and the coordinates that the plate solve found, are so wildly different that APCC is rejecting the sync - but silently.

In APCC, go to Settings > Advanced Settings and see if "Prevent errant RECALs" is turned on, which I *think* is the default. This option will make APCC ignore syncs if they are wildly different from the mount's current notion of its coordinates. How large that difference has to be is something that I can't recall off the top of my head.

If that's the case, the sync could be silently eaten by APCC and NINA would know about it. I haven't tested this kind of condition in recent times, but this kind of condition should cause the ASCOM driver to throw an exception, thus cluing NINA in on the failed sync. Some other drivers throw exceptions a lot when being asked to sync to some coordinates (EQMOD is known for this when a sync is asked too close to the meridian) so NINA would observe an exception if the driver threw one.

If that option is on, you can test this by disabling it, doing the plate solve and sync, then re-enable it. If things go well after that, that was the cause. I would need to look into the behavior of the A-P ASCOM driver when a RECAL nee sync is rejected or ignored for being too different.

On Feb 17, 2022, at 13:15, Wenhan Chang <sjtu.wenhan@...> wrote:

Hello,

I just used my AP900 (CP3 V2) for the first time, controlled by APCC (version 1.9.3) and NINA (version 1.10). The mount performed great, but I had trouble using NINA to sync the coordinates to APCC/mount after plate-solving. No APPM/PEM was used.

I initiated the mount from Park 3 position, unparked the mount and connected AP V2 driver through APCC, and started NINA. I then plate-solved through NINA, which has the "sync" function on but "reslew to target" function off. After this, NINA produced conflicting behavior: on the one hand it "should know" the sync faild, because NINA's telescope section was still showing the RA and DEC coordinates before plate-solving (i.e. consistent with APCC's coordiantes); but on the other hand it "thought" the sync succeeded, because if I immediated do another plate-solve in NINA, it thinks the RA and DEC error was basically 0. APCC's coordiantes remained unchanged during this process.

What puzzles me more is that sometimes NINA's sync function will cause the mount to start slewing, about 2-3 seconds after plate-solving/syncing, even though I turned off the "reslew to target" function in NINA. I don't know if the slew was initiated by NINA or APCC. After this, the mount would lost track of its position (e.g. can't go back to the original park position; thought it was on CW up position though it wasn't etc.), so I think this messed up with the pointing model CP3 had.

My workaround was to turn off both "sync" and "reslew to target" function in NINA, and then I manually put the plate-solved coordinates in APCC and used APCC's "sync" function. Then the coordiates were updated on both APCC and NINA, and would center my target by having another GoTo.

The above behavior existed both right after initialization from Park 3, or after a slew/GoTo from NINA/APCC.

PS: sometimes if the plate-solved coordinates were too distant from what the mount thinks (greater than 5 arcmin I remember), then APCC's sync function will produce an error message saying the new coordiates were too distant and refuse to sync. My workaround was to slew the mount as close to Park 3 position as possible, (in APCC) park it to current position but then unpark it from Park 3 position. After that, the plate-solved coordinates would be closer and APCC would sync.

Please let me know if you need any further information or have any suggestions. Thank you very much!

Best regards,
Wenhan
Wenhan Chang
 

Hello,

I just used my AP900 (CP3 V2) for the first time, controlled by APCC (version 1.9.3) and NINA (version 1.10). The mount performed great, but I had trouble using NINA to sync the coordinates to APCC/mount after plate-solving. No APPM/PEM was used.

I initiated the mount from Park 3 position, unparked the mount and connected AP V2 driver through APCC, and started NINA. I then plate-solved through NINA, which has the "sync" function on but "reslew to target" function off. After this, NINA produced conflicting behavior: on the one hand it "should know" the sync faild, because NINA's telescope section was still showing the RA and DEC coordinates before plate-solving (i.e. consistent with APCC's coordiantes); but on the other hand it "thought" the sync succeeded, because if I immediated do another plate-solve in NINA, it thinks the RA and DEC error was basically 0. APCC's coordiantes remained unchanged during this process.

What puzzles me more is that sometimes NINA's sync function will cause the mount to start slewing, about 2-3 seconds after plate-solving/syncing, even though I turned off the "reslew to target" function in NINA. I don't know if the slew was initiated by NINA or APCC. After this, the mount would lost track of its position (e.g. can't go back to the original park position; thought it was on CW up position though it wasn't etc.), so I think this messed up with the pointing model CP3 had.

My workaround was to turn off both "sync" and "reslew to target" function in NINA, and then I manually put the plate-solved coordinates in APCC and used APCC's "sync" function. Then the coordiates were updated on both APCC and NINA, and would center my target by having another GoTo.

The above behavior existed both right after initialization from Park 3, or after a slew/GoTo from NINA/APCC.

PS: sometimes if the plate-solved coordinates were too distant from what the mount thinks (greater than 5 arcmin I remember), then APCC's sync function will produce an error message saying the new coordiates were too distant and refuse to sync. My workaround was to slew the mount as close to Park 3 position as possible, (in APCC) park it to current position but then unpark it from Park 3 position. After that, the plate-solved coordinates would be closer and APCC would sync.

Please let me know if you need any further information or have any suggestions. Thank you very much!

Best regards,
Wenhan

1 - 5 of 5