due to the size of my telescope, is there a way of setting the meridian flip in a way where it flips one axis and then the other?
When I perform automated meridian flip, it starts to rotate both axis simultaneously and sometimes my camera hits the tripod leg causing the steppers to slip and then the SGP is no longer able to plate solve due to a large error. Solution for me would be if I could for example move the RA to 0, then flip DEC and then finish the flip with RA again.
Is that possible or would it have to be implemented?
We don’t really have any control over how the actual meridian flip is executed. The mount is deciding all of that. Maybe there are some options in the mount settings that can control it?
I have the same issue with my EQ6 mounts using EQMOD, there is a range of declinations around the zenith where the scope can’t track to the meridian because the camera will collide with the tripod, and a wider range of decs where a slew from near the meridian will swing the scope in dec too early and again cause the camera to collide with a tripod leg. EQMOD has a safe mode of movement but this only applies when slewing from a counterweight up position and is not relevant to my situation.
I have a solution which you may be able to adopt but it is a bit of a pain. For each object I image I create 4 targets in the sequence: #1 This is the actual object I’m imaging; I set the end time to prevent any collision with the mount as the target approaches the meridian e.g. this could be anywhere from 10 to 30 minutes before transit, depending on target declination. I’ve worked out these time margins in advance. #2 This is dummy target with the same declination as the imaged object but an RA which is + 3 hours. When the end time on target #1 is reached, SGP commands a slew to target #2 and this slew will be in RA only because the decs are the same. The end time for this target should be a few minutes after the transit time of the actual object being imaged. Just need to take e.g. 1 image of this dummy target and then let SGP command a slew to the next target when the end time is reached. #3 This is another dummy target, it also has the same declination as the imaged object but an RA which is -3 hours different. The slew from #2 to #3 includes a meridian flip but there is no risk of collision now because the start and end positions are far from the meridian. #4 This target is the actual imaged object again, this time post-meridian. The slew from #3 to #4 is another RA only movement because the decs are the same and the start time for #4 should be long enough after the transit time to ensure the camera is clear of the tripod.
It is definitely a hassle to do this. The timings have to be worked out and, if imaging over several nights, tweaked each night. There are two sets of images - AM from #1 and PM from #4 - for each imaged object. For me it is worth the hassle and I have the time to plan it all in advance.
One possible way around this I guess might be to implement a “pause near meridian” option whereby a non-zero value would suspend the imaging session for that number of minutes before the meridian (including stopping the mount), then wait until that same number of minutes after the meridian before issuing the slew command to get the mount to do its flip, re-centring, etc. I know that would mean losing time around the meridian, but it would be better than having equipment hitting the trip / pier / whatever.
The only way to avoid losing that time would be to implement a multi-part flip - if I were doing this manually to avoid hitting the tripod, I would follow Jan’s method. As I understand it, the ASCOM standard has a SlewToCoordinates(RA, Dec) and SlewToAltAz(Azimuth, Altitude) functions so implementing such a three-part slew / meridian flip shouldn’t be impossible. It would be something like:
Step 1 - SlewToCoordinates(current RA+6, current Dec) - slew only in RA
Step 2 - SlewToAltAz(360 - current Azimuth, current Altitude) - slew only in DEC
Step 3 - SlewToCoordinates(target RA, target Dec) - slew only in RA
Step 4 - SyncToTarget()
It’s not as straightforward as a simple SlewToCoordinates(target RA, target Dec) instruction, but it doesn’t appear to be that complicated - although I’m sure there’s more to it than I’ve shown here
