Ray:
That’s good to hear that the AP mounts take slewing time into account. I did some searching in the AP Yahoo group but could not locate the post I was “remembering” so it is possible something different was being discussed.
Charlie
I’m not sure you realize that my result confirms two things that Jared was asking about. 1) Does the mount really miss where it is aiming for - based on its own encoders? Yes it does. Chris’s Conform test shows the same thing - and they miss by a consistent and fairly precise amount. 2) If you aim a bit off from the target can you compensate for this component of the error? Yes - you can.
I’m not sure if Jared’s code change includes a log line showing where the mount thinks it landed after a slew - but that would be good info.
But yes I would be happy to see actual results under the sky with different mounts. Some mounts like mine will - I hope - center more accurately with this change. Other mounts should - I hope - continue to center well, as before - but without a sync.
What has dragged this thread down are non-constructive and negative predictions that it simply won’t work - for some reason. I have been responding to them because I think they create a false impression of the concept here. But at this point it would be nice to see some tests - which I still cannot do yet.
Frank
I just wanted to give a brief update. I have not been able to perform the test using the exe file Jared created to prove/disprove the centering concern. the weather has not cooperated and now I will not have access to do any imaging until the end of July. Not sure if anyone else would be willing or able to do the test to help out.
Backgournd informaton: I do notice for my rig I consistently get to approximately 80 pixels +/- 10 pixels but it will not converge any closer. It just seems to be very consistent around the 80 pixels. My image scale is 0.69". I’m using a ATIK 8300L+ OSC camera, 5.4um. at approximatley 1,610mm FL on a CGEM-DX mount. with the StarSense HC. I did try awhile back doing some testing with and without a model in the mount and it didn’t appear to make a difference in being able to converge. that was using 2.5.1.12 beta I believe.
Regards,
mahaffm
I intend to try it. Weather and schedule just haven’t cooperated.
Tim
It is a high priority for me but several things have prevented it. Hoping to be able to test in coming days.
Frank
OK - I was finally able to do a preliminary test with my cge-pro - but only of the slewing behavior and the ability to correct it, i.e. an indoor test with no sgp involved. This is the same as I did above with the evolution mount.
In this case I told the cge-pro to slew to 3:00:00 RA and 0 dec. - with the full telescope and imaging payload.
When I did this several times it consistently missed that target by -1.7s RA and +35" dec, with an occasional difference of 0.1s and 1". Again - this is just reading the handcontrol RA/Dec values after doing the slew - so there is no plate solve involved. The slew did not land exactly where it was told to land.
The error here amounts to 25.5" E/W and 35" N/S - for a total miss distance of 43".
I then made new slews that compensated for this fixed error - and told it to go to
RA 3:00:01.7 Dec -35"
On repeated slews it either went to exactly 0:0 or it missed the RA value by 0.1s or 1.5" - meaning a single compensation nailed the target repeatedly.
This is exactly the behavior I expected - and I observed similar behavior and improvement with the evolution mount - though not to this degree since the evo mount isn’t at the same level of performance.
This doesn’t mean the final centering accuracy with sgp will be 1.5" - but it does mean there is an inherent fixed miss due to the slew behavior alone that can itself be removed by compensating for it in the slew target - while a repeated sync/slew would never work.
When I have clear skies I will try the actual sgp implementation to test it for real under the skies and with plate solves.
Frank
OK - I was finally able to test Jared’s new code - and logs are attached.
In short - first I confirmed the slew/synch centering process was stuck in the same location at around 100 pixels with the normal 25.1.14 code.
Then I tried Jared’s modification to the code - and unfortunately it did not help anything. It appeared to behave slightly differently but got stuck at about the same location. Log is attached, ending with 1936.
Then I manually did the routine myself - by using the “Slew to target” in sgp, combined with a right-click plate solve on images that I took manually with the frame and focus tool. In that case it worked perfectly and I was quickly within about 2 arc-seconds of the target. And that is based on an actual plate solve - so it really did work as intended. That log is 2346.
One difference here is that I am using a new camera, a qhyiii174 for the test - and I did see some trailing in the images that were plate solved while centering. This implies it needed to wait a bit after the slew before taking the plate solve image. But even then it should have compensated for some of that motion.
So - was the routine implemented properly in the test code? Is there some other form of offset involved?
In my manual test - in log 2346 - I was aiming for RA 11:00:00 Dec -60:00 and on the first try I landed at 10:59:50, -59:59:19
So in the next slew I aimed for 11:00:10, 60:00:41
and I landed at 10:59:59, -60:00:02
That was an immediate improvement in one move and I was almost exactly on the target.
I then slewed to 11:00:11, -60:00:39
and it landed at 11:00:00, -60:00:01
which is great.
So the concept should definitely work and it avoids syncs - but I’m not sure why the test code didn’t work.
Frank
sg_logfile_20160625181936.txt (614.7 KB)
sg_logfile_20160625182346.txt (989.1 KB)
Based on the Frank’s logs Jared may be able to create another software test based on the information Frank has gathered? It would be great to see an improvement in the centering routine that gives better convergence. My rig seems to get stuck at around 80 pixels +/-10.
Thanks,
mahaffm
Hi-
Even without the code change - people can test this out with their own equipment the way I did. You just want to make sure SGP never triggers a sync.
I started a new sequence and opened up the target and gave it clear and simple RA/Dec values - like RA 6:00:00.0 and Dec 10:00:00. Then press the Slew Now button and wait for the slew to complete. Then use the Find/Focus control to take a short exposure to that shows a number of stars. Then right-click on the image and say Plate Solve. It will display the solved position and make note of how far off it is from the target.
Then change the target values to compensate for this miss. If it overshoots dec by 10" then decrease the dec. target value by 10". Then do another Slew Now and repeat - each time adjusting the offset a bit by the amount of the last miss.
Make sure not to use the actual Plate Solve control in SGP because it will cause a sync to happen.
Frank
Hi folks, just returning to this thread after about a month of periodic testing with my Losmandy G11.
When my mount had a model, my centering error grew into triple digits when tested over many months. I believe that’s because the G11 updates the model when it receives a SYNC from SGP. A SYNC is normally used to correct the G11 model to an existing alignment star when the mount is disturbed mechanically. So getting a SYNC from SGP during centering doesn’t make sense for the G11 (and probably many other mounts).
A month ago, I cleared the G11 model for both sides of the meridian (the G11 uses two models). Since then, I can center to less than 10 pixels everytime, and that’s at 0.64 seconds (") per pixel, or 6.4 seconds (") pointing accuracy!!!
SGP still sends the SYNC, but the G11 ignores it because I have no model to correct.
I highly recommend you clear the model in your mount when using SGP centering. Having a mount model just makes no sense when you use SGP centering, regardless of whether SGP sends a SYNC or not.
I also recommend you have nearly perfect polar alignment (uncorrected DEC drift less than +/- 1" for 2-3 minutes) and that you align to at least one star by mechanically moving DEC and RA. The latter greatly speeds local plate solving. I very rarely need to blind solve. The closer the mount’s reported RA/DEC is to the actual target, the faster you will plate solve. With Pinpoint, I plate solve within 1-2 seconds.
In summary, I Pinpoint plate solve within 1-2 seconds, slew and settle within 30 seconds, and have centering precision to within +/- 6.4" within 1-2 attempts every time. I can’t imagine a faster and more precise operation, especially at my 0.64"/pixel at 2758 x 2208 pixels (1420 mm focal length).
I think that all these mount-dependent details would go away if the centering routine followed the method I describe above - which I have confirmed works to the arc-second level with my mount. Just follow the routine and allow an option to sync the mount once centering has completed.
The issue of syncing the mount to make the plate solve work better is somewhat chicken and egg. SGP can only sync the mount after a successful plate solve in the first place - so if it fails nothing will happen. I suppose you might want an option to sync at the start of the centering routine rather than at the end - or in addition to the end. That would make the plate solves happen with more confidence.
But my main point is that if a mount misses by a very consistent amount during centering - as many do for many reasons - they would most likely center very well with the method I have described - with an option to sync the mount or not and the beginning and/or end.
Frank
Has it been established that “MANY” do?
Just wondering…
Certainly the eqmod - in certain modes - and the celestron mounts do have a problem converging with the current sgp implementation.
And the paramounts don’t like to be sync’d in this manner - as I understand. So I guess they may work - but it alters the model or something.
I think g11/gemini has a similar issue? Not sure.
The two requirements of this sync/slew process are: 1) sync means one thing exactly - and often it doesn’t. 2) slews will land exactly where they are aiming to land - and my mount doesn’t do that - and I expect others don’t also - because it is not trivial. It’s not clear how many users have actually checked that a slew lands where it is supposed to - and the logs don’t tell you if it did.
My question is - what is the reason not to use the method I propose. It adds a small amount of complexity on the sgp side - but sometimes that’s what you need to do if you want to get the best out of a range of equipment with different behaviors. As opposed to stating rigid requirements on exactly what the mount should do when asked to do certain things - and saying if it doesn’t behave as expected - it’s the mount’s fault.
Frank
Frank, would this not address every mount?
- When using SGP centering, be sure your mount model is cleared (no mount model).
- SGP does not send SYNC to mount when centering.
The problem isn’t a sync issue, it’s a pointing issue. A command is sent to the mount to move to a position and the position it reaches isn’t the same. In many cases this can be seen without looking at the sky because the position the mount reports it has reached is different to the position it was sent to.
Frank is suggesting that this should be handed in the application - SGP. I’m afraid I disagree, I think that mount issues should be resolved by the mount manufacturers.
I think that supporting mount issues in a application is a recipe for disaster because it’s a support nightmare. It would be like the DSLR support nightmare again. Some mounts may be OK, applying a consistent offset to the slew command would work but with some it wouldn’t. Trying to support this for free, by email and forum, will be immensely difficult and hugely frustrating.
I wouldn’t touch it with a barge pole, not even for money.
When you get down to it the errors that are being seen are tiny, something like an arc minute. It looks large because it’s in pixels and that’s minute. As I’ve said I would make the default limit something like an arc minute, even if expressed as pixels.
Chris
SGP already has code to deal with mount imperfections that should be resolved by the mount. When you tell the mount to go to a particular RA/Dec value and it misses - that is because the mount is not doing its job exactly right. It is a mount problem - and it can indeed be fixed by spending a ton on a high end mount.
But SGP wants good results with equipment at low price - so it uses an elegant approach to get around this problem - by doing a plate solve and sync’ing so that the subsequent slew will hit the target exactly. But even that doesn’t work right away - so they have a loop and error tolerance and all this elaborate code - as a workaround to try to get good results despite imperfect mount behavior. That is all in the spirit of combining smart software with imperfect hardware to get optimal results. I fully support that attitude - though clearly Chris does not. He would object even to the need for any of the existing centering code.
Not only does this centering code exist for the purpose - but it turns out the sync/slew is not as elegant as thought - because mounts sync differently and some should not be sync’d at all.
And for my mount - it doesn’t work well for other reasons - and as a result I cannot use the centering process due to its limited accuracy.
The alternate way I suggest doing the centering is no more complex than the one that already exists. It is a few lines of code - to replace a few lines of code that are already there. And it avoids a problematic and intrusive sync of the mount - that isn’t needed in the first place. In my case it allows a non high-end mount to center with arc-second accuracy - through a smart combination of plate solves and code. It’s cool when smart software can make mid-range equipment give high end results - and I support cool.
Frank
Frank, would this not address every mount?
1.When using SGP centering, be sure your mount model is cleared (no mount model).
2.SGP does not send SYNC to mount when centering.
I’m not sure what you’re asking - but the approach I describe should work for any mount and I’m not aware of any problem with centering reported in this forum that would stop my suggested method from working well.
As for your point 1 - it would not matter if your mount has a model or not. It just needs to have pointing accuracy adequate for a good plate solve - but that is already true of the existing centering method.
And for point 2 - my method would not require a sync - but it could be done as an option at the beginning and/or end of the centering routine.
Frank
Hi Chris, I completely agree with the applications not having to have mount knowledge. That’s the whole point of ASCOM as you well know as an ASCOM developer!
But I think the application can support a very generic way to center an object as follows…
- Plate solve what the scope is actually pointing at.
- Determine the desired pointing based on a plate solve of the RA/DEC the user entered or a plate solve of the user’s reference image.
- Send the DIFFERENTIAL RA/DEC to the mount.
The issue is how you do #3. I assume ASCOM also supports (?) differential and not absolute RA/DEC. If it does, this should be all that’s needed, and is essentially what Frank is doing manually.
The current SGP implementation, in my opinion, is flawed with the SYNC command. Sending a SYNC to the G-11, for example, re-biases its internal model. Surely something we don’t want to happen for a simple centering! Furthermore, some mounts (like the G11) have an option to add a new alignment point when it received a SYNC. That further complicates the issue!
In summary, SGP should simply send RA/DEC differentials and not mess with the mount model by sending any ASCOM command that may change it (like SYNC). With this, SGP may even work with an existing mount model, which could help correct for non-linearities in the mount even when sending just an RA/DEC differential centering.
Yes - that is effectively what I am asking - to calculate the RA/Dec offset in the miss - and compensate for it in the next slew. This offset is only needed during the centering process and can be thrown away once it is done. Using sync/slew to do this has no particular advantage - and it has many disadvantages.
There is no need or real benefit to doing a “differential” move. Mounts need to do a full slew to correct for backlash - and that is to a specific RA/Dec location. SGP just needs to subtract the measured overshoot in the RA/Dec values and slew again - instead of doing a sync and repeated slews to the same target RA/Dec values.
Frank
We will likely add an option at some point in the unknown future to allow you to specify what “sync” translates to
- Sync Mount
- Update offset
- Do nothing
No eta on this.
Thanks
Jared