Is anyone managing to do meridian flips with EQMOD?

Rob, as far as I can tell I have the same settings:

“SideOfPier” set to “Pointing (ASCOM)”

“Allow Auto Meridian Flip” is not checked

“Point Count” is “0”

Sync Data is cleared (although SGP enters new Sync Data when it performs the Sync just before the flip - this is what seems to be the problem)

User Interface is set to “Dialog Based”.

In SGP use Auto Meridian Flip is set for the Telescope.
“Minutes Past Meridian to Flip” is set to 5.
Autocenter after Meridian Flip is ON.

Or am I missing something?

Peter

sorry - i posted the wrong link! it was this one:

notably scott said to set the sideofpier to physical. maybe that’s actually the same as what you’ve set, i don’t know all the EQMOD terminology…

rob

Thanks Rob - SideOfPier is the one difference. Will give it a try.

Scott’s post was made in the context of earlier EQMOD versions that didn’t correctly report side of pier correctly for all cases.

Assuming you using at least EQMOD version 1.29a or later (and if you’re not you should be) you should definately stick with SideOfPier method as “pointing”. This is the only method to conform to the current ASCOM standards.

shoot. oh well.

Peter, in the EQMOD configuration dialog box, try checking “Strict Conformance” in the ASCOM Options section. Chris can tell you definitively, but I believe that corrected another small problem related to SideOfPier.

–Ernie

Thanks Ernie - will do

Yes, selecting the strict conformance option will automatically pre-select the sideofpier method to be pointing and ensure that all EQMOD will raise all exceptions (if necessary). The SideOfPier dropdown and exceptions checkboxes are hidden once strict conformance has been selected. The idea was that for new installs the EQMOD setup would default to “strict conformance” and the confusion assoicated with these controls would be removed.

Chris.

Thanks everyone. Just ran a test and it worked perfectly!!! Phew!

don’t worry about Sync data being entered by SGP…has no effect on flipping. I don’t clear data every time I turn the rig on and it seems to work just fine. Just make sure you don’t SAVE the data in EQMOD.

So, I’m still a little confused (happens easily) on the current recommended settings and approach for EQMOD and auto meridian flip. I had trouble the last time with plate solving. Seems that once I removed the point model from EQMOD, PS2 would fail and sometimes even the blind failover astrometry.net would fail. Once I managed to get the first plate solve, things would go better (sometimes PS2 would solve, sometimes not). Before removing the point model from SGP, PS2 would generally solve quickly and consistently.

EQMOD (using version 2.00e):
Points list - emptied
DxSA - clear out at start of session
DxSB - clear out at start of session
User Interface = Dialogue based

EQMOD Setup
SideofPier = Pointing (ASCOM)
Issue Exceptions = yes
Pulseguide Exceptions = yes
J2000

SGP (2.5.2.5):
Control Panel - Telescope - Sync Behavior = I had this set to “Sync”, but I might try “Offset” next time (hopefully tonight)

Am I missing something in the above? Mount is EQ8.

I did find one post on CN where a user had more success by leaving the point model in place, but sticking to “Dialogue” mode, so no new points would get added during the plate solves. I may try that approach if all else fails.

DaveNL

PS. I also still seem to have trouble with plate solve not waiting for the dome to finish slewing, but I’ll leave that for a later post when I gather more info/logs

@dnube

Sorry you are having trouble. I am a little confused as to how any EQMOD setting would be related to your ability to plate solve. Or maybe you are meaning the plate solve is fine, but you have trouble with “sync” after it’s done?

Hi Ken,
From what I’ve read, I think there are a couple theories on why EQMOD settings could impact plate solving. One is that if EQMOD is adding points to the model on each platesolve (“Append on Sync”), the plate solve and EQMOD end up fighting against each other (repeated plate solves don’t seem to get the target any closer to the center). It seems that the consensus recommendation is to remove the pointing model entirely from EQMOD, and also not to append points to the model on sync (ie. use “Dialogue based” instead).

I believe that by removing the pointing model entirely from EQMOD, PlateSolve2 has trouble because the initial slew is too far away from the target (I’ve seen reference to PS2 needing a good hint in order to solve). But not sure why the blind solve would not work.

I posted some of my other EQMOD settings just to make sure I wasn’t missing something else. Also, I’m not totally sure what setting I should be using for SGP “Sync Behavior” (for my particular setup).

Maybe I’ve got this all wrong (wouldn’t be the first time!) - so open to suggestions.

Unfortunately, last night’s clear sky … wasn’t. So didn’t get a chance to test further. Next several days don’t look promising either :=(

Dave

Hi, May I enquire as to how you run a test ?
thanks Kev

I simply slewed to just before the meridian and waited to see if the flip worked as it should as it crossed the meridian.

@Ken,
UPDATE - Finally got some clear weather last night (well, a short window of clearing at least) so tested this again. Started by trying to slew and plate solve with EQMOD having no points in pointing model (and set to Dialogue mode so no new points added). Plate Solve 2 failed. Then loaded point model (7 points) in EQMOD. PS2 still failed. Then realized I had not cleared out the Sync data (DxSA DxSB) - presumably left over from last session. Cleared these out (but point model still in place) and PS2 solved immediately. Only 2 reps for PS2 to center within my tolerance (50 pixels) - I think final was much less than 50. I can supply log file if it is of any help.

I wish I had cleared the sync data from the start. I did not get to test again because the clouds moved in. Would like to test some more (in particular from Park/new session) but seems like leaving the point model in place and clearing the sync data is the way to go with EQMOD (and Dialogue mode). I did let this sequence continue while I made a run to the hockey rink with my son - email notifications indicated that the autoflip completed successfully (for the first time - woo hoo!) but wish I was there in person to see it happen.

Will report back when I test some more (hopefully tonight).

Dave

I have successfully completed another 2 meridian flips, so that is now 3 for 3. For the benefit of any other EQMOD/SGP users who find this thread, here are my settings.

EQMOD (using version 2.00g):

  • Points list - using 7-point model
  • DxSA - clear out at start of first session but not subsequent sessions
  • DxSB - clear out at start of first session but not subsequent sessions
  • User Interface = “Dialogue based”
  • SideofPier = “Pointing (ASCOM)”
  • Issue Exceptions = yes
  • Pulseguide Exceptions = yes
  • J2000

SGP (2.5.2.5):

  • Control Panel - Telescope - Sync Behavior = “Offset”

Some other users have recommended to:
(a) not use a data model at all (remove all existing points - rely on plate solving only to get target in frame). I suppose I could spend more time trying to get this to work, but previous attempts failed and my current setup works, so little motivation :=)
(b) Not add any model points on Sync (ie. set to Dialogue mode, not “Append on Sync”). Primarily to avoid building up a large data point set? See next point.
© If using a data model, limit to a relatively small number of points. Can’t comment why this might be.

Hope this summary is useful to others. Perhaps other EQMOD/SGP users could confirm or identify different configurations that also work.

Dave NL

Do you set up a sequence in SGpro to take images so that it pauses during Meridan or just wait on the tracking to see if it flips after Meridan?

I set up a sequence in SGPro but to save time I then manually slew to just before the meridian and watch the flip happen.

Thanks. I believe I am almost there just need another clear night to confirm. Fingers crossed.