Hi. I’m using the awesome SGPro for my imaging. (I’ve switched from the competition!). However my telescope has a large filter wheel and so I can’t let the scope point directly upwards towards the meridian. (regardless of whether a meridian flip has occurred yet or not).
It seems to me that SGPro does not handle this situation? There is only one configuration value ‘Minutes Past Meridian to Flip’. Setting this to +10 minutes saves a 'scope collision after the flip, but doesn’t prevent it beforehand. Similarly, setting this negative means that my 'scope will collide with my tripod before the flip.
Am I misunderstanding something? Can we please have a second configuration value named ‘Minutes Before Meridian to Pause’ or similar to allow for my situation? Then I can set them both to 10 minutes and all will be good 
Thanks!
Dave
I’m not sure about this one… Adding this option would only work on a pretty small fraction of all mounts. What kind are you using?
Hi Ken. Thanks for your response.
I’m using an iOptron CEM60, with a skywatcher 120mm scope and a QHY filter wheel.
To be honest, I’m not sure that my scope (focusser) will quite collide with the tripier at a 90 degree elevation, but I can see that it is close. (and I’m paranoid about damaging my mount if I have a collision). When using a different software program to control my mount, I set the limits at 10 minutes either side of vertical, so that I had some confidence that it would not collide. Now that I have switched to SGPro (which, I must say, I am loving), I was looking for the same capability.
If you can add this feature, that would be great, but I understand it if is low priority.
Cheers Dave
The primary issue here is that SGPro cannot ask most mounts to flip directly. Instead, we just ask the mount to “slew” to the current position, but the mount must think it’s in a position where it should flip when the slew command is given or it will just do nothing. In most cases, the mount must think that it’s already past the meridian. Stopping normal tracking 10 minutes early and waiting until a sufficient amount of clearance on the other side exists may put the mount in a position where it never thinks it needs to flip because:
- The mount is not tracking or
- The mount thinks there is still plenty of room left on this side of the pier
I would need to think on this some. Stopping tracking and restarting it after some period of time will, for most mounts, start tracking at the same location it was stopped (even though the target is long gone). This, of course, puts us back into the same situation where issuing a slew command does not flip because the mount thinks it’s still good. I am not very familiar with that mount or its driver and I’m unsure if you can create a meridian offset at which the mount will decide to flip early if issued a slew command… like “flip to the other side if I receive a slew command within 10 minutes of meridian”. In this case, SGPro could actually pause for some time and when there is clearance on the other side, resume tracking and issue slew. The trick here is to convince the mount it needs to flip early.
Of course, if your mount supports direct flip commands none of this is necessary. I can’t remember if your mount does or not… If you were able to set the flip time to a negative number and actually start a sequence without SGPro complaining, your mount does actually support early flip. But… either way, the problem still remains that we would need to figure out how to present these new settings in a way that does not falsely advertise an ability that will not be respected for most mounts.
It needs some thought…
Thanks Ken. I don’t fully understand your concerns, but of course you know more about the subject than I do
My (perhaps simplistic) thinking was that a setting (specified in minutes) that would be named something like “Minutes before Meridian to stop Tracking” would be suitable for all scopes, since at worst it would merely halt the tracking at, say, 10 minutes before meridian. If the other conditions that normally cause a flip when SGPro emits a slew command remain the same, I don’t really understand why other mounts wouldn’t adhere to the same logic as if they hadn’t been paused for 10 minutes. In other words, why would a mount not flip at, say, 10 minutes after meridian when commanded to slew back to the lost target? (assuming that it previously did so correctly without a pause).
BTW, the main reason that I switched to SGPro was due to the autofocusing capabilities, and I’m very pleased to report that this is working great for me. I was having trouble, but what really made it work well for me was to set the Focuser Backlash Compensation to a high value (150 steps). Without this setting, my first autofocussing point was always dud. Now I get lovely parabolic looking curves You might want to highlight this feature in your documentation, since it is somewhat hidden and easy to overlook, but (for me) essential.
Thanks Dave
It would if the mount actually thought is was 10 minutes past the meridian, but, unfortunately stopping tracking for some period of time and restarting it does not account for movement of the sky during its pause period. For most mounts the RA that the mount thinks it’s pointed at will remain unchanged. It would be up to the driver what the behavior of the RA location value would be when tracking is resumed. In the case that it’s the same RA as when tracking was halted, the mount will do nothing in response to a slew command.
Ken,
this should allways work if you:
- stop tracking
- wait, wait, wait
- restart tracking
- slew and center to target
Kind regards,
Horia
I’ve been looking at this problem and it is not at all trivial.
The first part, stopping the mount tracking into the pier is fine, all that’s needed is an hour angle limit. When the mount hour angle reaches the limit pause imaging and stop tracking. Normally you would have the limit after the meridian, with a positive hour angle, and make it pier side aware so that if the mount hasn’t flipped you stop it. If you need to stop before you reach the meridian you set a negative hour angle limit. Simples!
I say simple, but that’s already quite a lot of extra code to be written, debugged and tested, plus at least one extra property for the UI to be implemented and documented. It only stops, it doesn’t resume.
If the mount can track through the meridian but cannot reach the object in the other pointing state until it is some way past the meridian then I think that’s covered by the existing meridian flip position.
But combining these is tricky. You can’t continue to monitor the scope hour angle to decide when to flip - which is what you normally do - because the mount is not tracking and so the hour angle is not changing. You need a new mode where instead you check the hour angle of the target object and use that to control the flip. You need to be sure there is a target object and there could be all sorts of different modes, edge cases and special cases that need considering.
This is getting complex and time consuming to develop, test and debug. It may need more UI and that will add more complexity.
I found this an interesting comment. I guess I assumed that the hour angle of the target object was a primary input datum to these routines already. Probably this explains why the ‘solution’ seems fairly easy to me (as an outsider), but is a bit tricky to implement in practise 
Regards
Dave
Chris,
Right, you can not monitor the scope and you should not. You stop the guider, stop tracking and pause the sequence. Then you start counting secconds. When the time of the dead zoe is over (the user specified it in form of “Min in front of meridian to stop” and " Min past meridian to restart"), you restart the tracking, and restart the sequence.
The new mode is not that complex and should be programable on top of the existing procedures. The first ideea comming to mind is to restart by recovering the sequence.
Now please do not misanderstund me, I am not suggesting that this is a no brainer and that it can be done during a coffee break.
I am also not arguing in favor of such a function. Shoud I have this problem, I would first try to rotate the filter wheel by 180° and then, if that does not work, I would rise the scope on the saddle.
Kind regards,
Horia
Looking forward to seeing your code.
This will not work for most mounts. As I have described above, restarting the tracking the mount’s internal position is still the same as when tracking was stopped (unless the driver somehow accounts for movement of the sky during this period). Now when we send the command to slew, the mount simply ignores it because it thinks it is already there.
I am pretty sure that my AP1100GTO mount would not get confused by stopping tracking. When tracking was resumed, the subsequent slew command would see the target coordinates had crossed the meridian and perform a meridian flip. I can’t imagine any mount not understanding that the target coordinates had crossed the meridian.
Charlie
Yes, for my iOptron mount, when the tracking is enabled, the RA and DECL values reported by the mount remain the same as time passes. The Alt/Azi values change. However once the tracking is disabled, then the Alt/Azi values stay the same, as does the DECL, but the RA value just changes second by second. This suggests that the mount fully understands the rotation of the earth is still occurring when tracking is disabled.
My rigs are similar to many others’ - refractors on EQ6 family mounts - and I have to be careful to prevent the camera colliding with a tripod leg. There’s a range of about 20 degrees in dec in the danger zone and for any objects in this zone I create 2 targets in SGP, one for ante-meridian and the second for post-meridian, and a dummy target (in the safe zone) in between and then set the target times so that SGP will terminate the AM target before it gets too close to the meridian, slew off to the dummy target and image that for e.g. 40 minutes and then slew back to the PM target after it has cleared the meridian. But I am absolutely certain that one day this hobby will humiliate me again and I will forget to configure this collision avoidance. It would be wonderful if SGP had the smarts to handle this automatically but I would be happy with e.g. EQASCOM including a meridian proximity check, similar to its existing horizon limits, where any attempt to slew or track into a user-defined zone near the meridian would cause EQASCOM to park the mount. The danger zone would be defined by a set of HA, DEC values configured by the user.
I’d also like to add my “yes please” to this request, as I have two mounts that hit piers at certain declinations. While there are other solutions (raising the OTAs off the saddle, cutting a piece out of the piers), I don’t think any of them would be as elegant as the proposed software solution IMHO.
Adding this option would only work on a pretty small fraction of all mounts.
I just tested three of my mounts and they all knew where they were pointing after tracking was stopped prior to the meridian, and all flipped as expected when asked to slew to the same target that had passed the meridian. The mounts concerned are a Sky-Watcher EQ8, an iOptron CEM60, and an iOptron CEM120 EC2. I’m sure my 10Micron GM2000 would be fine too, although I haven’t tested it yet.
For each mount, I slewed to Aldebaran (via software, not hardware HC) when it was 30 minutes from the meridian. I stopped tracking and confirmed that, for each mount, the Az/Alt readings were now not changing, while the RA reading was varying. This to me is confirmation that the mounts know where they are pointing when tracking is turned off. I then waited for Aldebaran to be past the meridian by 10 minutes. I then issued slews to Aldebaran again, and each of the three mounts flipped successfully. Although three mounts are a small sample of the mounts out there, I’d be surprised if recently produced mounts don’t behave in this manner. I assume this would be an “opt-in” setting anyway, so mounts that get lost when not tracking would be catered for by not selecting the option.
I appreciate that I do not understand just how easy or difficult it might be to implement such an feature though.
Cheers,
Ross
Just one other thought - could you flip the filter wheel to point upwards, rather than the conventional downwards? With the QHY system, since it does not have an integrated OAG, it can operate at any angle (in 60 degree increments)
Thanks Buzz. The short answer is no; flipping the FW flips the OAG too, so I either have the FW hitting the pier or the OAG camera hitting the pier.
The long answer is, for “operational purposes” I’ve had to choose a fixed rotation angle for imaging cameras across several imaging rigs. I align the imaging camera sensors’ x-axes horizontally (eye-balling with the dec saddle plate is easy enough) so that determines the OAG position as vertical (above or below the camera), and thus the filter wheel position is decided too (vertical, with slight rotational adjustment available).
that is a shame, worth asking the obvious though 
Ken, I don’t think any Goto equatorial mount acts that way when tracking is stopped. They are aware of local sidereal time and account for it when calculating RA. That is, stopping tracking does not cause a mount to lose position.
-Ray