I'm quite new to SiTech having recently purchased a new MESU e200. So I'm probably missing a trick here.
The Mesu has replaced a previous mount with no other changes other than I've built a new pier so that I could take advantages of the 'flipless' option that the e200 provides. It's housed within the same automated dome.
Straight out of the box I was surprised to find that with SiTechexe set to GEM mode it did an automatic flip at both Meridians. Granted there's some elbow room as I was able to configure the Meridian limits up to a point but the mount would always auto-flip somewhere.
After contacting Dan & explaining why I specifically wanted to run in GEM mode but avoid any auto-flips he kindly provided me with SiTechexe version 95Mwin. This gives complete control over the meridian limits. After a little experimentation I found that the attached mount params allow me to track past either meridian without ever flipping. But it will flip for a GOTO to the oposite side of the meridian- just as any GEM would - perfect (I think).
My initial Offset Init was in the EAST & always is if I ever need to re-initialise for any reason. East is much easier for me.
I've been using SGP for a while so I'm quite happy with how to set it up and use it but here's my problem:
My Mesu is parked as normal but has been previously initiallised prior to parking. So it knows whwere it is before I even begin. I start up SGP & connect to all my gear as normal. When I connect to the scope the SiTechexe interface initialises as expected & I can unpark the mount. So far so good.
If I select a target in the WEST and set up my SGP imaging sequence when I run the sequence my shutter opens, the dome slews to the correct position, the scope slews to the desired target, the focus routine runs followed by a plate solve, centering & offset init (maybe twice to get correctly centred). Then imaging continues as expected.
However for any target in the EAST the story is different.
The first plate solve takes place as expected but then the scope flips to the oposite side of the meridian by an amount equal to it's hour angle. By which I mean if my target is 2hrs before the meridian it will flip to 2hrs after the meridian. The declination remains the same. It then plate solves again but of course the dome does not catch up in time to capture an image. So it tries to plate solve an image of the inside of my dome. Obviously my sequence then fails because of the plate solving & the guide star has also been lost.
If the target happens to be in the EAST but close to the meridian - say within half an hour then I may get away with it & the plate solve succeeds. In which case the scope will re-flip back to the correct side, re-plate solve & the sequence will continue as normal & the mount will track past the meridian & keep going until I run out of sky. Which is just what I want.
Alternatively, if I make sure I'm on hand, I can manually slew my dome to ensure that it is in the correct place for the unwanted\unnecessary flips. But that defeats the object of an automated observatory.
I can't speed up my dome. SGP has a minimum 10 second update frequency for the dome slaving. If I slow down the Mesu's slew rate it gives me a slightly wider wndow of oportunity but not enough really.
So my question is why is my mount well behaved in the WEST but exhibits this strange flip behaviour for Targets in the EAST?
I'm wondering if it's related to my unusual mount parameter configuration (meridian limits) or should my initial Offset Init always be in the WEST? I don't know? Or what else am I missing?
I do know that the unwanted flip when targeting the EAST is deffinitely not initiated by SGP because I know this from the SGP log. However I'm not yet familiar with the SiTech log. It took me a while to find it & I realised none of the options ASCOM & Logging tab were selected. So my logs are basically empty.
Can anyone advise me which tick boxes I should have selected if trying to debug this condition?
If anyone has any suggestions as to how to go about resolving this I'd appreciate any help.