To simplify one of my questions.

• Losmandy Gemini has a range over which a flip will happen
• kstars has an hour angle to determine when a flip is to happen.
• Where can you let kstars know when a flip can first happen?

Paul

Hi Paul,
the earliest time a flip can happen is exactly the configurable angle when crossing the meridian. If this angle has been reached, a new slew will be issued. A running capture will postpone this, i.e. the slew will be started as soon as the capture has completed.
HTH
Wolfgang

Wolfgang,

So it is possible that a capture will cause a goto command to be issued too late, and the meridian flip will not occur.

Without the software knowing when the earliest and latest a flip can occur it cannot completely avoid the situation where a flip does not happen, except by keeping the exposures very short.

Paul

Paul

Is your time frame where a flip is possible so tight? In my setup waiting for 6-10min has never been a problem.

Wolfgang,

Referring back to my original post, I have a 20 minute window where a goto will trigger a meridian flip - and that is really a bit tight as it is possible for some positions to still be an issue.

Any goto outside this range will not produce a meridian flip.

So, for example, in a worst case scenario, if I have a 30 minute exposure it can start an exposure before the meridian flip is possible and finish after. Given the tolerances for matching the mount to the software there needs to be some leeway, so it means the window is actually narrower.

If the software knows where the range begins and ends it can intelligently determine whether to start an exposure, command a flip or to wait until a flip is possible and then command the flip. The current situation is that a flip may sometimes work but sometimes fail, which is what my experience has found.

Paul

Paul,
many thanks for the explanations. This makes sense, but it isn't implemented (yet).

What if we had a threshold of a configurable amount of minutes that gives capture the chance to terminate the current capture. If the remaining capture time exceeds this threshold, it could immediately abort the current capture if a flip is requested.

Wolfgang

Wolfgang,

I think the current limit setting is not as efficient as it could be because I would prefer to perform the flip at the latest point rather than at the earliest point.

For instance, if I have a 20m window and my exposures were only 60 seconds then I could keep imaging later, before needing to perform a flip. The software should be able to effortlessly work this out, but it currently lacks sufficient information.

The simplest way to envisage what I am thinking is to have two settings

1) I can perform a flip after this point
2) I must perform a flip before this point

This will allow the software to know that under some circumstances it needs to suspend capture, because it would finish after point 2) but wait until after point 1) to perform the flip.

I have to admit it has taken me a lot of thinking to understand how all this works.

Paul

I think that what I meant with the threshold.

Wolfgang,

Taking on board what you were saying about how it currently works, I wanted to perform the flip a bit earlier. I currently have the Hour Angle set to zero degrees, but when I try to enter a negative Hour Angle it does not allow it.

Paul

That's true, but if you are familiar with building from sources, the limitation is set in mount.ui.

Wolfgang,

I have managed to get around the issue of the meridian flip hour angle not allowing negatives.

A tripod extension, that I bought in May has finally been shipped and delivered and it allows me to use a positive hour angle.

I do wish the other meridian flip problems could be addressed but I can now mostly work around them.

Paul

Glad to hear it, thanks. Allowing negative values should not be that complicated, I have it on my list.
The other idea about forcing a flip when capturing takes too long as well, but that might take a while.

Wolfgang