First let me say, this is not another post about ‘Center Here not working, please fix’. I am using a Celestron mount, have pre-read the forums, and understand there is an issue with the ‘Center Here’ functionality related to Celestron mounts. That being said, it actually does appear to be trying to work which has lead me to using it in an odd way and I am really just writing in here in the hopes of finding out ‘why’ it is working this way. I am fairly new to all this and so it is also very likely I am missing something and I am hoping someone might shed some light on this. On with the show…
Equipment: Celestron 8", AVX Mount with Hyperstar, Atik 428ex camera.
After a solve/sync, most of the time the DSO will be in the 4th quadrant on the screen. When I first started using SGP and would try to do a ‘Center Here’, the object would go off the screen. I quickly noticed when it went off the screen it would always go the same amount down on the Y axis and right on the X axis. (Staying away from N,S,E,W to hopefully make it less confusing). Since this was repeatable, I tried to do a Center Here in an area that was exactly opposite the objects actual location across the X,Y axis. (Up and Left) Low and behold it worked! It put the object very close, if not dead center in the center of the cross hairs. See diagram.
Being new at this, my first thought was that I had the camera upside down. That wasn’t it, and I don’t know if it would have mattered as isn’t camera rotation a common method for framing the object? I then thought it was because I was using the Hyperstar which puts the camera on the front of the scope instead of the back creating a mirror image of the sky. I really don’t have a way to test this(Well I do, but it would be a pain), but this doesn’t make complete sense either since the scope still plate solves fine AND it’s not just a mirror image, but also flipped across the Y axis. I have never been good at spatial geometry and when I start thinking about this, my chin drops and I go into a foggy trance. Any ideas welcome. I’m really just trying to understand the ‘why’ and make sure I am not missing something where I could make it actually work the way it is supposed to. For now, I’m just using the Kentucky Windage method. I created a spreadsheet so I could quickly enter the objects X,Y coordinates and it spits out where I need to place my mouse to do the Center Here. It works and it’s considerably better than nudging the telescope to get it centered.
I run a CGEM and have the exact same issue, but because I am in the Southern Hemisphere and upside down relative to you, my image was always in quadrant 2. My image scale is 0.381"/px and I am off by about 350px which translates to 133 arc seconds. So, I did an experiment and thought I would change the target coordinates and see if I could walk the image to the center with successive Centre Here commands. I expected to find that I was right on target after moving 133 arc seconds in RA. To my surprise this occurred after changing the target coordinate by only 24 arc seconds. My conclusion was that Celestron has a serious problem in some calculation they are doing or the ASCOM driver is failing to do the J2000 to JNow conversion correctly. I searched Celestron for an updated hand controller firmware, but their published list of updates showed that I was up to date. I then checked the J2000 to JNow conversion accuracy and found that it was close enough that this couldn’t be the source of the problem. Even though I checked the revision history, I decided to force a check and update of the Celestron firmware and to my surprise, it updated to a significantly later revision. I now get about 100px error and the result is acceptable almost all of the time. Celestron or the J2000 to JNow conversion is still not totally accurate, but the result is acceptable. My next step is to go back to my data and have a look at the conversion accuracy and see if this is what is causing the residual error. It is often reported that you get what you pay for, but the CGEM is capable of repeatedly missing the target to within 20 px over and over again which tells me that this is the accuracy of the mount that should be possible if the programmers could get the mathematics right
I too forced a firmware check when I first read about the Celestron issues while performing a Center Here. I also got a newer version, but this didn’t appear to improve the results. It’s possible it did and it just wasn’t noticeable because it continued to slew in the wrong direction.
As I reported awhile back I have the EXACT same issue but with my QHY10 camera at the prime focus point! Using Hyperstar with this camera ‘center here’ works fine. So, same problem, but in precisely the reverse setup - mine fails at PF but works with Hyperstar.
So I’ve been just mirror imaging the location on the screen by eye and asking the mount to center here based on a point 180 degrees rotated from where I really want it to be.
I recently acquired a ASI1600mm pro and ‘center here’ works at prime focus for that camera (can’t check with Hyperstar as I don’t have an adapter to fit and I wouldn’t want to use it with Hyperstar anyway - no filter capability without a filter wheel).
@Gunny: No problem! Safe to say I set myself up when I put Kentucky Windage in the title. Thanks!
@XCalRocketMan: OK, still trying to wrap my head around that example. That would ‘seem’ to take the mount out of the equation and point to the camera but I don’t understand how the camera would effect it unless ‘Center Here’ is using the "/px to calculate a new move and it was set incorrectly in one setup, but not the other. I’m not sure that would explain the flip though. Maybe radically different focal lengths between Hyperstar vs prime focus? Based on my previous reading this is not how I understood it to work. I’m pretty new to this. I was under the impression plate solving doesn’t care about such things (FL, "/px, frame size, rotation) other than the ease/speed at which it solves and actually can help calculate all these things once the image is solved. Well, thanks for the info. Something else to ponder on.
I have written on this on several other threads, but never seem to attract a response from SGP Devs. Their explanation seems to be that they “close the loop” by plate solving, sync the mount to that location and then command the mount to go to the target coordinates again. I agree with them that this should work, but my argument is that it clearly doesn’t with some mounts and a better way would be to use a full feedback method to close the control loop properly. This is how the focus routine works. It doesn’t care where the focuser is going to, it is just achieving a result by testing what it gets at different positions. A better analogy is when we steer a car on level ground the steering wheel should be centered. If the camber of the road increases we steer away from the center to keep the car going straight. It isn’t the steering action that counts, only the outcome. I would like to throw it in again that SGP could eliminate all camera, mount, epoch conversion errors by looking at the image and automatically calculating the steering offset to achieve centering that is confirmed and measured by plate solving.
RocketMan’s observations show that it could be camera based, so I wonder if it is SGP or PS2 selecting the wrong image center in the plate solve. I have a Canon EOS 450 camera that centers almost perfectly, but I switch it out for my ZWO1600 with no other changes and it fails to center. It seems there is something here that needs more experimentation to prove one way or another. This weekend if the cloud gods permit, I will solve a few well known stars right in the center of field and see what the error is.
That should generally be the case for for auto center but Center Here is a little different.
What all plate solvers are you all using? Is anyone using PinPoint and seeing this or is it only with PS2? I’m mostly wondering as we get coordinates differently between the two.
Sorry, I was actually referring to Auto Center. I rarely use Center Here, but on the odd occasion that I have, it misses by the same amount and in the same direction, so I end up back where I was. I am using PS2 for all Auto Centering and Astrometry for blind solving for my first solve to sync the mount. PS2 solves within a few seconds once I am synced.
I’m using PS2 with Astrometry.net local(ANSVR) set as failover/blind solver. I have also used/tested my setup with Astrotortilla. All of these will basically solve/sync the object to the same place with my setup (4th quad). But yea, Center Here is using PS2. I think PP has a trial, think I should try that and see if it makes a difference?
That would be helpful. If you can also attach some FITs images that you’ve experienced this issue with that will help too.
For “Center Here” there are 2 sets of conversions that have to happen.
From coordinates pixels
From pixels to RA/Dec
For 1 it’s all SGP and should generally be straightforward. For 2 it is SGP in some cases and the PlateSolver in others (for instance in PinPoint we can say “what is the RA/Dec of this pixel?” and it will tell us). For other solvers we have to calculate it.
So I’m essentially wondering which part of #2 the problem is occurring in. If it’s in all solvers then it’s something about how we’re translating down to the image pixels. If it’s “not in PinPoint” then it’s the math we’re doing to calculate the RA/Dec based on the image and likely needs some work. I’m guessing it’s the latter.
Will do. Glad to help. Weather forecast isn’t looking very good until Sunday, but I will keep an eye out for some skies clear enough to get some files and test PP. Moon is out in all its glory anyway, so now is a perfect time to play around with it.
Managed to get a break in the clouds tonight and ran the test. It appears your guess was right. When using PinPoint as the plate solver for Center Here functionality, the target centered with no issues on the first attempt. Here is a link to a folder on OneDrive that contains all the fits files, screen shots of the process, and an excerpt of the log during the test: Test Files
Hope this helps. Would love to continue to use PlateSolve2. Also, below is a quick reference screenshot of the 4 images of the test.
Initial Solve and Sync to get the target in view (Star: SheDar, Used PlateSolve2 for this)
‘Center Here’ results using PlateSolve2
Re-Sync using Stellarium to get the star back where it was.
i am seeing this as well with a mach1gto and APCC. i think it must be a regression since i can remember a time when it worked right.
centering as part of a sequence works fine, but right-click-center-here behaves as the OP states. i wonder if it has anything to do with having a rotator - i have not been able to test if different rotator PAs influences the problem.
I am having the same issue with a Mach 1 GTO and APCC, but I have no rotator. The rotation setting could be related to this issue. My assumption is that the solved value from plate solve 2 is used by SGP, but perhaps that is not true. I’ll play with that next time I am setup.
Dear developers,
I operate with different setups. And I have the exact same issue that Stephen-D described ONLY when I am using my Hyperstar.
The hyperstar returns a mirrored image. I am pretty sure PlateSolve2 is returning the correct coordinate. I think the issue lies in the piece of code that determine where is the “HERE” clicked on. If it is a mirrored image, this code needs to start from the opposite corner if it calculates the X and Y of the pixel being clicked on I guess.
In the end, I have started to routinely click on the symmetrical mirror of where I want to center. This technique works but it is an annoying workaround. It would be very nice to fix this “hyperstar” issues once and for all.
I would agree Gunny. I’ve never been able to hit a thing with a Glock, which is why I own a Berreta.