Problem with meridian Flip or RA positioning in general

[Christoph Nieswand]

beta 2.0.0.2018

Worked fine with pre-2.0

Mount is an Skywatcher HEQ5.

Using the Skywatcher Telescope ASCOM driver, NO EQMOD !
”Do not Sync” was OFF, so it should sync back to the mount.

Two problems, which may be related. Observed two times up to now (only … had just 2 partly clear nights in the last 45 days ):

1. Flat Wizard: Slew to Zenith is way off in RA, by 20 degrees or so too far to the west side. Platesolving and pointing to any object is fine so far. So N.I.N.A and mount agree on RA position. Also when I send the mount to Home Position via hand controller it goes to the correct position.
2. Meridian flip happens (not) at wrong time: Sequence (simple sequencer) initiated a meridian flip way before real meridian transit (correspond aprox. to the RA offset described in 1) … but does not really do it. The sequence claims to do the meridian flip, but only moves the mount a bit, does a fresh plate solve and all the rest and continues with the mount on the same side. When the actual flip should happen … nothing happens … with risk to crash the scope.
   The meridian flip time in the sequencer view is displayed correctly, but I did not check, what the equipment/telescope tab said about “time to meridian”.
   Target was Sh2-202, which is not in the list of targets of the framing wizard, so I entered coordinates manually in the framing wizard, loaded the image, created a new (simple) sequence from the framing wizard and slewed and centered from the framing wizard … and got to the correct position.

This is strange, as I said it worked correctly for quite some time, but now since I moved to the beta 2.0 branch, it happened at least two times.

‌

[Christoph Nieswand]

Additional Info: “use telescope side of pier” was off

From the logfiles I found, that the meridian flip was initiated at 21:10 … and should have happend at about 21:45. This corresponds to an offset angle of about 8 degree in RA. So the above mentioned 20 degrees may have been estimated too large.

Times on computer and mount were in sync.

[Stefan B]

Hi,

this sounds more like an issue with the mount driver not reporting the correct sidereal time. From N.I.N.A. perspective all telescope drivers are treated the same, so an issue like this would happen for everyone.

[Christoph Nieswand]

Hi,

mmmhh, I understand that is seems to be a specific problem of my setup because apparently nobody else has the same problem. But your assumption does not sound logic to me:

N.I.N.A knows apparently exactly where the scope is pointing to, it knows precisely what time it is, It knows precisely when th eobject passes meridian … so why should the driver of the scope have any influence on when N.I.N.A triggers the Meridian flip?

Here is the part from the log:

2021-12-20T21:09:26.2652|INFO|SequenceItem.cs|Run|213|Finishing Category: , Item: Dither
2021-12-20T21:09:26.2652|INFO|SequenceItem.cs|Run|213|Finishing Category: , Item: NINA.Sequencer.Container.SequentialContainer, Strategy: SequentialStrategy, Items: 1, Conditions: Triggers:
2021-12-20T21:09:26.2652|INFO|MeridianFlipTrigger.cs|ShouldTrigger|221|Meridian Flip - Remaining Time is between minimum and maximum flip time. Minimum time remaining 00:00:00, maximum time remaining 00:03:49.1180000. Flip should happen now
2021-12-20T21:09:26.2652|INFO|SequenceTrigger.cs|Run|100|Starting Trigger: MeridianFlipTrigger
2021-12-20T21:09:26.2781|INFO|MeridianFlipVM.cs|DoMeridianFlip|152|Meridian Flip - Initializing Meridian Flip.
Current target coordinates RA: 03:17:05 Dec: 60° 04' 01" Epoch: J2000
Remaining wait time: 00:00:00
Pause Time Before Meridian: 0
Minutes After Meridian: 5
Max Minutes After Meridian: 10
AutoFocus After Flip: False
Recenter: True
Use SideOfPier: False
Settle Time: 30
2021-12-20T21:09:26.2852|INFO|MeridianFlipVM.cs|StopAutoguider|323|Meridian Flip - Stopping Autoguider
2021-12-20T21:09:27.3180|INFO|MeridianFlipVM.cs|PassMeridian|233|Meridian Flip - Stopping tracking to pass meridian
2021-12-20T21:09:28.3898|INFO|MeridianFlipVM.cs|PassMeridian|245|Meridian Flip - Resuming tracking after passing meridian
2021-12-20T21:09:28.4920|INFO|MeridianFlipVM.cs|DoFlip|127|Meridian Flip - Scope will flip to coordinates RA: 03:17:05 Dec: 60° 04' 01" Epoch: J2000
2021-12-20T21:09:31.3642|INFO|MeridianFlipVM.cs|Settle|310|Meridian Flip - Settling scope for 30
2021-12-20T21:10:00.5529|INFO|MeridianFlipVM.cs|Recenter|254|Meridian Flip - Recenter after meridian flip
2021-12-20T21:10:00.5582|INFO|CameraVM.cs|Capture|713|Starting Exposure - Exposure Time: 10s; Filter: ; Gain: 100; Offset 20; Binning: 1x1;
2021-12-20T21:10:12.3773|INFO|StarDetection.cs|Detect|221|Average HFR: 4.32634040920821, HFR σ: 1.46206466070297, Detected Stars 11
2021-12-20T21:10:12.4942|INFO|ImageSolver.cs|Solve|41|Platesolving with parameters: FocalLength: 540 PixelSize: 3.76 SearchRadius: 30 Regions: 5000 DownSampleFactor: 2 MaxObjects: 500 Reference Coordinates RA: 03:17:05 Dec: 60° 04' 01" Epoch: J2000
2021-12-20T21:10:13.0047|INFO|BaseImageData.cs|FinalizeSave|144|Saving image at C:\Users\cnieswand\AppData\Local\NINA\PlateSolver\p1l51zr1.hak.fits
2021-12-20T21:10:14.5602|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 03:17:09; Dec: 60° 03' 51"; Epoch: J2000
2021-12-20T21:10:14.6418|INFO|CenteringSolver.cs|Center|71|Centering Solver - Scope Position: RA: 02:35:16; Dec: 61° 16' 23"; Epoch: J2000; Offset: RA: 00:00:00; Dec: 00° 00' 00"; Distance: 00° 00' 00"; Bearing: 00° 00' 00"; Centering Coordinates: RA: 03:17:05; Dec: 60° 04' 01"; Epoch: J2000; Solved: RA: 03:17:09; Dec: 60° 03' 51"; Epoch: J2000; Separation RA: -00:00:04; Dec: 00° 00' 10"; Distance: 00° 00' 30"; Bearing: -108° 54' 26"; Threshold: 1
2021-12-20T21:10:14.6448|INFO|MeridianFlipVM.cs|SelectNewGuideStar|304|Meridian Flip - Selecting new guide star
2021-12-20T21:10:25.2876|INFO|MeridianFlipVM.cs|ResumeAutoguider|296|Meridian Flip - Resuming Autoguider
2021-12-20T21:10:25.2936|INFO|PHD2Guider.cs|TryStartGuideCommand|573|Phd2 - Requesting to start guiding. Recalibrate: False
2021-12-20T21:10:41.0149|INFO|MeridianFlipVM.cs|Settle|310|Meridian Flip - Settling scope for 30
2021-12-20T21:11:10.2266|INFO|SequenceItem.cs|Run|195|Starting Category: Filter Wheel, Item: SwitchFilter, Filter: H
2021-12-20T21:11:10.2276|INFO|SequenceItem.cs|Run|213|Finishing Category: Filter Wheel, Item: SwitchFilter, Filter: H
2021-12-20T21:11:10.2286|INFO|MeridianFlipTrigger.cs|ShouldTrigger|221|Meridian Flip - Remaining Time is between minimum and maximum flip time. Minimum time remaining 00:00:00, maximum time remaining 00:02:04.5900000. Flip should happen now
2021-12-20T21:11:10.2286|INFO|SequenceTrigger.cs|Run|100|Starting Trigger: MeridianFlipTrigger
2021-12-20T21:11:10.2286|INFO|MeridianFlipVM.cs|DoMeridianFlip|152|Meridian Flip - Initializing Meridian Flip.
Current target coordinates RA: 03:17:05 Dec: 60° 04' 01" Epoch: J2000
Remaining wait time: 00:00:00
Pause Time Before Meridian: 0
Minutes After Meridian: 5
Max Minutes After Meridian: 10
AutoFocus After Flip: False
Recenter: True
Use SideOfPier: False
Settle Time: 30
2021-12-20T21:11:10.2351|INFO|MeridianFlipVM.cs|StopAutoguider|323|Meridian Flip - Stopping Autoguider
2021-12-20T21:11:11.2581|INFO|MeridianFlipVM.cs|PassMeridian|233|Meridian Flip - Stopping tracking to pass meridian
2021-12-20T21:11:12.3814|INFO|MeridianFlipVM.cs|PassMeridian|245|Meridian Flip - Resuming tracking after passing meridian
2021-12-20T21:11:12.4953|INFO|MeridianFlipVM.cs|DoFlip|127|Meridian Flip - Scope will flip to coordinates RA: 03:17:05 Dec: 60° 04' 01" Epoch: J2000
2021-12-20T21:11:15.4409|INFO|MeridianFlipVM.cs|Settle|310|Meridian Flip - Settling scope for 30
2021-12-20T21:11:44.6401|INFO|MeridianFlipVM.cs|Recenter|254|Meridian Flip - Recenter after meridian flip
2021-12-20T21:11:44.6451|INFO|CameraVM.cs|Capture|713|Starting Exposure - Exposure Time: 10s; Filter: ; Gain: 100; Offset 20; Binning: 1x1;

‌

I mean, luckily I had to stop my session because of clouds … just before my scope crashed …

Curently I do not have much confidence in automatic meridian flip with N.I.N.A. in this setup ….

‌

‌

[Christoph Nieswand]

I will observe it bit more in detail on the next run … whenever that might be …

[Stefan B]

Nina relies on the values reported by the driver. Where the scope is pointing to is reported by the driver, when to flip is based on the sidereal time, which is reported by the driver. That's why the driver has influence on this behavior.

Also make sure that your location settings are correct.

[Christoph Nieswand]

Ok, I have identified the problem:

1. I aligned the scope initially only roughly … effictively on the wrong star.
2. Very early I suddenly lost connection to the camera for unknown reason, reconnected and everything appeared to be fine.
3. However something went wrong probably simultaneously with the connection to the scope.
4. I did plate solving on the target, the scope position was correctly read from the scope, but the sync back failed silently … nevertheless using the calculated offset, plate solving succeeded.

2021-12-20T19:00:10.8083|INFO|CenteringSolver.cs|Center|71|Centering Solver - Scope Position: RA: 02:35:39; Dec: 61° 09' 50"; Epoch: J2000; Offset: RA: -00:41:32; Dec: 01° 05' 42"; Distance: 05° 22' 22"; Bearing: -97° 14' 22"; Centering Coordinates: RA: 03:17:05; Dec: 60° 04' 01"; Epoch: J2000; Solved: RA: 03:17:06; Dec: 60° 02' 46"; Epoch: J2000; Separation RA: -00:00:01; Dec: 00° 01' 15"; Distance: 00° 01' 16"; Bearing: -171° 55' 32"; Threshold: 1
2021-12-20T19:00:10.9240|INFO|TelescopeVM.cs|Sync|747|Syncing scope from RA: 02:35:39; Dec: 61° 09' 50"; Epoch: J2000 to RA: 03:17:06; Dec: 60° 02' 46"; Epoch: J2000
2021-12-20T19:00:25.9385|WARNING|CenteringSolver.cs|Center|89|Sync failed silently - calculating offset instead to compensate. Position after sync: RA: 02:35:39; Dec: 61° 09' 50"; Epoch: J2000; Solved: RA: 03:17:06; Dec: 60° 02' 46"; Epoch: J2000; New Offset: RA: -00:41:28; Dec: 01° 07' 04"; Distance: 05° 12' 10"; Bearing: -97° 50' 22"
2021-12-20T19:00:25.9395|INFO|CenteringSolver.cs|Center|98|Slewing to target after sync. Current Position: RA: 02:35:39; Dec: 61° 09' 50"; Epoch: J2000; Target coordinates: RA: 03:17:05; Dec: 60° 04' 01"; Epoch: J2000; Offset RA: -00:41:28; Dec: 01° 07' 04"; Distance: 05° 12' 10"; Bearing: -97° 50' 22"
2021-12-20T19:00:25.9724|INFO|TelescopeVM.cs|SlewToCoordinatesAsync|867|Slewing from RA: 02:35:39; Dec: 61° 09' 50"; Epoch: J2000 to RA: 02:35:37; Dec: 61° 11' 05"; Epoch: J2000

To my opinion it should not only give a warning and fail SILENTLY … it should announce the failure loudly … if that can have as a consequence that meridian flips do not work and the scope crashes.

Next question is, what happens in case you set the flag to NOT sync back intentionally? I think this flag is new with 1.11/2.0.0 . Do I run into the same problem, when the scope is not properly aligned? It scares me a bit to use this flag now.

‌

[Stefan B]

The flag should only be used when your scope does have a good pointing model already, so an offset to compensate will only be using small adjustments.
In your case the offset is in the realm of multiple degrees and therefore your scope is not pointing correctly and should rather sync instead of not doing any sync.

That a sync failes silently means, that a call to the sync method was accepted, but the coordinates were not updated. This is a driver issue and NINA tries to compensate for it by using offsets then.

[Christoph Nieswand]

I perfectly understand and agree that I should put a bit more effort in alignment of the mount. However if you look a bit around in N.I.N.A. tutorials., common sense seems to be now, that alignment is not important at all, N.I.N.A. does plate solving which fixes everything … well obviously not in any situation.

My point is the following:

N.I.N.A knows at the point in time when it initiates the flip exactly where the scope is pointing to (nothing can do better than plate solving), it knows exactly what time it is and what the observation location is. In the sequence windows the time of meridian for the object is correctly displayed, so it knows exactly when it should initiate the flip (and that it should NOT at this time) … BUT it relies on (wrong) info from the mount (it should know that it is wrong … and knows obviously that it is wrong, because previous back sync failed) … and initiates the flip anyway based on wrong information.

This does not make sense to me.

Initiating the flip simply means, that N.I.N.A. tells the mount to re-slew to target or slew to a position given by N.I.N.A. and let the mount to decide to do the flip … or not. This is correct and should be like that, because only the mount knows for sure on which side of the pier the scope currently is. In this particular case the scope was still on the west side and should correctly stay there for a while … but N.I.N.A. should have initiated again … when N.I.N.A. actually thinks that meridian was passed.

Eventually this would have been done automatically on the next plate solve automatically … I do not know … did not get to this point … clouds anyway.

Think about what would happen to an autonomously driving car, if the system would behave like that: system tells the car to turn left, the car replies to the system: no, you are wrong, I do not! … and was right at that time. The system is insulted and thinks: I do not tell this stupid car anymore when it should turn left … although I know I am right this time ….

‌

If you like you can close this issue now … in your opinion, it works as designed …

But in my opinion the design could be improved.

Thanks anyway for your response!

[Christoph Nieswand]

And a great “Thank you” for N.I.N.A. in general … it is a great software and I love it anyway and will continue to use it!

Have to say it, because we profit so much from your work and effort you put into this software!

Chris

[Stefan B]

It is true that perfect alignment is not important. But for example for a skywatcher mount, you still need to start at roughly the home position. Skywatcher mounts will actively reject syncs that are different by many degrees, making it impossible to center via syncs.

As for the centering itself, the meridian flip has no relevance for it. The flip itself is independent of centering. The scope will flip (or don’t flip) on a reslew after crossing the meridian and then the centering logic will follow. As you can see in your logs, your driver behavior is erratic, but NINA still managed to get close to the target position, with vastly incorrectly reported coordinates by your mount: Distance: 00° 01' 16" - it was just your pointing tolerance setting that was set to less, that the centering logic never deemed this as close enough.

As for your car exampe, this is just not correct. It would be more like this:
Nina: “Car move to coordinates N49.5 E7.5”
Car: “OK i am at these coordinates”
Nina: “No actually while checking with GPS you are at N50 E8 - Please update your coordinates to these”
Car: “Ok updated”
Nina: “What is your current position?”
Car: “My current position is N49.5 E7.5”
Nina: “But you just told me that you updated your position to the real coordinates? So you are still reporting the old coordinates- ok then i’ll provide you coordinates based on your incorrectly assumed position to reach the target by driving in relative mode (using offsets)”
Nina: “Here drive to these coordinates instead”

And finally - NINA relies on the telescope for the position to determine if a flip should happen. Cross referencing an image or what it thinks the scope is pointing to would be a bad idea for this specific task, because in the meantime all kinds of things could happen, like a user manually moving the mount. Scope crashes should also be prevented by setting up slew limits. This is possible for example using EQMOD and prevents any pier crash, whatever the software will do. Proper Pier Limits are important to be set up always.

The Skywatcher mount driver often caused problems in the past. EQMOD or GS Server are far superior alternatives and they work reliably. I’m using and EQ6-R myself and never had a flip fail.
In case you haven’t seen it already, there is also an in-depth description about the flip parameters and how these affect the flip behavior: https://nighttime-imaging.eu/docs/develop/site/advanced/meridianflip/#meridian-flip-settings-in-detail

[Stefan B]

Removing version: 2.0 Beta (automated comment)