I am currently trialling SGP and the only thing i cannot get to work is the the auto meridian flip.
I have ASCOM 6.1 latest updates applied (according to the updater of ASCOM)
EQASCOM V1.271
HEQ5 PRO mount
I have set the side of pier setting on EQMOD to physical and it now shows time to meridian in SGP telescope, whereas before it would just show : NA, but its always some 13-15ish minutes difference with what the EQMOD is reporting in the mount limits editor.
I have also set the time on EQMOD as J2000 (same as the astronomy.net local solver).
I am able to perform accurate flipped gotos and the EQMOD performs auto meridian flips if the appropriate select box is on in the mount limits editor.
What am i doing wrong?
Due to this time difference (i suspect), SGP or the mount or the combination! always fails to perform the flip.
Itâs my understanding that the SGP takes its position and sidereal time from EQMOD, so how can it always have a set amount of difference on time remaining to meridian flip?
Also the meridian flip [run] button is usually greyed out and says on hover : Telescope must be pointer across the meridian to flip.
Does anyone has HEQ5 PRO mount and be able to perform meridian flips with SGP ?
Iâm no expert but I have the flips working with an heq6 which is the same as yours, just a bit heftier. I donât use eqmod at all and sgp and the mount talk nicely to each other. Just a suggestion - but Iâm sure someone more knowledgeable could provide a better answer or solutionâŚ
how is your EQ6 connected - interfaced to the PC? I wasnât aware there is an option to bypass the EQMOD all together!
What are you choosing in the ASCOM drop down in order to connect to your mount?
I have a HEQ5Pro and its doing meridian flips fine, on the Physical setting in EQMOD.
In the status bar at the bottom of SGP my time to flip value is always 12mins greater than the EQMOD difference between RA and sidereal because I have told SGP to flip 3 degrees after the meridian (3 degrees = 12 minutes).
Hope someone figures out whatâs not right for you, as it definitely can/should work.
These are my Control Panel/Telescope settings:
Use Auto Meridian Flip - Checked
Settings (Auto Meridian Flip):
Degrees past Meridian to Flip 3mins
Wait for Meridian - Checked
Pause before Meridian Flip - Unchecked
Auto Center After Meridian Flip - Checked
Pause Before Auto Center and Pause After Auto Centre - both unchecked
Auto meridian flip auto-close delay 30
Wow thanks!
I thought that there could be a way of âbypassingâ the time difference but could not point my finger on a solution.
I am going to try that out tonight and report back!
Fingers crossed
Probably worth enabling EQMOD meridian limits too for extra safety. I havenât bothered to set horizon limits, but setting a meridian limit for each side of the pier is easy and extra insurance.
Great success on the field, by setting : Degrees past Meridian to Flip - 5, the time difference came just about -+3mins and the mount performed on auto mode the meridian flip, plate solved and got to the âother sideâ with just 23px error. Unfortunately the focuser routine got messed up and it ruined the rest of the night but that is another story.
I have also setup some meridian limits and seems to be working fine, despite the time difference.
So thanks Rob for the âhackâ and Kit for the alternate route with the Celestron driver (i wasnât aware you could interface the mount without eqmod!! ).
Despite the workaround to the problem, if anyone has experience or knowledge (maybe the developers?) i would love to hear why there is a time difference in the first place, since SGP reads time and location from EQMOD.
Iâm unsure why there would be a difference. SGP uses the sidereal time, RA and longitude all from your scope to determine how close it is to the meridian. I would assume that the scope would also use these. itâs possible that EQMOD or whatever ASCOM driver youâre using is replacing values that are coming from the scope with ones on your PC (most likely time here). I would verify that the time between your PC and scope are synced. You could also test this assumption by changing the clock on your PC.
You could always open up a planetarium and see if it agrees with the scope or SGPâŚunfortunately this wonât make things right but it would at least give you an idea of what to expect.
I was under the (probably false) impression that when I am using EQMOD there is no need to set-up time location etc.( which I havenât since started using EQMOD some 3 months ago) in the hand controller but EQMOD does that for me by reading the PC time and the GPS instructed by the settings at EQMOD.
That is why I expected everything to have the same time! I will need to read up further i guess⌠I might have them all mixed up in my head!
Will test changing the time on the computer to see if that has any effect.
Just for future reference, in case anyone is facing similar problems ~
I am using the HEQ5 PRO syncscan hand controller on PC direct mode.
My time difference problems could be from using the NOT suggested way of using the hand controller (PC Direct mode) instead of an EQDIRECT module.
The eqmod manual states
Q: If using PC-Direct mode with EQASCOM, do I need to perform SynScan time/date synchronisation and Alignment.
A: If youâre using EQASCOM then all SynScan configuration settings are irrelevant.
So ok it does not matter if i set anything in the hand controller (which is tested because i have not input anything in the HC for ages).
BUT the manual also states
Q: So what is PC-Direct mode?
A: PC Direct Mode was introduced with handcontroller V3.21. When placed in PC direct mode the SynScan handcontroller effectively becomes âtransparentâ and simply passes messages received by its serial port directly to the mount (and vice versa). All handcontroller control functions are bypassed. Currently the only application we know of
for PC-Direct mode when used in conjunction with the EQASCOM driver.
Q: Why is PC-Direct mode not recommended for general use other then EQASCOM evaluation?
A: For those folks who own a SynScan V3 handcontroller PC-Direct represents a good way to try out the features of EQASCOM driver without the need to purchase or build an EQDIRECT interface. However use of PC-Direct is not advised for unattended mount operation as its reliability cannot be guaranteed. The protocol to the mount is, as far as we know, a Master slave type protocol. EQASCOM was therefore designed to operate in an environment where it is the sole master of the mount. When using PC-Direct mode there are potentially two active masters (PC and synscan) that can talk simultaneously. Unfortunately Synta have yet to provide any explanation as to what PC-Direct is intended for, how it works, how to use it correctly, and its limitations (if any). Against this background the EQMOD Project cannot assure the reliability of EQASCOM communications (and hence mount control) when this method is used
So⌠that might explain time difference along with some other things like occasional erratic gotos and all sorts of crazy bugs
Im off to build an EQDIRECT module.
Thanks again everyone in this thread for their solutions, hints + the developers for the awesome software!
Just got this on the yahoo EQMOD mailing list : On the Slew Limits screen, the value that is labelled âTime to Meridianâ should actually be labelled "Time to Meridian Limit. âŚ
So the time difference is irrelevant after all because it shows the time to limit based on what you have defined as limit.
Hopefully this comment will save someone else the head scratching
Iâm the guy that Silios quoted above about the âTime to Meridianâ caption in EQMOD. Having figured that out, I am no closer to getting SGP to perform an automatic flip. I also use an HEQ5.
I found that, for EQMOD to flip when given a goto command, the mount must have already tracked PAST the meridian. So the default limit of stopping at the meridian will prevent a flip. I then set my limit to be roughly 18 minutes past the meridian, and verified indepentendly of SGP that a goto to the current RA/Dec coordinates will cause a flip as little as 3 seconds (time) past the meridian. There should be plenty of room on the far side for a flip to occur.
In SGP, I have the following settings for an automatic flip:
Use Auto Meridian Flip
Degrees Past Meridian to Flip: 1
Wait for Meridian: ON
Pause Before Meridian Flip: OFF
Auto Center After Meridian Flip: ON
Pause Before Auto Center: OFF
Pause After Auto Center: OFF
Auto meridian flip auto-close delay: 100
When it approached the meridian, it suspended imaging. It then took a pre-flip plate-solve frame, and tried to slew the mount. The mount did not slew, and the sequence aborted, saying it failed to slew.
Unfortunately, I was not quick enough to note independently whether or not it had actually crossed the meridian. Either the mount had not yet crossed the meridian, in which case SGP is giving the slew command too early, or it was indeed past the merdian, but failed to give a proper slew command to the mount, since I have already verified that the mount will flip if only seconds past the meridian.
Not sure what the problem is. It is getting frustrating, since the reason I got SGP was for the auto-flip. I am past the trial period and have paid up in the hope that this can be resolved.
I would love to hear from anyone who has gotten SGP to work with EQMOD what settings I need to change to make this work.
When I found that I actually had that script (never seen it before), I got all excited. Then I saw that mine doesnât have that selection on it. I am using EQMOD v1.24g.
That is probably an old version, but I had a lot of trouble getting my dome to sync to the mount - trouble with Side-of-Pier interpretation - and that version (along with a specific version of the dome driver) was the only combination that worked properly at the time. I guess I have no choice but to upgrade to a version that has a Side-of-Pier setting, but I am worried that it will put me back to square one with dome synchronizartion. Aargh!
I feel your pain Keith, but strongly recommend its worth updating. Perhaps do a full image of your hard-drive first in case you want to go back to how things are now. Chris and the EQMOD team have included some nice features in the last few versions. The locals here convinced me auto-PEC recording for example makes it worthwhile.
You should be able to access the setup also by going to Properties as your connecting in SGP from memory.
I find the âPiersideâ option for syncing new data points for EQMOD is great with my Heq5Pro too - filters the data to only use points one side of the meridian.
Hope your dome driver comes along for the ride too.
Definitely keep posting if youâre having trouble, even if in a different thread. Do you have the Pro version of the HEQ5 by the way?
Just for future reference, in case some HEQ5 PRO owner lands here :
using the HEQ5 PRO mount and setting the Degrees past the meridian to Flip to 5 and not -5 as i said earlier during the tests, nails the flip each and every time.
Also i have completely disabled the data point collection in EQMOD and that solves the plate solving issue ( when i had the data points on the mount couldnât properly center the target unless I manually cleared any existing ones)
I am using EQMOD v1.24g.