I'm interested in exploring the Ekos Align mount model tool, but unsure how to verify that my Celestron CGX-L mount/hand controller interface supports Ekos sync updates in the way that's required for use by this tool. It's also not quite clear whether the CGX-L has an internal pointing model (residing either in the HC or mount proper), or is only implemented local to proprietary Celestron PWI software. Do any KStars/Ekos Celestron CGX mount users use the Ekos Align pointing model tool? If so, I'd be happy to hear your comments on usage/performance. Thank you!

p.s. My interest in the pointing model tool doesn't take anything away from how great plate-solving is. I use plate solving during acquisition and would never look back. What I'd like to do is explore minimizing tracking/guide errors via improved pointing modeling and see what kind of model terms and error residuals result after PEC, good polar alignment, and accurate location/time are set.

Sync works, if it didn't plate solve and sync would not work.

Strictly speaking the mount model is in the HC (or in CPWI if you use that) but as you can only connect through the HC it doesn't matter where it is.

I don't use the Ekos mount model, in fact I don't use any mount model, I set up, do a quick align and use solve and sync to get good pointing. One thing to bear in mind is that because the Ekos model is using data from the mount, through the HC, the setup in the HC needs to be consistent. I would start by doing an alignment reset in the HC and then doing a uick align. AIUI your mount has home switches and that should help to get a good starting position.

I don't think this will help with tracking/guiding, the mount model manages accurate pointing and position reporting but not how tracking works. PEC might help with tracking.

Chris

Hi Chris,

Thanks for responding and pointing out my neglect of PEC; It was assumed, but I've edited my original post to add this. I'm trying to be precise to understand how this all works (it's confusing enough as it is). I'll disagree (amicably) to a couple of your points.

First about pointing not helping tracking/guiding. The only reason why guiding is necessary is because of inaccurate pointing modeling (beyond PEC). A perfect pointing model would eliminate the need for guiding altogether; any attempt to guide under perfect pointing would result in "chasing the seeing". Thus, any improvement in the pointing model should directly translate to better tracking and smaller guiding residuals until the limit of seeing is reached.

I also think it's probably not precise to say that Ekos uses mount information through the HC (even though I agree with all your comments on consistency of HC startup procedure). Doesn't Ekos only have a one way command feed to the HC? Wouldn't it be more precise to say that Ekos derives mount position from solved camera images, and then just commands a new mount position via sync command through the HC?

The real issue I'm trying to understand is the sync command's relation to Celestron's CGX-L mount pointing model, and where that pointing model actually resides. First, It's not clear that a working sync command (adjusting a mount position to a plate solved position) also directly implies that a pointing model error term is captured as a result. There's an extra step required that may or may not be done. Also, this business of where the pointing model resides is confusing. It's not clear where the Celestron pointing model actually lives. Is it in really in the HC or CPWI? This was the basis for my original question and one I'm still sorting out. If it lives in the HC, then there's some hope...

I think we have different ideas of how pointing and tracking works. I see them as different things where perfect pointing makes a slew super accurate but after the slew has finished the mount tracks by moving the Ra axis with no further reference to pointing. The Ra and Dec that is generated using the perfect mout model will show the position changing but this does not affect the tracking. I think that will be what the reality is.

It's possible this is not the case. In the case of some Celestron HCs it is possible to set them in a tracking mode where the mount model is used to adjust the tracking rate in both Ra and Dec to give more accurate tracking. I don't know about the Ekos alignment but I'm not convinced it has the control available to do this.

The only position information that the Celestron GPS driver provides is Ra and Dec. I know this because I have been involved in writing the Celestron GPS driver. The Ra and Dec that the HC provides is generated by the mount model in the HC and this will as a minimum use the mount time and position to convert the mount axis values to Dec and Ra.

[quote="dmsummers" post=48380
The real issue I'm trying to understand is the sync command's relation to Celestron's CGX-L mount pointing model, and where that pointing model actually resides. First, It's not clear that a working sync command (adjusting a mount position to a plate solved position) also directly implies that a pointing model error term is captured as a result. There's an extra step required that may or may not be done. Also, this business of where the pointing model resides is confusing. It's not clear where the Celestron pointing model actually lives. Is it in really in the HC or CPWI? This was the basis for my original question and one I'm still sorting out. If it lives in the HC, then there's some hope...[/quote]

The mount Sync command does not change the pointing model. All it does is make the current position the same as the sync position.

If you are using the HC then the pointing model is in the HC. This will be the case for the Indi Celestron GPS driver because it connects to the HC and uses commands to the HC to get it's pointing information.
If you are using CPWI then the pointing model is in CPWI. This is because CPWI just uses the HC to pass through it's commands to the mount which provides axis data that CPWI uses to generate it's mount model. I don't think that Indi can connect to CPWI so how CWPI behaves is irrelevant to Indi.

Chris

Hi Chris,

re: "I think we have different ideas of how pointing and tracking works", I think we're just getting sideways due to inconsistency in how folks use the terms "pointing model" and "mount model". We've gotten a bit off-track to my original post, but hopefully we can quickly get back on track. Let me try again to convince you (off-topic) on pointing's relation to tracking error, then I'll come back to summarize what I see as the on-topic issue. I'll refrain for a moment from using the term pointing model, and just use "sky model" to describe a model that doesn't know about mount imperfections.

Here's my assertion: A perfect sky model will command a perfect mount to a position that results in zero errors for acquisition AND tracking. Conversely, a perfect sky model used with an imperfect mount will result in positional errors during acquisition AND tracking. All mounts are imperfect. One might think that in this imperfect case, a sync command to fix acquisition would end the story. However, while the tracking start position would be (almost) corrected by a sync, the mount's imperfections remain, conspiring against tracking too (more slowly, but just as surely). The imperfect mount is just not able to move as perfectly as commanded by the sky model to guide any better than it can acquire due to those imperfections. The tracking error is smaller in magnitude because the size of each time interval's move is smaller, but it's there and it would accumulate (to the same magnitude as an acquisition error) if not corrected by guiding. This is why programs like TPoint and PointXP exist. They model a mount's underlying imperfections and pre-adjust commanded positions to account for those imperfections so that the mount can (almost) achieve what is desired. Folks tend to call the result of those programs "pointing models", but that's not quite consistent with what other people talk about when they use the same term to describe simple/perfect sky pointing modeling (i.e. without knowledge of mount imperfections). For the trivia minded, did you know that TPoint can create pointing models from just guiding residuals? They produce the same model as an acquisition error approach (assuming the same sky coverage in each approach). Hence my argument that acquisition AND tracking errors are caused from the same problem (imperfect mounts).

Back to topic: I started this thread when I saw Ekos' "Mount Model", in the align tab, with some metrics and concepts I recognize from TPoint and PointXP. I then wondered if I could use the "Mount Model Tool" to build and employ a pointing model as TPoint users would use the term...mount imperfections included. The caveat expressed about the mount's pointing model needing to use the sync left me unsure about my mount. I also didn't see any classical pointing error modeling terms I expected to see in the Ekos tool. Hence the posted question. The Celestron CGX-L mount manual makes no reference to any mount model error terms saved in the HC (excepting PEC). The Celestron "Pointing Model" (term loosely used) exclusive of CPWI software, appears to be just a simple sky model (lat/lon/time basis; no mount modeling terms excepting PEC). For users of CPWI software, there IS a capability to capture acquisition errors and create a mount model along the lines of what TPoint users would be familiar with, but the model runs internal to CPWI software. The HC and CPWI software have likely implemented very different pointing model fidelities. I hazard to guess that CPWI mount modeling exists precisely because the HC and mount don't have similar abilities. If true, that's unfortunate as many older tools (e.g. Argo Navis) implemented this long ago.

My best guess at present is that the Celestron HC has a very limited mount model (not as TPoint users would think of, only a simple sky model). Another guess is that Ekos align mount model has ability to measure and display acquisition errors that COULD be used to build a higher fidelity mount model, but may not actually do so in a way that can actually change mount performance. Finally, although CPWI does have high fidelity mount modeling capability familiar to TPoint users, I don't wish to use it. I'm trying to completely avoid CPWI in favor of KStars/Ekos. If Ekos can't build and effect a high fidelity mount model, I'll probably do a one-off exercise using CPWI and then assess how much improvement might be achieved. It's academic really; Guiding will work fine, even if it could work less hard with a true mount model in effect. It would only be interesting to know the magnitudes and types of mount errors seen in any modeling exercise.

Finally, for those interested in the Ekos capability who might not use it or remember it, see this post:
indilib.org/forum/ekos/2002-exciting-new...delling.html?start=0

I've not found debate an effective way to determine how mounts behave. Experiment is much better.

While a perfect mount will track the stars, or any other object, perfectly no such mount exists. Real mounts have errors in pointing and tracking. The size and type of the errors will vary depending on a number of factors, largely how much you pay and how much trouble you take.

The mount model in the HC is limited, but not as limited as you believe. I'll leave you to deduce what modelling terms it uses; they are, I believe, all accessible to an enquiring mind. There is one important term you did not mention.

Patrick Wallace , who developed TPoint, has a lot of information about the basics of telescope pointing on his web site.

I know nothing about the Ekos mount model.

Chris

There is no "Ekos Mount Model" per se, all Ekos does is solve & sync. It leaves it up to the mount to do whatever with that information. Now, INDI EQMod driver has a mount model that can be configured in the driver itself. Other INDI drivers utilize INDI Alignment Subsystem which supports a basic model and a couple of plugin-based advanced mount models.

Chris & Jasem, Thanks for the latest input. This info is consistent with where my thoughts were converging. I haven't yet found any plugin-based advanced mount models for the Alignment Subsystem (I did find the math plugins), but I'm still learning to effectively traverse the code so it's all good exercise.

Yes this is very much mount dependent. Some mounts, like my Losmandy G11, have a very complex pointing model capability built into the mount. Some mounts, like EqMod compatible ones, don't have that capability in the mount, so that is built into the INDI driver instead. There are others that can only do a 3 star alignment. And there are some that can do just a 1 star alignment.

It would probably be possible to create an Ekos pointing model with a bit of work, but I'm not even sure that is a good idea because then if the mount is like my Losmandy, then there could be issues because the Mount would be trying to build a pointing model and so would Ekos, so in the end, the parameters might come out VERY strange and could produce bad results, particularly if they both try to apply the same correction at the same time.

One option might be to duplicate something like the EQMod pointing model and apply that to any mount that can't do what my Losmandy can do. Or maybe have it as an option for any mount driver, and have it be something you can turn on if needed. But I do think this would need to be done in INDI, not Ekos.

The Ekos mount model tool just automates a series of plate solves to help a mount model get built. It doesn't have anything to do with the actual model.

Yes, after playing with the simulator env, I see how the tool only generates one or more plate solve points, graphs and tab displays the offset errors, and can output errors to a spreadsheet for external consumption (but that's about it). I also wondered after Jasem's post why EQMod should be the home for a more sophisticated mount model as opposed to it being more generalized and available where possible/desired as you suggest. Maybe at some point, the outputs (errors) of the "mount model tool" can be integrated with a more generalized version of the EQMod mount model for wider consumption. Even if other mounts can't accept external mount model outputs, having a better analysis tool would be very helpful to understand the types of errors present in their mounts (as opposed to just the numerical values of the errors).

Getting external model adjusted positions into a mount is a whole different story. If a mount only accepts RA/DEC command positions (as is the case with the current Celestron driver), it's a no-go as the FITS header and display position wouldn't match the known target position. As a use case, it's interesting that CPWI can externally model the mount and provide adjusted positions that don't confuse the mount, but the INDI driver doesn't have access to the same interface (or it's just not implemented). This discrepancy might deserve further investigation by those of us who use Celestron mounts.

Just to wrap this topic for now, I wrote to Celestron tech support about whether ascom sync commands update mount modeling and received a reply today. Their answer is that the HC interface does not expose details of the mount model, so of course the ASCOM driver can't take advantage. From their reply, it doesn't seem that they intend for a config extension via the ASCOM HC interface to support this.

HOWEVER, Celestron did say that several requests have been made for allowing ascom syncs to affect mount modeling, and they ARE investigating adding this capability to the CPWI interface. They mentioned CPWI software's configuration button (mount config settings tool). A new check button along the lines of “ASCOM Sync adds alignment reference” is being actively considered. Once/if a CPWI SW update occurs, I take it to mean that a one-time setup with CPWI's interface to set that mount config parameter would then allow ASCOM syncs to work as needed for mount model point additions. Ekos' "mount model tool" and associated plate solving support will then become an effective means for improving Celestron mount pointing performance. Error processing might be slightly awkward as any necessary sync point errors (needing removal) would require use of CPWI or the HC directly, but a happy/careful path would allow users of KStars/Ekos to almost transparently buildup, analyze, save, and reuse a nice mount model for pointing. Let's hope this happens!

The iOptron CEM120 EC2 has duel hi-end encoders and Software Bisque's TheSky software has incorporated advanced sky modeling with the CEM120EC2 to account and adjust for polar alignment error as well as changes in atmospheric refraction. This allows the mount to track in both RA and DEC unguided at very high precision. I assume EKOS's mount modeling is not compatible.