Could cone error cause problems with meridian flips (and could ConeSharp fix this?)

[Luke Spacehopper]

Hi,

I've been experiencing failures with automated meridian flips recently in APT via EQMOD, driving an NEQ6. The mount goes to one side, an image is taken, solved, calculated to be about 6,000 pixels out, and then the mount slews right across to the other side, and repeat until the number of attempts limit is reached, and that's that. However, if I leave it for quite a while - nearly an hour - it then continues on its merry way, flips as it should, and everything is fine again.

I've checked multiple times that everything is set up correctly such as locations, times etc, it all checks out. This hasn't happened before, plus I haven't changed anything. However, I also recently had strange doubled/rotated diff spikes when stacking before and after a flip, which someone suggested could be cone error - so, I'm wondering, could cone error also cause this meridian flip issue?

I'm just thinking that, if the scope is on one side, takes the shot, flips and takes another, could cone error make it think it's way out given the non-orthogonality, and just keep flipping? It's just a notion I had, I haven't seen this mentioned anywhere but I'm at the end of my tether with this issue and I'm hoping ConeSharp might be the answer.

Thanks
Brendan

[admin]

Hi Brendan,

I think there might be something in the cone error idea - at least it might be one way to explain what is happening.

Let's suppose you have really bad cone error - so that when the mount thinks it is getting close to the meridian (pointing nearly due S, or bearing=180), the telescope is offset by maybe 5 degrees and is pointing to roughly bearing 175.

At this point, the software decides to do a meridian flip, moving the mount round to point just past the meridian, say bearing 180.1. But... cone error points the other way when the mount flips, so now the telescope is pointing to bearing 185 Plate solving kicks in and tells the mount to recenter, but the offset is so much that it puts the target co-ordinates back on the *EAST* side of the meridian, so the mount flips again as part of the GOTO (which is pretty much expected if you tell it to GOTO somewhere on the east side...)

Obviously 5 degrees is a crazy amount of cone error, but it could happen with 1 or 2 degrees in the same way if the flip/plate solve/goto happens fast enough (before the target has drifted enough to put it properly past the meridian).

Certainly trying to fix any cone error would be a good first step - other options (if possible - I don't use APT these days) would be

* Let the mount track a few degrees past the meridian before flipping - might require EQMOD settings tweaks too. That would let the target get far enough past the meridian that when flipped the recenter doesn't re-cross the meridian

* Put some sort of delay in the flip - so it hits the meridan, waits 10 minutes, flips, continues - the 10 minutes will allow the target to drift 2.5 degrees, which might be enough to fix the issue - increase the time otherwise.

Hope this is helpful,

Robin

[Luke Spacehopper]

Thank you Robin.

I already have delays built in via APT - five minutes before the meridian and 10 minutes after. This would make it a very large cone error though, I suppose?

I could also change the limits in EQMOD but I don't want to turn them off because I know they've stopped my scope from hitting the mount in the past.

It's a mystery frankly. If it isn't cone error, I don't know what it is.