I’ve been trying all night to get the Center Here function to work properly. Every time I try SGP moves the mount in the proper direction in DEC but in the opposite (wrong) direction in RA. I’m using a CGEM-DX mount. Plate solving works fine, I can use Solve and Sync and have SGP center my target just fine. Entering RA/DEC and selecting Center Now works fine. But any attempt at using the mouse to center here fails. Using 2.5.0.7 and ASCOM 6.1
It would be very helpful if you could save and send the image of the sky you are working with (in addition to the stuff below)
Please see here for directions on how to find logs and we’ll take a look:
OK. Thanks for the directions for asking for help. Good to know and I should have checked first; my bad.
Time of the issue between 9:45 and 9:55 PM EST Feb 20th.
Here’s what I just did:
- Slewed to M42; did a Solve and Sync Blind to get started.
- M42 was centered in the QHY10 frame. (using 4x4bin)
- Took an image (Orion_1.fit)
- Right clicked on M43 and selected Center Here.
- After the centering routine finished I took another image (Orion_2.fit)
You will see that the DEC position is correct, but the RA is a mirror of what it should have been.
Images and LogFile are located in my DropBox at:
Thanks.
OK… well, I am unable to reproduce the issue you are describing. I am able to duplicate your exact scenario with synthetic star fields. Based on where you clicked, we calculate its location based off of the current image center. Your images are solving properly. One of the more important pieces of data in the calculation of the new desired location is the angle of the image. PlateSolve2 and all of the other solvers we use report ~357 deg east of north. If PlateSolve2 reported this angle with a 180 degree error, the new calculation would be flipped… but it’s not.
I’ll need to think about this a bit more. I did see another issue, but I believe this to be unrelated to what you are seeing.
I have an update to the problem … last evening I set up my scope with the Hyperstar FR attached. Decided to image the Christmas Tree Cluster and Rosette. Telescope was on East side of pier. SGP worked flawlessly - Slews and ‘Center here’ were almost perfect.
This time I had the CGEM-DX in hibernate mode, did not do any alignment, just mounted the OTA and slewed to Betelguese. Then centered the image on the star and synced up with that location with both SGP and SN7. From there everything worked fine. Later that evening, before tearing everything down, I slewed to a galaxy cluster, to the east (scope on West side of pier) and tried ‘center here’ again. Still worked.
So, what was the change? Is it a pier side issue? Does the alignment process of the CGEM-DX mess up something in the sky model?
Was the original problem with or without hyperstar?
I don’t think so. If anything I’m wondering of we have an issue with some configurations of OTAs “flipping” images and that is messing with our math. I cannot remember exactly how hyperstar works, but I think it removes the secondary mirror right? As a result of this it would also flip image orientation possibly? Not sure.
The original problem occurred without the Hyperstar. In fact, if memory serves me (which is difficult as of late 
) it has always worked with Hyperstar.
Yes, the secondary mirror is replaced and the Hyperstar attaches in its place - this flips the image horizontally (E-W).
OK… I’ll take a look with a few new assumptions then. If your solve actually gave us a sky angle “west of north” instead of the expected “east of north”, we could end up with some backward looking movement. Technically this error would be present in both RA and DEC, but if your camera is oriented a certain way this might manifest itself only in RA.
So if the problem occurs only without Hyperstar, and doesn’t show up with Hyperstar it would seem that any fix in the software would simply reverse the problem - i.e., how would SGP know what kind of optical path is present. Perhaps a UI button that would allow the user to ‘flip’ the orientation of the image? Just thinkin’ out loud here.
I was going to run some additional tests but either I was not available to setup at night or there were cloudy nights (more of the later unfortunately). I wanted to see if the issue ever occurred in DEC.
Yes… another setting would be the only way I can think of to fix this issue. I have a general aversion to adding new settings (slippery slope before SGPro looks like the cockpit of a 747). I’ll still need to consider this a vbit when time allows. It’s not forgotten.
Maybe a shot in the dark, but are you using the QHY10 camera? If so, are you rotating the image for landscape display before clicking “Center Here”? As I’m sure you know, the QHY10 camera has an odd habit of providing images in portrait mode. One of the things I noticed was that if I rotated the image for landscape display, the HFR calculations were still performed in portrait orientation and the HFR squares were displayed as though the image were still orientated as portrait even though I had rotated it to landscape. If you are rotating your images and clicking “Center Here” on the rotated image, but SGP is calculating that click position based on the portrait orientation, it could explain the incorrect motion.
If you’re not rotating your images before clicking “Center Here” then this is a rabbit hole. But if you are, you could try one of two things - don’t rotate the image before trying “Center Here”, or trying 2.5.0.16 which forces downloaded images into landscape orientation.
Tim
Tim,
Yes, a QHY10, but I don’t rotate the image, so that’s not the problem. I was going to run some imaging runs last night with the camera rotated 45 degrees to the Celestial Equator, thus seeing if the issue occurs in both RA and DEC, but I decided to spend the few hours of relatively clear skies on capturing some additional subs of the Rosette nebula. The next week doesn’t look good, but if the evenings are partly cloudy I might be able to run those tests.
Mikey
@XCalRocketMan I had a thought about this… when you are not using your hyperstar, I am wondering if you see a FITS header named FLIPPED set to TRUE (and the opposite when using it). If this holds true, we may be able to auto-detect flipped images and adjust the reported sky angle to what it would be if the image were not flipped.
In both cases the FITS metadata indicates FLIPPED=F (False). Not surprising since other than mounting the camera on the Hyperstar vs. the FR at the prime focus there is nothing different so I didn’t expect the value to change - the camera doesn’t know where it’s mounted.
In another thread on this forum Flipping Image Problems - Sequence Generator - Main Sequence Software there is a discussion about the FLIPPED data element where JulianR claims it is related to the side of pier. I looked at some images I took Fri night/Sat morning where I had SGP imaging M100 unattended during the early morning hours. In images prior to and after meridian flip the FLIPPED value was F - it didn’t change. SGP log shows the telescope moved to the east side of pier during the night. So if the FLIPPED value is supposed to be an indicator of pier side it didn’t work.
That is not relevant to the FLIPPED attribute.
Right, flipping should not change this value. It should change when when the number of mirrors changes from even to odd or possibly if your camera readout is from bottom to op instead of top to bottom. Our implementation of PlateSolve2 is pretty new and we don’t really use the FLIPPED header for anything important so I’ll need to make sure that it is reporting properly.
Yep - but without any option in the software to indicate this how else would SGP/PlateSolve know?
Not sure I follow. Your image is either flipped with respect to its relative appearance in the sky or it’s not. This has nothing to do with user defined settings.
Agreed. But here’s what I’m saying …
I point the scope to some object (let’s say the Rosette). I’m using Hyperstar so only one mirror in play. SGP works just fine. Now I remove the Hyperstar, place the camera at the rear cell of the OTA and image again. Now there are two mirrors in play - SGP’s center here won’t work. In the first case, the image is flipped. In the second case it’s not (or vice versa, doesn’t matter).
Sure. I don’t think we are saying different things. All I am saying is that one of these two should report “FLIPPED”. The one that does will have a sky angle that needs adjustment as if the image were present in a non-flipped way (so that we can get a normal east of north angle). This does not require additional user settings to convey.
This may be a bit late but would REFLECTED be a better keyword than FLIPPED? That’s what it actually means.
Chris