NINA platesolve / recenter issue after merdian flip

[JR Schmidt]

I experienced an issue issue with NINA / platesolve / merdian flip. The issue has to do with an interesting set of circumstances, but ones which are also fairly general:

1. Imaged just through meridian, as normal
2. NINA requested a merdian flip, which initially completed successfully (as verified by Ring camera video). The RA and DEC axis are all pointing (roughly) as I would expect.
3. NINA successfully auto-focused, as expected post-flip.
4. Things go off the rails during the subsequent attempt to re-center (one of the last steps post-flip): During the “re-center” process NINA attempted to rotate the DEC axis (alone, only tiny RA correction) by a very large amount. I believe it was trying to rotate it by a full ~180 degrees to the orientation it would have had on the OPPOSITE side of the meredian, pre-flip. However, it then suffered a tripod collision before it could go that far(no harm done this time, thankfully).
5. (Note all subsequent plate solves fail, since the camera is now pointed below the horizon!!)

Below is the log file of the relevant section, but the relevant (I think) section in bold. It is also important to note that the position of the meridan at this instant in time was 09:25:00 (roughly). I believe this is critical in explaining the “bad” behavior.

I believe the explanation is as follows:

1. Post merdian flip, due to a crappy alignment model, the pointing was off by ~3 degrees. Not great, but not terrible.
2. Even though I delay the meridian flip to ~10 minutes past the merdian, this error in pointing led the initial position (post flip) to be slightly on the OTHER side of the meridian (i.e. where it was pre-flip). See the “solved” position in the bolded entry (RA = 09:43), in comparison to the desired target position (RA=09:23) and the current merdian (RA=09:25).
3. In the re-center attempt, NINA somehow gets confused about how DEC should be oriented, and adjusts it as if it is on the opposite side of the meridian (where it WAS, prior to the flip). This leads to a “bad” outcome. I think this is somehow reflected in the Bearing: -90° 10' 01" in the log file (?).

In short: the desired behavior would simply be either:

(1) Fail gracefully, but NEVER allow such a large change in DEC (or even RA). I would think that errors of more than 10-15 degrees should refuse to move the mount, as something clearly has gone wrong.

(2) In the specific case outlined above, I would think that this “corner case” could be detected and handeld gracefully.

---

---2024-03-10T23:18:42.3758|INFO|ImageSolver.cs|Solve|41|Platesolving with parameters: FocalLength: 1400 PixelSize: 4.63 SearchRadius: 30 BlindFailoverEnabled: True Regions: 5000 DownSampleFactor: 0 MaxObjects: 500 Reference Coordinates RA: 09:22:03 Dec: 50° 58' 35" Epoch: J2000
2024-03-10T23:18:42.7075|INFO|BaseImageData.cs|FinalizeSave|162|Finalize image and moving it to C:\Users\JR Schmidt\AppData\Local\NINA\PlateSolver\vn3rupbs.m2f.fits
2024-03-10T23:18:43.9056|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 09:42:13; Dec: 50° 51' 59"; Epoch: J2000
2024-03-10T23:18:43.9086|INFO|CenteringSolver.cs|Center|85|Centering Solver - Scope Position: RA: 09:23:46; Dec: 50° 52' 29"; Epoch: JNOW; Offset: RA: 00:00:00; Dec: 00° 00' 00"; Distance: 00° 00' 00"; Bearing: 00° 00' 00"; Centering Coordinates: RA: 09:23:45; Dec: 50° 52' 29"; Epoch: JNOW; Solved: RA: 09:43:51; Dec: 50° 45' 26"; Epoch: JNOW; Separation RA: -00:20:07; Dec: 00° 07' 03"; Distance: 03° 10' 43"; Bearing: -90° 10' 01"; Threshold: 1
2024-03-10T23:18:44.1534|INFO|TelescopeVM.cs|Sync|783|Syncing scope from RA: 09:23:46; Dec: 50° 52' 29"; Epoch: JNOW to RA: 09:43:51; Dec: 50° 45' 26"; Epoch: JNOW
2024-03-10T23:18:49.1714|INFO|CenteringSolver.cs|Center|115|Slewing to target after sync. Current Position: RA: 09:43:52; Dec: 50° 45' 26"; Epoch: JNOW; Target coordinates: RA: 09:23:45; Dec: 50° 52' 29"; Epoch: JNOW; Offset RA: 00:00:00; Dec: 00° 00' 00"; Distance: 00° 00' 00"; Bearing: 00° 00' 00"
2024-03-10T23:18:49.1854|INFO|TelescopeVM.cs|SlewToCoordinatesAsync|904|Slewing from RA: 09:43:52; Dec: 50° 45' 26"; Epoch: JNOW to RA: 09:23:45; Dec: 50° 52' 29"; Epoch: JNOW
2024-03-10T23:19:44.1230|INFO|CameraVM.cs|Capture|732|Starting Exposure - Exposure Time: 5s; Filter: LPro; Gain: 300; Offset 4; Binning: 1x1;
2024-03-10T23:19:50.7012|INFO|ImageSolver.cs|Solve|41|Platesolving with parameters: FocalLength: 1400 PixelSize: 4.63 SearchRadius: 30 BlindFailoverEnabled: True Regions: 5000 DownSampleFactor: 0 MaxObjects: 500 Reference Coordinates RA: 09:22:03 Dec: 50° 58' 35" Epoch: J2000
2024-03-10T23:19:50.8692|INFO|BaseImageData.cs|FinalizeSave|162|Finalize image and moving it to C:\Users\JR Schmidt\AppData\Local\NINA\PlateSolver\gxvzke5d.kfk.fits
2024-03-10T23:19:51.7737|ERROR|ASTAPSolver.cs|ReadResult|62|ASTAP - Plate solve failed.

‌

[JR Schmidt]

While I still haven’t entirely figured out the confusing conversion between RA/DEC and alt/az in Coordinates.cs, I think the large “bearing” of -90 might be the “trigger” that problems are going to result.

It could also be important to note that the mount was running under CPWI (Celestron AVX). I’m guessing it is some interaction between the slew/correction requested by NINA and CPWI that yielded the dangerously large rotation of the DEC axis.

I also realize that increase the “wait” time of the merdian flip will hopefully avoid this, but given the potential serious risks posed by such a DEC rotation, it would be ideal if a safety feature could be added to avoid this in the future.

[Stefan B]

Hi,

I would disagree that this as a bug, nor that it can be handled gracefully. N.I.N.A. was just doing what it should do - slew to coordinates and recenter on them, but the mount driver did not protect itself from this scenario when slewing into the pier. Hardware limits should be set up so that pier collisions cannot happen.

Additionally after the sync the mount should not have moved into a pier crash, but rather to the correct position after the sync. The position of the mount is expected to be correct pre-flip, so when the meridian flip happens for the current coordinates a reslew after a sync should not flip it back.
Maybe it lost its alignment or the pointing model is really bad so the correction slew ended up like that, which is something that N.I.N.A. cannot know.

[JR Schmidt]

You may be correct. It is just very odd that the FLIP itself worked fine (so presumably alignment was OK at that instant in time), but then things go so awry only a few minutes later.

I’m almost 100% sure this has something to do with the actual pointing being on one side of the meridian and the target on the other. That said, I’m not sure why. Incidentally, there is another recent post on Cloudy Nights that also saw this (also with an AVX/CPWI!):

https://www.cloudynights.com/topic/914478-avx-anomaly-parallel-parking/

[Stefan B]

The issue described in the cloudynight thread mentions that the scope slewed somewhere completely else after the sync. This indicates that it lost its pointing state.

Nina is simply solving the current frame and then slews again to the target position, that the mount should have reached by the flip. There is no slew to a prior position.
These hardware issues are not visible to the applications.

[Marc Blank]

This would be a better discussion in the NINA discord I think.

[Stefan B]

Follow up discussion starts here: https://discord.com/channels/436650817295089664/436650937663356939/1217535936703762493

[JR Schmidt]

This bug can be CLOSED. I have confirmed that the true issue is (was) an underlying reproducible bug in CPWI that dealt with a corner case when syncing with points that are “across” the meridian from the telescope side of pier. (The motor encoder positions in that case are off by \pi rad [for RA] and \pi - theta [for DEC]). This is completely reproducable.

The additional good news is that this appears to have been fixed in a recent CPWI update. Updating to that version fixes the issue, as verified by the log files.