I’m nearing initial completion of my direct-to-motor ASCOM driver for equatorial mounted NexStars. This driver completely eliminates the need for NexRemote or a hand controller and automatically “hibernates” and restores on shut down and restart of the driver. It also supports direct setting of the RA/DEC position from a plate solve result, so no more searching for a target in a database! Just point at the sky, plate solve, enter the value. Done! The plan of course is for the ASCOM Sync function will allow programs like SGP to do that automatically, and it’s ALMOST working.
Over the past couple of nights I’ve been debugging my targeting algorithm to get the scope to hit the target exactly, and as of last night I have it incredibly repeatable, where before it would oscillate (primarily DEC) on repeat attempts in the plate solver. However, now that it’s repeatable, the scope would never sync to the center position (5 tries per event), so I figured there was something off on my driver. I noticed that SGP has several options for the Sync function and tried those, and while on one setting it eventually centered on the Ring Nebula after a repeat start of the solver dialog, as soon as I changed target and tried again, no such luck. I would have expected that an option that didn’t use my driver’s sync function should have worked fine. This morning I noticed that this function is apparently “new” as it’s not in the 2.5x release I had on my local desktop, and even after updating it doesn’t appear to be in the documentation to figure out the difference in the two alternate approaches. Any enlightenment?
I never received a response here, but I went ahead and paid the $80+tax upgrade fee to get to V3.0, even though I don’t really need any of the added features. The Sync Behavior still doesn’t appear to be documented in the help file, so I’m still not sure what I should expect from each setting. At any rate, I’ve dialed in my driver so that it will stop within half an arc-minute of the target, and after fooling around with SGP, I finally just went back to the standard Sync mode there. With my current targeting algorithm, SGP will now center the target (6 pixels on the Ring Nebula and 15 pixels on the Eagle on my last two attempts) after about 4-5 iterations. My pixel size should be about 0.288 arc seconds per pixel, so the result is about what I would expect, but what I don’t understand is why SGP has to take multiple iterations to get there vs. being able to do a single plate solve and apply the offset and hit it dead-on with the next try. Hopefully bouncing this thread back to the top will get a response.
I can’t directly answer your question, but at that pixel scale (0.288"/px!) it doesn’t surprise me at all that it takes 4 iterations to get there. At that image scale you might even be fighting seeing conditions or some kind of mount bobble. Even at my more forgiving 0.62"/px it still takes 2-3 iterations before I get inside my tolerance.
Thanks Joel, but I don’t think that explains it, since my targeting algorithm can hit the specified target within an arc second (roughly three to four pixels)… Even allowing for backlash, if SGP were to apply the error in a plate solve to the current position (either through the ASCOM sync function or by offsetting the target it sends) and attempt to go to the offset position, the mount motors would stop within an arc second of that offset position. Thus, at a minimum, the RA position would be correct after the first shot, since any backlash would be quickly taken up by the tracking.
The only things I can think of that would explain the iterative behavior would be if the mount alignment were way off, (not the case here) so that the RA/DEC corrections were mixed and thus the target would presumably “circle in” as it attempted to correct to the target, or if the scaling of the plate solve were off somehow so that it was not returning the proper center of the image as the detected RA/DEC. I guess the latter would be easy enough to check by comparing a plate solve in SGP with one from Astrometry.net.
I need to go dig through the latest log and see if I can figure out what SGP is actually doing.
Just as a quick summary out of the log, here’s what my driver believes is happening…
Slewing to RA = 18:54:17.47, DEC = 33:03:19.39
Stopped at RA = 18:54:18, DEC = 33:03:19
Syncing to RA = 18:54:18.15, DEC = 33:02:32.58
Slewing to RA = 18:54:17.47, DEC = 33:03:19.39
Stopped at RA = 18:54:17, DEC = 33:03:19
Syncing to RA = 18:54:17.28, DEC = 33:03:49.68
Slewing to RA = 18:54:17.47, DEC = 33:03:19.39
Stopped at RA = 18:54:17, DEC = 33:03:20
Syncing to RA = 18:54:16.96, DEC = 33:03:39.16
Slewing to RA = 18:54:17.47, DEC = 33:03:19.39
Stopped at RA = 18:54:17, DEC = 33:03:20
Syncing to RA = 18:54:17.35, DEC = 33:03:19.34
I had to go back and add decimal places, since the RA numbers actually looked good for this run, but that was because a second in RA is 15 arc seconds, so the error wasn’t visible at the time second scale. Unfortunately the stopped positions are formatted by the ASCOM formatting function and thus I’m not able to pull out that additional resolution.
I can look deeper at the offsets being created by the Sync function, but those are relative to the zero (home sensor) positions, so they don’t reflect the direct delta being applied each time.
Could it be that there is a floating point resolution problem here with the target Ra/Dec when SGP either issues the command or when it gets the Sync from the plate solve. I have a CGEM mount and I always find that the mount settles at about 100 pixels from the target and can’t approach any closer. It acts like there is a barrier at that point and will have three or four attempts, always landing within a 10 arc seconds of the same point that is around 100px from the target I have set (my camera is 0.35"/px).
Well, the default slew mechanisms in the NexStar motor controllers do have a pretty good amount of slop to them. There are actually two different slew-to-target commands with associated rates. The first is the one that you normally notice, which is the fast slew followed by the approach from direction behavior, but if you watch closely you’ll see the hand controller has to send a second command for the second slew which moves the last distance slowly. What I had to do in my driver is to make that secondary slew stop short as well and then go down to a simple move command (the same thing as hitting a button on the HC) at speed 2 (sidereal) and sit there monitoring the position until it’s within the tolerance. The update loop for both motors takes about 30 ms and the motors can move a couple tenths of an arc-second during that period. Note that because I’m using the move (button) commands, the backlash compensation must absolutely be disabled. Otherwise it will jump from the final position by whatever the backlash compensation is.
As far as the round-off error, unless there’s something in SGP (which I don’t think so) then that’s unlikely as well. ASCOM uses a double for RA/DEC in hours/degrees, and the motor controller is a 24 bit signed integer, making a single encoder count something like 0.077 arc-minutes.
Testing the plate solver tonight, from astrometry.net on a screen grab I get
|Center (RA, hms):|18h 53m 47.786s|
|Center (Dec, dms):|+33° 01’ 14.773"|
SGP reports:
So DEC is a bit off and RA doesn’t have enough decimal places to tell.
On the other hand, as far as the actual position information, this is a bit more disturbing. The position reported by SGP doesn’t match the actual scope position.
The targeted location (the ring nebula) is of course:
R.A.: 18h53m35.1s, Dec.: +33°01’45", so SGP thinks it’s on target but it’s not. Somewhere it appears to be applying an offset to what my driver is reporting. Thoughts Jared?
BTW, I just went ahead and did a center on target and the one thing I note that I assume is just a display space issue is that positions are displayed in floating point with only three decimal places. I’m assuming that is just the display and not representative of the resolution internally. Note that this time on the second attempt it centered within five pixels.
Thanks Buzz, but going back to the original question, I think there are two issues at stake here. On the first point, just in case there’s any confusion as to what I’m talking about, I’m referring to the following setting that was added in v2.6.
Going back and looking at the release notes, it’s apparent that this feature was still being debugged and it wasn’t clear exactly what the issue was or if it had been resolved. While Jared’s response didn’t actually answer the original question of what the other two (or actually three, including “none”) sync behaviors are supposed to be doing, the fact remains that I attempted to use them when I was having trouble with the default Celestron targeting functions. Now that I have my targeting dialed in, and can confirm that my ASCOM SyncToTarget function works correctly and that SGP uses that function when in Sync mode, the evidence from the second picture in my last post would indicate that SGP still apparently has some sort of offset stuck in my sequence profile somewhere from one of those other modes that is causing an offset between the scope readiout and SGP’s. I’m assuming that’s a bug that the offsets aren’t getting cleared when the mode is switched back to Sync, but either way I need to get that offset cleared out, preferably without having to set everything up again.
The second issue is with the accuracy of the PlaceWave solver vs. Astrometry.net. This isn’t a completely fair test, as I need to send the same FITS file to Astrometry.net as is being solved locally. Instead I sent a screen grab of the display in SGP, so the latter is lower resolution and could be a pixel or two off at the edges. I’ll have to recheck that later, but since it looks like SGP has the same reporting limits as the ASCOM RA/Dec print functions, it’s not possible to compare the RA to within anything better than 15 arc seconds anyway.
Hi Beo - yes - there are three sync choices and I recall at one time only two of them were fully implemented. I think the ‘scope offset’ choice was not working. Jared will know for sure.
Since TSX updates two years ago, which stopped supporting external syncs on my Paramount (to protect modelling accuracy) I had to stop using the ‘sync’ option and I use the ‘target offset’.
There’s still an offset stuck in SGP somewhere between the telescope driver and SGP. I’m assuming that came in when I attempted to use the other sync options. How do I get it cleared?
Probably not an offset. Likely a difference in coordinate systems. SGP uses and displays J2000 everywhere, but it will internally convert J2000 to JNow if that is the coordinate system that your mount is displaying.
I would assume that’s the difference you’re seeing here. If you look in the SGP logs you should see these conversion calls and I’m pretty sure the “pre conversion” coordinates are also in there (which should hopefully match).
Presumably that’s it. I fixed a different bug in my targeting algorithm (different Celestron mounts apparently define positive/negative/CW/CCW differently) and seem to be targeting accurately now after a plate solve, although the offset is still disconcerting.
If your driver has the option to switch to J2000 give that a shot and see if it resolves the offset. Or look in the SGP logs and verify that the JNow coordinates match what your mount says. …
