First post to the forum so please bear with me
I am on the trial period of SGP and use an AP1100GTO + APCC as imaging mount. I have found some threads mentioning APCC but nothing specific to how SGP interacts with it on meridian flips.
As some of you may know APCC handles meridian flips for AP mounts according to user specific profiles for their own meridian limits. For example if imaging close to the local equator there may no need to flip at all during an imaging sessions whilst imaging at the zenith will trigger a flip halfway through.
I can see in SGP the option to enable or disable meridian flip and within it the option to re-centre. Is it possible to allow APCC to handle the meridian flip but for SGP to then take over and handle the re-centring?
Thank you
Roberto
Has this been addressed in the newest release of SGP? Could SGP query the driver (APCC/AP ASCOM) for pier side and need to flip before triggering the flip?
Hi Ken
Thanks for replying. I’m not sure new software would be necessary. APCC controls the meridian flip, SGP would only need to instruct the GoTo.
Maybe Ray Gralak is who I should be asking? There are countdown timers for each Meridian and Horizon limits in APCC (corresponding to each users’ particular equipment and horizon) and maybe those can be queried by the imaging software.
Roberto
Not actually ALL, just those that don’t support setting the SideOfPier.
But yes, SGP recognizes when your mount has passed the meridian and issues a slew based on your Pier Flip settings. APCC should NOT be allowed to decide when to flip the mount. That will cause your sequence to fail prematurely. SGP needs to tell APCC when the flip should occur. I would certainly advise safety limits inside of APCC but they need to be permissive such that SGP has time to flip.
Jared is correct. At this time it is best to turn off the East/West checkboxes in APCC’s meridian limits and let SGPro flip the mount at the meridian. APCC will still protect the scope from hitting the pier by stopping tracking when a limit is reached (if somehow the mount is left tracking).
Thank you all. I’m disappointed APCC cannot be used in this fashion. I have considered one of the main advantages of the application the ability to allow my setup to track past the meridian in a fashion that reflects the OTA and camera the mount is carrying as well as the altitude of the object being imaged.
If I can image M42 all night like long without pier flipping why would I?
At the moment I have no limits set up in MaxIM DL Pro and MaxPilote controls multi-target acquisition and simply sends GoTo commands. Not once has the scope crashed into the pier with APCC enabled.
Why would it be different in SGP?
Roberto
SGP (or any program) needs to coordinate the flip so that it occurs between exposures. If you let the mount handle the flip, it will likely occur during an exposure. Until I figured this out, I had more than one time when this happened to me. So now I set my mount to stop a X degrees past the meridian and let SGP determine when a flip is needed. The value of X needs to be slightly more than what is needed for one exposure. This is not a limitation of SGP but rather a physical reality. ASCOM does not have a “meridian flip” command. In order for SGP to flip the mount, the mount needs to be past the meridian at which time SGP issues a GOTO which will cause the mount to flip.
Having never used APCC or MaxPilote it’s difficult for me to answer this question. Really SGP doesn’t care if a flip happens outside of its control or not. But since SGP is coordinating the Auto Guider this can cause issues. If you’re not autoguiding and you don’t mind a frame or two to get destroyed while the mount is slewing (unbeknownst to SGP) then you can let APCC flip your mount no problem. Just disable the meridian flip option in SGP and it will slew between targets just fine without caring about the meridian. However don’t be surprised if a frame or two get destroyed as SGP will never know when the slew is happening.
Thanks for your input. The issue with APCC and the AP mounts is that I can image with my scope under the counterweight bar for many hours without an issue. APCC does not prevent GoTos/Slews, it only prevents the mount tracking into limits which are dependent on each specific user’s horizon and meridian profile. My meridian profile is not a straight line. My setup (a 6" refractor) will not hit the pier (at all during the night) if the object is say <30d elevation. Whereas if the object is near the Zenith I will have to flip very close to that imaginary meridian line.
I thought SGP or other imaging program was able to query the mount driver to know when to flip or how long there was left before a flip so that an image could be initiated or delayed until the telescope flipped.
As an example, say SGP was just about to start a 20 min exposure but there were 15 mins left before the meridian. Most programs would have to wait this out. My current setup allows me to flip to the other side with the weights above the scope and start that exposure “early” on the other side of the pier.
Jared, I understand SGP also has to control the guider; but the guider is just a procedure that starts after the mount settles. Why would this be a complication? Forgive me, I am not claiming I know the works of SGP - clearly I don’t! - but I thought what I was trying to achieve would seem pretty logical from a maximisation of imaging time point of view?
ASCOM does not provide any information about time to meridian, or even an idea of the meridian limits of the mount, so there is no way to even infer this data. Because of that we have no idea when the mount would perform an automatic flip. Which is why it would occur “out of he blue” to us. We don’t get the opportunity to pause the guider, stop a frame or really do anything. To us it is random and unplanned. If we knew when the mount was going to flip then we could make some decisions about what to do (wait for the flip, continue the frame, etc). But we don’t have this data.
I don’t disagree, we just don’t have what we need to make that decision. It’s not provided by the ASCOM interface and a native implementation isn’t something worthwhile for us as there is a high cost of implementation and support as well as a low return on investment.
Interesting that you mention this, we have discussed providing properties that give time information in the hope of solving this sort of problem. In fact the current Telescope simulator driver has a couple of properties as supported actions:
AvailableTimeInThisPointingState this returns the time in minutes that the mount can remain in this pointing state, it decreases to zero when the limit is reached.
TimeUntilPointingStateCanChange this returns the time until a set SideOfPier command can be sent to change the mount to the other pointing state. It will be positive before the pointing state change can be done and will decrease and become negative when the pointing state can be changed.
This could be a basis for something for a future Telescope V4 specification.
In the meantime interested driver and application authors could use these supported actions. They could maybe be implemented in a real driver.
This will need some careful documenting and testing, I can see all sorts of pitfalls if it isn’t clear exactly what they do.
You actually can query APCC to get the meridian limits through the ASCOM driver but I didn’t figure you guys would want to make a special solution for a single mount type.
Hooray! I was not crazy. MaxPilote allows me to do as I laid out above and does it by querying APCC…
It would be excellent if SGP could do the same; I would not need several programs running under a master session programme but a single one!
Good to know but you are correct. Accessing device specific things, even through ASCOM, tends to make device specific implementations. So while possible it would add a lot of code only specific to APCC. Now if ASCOM as a whole starts to add this functionality then that’s a completely different conversation.
We’re certainly not opposed to it just need the rest of the framework there. And even if this does exist it’s still not a 10 minute change in SGP. Allowing the telescope to tell us when the flip is going to happen is actually quite invasive and a fairly large change for us.
Moving to feature requests. Please keep in mind that this is unlikely to happen until ASCOM changes or we have a significant number of folks using APCC to change our mind.
This is not a “No” but a “we’ll have to wait and see.”
