Avoiding the Zenith on the way to the Calibration Zone

[Brad Templeton]

PHD2 likes to calibrate on the equator, near the meridian.   However, if your mount is currently pointed somewhere not too far from the meridian towards the pole (As Ursa Major is right now. or in the home position of most telescopes) that's a problem, because the shortest path from there to PHD2's calibration zone is through or close to the Zenith.  Which is the zone of danger for anybody with a refractor, and a high risk of a tripod leg strike.

Now if you can, you set limits in your mount so it won't go to places that might cause a collision.   In my case though, if PHD2 attempts to slew to the calibration zone, the mount will correctly stop when it hits the limit.     And stay stopped, with tracking off.  I have to manually reset things, start tracking again and then slew for calibration.

One solution would be for PHD2 to understand a limit (perhaps in distance from Zenith) or just by default stay some safe distance away from it.   That means when slewing through that danger zone calculating a multi-hop journey that stays away.  I could try to do this manually but it seems like a good idea for everybody.

Also on the wishlist -- since there is no value in PHD2 trying to guide or calibrate when the mount is not in siderial tracking, PHD2 could just turn those on before doing such actions, or warn if tracking is off.

It would also be nice if I set a calibration zone at +10 degrees instead of the default +5 if it would remember it.  +/- 10 is less likely to enter the bad zone as well.   In general it's better to calibrate west of meridian unless you want to guide east of it and it makes a different, because if you go to 5 degrees east of meridian you are due for a flip in a short time.

[Bruce Waddington]

I think if you have this problem, you can avoid it by using the tools already available in the Calibration Assistant.  You can set and re-use a custom pointing position to stay as far away from the celestial meridian as you like.  Please read the Use Guide on the topic and give it a try.

https://openphdguiding.org/man-dev/Tools.htm#Calibration_Assistant

Bruce

[Brian Valente]

Brad

what mount do you have?

The limits you are describing are generally referred to as a "safety slew area" and imo really should be something implemented in the mount controller/driver. PHD is no different than any other ascom client if there are certain sky positions where you need to slew around. Mounts like astro-physics already have this built-in to the control box and configurable via the software.

Brian

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/e62462f3-2d2f-45f9-a557-4dfc24f35bb9n%40googlegroups.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

nature portfolio brianvalentephotography.com 

other astronomy https://www.brianvalentephotography.com/astrophotography/ 

[4b...@templetons.com]

I have an onstep mount.  And yes, the limits are built into it. And should be!   The problem is that while I would wish dearly otherwise, maybe mounts, if asked to slew to a place on the other side of their limits, are not smart enough to go around them.  So they go up to them and abort.    So, while mounts should fix this, they aren't any time soon.

The phd2 specific issue is that it, every time I calibrate, wants to slew near the meridian

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[4b...@templetons.com]

Yes. I could calibrate elsewhere, but as that guide says, the recommended spot is best, and why not calibrate there?  I can calibrate there just fine. I just can't slew directly there if the short path there is near the zenith.  The mounts could be smarter, and take a roundabout path if the direct path is barred. But none of my mounts are.  If everybody else has a mount that does this right, my request becomes low utility.

--

[Dale Ghent]

Heh if you’ve defined no-go areas in you mount’s driver and the mount is blithely ignoring those limits and is willfully violating them when skewing from point A to point B, *that* is definitely a driver defect that the driver’s author should address. Asking higher-lever apps in the stack, such as PHD2, to somehow be aware of these limits and avoid them (there is no way for these apps to know of such limits) is really barking up the wrong tree.

> On May 22, 2024, at 04:29, 4b...@templetons.com wrote:
>
> not

[Brad Templeton]

You may misunderstand, because I agree with this.  The mounts should know how to seek along an indirect path to avoid blocked areas.  Perhaps someday they will.  But today, I believe many don't.  (Could be wrong, haven't tried enough of them.)       I also agree this is a layer violation, that it belongs in the mount.   But facts on the ground are that it's not in some mounts and won't be soon.  (I would be interested in which mounts do handle this correctly.)       Some mounts view the limits as a way to say, "If the user mistakenly drives the mount into this area, protect them from their error causing a leg strike by halting all movement."    They think the user has made a mistake trying to seek from one side of the Zenith to the other, and they have done their job stopping the user.      The smarter thing is to correct the mistake and take an indirect path.   But sadly, they are not that smart, and that leaves the being smart to the smarter higher level layers, or that it be nowhere.

I mean, I can work around this.   I can think about whether it might happen, and manually slew a path around the zenith with multiple targets.  A computer can do that better and faster, but I could pull it off.    The only reason I bring this up in PHD2 is it's the only tool I use that as part of regular use, wants to deliberately seek close to the meridian, which it thinks is the best place to calibrate.    Most other tools spend their effort trying to avoid the meridian.   That's probably why the mounts don't feel motivated to be smart about this.  Their users are not trying to seek from things near the north meridian (where you are in the home position, or after a NINA 3 point polar align, or looking at targets in Ursa Major in galaxy season) to the south meridian for calibration.  So this problem hasn't come up much, only for people who start their night calibrating PHD2.

[Dale Ghent]

> On May 22, 2024, at 14:50, Brad Templeton <bra...@gmail.com> wrote:
>
> You may misunderstand, because I agree with this. The mounts should know how to seek along an indirect path to avoid blocked areas. Perhaps someday they will. But today, I believe many don't. (Could be wrong, haven't tried enough of them.) I also agree this is a layer violation, that it belongs in the mount. But facts on the ground are that it's not in some mounts and won't be soon. (I would be interested in which mounts do handle this correctly.) Some mounts view the limits as a way to say, "If the user mistakenly drives the mount into this area, protect them from their error causing a leg strike by halting all movement." They think the user has made a mistake trying to seek from one side of the Zenith to the other, and they have done their job stopping the user. The smarter thing is to correct the mistake and take an indirect path. But sadly, they are not that smart, and that leaves the being smart to the smarter higher level layers, or that it be nowhere.

I don't misunderstand you at all. In fact I've seen this movie *plenty* of times before. User wants something improved or fixed in a hardware product or its driver and, instead of engaging the vendor who is responsible for the product, the user instead petitions the people who seem most or immediately accessible, even if those people have nothing to do with the issue at hand or addressing it at their app's higher level in the stack would be inappropriate, if not extremely cumbersome or even impossible.

The problem here isn't that PHD2 is doing something wrong - it is in fact correctly doing everything it needs to do to perform a function that requires mount movement - a most pedestrian of operations that is slewing to a coordinate. The problem, as you descried it, is that the mount is violating the slew or tracking limits you have set up in it. The problem must be addressed at its source; not worked around in a blind and ham-fisted fashion higher up in the stack. OnStep must be made to honor these limits during slews and move the axes in the ways needed to avoid them. It should also promptly throw an error if the destination coordinate is within an off-limits area. Or, perhaps it can already do that, but an inadequate configuration prevents it.

I monitor the OnStep Groups.IO forum and I have not seen a post from a person of your name there concerning this topic, or any other topic, unless you happen to be posting there under a different email address and name. Even if that were the case, I can't seem to find a recent thread regarding this issue. So, I have to ask, have you /really/ asked the OnStep maintainers and its community about the issue of slews violating limits? Is your conclusion that nothing could ever be done for OnStep really born out of interactions with the OnStep maintainers? Have you made sure that your issue with limit violations isn't the result of a misconfiguration in the OnStep ASCOM driver or firmware? The OnStep ASCOM driver and the OnStepX firmware is also open source and available on github[1][2]. I do not see any issues posted there concerning this problem limit violations during slews.

> I mean, I can work around this. I can think about whether it might happen, and manually slew a path around the zenith with multiple targets. A computer can do that better and faster, but I could pull it off. The only reason I bring this up in PHD2 is it's the only tool I use that as part of regular use, wants to deliberately seek close to the meridian, which it thinks is the best place to calibrate. Most other tools spend their effort trying to avoid the meridian. That's probably why the mounts don't feel motivated to be smart about this. Their users are not trying to seek from things near the north meridian (where you are in the home position, or after a NINA 3 point polar align, or looking at targets in Ursa Major in galaxy season) to the south meridian for calibration. So this problem hasn't come up much, only for people who start their night calibrating PHD2.

The movement of the mount axes during a slew is not controlled in any way by user-facing apps such as PHD2. PHD2 gives the mount driver an RA+Declination coordinate to point at, and it's the mount's job to manage how it physically maneuvers the axes in order to point at the requested coordinate. If the mount, via its ASCOM driver or management UI, permits you to program in slew or tracking limits and it is not honoring them, that is a concern that must be addressed in by whoever is in charge of maintaining the mount driver and its management functions.

Additionally, there is no feature in the ASCOM mount/telescope API that even allows a driver to convey any limits to an up-stack app such as PHD2. So the argument that PHD2 should try to divine some way to maneuver around the limits doesn't hold water because there is no programmatic way it could make itself aware of any limits in the first place.

You really need to take this issue to the OnStep forum. The problem you describe can involve *any* user-facing ASCOM client app, and I doubt your plan includes going around to each. and. every. imaging and planetarium app out there to petition them to conjure up some way to do execute slews that magically avoid limits they are unable to know that even exist.

[1] https://github.com/hjd1964/OnStep
[2] https://github.com/hjd1964/OnStepX

[4b...@templetons.com]

As I have said I agree that it's the mount's job, or should be.  And I have posted about things in the onstep forums, and about this specific issue in the forums for my particular mount.  I 99 percent agree this is the right order of places to bring it up, and perhaps it was not clear, but the term I used. "layer violation" is the term of art in my world to express that philosophy and all the things you point out.  I really, really get that, fear not.

But to wax philosophical...

But sometimes, rarely but not as rarely as it should be, layer violations make sense.  I only raised the issue here because of the potential of that.  Note that this is not to do with seeking into the forbidden area, which I think every mount should reject immediately.  This is about seeking through it, to a valid location, which mounts should not reject. Rather they should be clever about it.  But clever is more work, and embedded firmware resists complexity where pc apps have less fear of it. And sometimes we do layer violations in such situations.  Particularly if the outer layer program is unusual in wanting the inner feature even though it belongs there.

That said, I will encourage better handling of this from the mount vendor and onstep.  Maybe even take the effort to see if I can build my mount's version of onstep from source to fix it.  But right now, phd2 is about the only place I am likely to run into this.  (I don't tend to image multiple targets in one night, which could in theory trigger it.). Plus I am going to put in a pier so I only would get it when doing remote trips on a tripod.

Anyway, rest assured. I comprehend what you say about whose job it should be perfectly, and did when I brought this up.