NINA and ASTAP Dance: Framing "Slew and Center" and Plate Solving strange movement

[michael mccann]

• using NINA framing tool I initiated the ‘slew and center ‘ function on M31

• AP 1600 slewed to within a few seconds of the targeted framing destination

-Nina plate-solve tool takes a photo, Andromeda is mostly in the photos and ASTAP reports “00,44,05 and 41,12,31 just a little off,

• plate-solve initiates a slew to correct, However slews to — 22,05,15 and 41,20,30many degrees off.

• plate-solve initiates a slew to correct, However slews to — 00,43,32 and 41,12,31 close, only a little off.

• plate-solve initiates a slew to correct, However slews to — 22,05,53 and 41,20,31 again many degrees off.

This happened several more times before I stopped it.

Question: could meridian limits interfere?? I tested several other targets that weren’t testing the limits. I had the same tennis court action from NINA plate solve and ASTAP .

So that leads to probably asking how to resolve this. I’m hoping that someone here recognizes which software ( NINA or ASTAP) that needs to address this issue.

Oh, this acted the same with an October or November nightly version of NINA and Sunday’s version of Beta.

Thanks ahead

[Dale Ghent]

Hi Michael,

First, your installed version of NINA is grossly out of date. You ought to update that to the 2.0 betas, which have superseded the 1.11 nightly builds. You should look in the upper right corner of NINA’s window for an update notification and, if there isn’t one, go to Options > General and ensure that Auto Update Source is set to Beta or Nightly, and then you will see one.

I saw in another thread on the ap-gto mailing list that you discovered an issue with time and DST settings on your mount. Has correcting that resolved this problem? The wrong time can definitely make a mount get lost in the sky. Versions of NINA that are more recent than what you have will show a warning if your PC time and mount time have a 1 or more hour of difference.

‌

[Stefan B]

There is also some unexpected driver behavior in the logs, that it does not reflect the updated position properly:

2021-11-28T21:07:08.2723|INFO|TelescopeVM.cs|SlewToCoordinatesAsync|849|Slewing from RA: 22:04:59; Dec: -00° 00' 18"; Epoch: JNOW to RA: 00:43:56; Dec: 41° 23' 27"; Epoch: JNOW
2021-11-28T21:07:26.1232|INFO|CameraVM.cs|Capture|709|Starting Exposure - Exposure Time: 4s; Filter: ; Gain: 200; Offset 8; Binning: 1x1;
2021-11-28T21:07:31.3208|INFO|StarDetection.cs|Detect|221|Average HFR: 7.08185014422529, HFR σ: 0.408013302715352, Detected Stars 168
2021-11-28T21:07:31.5579|INFO|ImageSolver.cs|Solve|41|Platesolving with parameters: FocalLength: 728 PixelSize: 3.8 SearchRadius: 30 Regions: 5000 DownSampleFactor: 0 MaxObjects: 500 Reference Coordinates RA: 00:42:44 Dec: 41° 16' 07" Epoch: J2000
2021-11-28T21:07:33.5621|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 00:42:21; Dec: 41° 16' 42"; Epoch: J2000
2021-11-28T21:07:33.5936|INFO|CenteringSolver.cs|Center|69|Centering Solver - Scope Position: RA: 22:04:32; Dec: 41° 16' 54"; Epoch: J2000; --- Solved: RA: 00:42:21; Dec: 41° 16' 42"; Epoch: J2000; Separation RA: 00:00:23; Dec: -00° 00' 35"; Distance: 00° 04' 21"; Bearing: 82° 15' 10"
2021-11-28T21:07:33.6989|INFO|TelescopeVM.cs|Sync|730|Syncing scope from RA: 22:05:25; Dec: 41° 23' 27"; Epoch: JNOW to RA: 00:43:33; Dec: 41° 24' 02"; Epoch: JNOW

As you can see, the RightAscension read from the driver is not updated after the slew, although the scope seems to have slewed just fine, which is indicated by the solved coordinates. This will throw off the whole calculation, as the mount does not correctly report the position.

[Stefan B]

log indicates a driver problem not updating the right ascension value properly

[michael mccann]

So help me understand . Which application does the driver that’s not updating correctly belong to. I’m assuming it’s not the GtoCp4, is it Ascom, Astro-Physics V2 ASCOM, or N.I.N.A?

[Stefan B]

Removing version: 1.11 Nightly (automated comment)