I have recently been experiencing what I can only describe as inconsistencies with the meridian flip. It occasionally works but not always.
So, to try and understand what was happening I have been running some tests on stars that were close to crossing the meridian and watched what was happening.
I have my mount set up to flip when a goto command is issued from 86°18’ to 91°18’ which is anywhere between 3°42’ before the meridian and 1°18' after the meridian.
I have INDI set up to flip if HA is > 0°.
When the star gets within my preset range and I use the goto icon it automatically flips the telescope, so I am confident that the software can work if it issues the goto.
However, when I watch the star cross the meridian it does not seem to issue the command.
I have noticed that the mount tab has a new meridian countdown that aften seems to remain fixed.
In the attachment it shows the main screen has HA: -00h 50m 20s but the mount has stopped changing and is frozen at Meridian Flip in 01:14:07.
I also notice that when I first goto the star the mount tab seems to be about 10minutes behind what the HA shows.

A further question is related to my mount configuration. I have a 20 minute period where a goto issued will produce a meridian flip. but what should happen if I have a 30 minute exposure just before the meridian flip range is reached. If it starts the exposure it will exceed the limit before the exposure is complete and not flip but if it attempts a goto before the image it will not flip. Does it wait until it is within the flip range? How does it know what the flip range is, there does not seem to be any way to configure it.

Paul
 

I am wondering if this is a daytime problem only as testing at night seems to produce the meridian flip.

Paul

I have two screen shots that show that when the Hour Angle shows 00h 00m 02s it has not reached the meridian line displayed.
About 2 minues later the flip is initiated and the telescope arrives at the star shortly after the star goes under the meridian line.
I was expecting the star to be at the meridian line at the zero hour angle.

Paul
 

Hi Paul,
let’s go through your questions step by step. When the MF countdown is freezing, the mount should have stopped tracking. Is your mount really tracking *and* the countdown is frozen?

Wolfgang

Wolfgang,

The tracking is enabled and eventually it gets to the point where a goto will not work as the mount limit is reached. The screenshots provide confirmation.

Paul

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