Have been out of action for 6 months and just getting back to imaging. Anyways, using SGP 2.4.3, SBMyT, Atik 460 and Stellarvue 130mm I always used to be able to easily center my objects two within 5 pixels. Presently I’m having difficulty getting to within 400 pixels of total error using the exact settings and set-up that I used to use. I’m using Pinpoint to plate solve using 2X2 binning for 2 seconds. I having no problem plate solving, just getting the error down. Any thoughts?
Thanks,
Marty
Please see this and we’ll see what we can find:
Certainly provide log files as Ken suggests, however, I wonder if you are having a J2000 vs JNow problem. I don’t remember the exact date but SGP added support for mounts that report being JNow earlier this year. That is, if your mount is JNow, SGP translates internal J2000 coordinates to JNow for slewing etc. A JNow/J2000 discrepancy could easily account for the error. After this change went into effect I found that with my JNow mount plate solves are now within a few pixels. Are you entering J2000 coordinates into SGP as it expects? Do you know whether your mount is JNow or J2000? Is the ASCOM driver reporting the right value for the mount?
Hi Marty,
I was getting this issue a while ago and no matter how many iterations of plate solving was done during the centering it would not improve on rather large offsets of possibly several hundred pixels.
The cure was to clear the pointing model, I use EQASCOM and because I setup the gear and did polar alignment on each session, the pointing model from the previous session was invalid and really messed up the centering.
Now I just clear the pointing model in EQASCOM and just do a one star align and all works well. Now that I have an observatory, I probably don’t need to bother with that now.
Mike
OK here is the log file: Dropbox - Error
The centering process begins at 8:57:37 i believe.
One thing I’ll add, usually I set a specific angle in the FMW and manually rotate as requested during the centering process but in this case I did not set a specific angle and unchecked that option in the FMW when adding it to the sequence. I didn’t think that would affect centering but maybe I’m wrong…
Marty,
What type of mount do you have?
Software Bisque MyT
Tried again tonight using rotation and still couldn’t get under 150 pixel error where I used to get under 5 routinely.
Are you using Tpoint or are you actively plate solving? Hopefully someone with a SB mount will chime in. I know they’re difficult to integrate.
I am actively plate solving and do have Tpoint on with Protract. I have always used this combination in the past without any issues. I’m wondering if the J2000 to JNow conversion presently in the software has anything to do with this. Last time I used the software that update had not yet taken place.
That could be it. Is there a way to specify in your driver which one you should use?
The TSX ASCOM driver says that the coordinates used by it should be JNow. This is what the TSX scripting (which the ASCOM driver uses) is said to use for it’s coordinates.
Chris
The log file I linked above, clearly shows the software converting to JNow on the fly which is what TSX wants, but I’m wondering, since the FMW works in J2000, is the error computation using the original J2000 coordinates vs the converted JNow coordinates, and thus explaining the larger error I’m now getting?
Ken,
Did the log shed any light as to the cause of this issue?
What epoch are you using for your plate solver? You would have needed to set it to JNow before SGP was using J2000. I don’t think that would show on the logs.
Chris
@Chrisis right. The logs don’t show any of your gear or equipment acting up. One thing to remember is that any epoch coordinates going in to SGPro must be J2000. SGPro will take care of converting any outbound coordinates.
OK, now I’m totally confused. Yours and Chris’ comments seem to contradict one another.
In any case, I am using Pinpoint to plate solve after using the FMW to establish my target. My understanding is that both use J2000. My concern, which may be totally wrong, is that the error tabulation may be comparing J2000 vs JNow and thus would explain the larger error I’m now seeing. Again, in previous versions that I have used that did not do the conversion, I had no problem getting to within 5 pix or error with the exact same set-up.
We are saying the same thing…
Pinpoint always produces J2000 coordinates. SGPro needs J2000 coordinates. It is the only system that SGPro understands. SGPro, despite using J2000 as its internal coordinate system, will recognize if your mount needs JNow coords when syncing. Your mount does require JNow:
[10/29/2015 9:01:24 PM] [DEBUG] [Telescope Thread] Telescope: Syncing to J2000 RA: 23.339217490382 Dec: 61.2231063752825
[10/29/2015 9:01:24 PM] [DEBUG] [Telescope Thread] Telescope Sync: Passed in J2000 but mount requires JNOW, converting…
[10/29/2015 9:01:24 PM] [DEBUG] [Telescope Thread] Telescope: Syncing to JNOW RA: 23.3516802412453 Dec: 61.3146327044391
I guess I should ask in general to the community… is anyone else seeing issues like this (very high errors) when using a plate solver that solves in J2000 (should be all of them…) and a mount that wants to sync and slew with JNow? It’s OK if you get a high error… I’m referring to subsequent (iterative) attempts refusing to zero in on the intended location.
I think we have lots of users in this exact situation and their centering process seems to perform as expected, but I thought I would ask for sanity’s sake…
My mount is in that category (sync & slew in JNow) and centering works perfectly, so no, I do not think it is a problem in general.
[10/30/2015 7:09:42 PM] [DEBUG] [Telescope Thread] Telescope: Syncing to J2000 RA: 22.1318063755183 Dec: 31.3616390359897 [10/30/2015 7:09:42 PM] [DEBUG] [Telescope Thread] Telescope Sync: Passed in J2000 but mount requires JNOW, converting... [10/30/2015 7:09:42 PM] [DEBUG] [Telescope Thread] Telescope: Syncing to JNOW RA: 22.143870417187 Dec: 31.4446823311213 [10/30/2015 7:09:43 PM] [DEBUG] [Center Scope Thread] Automatic Auto Center Success - Total Error <= Allowable error: 12.6 <= 20.0
Andy