Syncing/Align Fundamental Question....


Martin Bonfiore
 

Let's say I wanted to do a three star alignment after powering up the mount pointing to the NCP. 

Case one:  I then do a goto a bright star, I tweak the ra/dec until it is centered and I do a "sync".  Then repeat for two more stars.   

Case two: I power up the mount pointing to the NCP as in case one.  I start a "three star alignment" procedure (as opposed to just goto to a bright star) using the same stars as in case one.  I tweak as before and confirm for that star.  The sequence then leads me through to do two more stars, which I do and confirm. 

Is the internal, adjusted "model" in Onstep any different for these two cases?   Based on reading the onstep docs and forum, I *think* the answer is no, both give the same result, the same internal adjusted model.  

The reason I ask it that it would seem that a "sync" is a fairly simple matter of determining the offset in ra and dec for the given location....or is my thinking flawed...that a sync (and importantly, subsequent "syncs" making more sophisticated changes in the model....more sophisticated than just simple offsets?  


Khalid Baheyeldin
 

Initially, OnStep required that you start an alignment on n stars, then after each star you
should accept the align from an OnStep specific client, e.g. the web interface or Android app.
That was changed to allow Sync to do the "accept align" function implicitly, provided that
an n star align was started in the first place. That opened up completing the align process
from any client that are mount agnostic (e.g. KStars/Ekos or Sky Safari).

To your questions:

Case 1 does not build a model at all, because you did not tell OnStep that you will aligning.
If OnStep is not told that you intend to align, it will not calculate a model at all, based on the
corrections you make, even if you make them.

Case 2 is where OnStep builds a model, and tells you how far off in Alt and Az is your polar
alignment.

Which one you use depends on your needs. In my case, since I use plate solving and then
autoguiding, I don't bother with alignment at all, just a rough polar alignment using the
polar scope on the mount, and off I go.

If you are not autoguiding, then the error relative to the celestial pole will cause errors in
tracking (along with various other things like cone error, leveling, and so on ...)

By the way, Syncs that are done after the alignment is complete (i.e. you exhausted the
n stars) do not affect the model at all. They do refine pointing somewhat near where you
are in the sky though.

I hope that clears up the question in your last paragraph, which is basically "N/A".


Martin Bonfiore
 

Thanks Khalid.  Interesting…. So if I understand that seems to imply there is no way to use plate solving with onstep to do an alignment I.e. build the model.  Is that correct?

 I guess I could do plate solve based syncs on let’s say three stars that I can then subsequently use to do a real align??  


Basically it would seem to be nice to do an align using plate solving so that you don’t have to hunt around to center the alignment targets.  

Or maybe the alternative is to roughly align and then do a goto to the object of interest then plate solve and do a final sync to the object of interest and forget about refining the model….hop close to object, plate solve, then goto to object.  Am I missing something?

 


Khalid Baheyeldin
 

On Sat, Oct 23, 2021 at 03:48 PM, Martin Bonfiore wrote:

So if I understand that seems to imply there is no way to use plate solving with onstep to do an alignment I.e. build the model.  Is that correct?

No.
You can absolutely use plate solving for alignment if you so wish.
Just start an align, and slew to each star, and sync on the solution coordinates.
KStars/Ekos makes that easy because you have various selections on what to do after you solve: Sync on solution coordinates, Slew to Object, or Nothing.

The options will vary with other plate solving software, but there should be a Sync option in most of them.

Note the "start an align" part? That is the key here, otherwise sync will not do anything to the model.
There even won't be a model to begin with if you don't start with that ...

Or maybe the alternative is to roughly align and then do a goto to the object of interest then plate solve and do a final sync to the object of interest and forget about refining the model….hop close to object, plate solve, then goto to object.  Am I missing something?

That is the strategy I use. As a bonus, there is a Solve and Slew option, which perfectly centers the object
within 5 arc second accuracy.

I do that because I can skip the align part, and it takes less time.
I do the polar scope rough align around 30 minutes after sunset, when plate solving is not yet possible.
Then when it is darker, I go about with autoguiding and plate solving.

One workflow is not better than the other, it is just that there is less steps for me outside ...


Martin Bonfiore
 

Ahhh...the light is starting to dawn over Marblehead (a colloquial expression that is used here in Massachusets USA...there is a city on the coast called "Marblehead"..you get the gist..anyway...).  Let me test another, possibly flawed conjecture to test my understanding....within reason, the accuracy of the alignment process has a lot to do with the ability to command a goto and then see the object within the field of view....but it does not have a strong influence on the quality of tracking *if* you have an excellent polar alignment....???


Khalid Baheyeldin
 

On Sat, Oct 23, 2021 at 04:09 PM, Martin Bonfiore wrote:
Let me test another, possibly flawed conjecture to test my understanding....within reason, the accuracy of the alignment process has a lot to do with the ability to command a goto and then see the object within the field of view....but it does not have a strong influence on the quality of tracking *if* you have an excellent polar alignment....???
Like almost everything, the difference between practice and theory is the difference between theory and practice.
[That is, they should be the same, but often they are not]

If you have perfect polar alignment, then tracking should be perfect, in theory, and you would need to do an alignment, because there is nothing to compensate for.

But there are other factors that affect pointing, and/or tracking, including: cone error, balance, periodic error, or refraction (some of these OnStep can compensate for, but not all).

Oh, and doing an alignment does not correct tracking, only pointing. Although OnStep has full compensated tracking, which corrects to a certain degree, it is not perfect, because there are other things it cannot account for.

I did try periodic error correction, and full compensated tracking, but I ended up with autoguiding, and live with its quirks. Things are just way too complex with the consumer level gears that we have.


Martin Bonfiore
 

Khalid,

Thanks.  I am heading for plate solving assisted alignment and ultimately guided tracking. 

I must confess that the more I read about "alignment" and the more confused I become.  If I understand correctly, Onstep's alignment using say, three or more stars, generates a model that accounts for errors such as cone error. 

When I read about other so-called alignment tools/software, it is not clear to me that their alignment routines acccount for cone error (for example)...that they can achieve highly accurate gotos but only if there is no cone error i.e. they assume a cone-error free mount (through mechnical adjustment or construction).  I think I can see that if you have a cone-free mount and do an excellent polar alignment then a one star "align" is all you need to have the system understand the spatial relationship between the mount coordinates and the celestial coordinates.  One of the beauties of Onstep would seem to be that its deals with that mechanical imprecision by some kind of warping/transformation??

The one alignment tool in particular I was studying was connected with the Ekos software.  I assume you use the onstep alignment, not the alignment feature in Ekos?  Bottom line is that I am chasing my tail trying to understand the interplay between onstep alignment and an alignment tool such as part of the Ekos software?  

I have been using Stellarium but I just took a look at Kstars and think I might give it a try.  It certainly looks like it would require less CPU bandwidth than Stellarium and per your comments, can be better integrated into the mount control.


Khalid Baheyeldin
 

On Sun, Oct 24, 2021 at 05:41 PM, Martin Bonfiore wrote:
I must confess that the more I read about "alignment" and the more confused I become.  If I understand correctly, Onstep's alignment using say, three or more stars, generates a model that accounts for errors such as cone error. 
Yes.
And the alignment and model building only happens at the start of the session (from when you tell OnStep to start the alignment process, and slew to the first star), and ends shortly after the last start has been synced/aligned.
OnStep takes some time to calculate the model, and refine it using some iterative calculations.
I recall it was a minute or so on the Blue Pill, longer on the Arduino platforms.

From that point on, there is no alignment active or anything. Only the calculated corrections in alt, az, and some cone error (If I remember correctly).

When I read about other so-called alignment tools/software, it is not clear to me that their alignment routines acccount for cone error (for example)...that they can achieve highly accurate gotos but only if there is no cone error i.e. they assume a cone-error free mount (through mechnical adjustment or construction).  I think I can see that if you have a cone-free mount and do an excellent polar alignment then a one star "align" is all you need to have the system understand the spatial relationship between the mount coordinates and the celestial coordinates.  One of the beauties of Onstep would seem to be that its deals with that mechanical imprecision by some kind of warping/transformation??
Many of the alignment algorithms are based on Toshimi Taki's equations and BASIC code that was published back in 1989.
They do include cone error, which he calls fabrication error.  The original page is now lost to the bit heaps of years gone by, but you can still find the source code here.

OnStep was initially based on these same equations, but Howard rewrote those a couple of years or so ago to what they are now.

The one alignment tool in particular I was studying was connected with the Ekos software.  I assume you use the onstep alignment, not the alignment feature in Ekos? 
I don't use either alignment. As I said, a rough polar align using a polar scope along with autoguiding gets me where I want with the least time and effort. Previously, I tried various methods to refine polar alignment, and they were just too time consuming (and I am impatient). So autoguiding cut the time needed to get setup, and saves dark time.

Bottom line is that I am chasing my tail trying to understand the interplay between onstep alignment and an alignment tool such as part of the Ekos software?  
They are two different paradigms.

Ekos alignment is a tool to help you get better polar alignment. So it goes through its steps, then gives you a result and expects you to use its various methods (legacy, or the newer method) to correct for those errors by using the alt and az knobs on your scope. Ekos DOES NOT provide logic to correct pointing or tracking based on the errors it shows. I don't think that Ekos has cone error. Or maybe it is there, but hidden from the user interface.

OnStep's alignment takes that one step further: it calculates the errors, remembers them, and does active corrections to  compensate for them in pointing when doing Gotos (and somewhat in tracking, though it is not perfect, and probably can never be, not too many people using that feature).

I have been using Stellarium but I just took a look at Kstars and think I might give it a try.  It certainly looks like it would require less CPU bandwidth than Stellarium and per your comments, can be better integrated into the mount control.
Stellarium is CPU intensive because it prioritizes 'looks'. It wants a realistic view of the sky.
One way to reduce its CPU load is to change its config.ini. Find maximum_fps and set it to 3, and minimum_fps to 1.

But KStars/Ekos has better overall integration, build in plate solving, sequence capture, and so on. It is just a very pleasant experience overall, and well thought out. Its planetarium is not the best, but still functional.


Martin Bonfiore
 

Khalid,

Thanks for the additonal detail and explanation.  The mention of Taki brings back memories of my first foray into astronomy a few decades ago.  I had an HP 41C programmable hand held (sort of hand held) calculator running a Taki algorithm that I used to generate alt/az coordinates for my manual setting circles on my homemade dob mount.  Cumbersome as all get out but seemed like magic back then.

Off to put Stellarium on the shelf and climb another learning curve with Kstars/Ekos.  With my growing appreciation of plate solving and guiding and then add on imaging software, better integation of the work flow seems well worth the learning effort  and having less "pretty" planetarium views.