Meridian flip with NINA

I dont know if it's related, but i've had trouble with meridian flips all week. (never had a single issue with them prior)

it's a bit odd for me. It's like the mount doesn't start tracking again after the flip. 

no hand controller on my CEM70 though. (I dont even plug it in)

I think I have figured it out, but I haven't been able to confirm yet.  In the iOptron Commander there's a meridian setting and it appears defaulted to 'stop' so I changed it to 'flip' and will have to test it soon.

No, that's incorrect (setting it to flip). Or more precisely it should not matter because the proper way to set it up is so that the iOptron commander/mount does NOT participate in the flip at all. You need it set up so that the mount can continue moving throughout whatever timing and mechanism you set up in NINA.

There are two approaches to setting this up in NINA, and most explanations tell you the hard way because it is more efficient in imaging time, but it also requires the mount (and mount control software) be carefully set up to stay out of NINA's way.

In NINA there is a "Pause before meridian" setting. Most instructions say set it to zero, and what this means is NINA will image THROUGH the meridian and go counterweight up.  Most mounts seem to default to taking some action to prevent counterweight up, either to stop, park, bounceback, etc.

What I recommend for people struggling with this is to do the following: 

- Set the pause before to a small but non-zero number, let's say 2 (how small is governed by how well synchronized your mount is with NINA, e.g. clock, longitude, etc., if in doubt start a bit larger). 

- Set the after-meridian times (Both time and max time) to a similar small number, let's say 2. 

- Ensure in NINA the "use side of pier" is turned on (probably already is). 

Now here is what happens – NINA images until you approach the meridian, but stops taking images so as to leave at least 2 minutes before transit. Note if taking 3 minute images this means it may stop up to 5 minutes before.  It then STOP TRACKING so the mount stops moving, and sits and waits…..

It waits until 2 minutes after meridian passage and issues a slew command to the mount for the target. This slew is not to a target past the meridian so the natural thing for the mount to do (pretty much all mounts) is to flip.  This is NOT reliant on the mount's meridian behavior (flip, stop, park) this is just the normal thing that happens.

This is the 'easy' way to do flips, and almost always works if times and such are reasonably synchronized.   The downside is it stops imaging for 4+ minutes at meridian.  For many a small price to pay.

To contrast this to the more efficient approach, when minutes-before is zero, NINA images THROUGH the meridian and expects the mount to keep tracking and NOT REACT to passing the meridian. This requires the mount be configured for a period of counterweight up tracking, which is not the default.  If you fail to configure it properly, it will take action on its own  - stop, park, something.  Nothing it can do is correct since NINA thinks it is in control, so even if it flips that is wrong since it will flip while NINA is imaging.

The more efficient approach is good, and worth considering, but it does require compatible settings.  I think anyone struggling should first try the easy, less efficient way.

But do NOT try to let the mount participate in the process in the sense of itself invoking the flip.  That will never work properly.  It may WORK, but it will the defeat everything NINA must do following, e.g. a recenter, possibly an AF run, etc.

Linwood

If it flips but cannot plate solve one distant possibility is that it mechanically has flipped but the mount thinks the target is back behind the meridian still, or more precisely after the first plate solve it tries to slew back past transit and something in the mount hangs.  

Are you sure it successfully plate solves after the flip, and then it is the slew to recenter that hangs?   It would be interesting to look at the log around that time, see what responses the mount sent back and how far off the sync was.

If all else fails give it a couple more minutes to get further from the meridian. 

And finally … double check cables.  Everyone gets so hung up in flip configuration that sometimes they find a cable snag occurred but that's too low-tech to consider. 

But most clues are in the log for what is happening.  Maybe not how to fix it, but it may give a clue what.

Why would you ever run a sequence in NINA without the target coordinates in NINA?   I think what you stated is true, it just seems like shooting yourself in the foot.

Generally speaking if you want a meridian flip to work properly (as well as a lot of other stuff like center-after-drift), all instructions that image for an object should appear underneath the context of a target in the advanced sequencer. 

It is certainly possible to not do so, by using the sequential instruction or placing instructions at the end outside the target. 

A quick way to see if your instructions are in the proper context is to drag in a slew to RA/DEC.  If it's under a target the instruction just appears, if it is not it creates a slot for you to enter the RA/DEC.   Look at this example.  the target (right now not filled in but present) is above and includes one slew instruction (green arrow), but the other is outside and does not.  So when executing anything like the last instruction there is no target context, and in a meridian flip it does not know what to do (other than use the last suspected coordinate). 

Generally everything when imaging should be under a target. 

Once the telescope is disconnected I do not expect anything reported about it to be valid. 

Are you saying the "disconnected" is not because you disconnected it (notably in the latter case)?

If you did not disconnect it, you need to figure out what did – commander (a logical disconnect of some sort), a physical disconnect, etc. 

Or am I not understanding.  The very first line of log would indicate the telescope stopped tracking, but I would anticipate something in the log before that to say why?

Linwood Ferguson:
If you did not disconnect it, you need to figure out what did -- commander (a logical disconnect of some sort), a physical disconnect, etc.

I am almost certain it was logical.  In the commander mount control panel the ra/dec numbers were spinning like slot machines.  I closed that and restarted it and it was still stuck.  I'm hoping it was a "first encounter" of a bug that caused the firmware upgrades that I recently installed.  My stuff was only 2yrs old.... 😅