SharpCap Forums

So I finally had a chance to do some DSO imaging in the past week, after months of incompatible weather. I've had two attempts, and both suffered the same issue, which is that SharpCap did not get back on target after the automated meridian flip. The flip occurs, and the scope ends up pointed close to close to the right spot, but not exactly, and it does not seem to then do a plate solve and sync to correct the slew after the flip. The first night I had gone to bed and so lost the whole rest of the night. The second night I stayed up to observe what had happened, determined the problem, and did a manual plate solve and sync, which worked just fine. SharpCap nudged the mount a bit onto the target and it was off to the races, I went to bed and there were no further problems over night.

I presume SharpCap is supposed to do a plate solve and sync after the flip, yes? It would be pretty useless if not. :O) Am I missing a setting somewhere?

Thanks,

Mike

Hi Mike,

I have a similar challenge at the moment because I want to write a corresponding sequence: viewtopic.php?t=7945

If the polar alignment of the mount is not exact, you won't be able to get back to the target object with the flip alone.
So plate solving will always be necessary here.

However, we are currently trying to find out why the plate solver always grabs the last image BEFORE the flip during paused live stacking. Of course, the solution is then not correct...

We'll keep at it!

StarFlea

Thanks. That would be distressing if I have to manually intervene to get this to work.

Hi Mike,

the Meridian Flip step in the sequencer is purely to move the mount to the other side of the pier - this is inline with the philosophy of the sequencer where blocks typically do something simple and you build more complex things by using multiple blocks. Actually, just getting the mount to the other side is not so simple as it sounds, as some mounts support a single command to flip sides, others don't and some can get 'stuck' if they track beyond the meridian and need to be nudged back to the right side of the meridian before executing a GOTO to flip to the other side.

At a minimum, you would probably also want to re-GOTO the target after the flip, then solve and sync. You may also need additional steps to deal with guiding, live stacking, settings during the solve/sync process, etc.

You can see why the step is currently marked as experimental!

cheers,

Robin

Robin,

Just to clarify, I am not using the sequencer. Just live stacking. No guiding, just SharpCap dithers and re-centering. It happily flips at the meridian. It just doesn't end up quite on the target and then can’t align.

I suspect what is happening is that at some point the recenter function issues a goto command to recenter, which causes the mount to automatically flip once the meridian is passed, which is great. The only thing I think it needs is a setting that automatically does a plate solve and sync if (a) plenty of stars are found but (b) SharpCap can’t align the frame, indicating that the pointing is wrong.

Ah,

right, that makes sense - the mount driver itself will decide to flip at some point when the GOTO for the recenter ends up being on the 'wrong' side of the meridian. I wonder if that is robust though - if you don't have a recenter at the right moment then you could end up reaching the meridian, tracking stops, trailed stars, fails to stack, stuck...

Once the mount has decided to flip, if you are far enough out of position that live stacking cannot align then you end up stuck too at the moment. If the alignment manages to succeed (even if 1/2 a frame out) then the recenter would trigger again and it may well correct and continue. On the other hand, it might go wild at that point because the orientation between screen and mount co-ordinates is inverted from how it was before the meridian.

I'll have to check the code when I get back from vacation to see how it might be made to cope with a flip happening behind the scenese during stacking - I suspect it will need a fair amount of change to cope robustly.

cheers,

Robin

My setup is robust to the first failure mode, as I have my meridian limit disabled on the mount, so it will never stop tracking and will definitely need a recenter within a reasonable time after passing the meridian, long before any risk of collision, which would be many hours later even without a flip.

Robin,

Is there any update on fixing this?

Thanks,

Mike

Hi Mike,

no - still trying to work out what the best approach is, since this is an 'accidental' feature - the flip happens because the mount ASCOM driver decides the GOTO needs a flip, rather than because of any code I have written. I'm also busy with a number of other (non SharpCap) things right now, so I'm not doing a great deal beyond answering forum questions and fixing clear bugs for the next couple of weeks.

cheers,

Robin

Understood. Thanks for all the great work, Robin.

Mike