When SGP tries to do a meridian flip, it takes its reference frame then commands EQMOD to slew to the target coordinates. I get an almost immediate error from SGP saying the mount failed to slew. SGP log file confirms this and gives no additinal information.
I’m pretty sure the problem is in EQMOD, but my question isn’t getting any traction on their forum. So, I am asking here in the hope that someone else uses EQMOD with SGP and can help with whatever settings are required to let it do the flip.
I am away from my imaging location and don’t have access to my EQMOD computer settings. However, I remember that I’m using V1.27l and that I had to set the mount to “physical” in the setup for the meridian flip to work for me. In SGP I also set the flip for 1 degree past the meridian. I can go a fair ways past the meridian before I hit the pier but I did set stop limits in EQMOD just in case the flip failed. Its worked every time.
Change the eqmod setup to PHYSICAL …I had the same problem…Chris Shillito of the eqmod project said that was the problem. I believe it is under “Side of Pier” in the eqmod driver setup.
OK, I upgraded EQMOD to the latest version: “Physical” breaks my dome software. Went back to “Pointing”, and that breaks the dome software, too. The dome ends up in a different position with Pointing vs. Physical, but neither position is in front of the scope. Re-installed EQMOD 1.24g, and the dome works again.
Having the dome properly synchronized is non-negotiable. There is only one driver for the dome hardware I have. It is junk, but I am stuck with it until I can rip out the hardware and replace it. So the bottom line is no automatic meridian flips for me.
Things I might try if I feel masochistic enough:
re-inserting POTH between the latest EQMOD and the dome driver: might work, might not;
removing EQMOD altogether when using SGP and use a different scope driver (Celestron??);
2a. I’d still need EQMOD for gotos when doing visual observing;
2b. I suppose I could go back to using the HEQ5 Pro handset instead of EQMOD for visual gotos, but then I’d have to slew the dome by hand, too.
The basic issue is an ASCOM one: the change in the interpretation of Side-of-Pier. The ASCOM folks messed up the original definition, and then they messed up the transition. It will likely be a few years before everyone’s software catches up.
The basic issue is an ASCOM one: the change in the interpretation of Side-of-Pier. The ASCOM folks messed up the
original definition, and then they messed up the transition. It will likely be a few years before everyone’s software
catches up.
What transition? I don’t think the side of pier definition has ever changed, just explained better in the ASCOM help file. Most ASCOM client software works correctly with most ASCOM drivers.
Maybe the problem is that the EQMOD driver author(s) did not follow the standard? IMO having used the EQMOD driver in the past it didn’t seem to adhere to the ASCOM spec very well. That you say there are multiple choices for pier side definition is a good example of that particular driver not following the standard. That’s bad programming because if you choose one option just to make it work with one ASCOM client program might break it in others.
You are correct. The change was more in the documentation than in the function. It seem that, in the past, incorrect interpretations were more common in software implementations than correct ones. Clearly, that is changing, but right now, there is a mix of correct and incorrect implementations out there, which affects interoperability.
Offering a choice of interpretations is obviously an attempt to improve interoperability, but as you say, it is poor programming practice.
There’s a fairly quick way to figure out if your driver is behaving up to the ASCOM standard. Just run it against conform. It tests the side of pier functionality.
The recent change to the documentation actually only changed the wording when the scope was pointed below the pole.
The EQMOD driver seems to be going through a lot of flux lately with regard to pier side. It worked for a long while…then it started reporting the incorrect pier side everywhere. I believe that was resolved but it sounds like something may have reverted? Personally I don’t follow the EQMOD drivers. I’m sure there’s some combination of things that will work. Just might take some time to find them.
What all options do you have in your dome hardware? Does the version that works with your dome specify the side of pier correctly? (As in the side that the scope is on)
There’s a suggestion that the ASCOM side of pier commands and states are renamed to have names that more accurately represent what is happening and what they mean. The commands would be PointingState and DestinationPointingState. The states would be Normal and Through the Pier. This doesn’t change what should happen, only how it’s described.
The idea is that these more accurately reflect what is required than side of pier, which seems to be capable of all manner of misinterpretations.
As Ray says, the intended definition of side of pier hasn’t changed since it was introduced.
Take a look to EQMOD’s yahoo group, Chris Chillito has put together a new test release with the option to handle side of the pier in legacy mode. That should alleviate the time to flip issues.