goto object crashes into pier when refining position

[nigeld]

setup :-
latest sharpcap 4.1.11680 and also previous version
windows 11
iexos-100 mount
svbony sv705c
C6 with reducer

Problem
Trying to point at Jupiter which is close to the moon and is just above my house (I’m within a few yards of my house so it’s just above it). The telescope slews in the right direction, it then tries to platesolve and refine its position. At this point I’m not entirely sure whether it fails completely to platesolve (possibly due to too short an exposure, or the moon glare or the house or something else) or it platesolves, but it then it moves the scope. At this point rather than moving a short distance it crashes the scope into the pier. No idea if it’s accidentally getting incorrect coords due to the problems with what it can see and getting confused or something else.

Thing is when this happens I hit the emergency stop, but this doesn’t seem to stop things. Instead the ascom devicehub seems to lock up and sharpcap as well. I end up shutting things down and restarting.

At one point I hit cancel when it looks like it was moving to a correct position (it decided to do a flip which is why I thought it was going to crash), this resulted in it completing the move which I believe would be what’s expected. Sharpcap and ascom were fine.

So I’m hitting two problems :-
The refine position crashing the scope into the pier.
The emergency stop not working.

I will try and work out which logs contains the details and add them.

[admin]

Hi Nigel,

ouch! Not a nice thing to happen

There are various things in the ASCOM driver and the scope control handset that should prevent this from happening (slew and movement limits) but it may be possible for those things to end up being disabled, confused, or even not there at all if they were never written by the ASCOM driver author in the first place.

The 'confused' state is perhaps most likely as it would tie in with your idea about a bad plate solve. If the plate solve co-ordinates are wrong and the mount accepts them then the actual physical position of the telescope could be quite different to the position that the mount *thinks* the telescope is. So, the mount may think the movement is safe when it isn't. The only problem with that is that SharpCap only searches with 15 degrees of the current position when plate solving, so the result couldn't have been far out (unless the plate solve radius setting has been changed).

Another possibility that came to mind was what would happen if the mount position was one side of the meridian and the sync position was the other side - that could possible thoroughly confuse an ASCOM driver if the author hadn't considered that possibility, but from the time of your posting, I suspect that Jupiter (and moon) were well past the meridian, so that doesn't really hold water either.

Of course, we mustn't forget the possibility of a simple glitch in either the mount ASCOM driver or the mount itself - if something went wrong during the movement and the microcontroller in the mount got 'stuck', that might explain both the continued movement and the fact that it did not respond to emergency stop requests.

Seeing the log would definitely be useful, as it should record the position of the mount initially, plate solve results and the commands that SharpCap sent to move after the sync. If those all look sensible then we would be looking for issues on the ASCOM/Mount side, while if one or more of those seem to be bad values we will be looking for issues on the SharpCap or plate solving side.

cheers,

Robin

[nigeld]

I think Ive managed to dig out one of the appropriate logs.

My mount is an iexos-100, so no hand controller and there are no limits that I know of that the user would set in the mount or its ascom driver afaik.

The time I did a cancel instead of an emergency stop it completed its slew which was basically a flip which I wasn't expecting hence the cancel so it could be that things were around the meridian. There have been incidents of meridian flips and platesolving causing pier crashes. The solution usually is to set things so that the mount isn't told to do a flip until a reasonable way past the meridian as there seems to be some edge case with flips and platesolving which can cause problems.

[admin]

Hi,

thanks for the log - I checked in stellarium for the times shown in the log and your rough lat/long co-ordinates, and it looks like you were targetting Jupiter when it was within a degree or two of the meridian. In the end, when you got a plate solve/sync to suceeed in the first log, the offset was 9.8 degrees (quite large, but not excessive). I'm pretty sure that the sync command ended up putting the mount into a situation where it decided it was on the wrong side of the meridian, so the re-GOTO then caused it to flip. I still can't quite see why a flip should crash the telescope into the mount, even in this case though. It may be that the cross-meridian sync got the ASCOM driver for the mount into a confused state.

I can also see at least part of the reason why the emergency stop failed - SharpCap tries to stop the mount tracking and to stop any GOTO movements when you press emergency stop, and the ASCOM driver was giving an error to the request to stop tracking (the error message was a cryptic 'Tracking'). Because of that error, the Stop goto code was not happening. I will fix that so that it ignores any errors from stop tracking and tries the stop goto anyway.

For the cross meridian sync, I will put in an additional check and confirmation prompt I think - other mounts I have tested reject the sync if it is across the meridian, but it seems that is not universal.

Hopefully this should make the whole thing safer for future versions - hopefully nothing was damaged during the incident!

cheers,

Robin

[nigeld]

It seems that the emergency stop causing a hang might be due to problems lower down in the stack, this is being looked at.

Ok so I was close to the meridian, one day I will work out exactly where that is

I usually avoid flip’s having had similar problems before with kstars. Seems to be some problem if a flip happens too close to the meridian and the answer was to overshoot so that the platesolve always ended up in right half and doesn’t cause the mount to think it’s in australia or whatever. Is sharpcap telling the mount to flip or is it down to the mount to decide?

[admin]

Hi,

in this case it's down to the mount to decide - SharpCap just says to it

* These are your current co-ordinates
* Please go to this location

and one of those triggers the mount to flip when it is close to the meridian (due south).

cheers,

Robin

[nigeld]

Hmm, it does flip ok at least some of the time given that when I tried a cancel instead of an emergency stop it was actually flipping. When I did the emergency stop were the coordinates it was being told to go to reasonable?

[admin]

Hi,

the offsets calculated by the plate solving are about 9.8 degrees in one of the logs and 2.0 in the other - both seem reasonable if you have a rough initial alignment to begin with.

I did make changes for the most recent update to prompt the user if the current position is one side of the meridian and the calculated plate solve position is the other when doing plate solve + resync, which should at least prevent this from happening in future without warning. I have also improved the emergency stop.

cheers,

Robin