I’m writing a new ASCOM driver for a GEM mount and at present the side of pier information is not available.
I’m testing with SGP and find that when I start a sequence that crosses the meridian I get the warning “This telescope is not capable of performing a meridian flip!” and during the sequence the mount keeps going past the meridian.
The mount will do a meridian flip, once it’s tracked past the meridian a slew will do this.
It seems to me that this flip handling is a little too restrictive. Simply waiting until the mount has tracked past the meridian - as set by the flip position - and doing a slew will do the flip. I don’t know of a reason this would be harmful while not doing the flip could be because it leaves the mount tracking past the meridian, heading for a stop - hopefully a soft one.
Can I suggest this is changed as follows:
Change the warning message to say that the Meridian flip state is
unknown and that a flip will be attempted at the flip position
defined.
Ignore the PropertyNotImplementedException errors that attempting to
read the SideOfPier throws.
When the flip position is reached do the flip by slewing to the
current position as you do now.
This will, I think, make SGP more reliable and able to handle a wider range of mounts. I doubt this one is the only one where the pointing state isn’t available.
You can determine the side of pier by calculating the hour angle for the mount which requires that the mount give you an accurate sidereal time. I did this for a mount that does not report side of pier and it passed the ASCOM conformance test 100% I think you know that side of pier is not the physical side but the pointing state which is what the hour angle will give you.
+1. My AP mount will flip after the meridian, but I frequently use the meridian delay which allows the mount to flip early. It would be ideal if the driver and mount support this, but…
I’m no expert on this issue, however, if your refer to “ASCOM SideOfPier Behaviour.pdf” in the ASCOM developer documentation and look at figure 2, it seems to pretty clearly indicate that the hour angle represents the pointing state. As to the pointing state changing through the meridian, yes I agree it will according to this document and I see nothing that indicates that it is wrong to do so. Based on what I have seen in the SGP logs, it appears that SGP is using hour angle to determine time to flip. Having said all this, I did suggest to Ken and Jared that it was possible that a mount would change pier side as it moved through the meridian and they replied they have never seen a mount do so. As to the conformance test, it is documented that it avoids testing near the meridian because of variations in how a mount reports near the meridian.
No. The pointing state must not change as the result of any tracking move, only as a result of a slew.
If you think about it if the pointing state did change as a result of tracking past the meridian then synchronising a dome shutter would go wrong at that point
The only reliable way to get the pointing state is by reading the declination axis position.
Hour angle will work to determine roughly what side of pier a slew will end up on but that’s not the same as what the current pointing state is. Even that isn’t accurate close to the meridian which is why there’s a delay.
It took me a long time to get this sorted out and it’s not trivial.
@Chris I get changing the message, but I don’t see what else we can do. It seems like everything on your list is in the current behavior set. We already stay away from side of pier if it’s not implemented, we already warn when mounts like this need to be past the meridian and, as you noted, have a fallback instruction set to perform flips via slew.
So, this…
I don’t understand. We are already compatible with these mounts… I agree that the messaging needs to be changed to make it a bit more clear (this back from when we actually didn’t support flips without side of pier implemented). Am I missing something?
What you say makes sense but I find the ASCOM documentation ambiguous on this point. On one hand, Figure 2 indicates that hour angle indicates SideOfPier, however, the API document does talk about reading the physical DEC axis angle at least for GEM mounts.
The mount for which I wrote a driver (iEQ45) has no way to report the physical DEC axis position, yet the manufacturer’s driver does report SideOfPier and does pass the conformance test. So I don’t know how they do that if they are not using hour angle. This is exactly the issue raised by your original question. If you would like to continue this discussion, please private message me.
I wasn’t clear. If read SideOfPier is not available in the driver then SGP shows the warning I posted and also disables the meridian flip.
There is no flip done, the “Use Auto Meridian Flip” checkbox in Control Panel - Telescope is unchecked. I had checked this.
All It comes to is that I’m suggesting that this is not done and that the slew to flip is done. I’d also change the warning message but it’s allowing the slew that is what I think we should have.
Right… .OK. So we are supporting “AP Like” mounts that can read side of pier, but not set it and you are referring to a set of mounts that can neither read or set (we seem to be rejecting these). I think I get it now. Is that right?
On a slightly different note, for AP mounts, is there any feasibility in allowing the mount to flip early if the meridian delay is enabled in the driver? If I try to set a negative value in degrees past meridian, I’ll get the error that the mount doesn’t support flipping early (as expected).
I’m not sure how we could ever correctly flip a mount if it doesn’t expose the side of meridian it is currently on. I mean we could guess but it would be just that. And if it failed we would have no way of knowing (unless we forced plate solving and validated that the camera angle was now 180 degrees from where we started).
I can see the desire to want to do this but unfortunately I don’t think we have enough data to actually make this happen with any sort of reliability. We could certainly attempt to make this work but in all honesty I think this would really just add more headache to the end user than necessary.
I got the impression from Ken’s reply earlier in this thread that this behaviour was already expected and not having this was some sort of an oversight from when the meridian flip process had been simplified.
It seems very reasonable that a pier flip is attempted when the user specifies. This is what SGP does if SideofPier is available. If the user is wrong no harm is done, the slew ends up on the same side. This is the same as when get SideOfPier is available because you are still relying on the user deciding when the flip is done.
It will cause no more headache to the end user than the existing system. You will still get messages asking why the mount did not move and the answer will be the same - the mount’s idea of where the flip position is and the user’s are different.
What you won’t get is this thread and the other similar ones asking for this, so less headache for the end user and less support for you. Sometimes less is more.
I think there was some confusion on the Get vs Set for SideOfPier. We currently support meridian flips regardless if the setter is available. However we rely on the Get SideOfPier to be able to flip.
Actually you wouldn’t get a message about the mount not flipping as we’d never be able to know if it did the flip or not. SGP would just continue on happily until the mount stopped tracking or hit the pier. The only way to validate would be to require plate solving to be enabled in that case.
Yes indeed, this how SGP currently behaves. You disable a function that the user has set and allow the mount to continue until it hits a stop - hopefully a soft one.
I did not mean to convey my agreement / disagreement one way or the other on this subject. I made a couple comments and asked a couple questions in order to gain an understanding of the problem domain.
I did not read the conversation,
but let me state please allow for this will attempt flip.
I too have a mount that does not implement side of pier … so frustrating you see the time to meridian when not imaging, only to see it disappear when you actually start imaging!
I can get around by this using POTH hub and simulated SOP, but POTH hub is slooooowwwww for my mount and it does not always simulate SOP so the only way is to reboot everything so I start from a working state for the night.
Other automation softwares do work with my mount, reported by other users, until know I hold off investing in those but sooner or later I will, as automation is for me important.
@Jared and I discussed this and we approached it from an open-minded “how can we do this perspective”. In the end though, we have decided that this is not something we are willing to support right now. All of the implementation strategies we discussed leave unknowns (at some point in a sequence) about true mount position for which we feel uncomfortable guessing about.
For now, we will continue to support ASCOM mounts in two categories:
Those that can read and write to side of pier
Those that can read from side of pier, but not write to it
An alternate solution for those authors that feel it is not possible to determine the side of pier within their own driver, the POTH driver appears to wrap this property with some logic that attempts it.