I’ve been using SGP for around a year now, learning bits and adding them to my workflow as I master them. I’d got to the point where everything was working; framing and mosaic wizard with reliable, fast, solves, good auto-focus and good guiding, so I decided to read up on setting my AZ EQ6 (through EQMOD) to auto meridian flip.
On Friday night I set a sequence running on M82 and I knew I’d see a flip at some point after 10.15pm. Sure enough the flip started, completed and the plate solve seemed to complete okay after the flip, all this was watched from indoors and I then let it run.
Around 30 minutes later I checked and noticed that M82 wasn’t on the screen for the last capture, I went outside, aborted the sequence, re-centred and re-started it, then all was good until I called it a night a bit later. On looking today I see that images 1 - 5 are all good, images 6, 7 & 8 are all centred in the wrong place, and the framing returns to normal on image 9 after I’d re-centred.
I realise that this is likely to be user error rather than a bug, but could someone please look through the logs and see what I’ve done wrong? SGP version is: 2.6.0.20.
The DB folder contains the log file, sequence file, equipment profile and images; 5 (pre-flip), 6 (first image after flip) and 9 (first image after I’d re-centred).
This sounds similar to an issue I came across last night… After the flip SGP is saying that the plate solve is successful, yet it clearly isn’t… I’m sure there is a fix to this…
This location is not related to a target, but rather wherever the telescope was pointing prior to the flip. It is very likely that they will not be the same. The idea is to get the scope back to where it was pointing, not to recenter the target.
I am not certain why the end location seems to not be representative of the location prior to flip.
The location the mount reports is where it thinks it is pointing, not where it is actually pointing. There can be all sorts of mount errors that cause this.
It needs the change you mentioned, to acquire an image and plate solve it prior to the flip. This will give the position on the sky that the mount is pointing at. If this is used then the solve and sync process after the flip should be correct.
Thanks for the replies, the target stayed centred in frames 1 to 5, I can’t understand why the scope would be reporting a position so far off prior to the flip, the mount is on a pier and well polar aligned.
Here’s the coordinates from solves on the actual images;
Image 1 - RA: 09:55:56 DEC: 69 41 13
Image 5 - RA: 09:55:56 DEC: 69 41 15
Auto Flip
Image 6 - RA: 09:56:01 DEC: 69 23 42
Re-centre target
Image 9 - RA: 09:55:56 DEC: 69 41 09
I understand that SGP flipped and centred to where the mount may have reported that it was pointing, but I’m struggling to understand how the mount thought it was pointing so far off after only 50 odd minutes of imaging.
I’d rather see the behaviour whereby the mount re-centres to the target specified in the sequence.
[quote]
I understand that SGP flipped and centred to where the mount may have reported that it was pointing, but I’m struggling to understand how the mount thought it was pointing so far off after only 50 odd minutes of imaging.[/quote]
One possible explanation is: If there is some polar misalignment, there will be declination drift, which gets corrected by the auto guider telling the mount to move. If you then ask the mount where it think it is pointing, that will be the target declination plus (or minus) the correction. In your example the correction was about 18’ in 50 min.
The logs seem pretty clear, The solve and sync after the flip is working correctly but to a position that is a little different to the original target position. I don’t know where that position is coming from but there’s no evidence of a solve immediately before the flip.
If it is using the position the mount reports before the flip then collecting and examining the telescope logs should show that the post flip position is the reported mount position before the flip.
Missed that, sorry. I think I was thinking of the previous log file. Those numbers are the hint data, not the actual position reported by the solver so as you say the actual solve position would be useful.
The log seems pretty clear that the solve and centre is using a different position to what was used for the original target solve and centre. It’s difficult to see why a successfully centred and guided field should not have the same sky position.
The image has rotated through 180 degrees as a result of the pier flip, I don’t suppose that had any effect?
Could the main scope position have shifted relative to the guider because of something such as mirror flop. The difference seems to be a few arc seconds. Mirror flop could shift the image relative to the guider so even though the guide star location hasn’t changed the image location has.
Thanks for the replies and apologies for my lack of response, I’ve been away for a week without internet access.
This image run is with an Orion Optics newt and OAG, so no mirror flop and as mentioned I don’t get a lot of drift from PA misalignment.
Anyway, it’s forecast clear for a couple of nights this week, will updating to the latest beta solve this problem for me? I think it needs a solve (and sync?) prior to the flip, has this behaviour been reinstated in the latest beta, or should I downgrade to a certain version?
I am not sure… The problem you are seeing is not immediately clear to me. The first centering routine worked to center the target’s provided location, then the centering routine during the flip works to recenter you where you were pointed prior to flip. These 2 positions were not the same (as indicated above) and this, to me, means that somehow between initial target centering and flip, your position drifted.
For some reason the mount thought it was pointed somewhere else prior to the flip. I can’t explain why this would be as the target remained very well centered over the five images prior to the flip and drift from PA was around 0.1 arcsec per minute.
If SGP had performed a solve prior to the flip then it would have realised the position, as reported by the mount, was incorrect and it would then flip to the actual position. I thought this was the previous standard behaviour but the solve prior to flip had been removed at some point before the version I’m using, but I stand to be corrected.
For clarity I should maybe add that I didn’t tweak the position manually at all after the initial solve. PS2 always puts me bang on where I want to be from the target defined in the Framing and Mosaic Wizard.