My auto pier flips fail every night because sgp slews to an RA on the other side of the meridian. Sometimes it syncs to the other side of the meridian, and sometimes it slews to the other side of the meridian. Last night I tried changing eqmod pier side from ‘physical’ to ‘1.24g’. It synced correctly but then sgp issued a slew command to ~23’ east of the sync?
[2015-02-28 3:55:12 AM] [DEBUG] [Telescope Thread] Telescope: Syncing to RA: 14.0521160185091 Dec: 54.3894295347346
…
[2015-02-28 3:55:13 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[2015-02-28 3:55:13 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using slew
[2015-02-28 3:55:13 AM] [DEBUG] [Telescope Thread] Telescope: Slewing to RA: 14.3912547517186 Dec: 55.1355319148936
My setup is: sgp beta 15, pinpoint, eqmod 1.28b (set to J2000)/eq6, phd2 2.4.1g
Hello? Anybody?
My auto pier flips consistently fail due to plate solves that sync back across the meridian. Somebody has to have some ideas on how to deal with this…
We just tell it where to sync. Unfortunately we can’t control how it interprets the coordinates. For scopes that don’t support us telling it the pier side we then query the scope for the current position and issue a slew to that location. Since this should be beyond the meridian the scope should then flip.
It’s interesting that the coordinates aren’t the same from when we sync the mount to when we ask for the location for the flip. It seems like the mount is doing some transformation on the coordinates. If I transform the sync into JNow then I get a difference of about 23’ like you’re seeing. Which means that the mount is taking the J2000 coordinates and transforming them to JNOW when we read them. I’m not sure how we could possibly account for this schizophrenic behavior. My advice would be to flip further past the meridian.
What is happening is that SGP is acquiring an image then plate solving and syncing before doing the pier flip.
The sync when past the meridian is an edge case which not all mounts can cope with. Even if it works the sync, which can only be relied on to improve the local accuracy, may make the meridian flip less accurate.
Doing an image acquire and plate solve before the sync make sense because it provides an accurate position for the subsequent pier flip slew but I’ve not heard a good reason for doing a sync as well.
You can always disable the plate solving options for meridian flips if your hardware can’t handle it and just use slew. We can’t be expected to support mounts that don’t know how to interpret a sync.
OK. Thanks for the replies fellas! I’ll experiment with the j2000/jnow thing and see what happens. It’s interesting that ‘center now’ works beautifully away from the meridian - maybe there is a mount related issue there? I’ll try some solve and syncs near both sides of the meridian too.
I’m surprised no one else has had this issue - I can’t be the only guy using sgp with eq6/eqmod?
Anyway, thanks for the feedback.
Paul
I don’t have this setup but have helped a few who have, in EQMod makes sure you have dialogue mode NOT append and clear all sync points, set the degrees past meridian to 5 and think you also have disable flip handling in EQMod, will check and post an update.
Just a follow up. I did some testing last night and found the cause of the shift. It’s an EQMOD issue.
As soon as the target touches the meridian EQMOD erases the ‘sync’ data, and any subsequent syncs aren’t applied to the alignment model. The error I’m seeing is the error in the mount’s ‘start’ position. Since plate solving and ‘center here’ work so well I never bother being too careful about the initial start position each night. I tried messing around with the alignment settings but couldn’t get EQMOD to apply sync past the meridian.
I’ll take this over to the EQMOD group to see if anyone there has a solution. I’m hoping there is a way to keep sync data across the meridian, but if not I guess I’ll have to try spending extra time each night getting the mount more accurately aligned.
I have the same configuration and it works perfectly. I avoid using a star model in eqmod, just a simple sync will do the trick. If you avoid using a star model EQMOD will not have any issues with the epoch of the SGP syncs and in my experience the gotos converge faster to your error threshold if you don’t use a star model.
If you want to keep using a sky model in EQMOD you need to do 2 things:
– Build the model using J2000 syncs
– Use nearest point for goto strategy
Hi Jose
Thanks for the reply. I don’t use a star model either. I only use ‘center on target’ at the start of each session. I have everything set to J2000 too. I asked on the EQMOD group and it is not normal eqmod behaviour.
I will try to do some more testing tonight with the eqmod driver setup and alignment settings and post the results.
Cheers
Paul
OK. Just finished further testing with syncs across the meridian. I can’t for the life of me get EQMOD to accept a ‘sync offset’ after the scope crosses the meridian. I tried it with my old APT/Astrotortilla setup and got the exact same behaviour as SGP/Pinpoint. I even tried a direct EQMOD ‘dialogue’ sync. My pier flip problems arose from a (quite large) error in my ‘home’ start position. I have a semi-permanent set-up on my balcony that I at least take the scope off every morning, and re-mount every night. I have to unlock both axes to balance everything and I guess my setting rings shifted at some point to introduce a several degree error.
The sync re-alignment was able to correct it for the whole eastern or western sky, but when the sync offsets reverted to zero across the meridian there was a huge error - enough to put the reported RA back across the meridian and cause the pier flip slew to fail. Lesson learned. I have to be much more careful with setting the home position every night, and monitor the EQMOD ‘DxSA’ and ‘DxSB’ values for large offsets.
If anyone else out there running EQMOD/EQ6 can achieve a non-zero ‘sync and solve’ pointing across the meridian I would love to hear from you! Although, I suspect that most errors are small enough that they just go unnoticed…
This could be resolved very easily if SGP did not insist on doing a sync after the mount has crossed the meridian, just before the slew to trigger the pier flip.
There is a good reason for acquiring an image and solving it before the pier flip because this provides an accurate position for the subsequent pier flip slew and the sync after the pier flip but I’ve never heard an explanation of why the sync before the flip is essential.
Sync of a mount is a slippery concept. The mount has it’s own pointing model, about which we know nothing.
Mounts implement sync in a number of different ways and all we can reasonably expect is that sync will improve slews for positions that are close to the sync position.
A pier flip is, in the mount system, a long slew. The Ra axis changes by 180 degrees and the Dec axis by twice the zenith distance. It’s difficult to go further. The mount geometry is completely different. We cannot rely on a sync before a pier flip improving things afterwards. In many cases it will make things worse.
I learned from Chris S (eqmod developer) that a sync across the meridian looks so far out that the program discards all sync data. I don’t think that’s unreasonable behaviour for a mount. The pre-meridian sync data persists past the meridian, but there really is no good reason to try to re-sync the mount past the meridian. Even if you are not using a target reference image to center on the target in the first place, a simple capture would provide a reference image to re-align to after the flip. It seems highly unlikely that a sync will provide better accuracy after the mount slews 180 degrees in RA as well as in DEC.
A feature request would be to have the option to ‘Center on target reference image after meridian flip’, or ‘Capture reference image before meridian flip’.