I’m a fairly new user (still on my trial period) and I used this thread,with the help of some other users on the forums, to help me get Meridian Flips working properly. I am using Dialog Based, and my other dropdown simply says “Nearest Point” and flips work perfectly. My point count has always been zero and I have never needed to adjust this value. My assumption is that by using the settings I picked, the point count always stays at zero. But I think you’re correct by telling new users to insure that the count should be zero, and if its anything else, they should clear the alignment points out.
In your next screenshot, you’re pointing to the “horizon” area of EQMOD. I have nothing in this section. The important thing is to set the limits in the Meridian box right above it. What you’re showing in the screenshot shows the yellow markers right at the 0 and 12 positions, and this is too restrictive. It needs to look more like this:
The meridian limits can be set by using this excellent tutorial created by Chris which explains exactly how to do it.
The important thing is the limits you set in EQMOD must be greater than the limits you set in SGP. So for example, if you set the “Minutes past Meridian to Flip” in SGP to 8 minutes, then your limits in EQMOD must be greater than 2 degrees. Otherwise, EQMOD will intervene before SGP has a chance to do its magic. So really we’re letting EQMOD act as a safety net in case SGP doesn’t flip properly.
Its also important to mention in a tutorial (as Chris did) that the limits must be set carefully so that your equipment doesn’t strike the tripod. So just choosing whatever limits and settings that are shown in your tutorial could lead to disaster. For example, in my case I set the limits in EQMOD to be VERY BIG… like 1 hour past the meridian, but its fine for me because I have a short OTA and nothing is going to collide if SGP should fail to flip as expected.
Thanks @DonWalters. That makes more sense than my first guess… I didnt event realize you could drag those markers. I’ll get a draft together for the official help file docs tomorrow and post it here.
No prob! You can’t really “drag” the markers, per se. As shown in Chris’ tutorial, you have to rotate the RA to the point you want then click the green plus icon in that Meridian panel to set the markers. This is a good exercise to do in the living room on a rainy night. Chris explains that you should rotate the RA to a good spot and make sure any DEC movement won’t collide with anything before you click the icon to set the marker. Once this is done, you never have to mess with it again. It remembers the marker positions next time you setup.
Ken - Don has just done a very good job of answering the questions that you asked. I’d just like to add that I used pointing models with SGP for awhile without a problem. However, over time my centering became less and less accurate and presented the same symptoms as using JNOW with J2000. When I realized the problem I changed the settings as Don indicated and also cleared all my past points. Haven’t had a problem since.
Looks very good! In the ordeal of getting everything working, one thing I learned that was a bit of a surprise to me is that you don’t need to define a pointing model at all. The settings you specify in your how-to definitely cover this, but if you wanted to be thorough you could add a few words about not needing to do any star alignment. This was something that wasn’t clear to me before it was specifically said. I was still trying to do star alignment thinking it was essential. Nope!!! All that’s necessary is to use plate solving (Solve and Sync) to identify where the scope is pointed.
So now when I begin a session, I simply put the scope into the home position and use Cartes Du Ciel to rotate the scope to my object. If I take a camera shot at this point, the object is likely to be nowhere to be found. No worries. Now I run a Solve and Sync. Looking again at CDC, I notice that the object has moved slightly. This is because the sync has provided EQMOD with a better idea of where we are pointed. So then I select my object again in CDC and slew again. Shooting another quick frame I can see that my object is now dead center!
If the object is centered nicely enough I wil use Solve and Sync again and when it’s done it will present me with the dialog asking if I would like to sync the object to those coordinates. I do, and click OK so now it has the perfect coordinates for any centering I might do later.
So I was pretty shocked when I came to the realization that star alignment is not necessary when you have plate solving. This was a welcome surprise because it takes a big chunk of time out of my initial setup.
One thing it may be worth pointing out is that the screen shots are done using the simulator and the users will need to use the version that connects to the real hardware.
Many of the later points, such as setting the movement limits, setting a flip position that’s after the meridian and using SGP to control the mount by doing a basic align and relying on solve and sync to get good pointing apply to all mounts.
Could these be put in some generic how to set up and operate a mount advice? Or does this already exist?
Can I check why the EPOCH is being set to J2000. Doing this doesn’t affect anything within EQMOD itself (EQMOD is not precessing any coordinates), all this does is sets the EPOCH value that EQMOD will report to any ASCOM client that happens to ask for it (many don’t). I wouldn’t hav ethought that this setting itself would have had any impact on SGPro’s automatic centering and flipping features - but if it does I’d be interested to know why.
If you want to clear out all the EQMOD pointing adjustments then you should also any active sync (the shift applied to a model) - this is the button showing “DX” and a red cross.
With repsect to EQMOD’s point model, it has two modes of operation. In append on sync mode each ascom sync received wil result in a new point being added to the pointing model, In dialog mode points can only be added by going through an EQMOD specific dialog and any ASCOM syncs received will simply be used to shift the current model.
If you want to disable the EQMOD pointing model all you have to do is clear out any current alignment points, clear any active sync offset and then set the mode to “Dialog” . There is really no need to set the Alignment behaviour to “nearest point” as points are not going to be created (unless you manually add them via the alignment dialog).
Are you absolutely sure that the advice that disables the EQMOD pointing model applies to all of your users? I’ve no experience of SGP use myself but I am aware that amongst EQMOD users generally some still see value in pointing model creation. Now it is true that where you have an iterative plate slove/sync/goto process going on this can lead to essentially redundent, closely spaced, alignment points being added to the model. However this situation is easilly prevented via the EQMOD “proximity range” slider which ensures that only the “newest” point within a set proximity range ever gets added to the model (older points within the range being automatically removed). What is it about the use of a pointing model itself that makes EQMOD incompatible with SGP?
I’ve found that setting epoch to 2000 or now works equally well when imaging with SGP.
When using default settings, the solve and syncs get closer to the requested target without using any model at all (dialog mode). I remember hitting an error threshold when using append on sync and since dialog worked perfectly I didn’t bother to tweak any other parameter.
Chris_Shillito - I will try to give you my view as to the Pointing Model and J2000 issues. The issue isn’t that EQMOD can’t handle JNOW correctly or that there is an issue with the pointing model. The issue is that with the pointing model turned off and using J2000 - EQMOD will always work with SGP. Yes, you can get JNOW and pointing to work with SGP but its more complex and can lead to problems.
J2000 - The recommendation to use J2000 is because no other functions, programs or plate solvers that SGP uses have JNOW as the default. So, setting EQMOD to J2000 makes things easy. SGP will work with JNOW only mounts but more settings have to be changed in other programs.
Pointing Model - Yes, this could be said for all non EQMOD mounts. I agree with your last paragraph. However, many users were having issues with the accuracy of plate solves because of their pointing model. Most - myself included - didn’t need it anymore. It was something we just left on. So, rather than getting into the inner workings of pointing models just turning it off, works.
I guess what I am trying - somewhat poorly - to say is that I am trying to simplify things a bit. EQMOD, SGP and PHD2 and the plate solvers are all great programs with lots of internal options. Getting them to work together is often the challenge. Many EQMOD users are/were having issues interfacing with SGP. The fact that most versions of EQMOD didn’t handle the side of pier correctly, coupled with these other issues were leading to many frustrations for us EQMOD users. The particular choices that Ken listed will ALWAYS work. I guess he could add that JNOW and the Pointing model can work, but if you don’t know what you are doing you could have problems.
I was’t particularly pushing JNOW as an EPOCH option - just curious as to what folks thought setting EQMOD to J2000 was actually achieving. Wouldn’t leaving the EQMOD EPOCH setting at “None” (the default, I think) also work eqaually as well? At least with the “None” option you know for sure that all connected clients will work according to their own local settings. If you set EQMOD’s EPOCH to anything else then those clients that use ASCOM to read the EPOCH, and then act on it, will follow the EQMOD setting, whilst thoe not reading the EPOCH will work using their own local setting - so you could end up with a conflict!.
I do accept that the advice given here aims for a “one size” EQMOD setup for the specific case where SGP is used in combination with a plate solver. I simply would caution that some may seek a setup that works equally well with or without SGP/plate solving or that perhaps works where some aspects of SGP are in play, but others, like plate solved gotos, are not. So long as folks are clear about the context of the advice they are give there should be no problem.
I would add that if anyone needs advice, or action, on a specific EQMOD issue then the EQMOD Yahoo group is the really the best place to post. I will also take this opertunity to re-inforce the fact that there is comprehensive EQMOD documentation available via our Project Website, Yahoo Group and Video tutorials and I would urge folks to take advantage of these resources to fully understand the implictions of any setting changes made.
It seems to me that if you are using SGP’s plate solve and centre method of aligning it makes very little difference what epoch you use. You only only have a local alignment but when you move you collect another image and plate solve it to get a new alignment.
But if you are using multiple star positions to generate an alignment model then that must be JNow because the stars you see to align the mount on are inherently in their JNow positions.
The difference is caused by precession and this isn’t a simple offset. It is a rotation about the ecliptical pole and so the offsets from J2000 to JNow will vary depending on where you are looking.
I agree Chris and maybe I misunderstand the issue. I thought you had to use JNOW or J2000 across all your programs. Mixing isn’t good. I’m aware of people that have had issues with J2000 being the default in other situations. For example there were issues with astrometry.net when using JNOW. I realize that you can now use JNOW with astrometry.net but J2000 is still the default. Again, just trying to make it easier for people.
True, but how to set them in each ASCOM driver will vary. I am willing to take write ups from others as well and include them in the help file. The explanation from the SGPro side is in the Meridian Flip Section of the help file. That said, it would be a good idea to talk about ASCOM based mount meridian limits in a general way.
You are right… SGPro does not care. Just a brain fart on my part. This section of the setup has been removed. You can use either JNow or J2000.
Thx, I have added this.
Noted. I have removed that section.
I am sure of nothing. I have no experience with EQMOD so all of my advice is hearsay. If the pointing model works in SGPro, my advice is to use it. Most folks say they have better experinece clearing it and letting SGPro manage pointing. As to why the EQMOD pointing model and SGPro seem to fight, you might need to ask someone with field experience. This thread is a desperate attempt to cull the number of help requests we have from failed meridian flips by users driving their mounts with EQMOD. I wish I had more info / data, but because I don’t, I started this thread.
For what it is worth, I disable the EQMod pointing model because I find that a pre-flip model does not bring a target within range of the plate solver after a meridian flip.
I wonder is my system has sufficient flex to require a different model for each side of the meridian?
Without the pointing model, the plate solver just works, before or after the meridian, every time.
As pointed out elsewhere in this chain, the systematic use of plate solving, and automated meridian flips has changed the way we image, and so places different requirements on our hardware and driver software.
Many thanks to all involved developing and supporting this complex software.
Can I suggest a couple of edit/additions to the EQMOD help section:
It is a better strategy to run EQMOD from the ‘Start EQMOD’ script (included in the EQMOD package). If EQMOD is started by a program (eg SGP) it will die when the program closes or crashes. The script ensures an instance of EQMOD persists until it is explicitly closed.
A warning about syncs on the wrong side of the meridian. When EQMOD is synced on the wrong side of the meridian it not only rejects the sync, but it also erases any pointing offsets from previous syncs. If the initial positioning of the encoders is out by a couple of degrees it could ‘sync’ back to the ‘right’ side of the meridian so the SGP slew command is to an RA that EQMOD thinks is still on the same side of the meridian. Work-around solutions are to ensure the initial mount encoder positions are as accurate as possible, and don’t flip until well past the meridian.
If moving to an area of sky that is not already covered by any aligment points EQMOD will revert to using then nearest point transformation data. If you’re doing a flip with no alignment points on the flipped side then this could be a source of goto error. To combat this EQMOD provides a point filter which gives you the option to force the model to only consider points on the same side of the meridian, or in the same quadrant, as your target.
I’ve no problem with that but you should be aware that using that script is about as ASCOM non-compliant as you can get. ASCOM drivers aren’t supposed to be able to run by themselves with no clients attached - some ASCOM folks get a bit wound up about that so probably best not to “officially” reccomend it. To keep EQMOD immune from client application crashes there is an ASCOM compliant alternative in EQASCON_RUN application. This is a very simple ASCOM client appliction (so pretty robust) that tries to keep an permement connection with EQMOD (if EQMOD closes it will restart it) and that sits in the taskbar out of the way and isn’t easilly closed (windows shutdown will do it, the user can after a warning prompt).
It’s a little unconventional to lock and unlock a driver by incrementing and decrementing an instance count, not sure I’d get hugely upset about it though.
Personally I simply run something like CdC to keep the driver connected in spite of whatever is crashing around it.
Or a simple mod to Chris’s script would keep the ASCOM police happy:
set scope = CreateObject(“EQMOD_sim.Telescope”)
scope.Connected = true
msgbox “Press OK to fully close EQMOD”
scope.Connected = false
That does nothing but run EQMOD and keep it active. It closes when all connections, including this one, are released.
