Hello
I’ve read several threads about that topic, and now I’m completely confused.
I used to image with a G11 and let SGP control the meridian flip - worked like a charm.
I have acquired a Mach1 mount recently and faced issues with meridian flipsw, hich did not occur at all and left the scope in a very weird position.
Being rater a novice AP user, I’m looking for very simple recommendations about how to configure both software to achieve the desired reslts: I’d like to replicate the behavior I experienced with the G11: have SGP do the flip when necessary, and nothing else - I don’t care about safety limits or the like for now.
What should I do in SGP and the AP Ascom driver or in APCC to obtain that exact same behavior?
Thanks in advance for your feedback.
I image w/ a Mach1, no APCC, and have exactly the bahaviour you describe…SGP handles flip, mount flips fine, all good.
Unfortunately, my laptop is not connected to my rig at the moment, so I can’t open the driver window and screenshot settings for you.
I’ll follow this thread, and if someone hasn’t provided a clear answer for you today or tomorrow, I’ll see if I can’t knock out some screenshots for you real quick.
Unless you plan on imaging past the meridian by a significant amount of time, there are no special settings that you need to setup in APCC. The mount will do a pier flip automatically when SGP issues a slew after the mount reaches the meridian.
Ignore the solar rate tracking…took these while capturing the Mercury Transit today (well…while capturing a crapload of clouds behind which was an occasional glimpse of the mercury transit)
what i do is set my meridian limits in APCC, then tell APCC to send the limit to SGP. when you do this, there’s no reason to set the meridian flip options in that SGP window that gboulton has shown; APCC takes care of setting the value (but the value is not shown.)
the other thing to do is to give a delay in APCC (right next to the “send limit to SGP”). as you can imagine, if APCC sent the exact meridian limit to SGP, there’s a risk that APCC would stop the mount before SGP was able to command the meridian flip. so you enter a delay in APCC, and then the “minutes past meridian to flip” is the time of the meridian limit minus that delay. that way SGP will command the flip before APCC stops the mount. i’ve got that set to 15 minutes IIRC. i can’t remember because i set this up just once and from that point it’s worked flawlessly.
the advantage of doing this is that if you have a complex meridian delay “surface” in APCC, every time the mount slews, APCC sends the new limit to SGP. without this feature you’d have to statically set the most conservative flip time for your system.
also, be careful with “stop tracking” as a meridian delay action. it turns out that there are many commands that PhD (or other ascom clients) can send that will cause the mount to start tracking again and then you can have a pier crash. it’s safer to select “park mount”. you can also choose “flip mount” but there’s no guarantee SGP would be able to recover from a mount that flips itself.
Hi gboulton,
Thanks for the screen shots, much appreciated - I’ll give it a shot when clouds and rain decide to give me a break (3 weeks in a row ).
Rodolphe
I tried that route when I received the Mach1 and purchased APCC a few months ago, without much success, I admit. Probably by lack of working experience with both, I got lost with the different settings such as limits, homing, etc. The setting of meridian delay is also counterintuitve to me (negative value needed to actually have a delay…) and adds to the overall confusion.
I appreciate the possible conflicts with PHD2, SGP and APPC - looks like each piece of software races to get final control, making interactions more complex than I can cope with at present.
From the first day I started AP, years ago, I consistently applied a rule to change/improve only one variable at a time. In this case, I’ll first try to just “make it work” with the ASCOM driver and temporarily eliminate APCC from the equation; I can easily plan a full night imaging session without fearing a pier crash - be it simply by reducing the overall imaging time. Once mastered, I’ll move on to APCC subtleties.
Anyway, thanks for the advices you took time to lay down here: I’ll surely come back to them when I feel it’s time.
yes i completely understand - there is a lot to digest in APCC. for my part i have only defined some RA/DEC limits and the meridian limits. when ray was developing this i was in a situation where i had a very complex meridian limit surface as my telescope sat very low on the saddle. i solved my problem by putting the telescope on riser blocks and now my meridian limit is > 1hr past the meridian at all declinations, so in APCC the meridian limit is just a line. this means i don’t really need the fancy “send limit to SGP” feature in APCC as i could just statically configure it in both places… but the feature works and prevents me from having to manually synchronize the two values, which could be error-prone.
Thanks all for your great recommendations - going ahead with simple settings for now, as advised in above messages - I’ll play with APCC settings later on.
Rodolphe
Just a continuation of this thread - what about if I want to start imaging 1 hour before the meridian is reached and want to do a premature flip? What settings would I use and where in APCC?
sorry i missed your question - i am not sure exactly how to do this in APCC. it might be possible but i also remember roland & company saying that in general they believe early flips to be dangerous. of course APCC can know all the meridian limits and refuse to flip if it is unsafe, so it might be possible. best probably to ask Ray on ap-gto @ groups.io
Hi
Well I decided not to change any parameters nor tinker with the meridian limits in APCC, just use the default settings. I let SGP do the work, and… it works just fine.
Thanks all for the feedback and valuable inputs.
).