I have all my equipment and software ready and have run some simulations indoors and am waiting for the weather to get better. And in the mean time I continue reading.
Something I am not at peace with yet is Plate Solving.
It seems very logical that you can start by pointing your scope to a random location in the sky, take an image, and have your computer figure out where the scope was pointing to. Then knowing where you want the scope to point, you can have your mount guided to that spot. And I am not trying to overlook the need to specify parameters such as scale pixel size, etc.
But from the tutorial material that I am looking at it doesn’t seem to be that simple and proper initial syncing of the mount is required. I am curious as to why syncing should be required if you are having a computer figure out where you are pointing already.
Can anyone address the plate solving and mount syncing please?
This is 100% true. One way or another, the scope must incur an initial sync. Not everyone has access to a blind solver, so if you don’t, then you must perform an initial sync of the scope and its accuracy must be within acceptable error tolerated by the solver. If you do have access to a blind solver (and 2-5 minutes to spare), then you should absolutely use it for the initial sync. User beware that using this method can turn out very badly if your mount syncs fine, but it thinks it is on the other side of the meridian. The onus is still on the sure to make sure that much is accurate about the initial sync.
I appreciate the reply. As someone new to this industry let me tell you
that I believe it has its own language and I am still trying to adjust to
its semantics.
What does “sync” mean here? Does this mean synchronizing one thing with
something else? Does initial sync mean helping the mount know where it is?
Using the two or three star alignment? If so, this unfortunately talks me
back to months ago when people told me I won’t need that if I use plate
solving. What does the “solve and sync” button in SGP do? It solves and
then syncs what?
There seem to be a lot more caveats involved in plate solving than people
care to want to talk about. And maybe someone in the industry should. I
fall asleep trying to watch YouTube after YouTube on useless plate solving
introductions.
To an engineer like me it makes complete sense that if I have a telescope
mounts in a piece of rock or bolts to a tree and I have a camera attached
to it, that if I take a picture of a bunch of dots in the sky and tell a
plate solving program what the scale of that image is then that program
could search in a database for a match and tell me if the picture were to
be of stars then the center of it would be this certain RA and DEC. and
then if this were possible, and the tree or rock were motorized and
computerized, I should be able to tell the driving program, "hey, you are
looking at RA1, DEC1 and I want you to move the motoro to RA2, DEC2. And
the program simply does a bit of math and then starts moving the mount.
But no, there is this mysterious “sync” and a few other undocumented
caveats that are so simple that don’t bother anyone else and too simple for
any experts to write about it. I know that ultimately I am going to have to
take my gear out and point to the sky and try to figure it out. But I have
to wait a couple more months for the clouds that are glued to the sky
because of new telescopes people are buying to get unglued.
And what if you have access to a blind solver? I have access to it and I
have not been able to tell the difference and when I ask experienced people
why they are not using it and they opt for something like PS2 they say PS2
is just so much better and easie. It seems from what you wrote that blind
solving has a completely different purpose.
It is high time somebody wrote about plate solving and blind plate solving,
and how they fit between the scope and the mount.
Yes, and yes. Syncing the actual position of the scope with where the software (driver) thinks it is.
You won’t need this. SGPro will be fine with a general one-location sync. That methodology is primarily for visual users not having a laptop nearby.
See above.
Not sure what this means. Plate solving is pretty simple (given that AP itself has a pretty steep learning curve). Given an image and hints (location and scale) a computer will tell you where the real center of the image is located.
The difference of what? A blind solver to a solver? A blind solver is no different than a solver. It just does not need hints to work.
Maybe once you become an expert you can do just this
…right, first thing I am going to do is to publish a tutorial for people
like me.
I am still not sure what the “solve and sync” and the “blind solve and
sync” do in the SGP, with emphasis on the “sync” part.
And what is so difficult about having access to a blind solver when you can
have local ANSVR installed on any computer and no connection to the
Internet is needed?
Hi Fazard, I would’t worry about it too much as SGP platesole works really well. Just start by making sure that your mount is polar aligned as best as you can and everything should work just fine.
Depending upon your mount, most mounts will require you to do some initial sync’s as part of the polar alignment routine anyway, unless you have an obs, then you will only do this once.
I have an eq8 in my obs which is far from perfectly polar aligned and I use eqascom/eqmod and I always start with zero saved syncs point, then just slew to a target & plate solve then slew again after plate solve is finished. Most of the time I just use the auto-centre function.
For me I get the best results if my plate solve exposure is around 10-20 secs, and I tend to stick with the astrometry.net as the solver as it never fails.
A few tips I would recommend:
create a new sequence for each target, e.g. M31, and when you are happy you have the target exactly where you want it, run a second plate solve and when you get the notification window to say it’s complete, then tick the box to save the exact position info into SGP then save your sequence. This will allow you to use the auto center function to great effect, which will allow you to consistently slew back to target and position it within a few pixels every time and if like me you like your sleep, then it allows for imaging automation.
don’t waste time trying to build pointing models, as that’s the whole point of plate solving.
set auto centre retries to 5, and set it to centre to within 25px.
try to make sure your are polar aligned as accurately as possible as this will make a big difference between success and failure.
Thanks, Rich. I am tearing into the manual and want to learn as much of it
as possible. I do have a license for the mosaic module too and I am looking
forward to being able to fully exploit the software and its features.
I still don’t know what “solve and sync” does. Hopefully I can find an
answer to that in the manual. I want to know what “sync” means in this
context and what I should expect to happen when I make that choice.
Hi frarzad, “solve and sync” does exactly what it says on the tin, it solves the position your camera is looking at and then updates your mount and tells it exactly where it is pointing as vs where the mount roughly thought it was pointing at.
So let’s say before the solve, the mount thinks it’s pointing at x, a solve is performed which determines that you are pointing at y, the “sync” bit is where sgp tells the mount that it’s really pointing at position y and not x
That makes a lot of sense and that is what I had expected. Since I use
EQMOD to operate the Atlas Pro, would this reset what EQMOD shows as being
the aiming point of the mount, the RA and DEC when doing sidereal tracking?
Or will the scope module of the SGP just update its own current location.
It updates eqmod, with the correct position. Some people use sync points to build up a pointing model to get better pointing accuracy, but using plate solving negates the need to that especially with the superb auto centre function in sgp.
Farzad, please forgive my limited knowledge, but my understanding of Solve and Sync is as follows; let’s assume that you’ve previously lined up your mount to the pole as best as you can, and then performed a two or three star alignment, this has generated a model of the night sky within the mount software and where the mount is currently pointing.
Now, my understanding of Solve and Sync is that the camera takes an image, and together with some “Hints” like current pixel scale, rotation, and the mounts reported position starts searching for and exact match, which if it’s hints are reasonably on the ball will get a match (a Solve) fairly quickly, this information is then transferred to the mounts software where it temporarily replaces the mount data to provide a precise pointing location (a Sync) which is used for subsequent slews to get to the precise location wanted.
Now given the above, this is why in my understanding you also need to “Undo Sync” on your Handset if you want to refine your pointing model by adding extra calibration stars as its been temporarily superceded by the previous sync.
Anyway hope that helps some, and maybe one of the local experts can clarify my thinking.
I don’t use the handset anymore; I just use EQMOD which does the same thing
when it comes to driving the mount and then some. I haven’t done a three
(or two) star alignment yet and I hope I won’t have to. For the only couple
of times I have been out I have simply slewed my scope to a place visually
familiar and practiced.
Some are saying the the “sync” will synchronize the RA and DEC that a plate
solver has determined with the device that is driving the mount. In other
words the driver (hand controller or EQMOD) will get their internal RA and
DEC updated based on what the plate solver determines and as soon as the
user is satisfied.
I have yet to practice plate solving in real time and as soon as the
weather gets a bit more tolerable. I think plate solving becomes more and
more important as you look deeper and deeper in the skies and when that
happens, plate solving might take more and more time. But we will see.
That is generally what happens, however that behavior is entirely up to your mount. SGP can only send in the values saying “This is very precicely where you’re located”, we don’t get to determine what the mount does with those values. Most mounts will use that data to realign their pointing model. Some mounts have the option to use that as an additional model point. Other mounts just throw it away entirely and do nothing.
I believe your main question was already answered…but just in case:
Solve and Sync - Captures an image, solves the image, then tells the telescope to sync at the center of the solved image.
Blind Solve and Sync - Same as above, but uses a blind solver (as setup by the “Blind Solve Failover” option rather than your primary (likely non-blind) solver.
Blind Solves are generally slower but if your scope is very lost they can generally get you back on track.
This gets a little more complicated depending on what your “Sync Behavior” is set to in SGP. But the general, “normal”, behavior is listed above.
EQMOD is the intelligence behind the Atlas Pro mount which I use and I am
sure it gets along fine with SGP. I am more confident about the SGP as I
also am reading the manual intensely.
One way to get familiar with the Plate Solving function is to just solve images instead of hauling the mount and scope outside. Open the image and right click on it and you are able to solve an image without it affecting anything else. Also, use the control panel to go back and forth with the plate solve setting till you get it right. The sync’ing part of the equation is the natural next step which will work 99% of the time once you have the plate solving thing down.
The developers have made it very easy to do all of this. I can’t imaging doing any kind of astrophotography without it!
I have been doing just what you say, but I have only had success with local
ANSVR. I have not been able to succeed at all with PS2, and solve & sync is
something that I am not able to try at home.
I don’t know if PS2 would work in the field and I don’t know how it would
work there but not at home for me. It looks like it just wants a ton of
information, and when I provide the exact coordinates it still runs for
ever until it times out.
I think PS2 only really works if you know the approximate RA/DEC and scale. If you import a picture with this information in the header it “should” import those numbers into PS2 using the API automatically.
The two times I had issues with PS2 was 1) I had improper focal length / sensor size information entered 2) I tried running PS2 in a virtual environment (sharing the USB port) and for some reason I think the USB connection was messing things up.
Keep on working at it and don’t give up. PS2 is a lot faster than ANSVR so its more practical in the field with time is of the essence.
