74 replies to this topic

[ButterFly]

The person who wants this can write a little piece of code for ASCOM to convert from moveaxis commands to the RA and Dec rate commands which get forwarded to the mount. I am a little curious what the standard says about how to treat these for alt az. The reason I’ve advocated to expose the fine rate functions is to allow programs like NINA to run mount models so they don’t have to be proprietary. Also for the adaptive tracking thing.

If we did have access to the mount's alignment, that would be great, but without it, one has to assume that an EQ mount is perfectly polar aligned, or that an alt/az mount is perfectly level; and that both are perfectly fabricated.  As time goes on, one could build a model based on the deviations from expected behavior, and adjust accordingly.  That's not much different than just using moveaxis in the first place!

 

Unfortunately, there is no standard set of alignment parameters, so sending such information would be far outside the scope of a generic interface like ascom.  However, nothing stops a developer from taking the mount's reported RA/Dec, however obtained, and using those as "encoder counts" to build their own model on top of the mount's model.  They are just angles after all, same as what an encoder would report, taking care for side of pier and the like.  The developer would then back transform the desired RA/Dec (or rate) into the mount's reported RA/Dec.  The issue then becomes whether the mount can actually deliver accurately to the desired levels of precision.  It is surprising how well a lowly AVX does with CPWI in terms of positioning.  It would still take a whole lot of points to get a decent representation of PEC with just the model alone, but there's separate PEC training for that.

[555aaa]

There’s two different ideas here, so maybe I’m not understanding your reply.

Idea 1.

If a mount has variable tracking rates but not moveaxis, you can write a piece of code that takes in moveaxis and outputs axis rates commands, they are functionally equivalent. This piece of code has to act like a hub. Probably there is a simple way in alpaca / python to do this.

Idea 2: mount makers should support variable rate tracking commands, because by doing so we could make mount modeling and unguided tracking an open source functionality. Client imaging programs can also implement adaptive guiding or other means as well as automatic model updating. There is a standard for models.

These are separate ideas. The only thing relating them is that in satellite tracking it’s better if the reported position is accurate (is modeled ).

[ButterFly]

There’s two different ideas here, so maybe I’m not understanding your reply.

Idea 1.

If a mount has variable tracking rates but not moveaxis, you can write a piece of code that takes in moveaxis and outputs axis rates commands, they are functionally equivalent. This piece of code has to act like a hub. Probably there is a simple way in alpaca / python to do this.

Idea 2: mount makers should support variable rate tracking commands, because by doing so we could make mount modeling and unguided tracking an open source functionality. Client imaging programs can also implement adaptive guiding or other means as well as automatic model updating. There is a standard for models.

These are separate ideas. The only thing relating them is that in satellite tracking it’s better if the reported position is accurate (is modeled ).

I can only assume you are attempting to paraphrase what I wrote, so I'll address them individually:

 

 

Idea 1.

If a mount has variable tracking rates but not moveaxis, you can write a piece of code that takes in moveaxis and outputs axis rates commands, they are functionally equivalent. This piece of code has to act like a hub. Probably there is a simple way in alpaca / python to do this.

Variable tracking rates alone are not always enough.  Sidereal, lunar, and solar are variable tracking rates, but they may not offer the necessary granularity to implement a proper RightAscensionRate from a moveaxis.

 

I was responding to:

 

 

The person who wants this can write a little piece of code for ASCOM to convert from moveaxis commands to the RA and Dec rate commands which get forwarded to the mount.

 so I assume there was a proper moveaxis, with sufficient granularity.  I'm not sure where you read "variable tracking rates but not moveaxis" from that, but sure, that's not there, so stop reading that into it.

 

Yes; the code would have to "act as a hub".  You could do it as a pure ascom driver if you want, taking another deficient ascom driver as input.  You would have to register that new non-deficient driver with COM.  You could also do it as an alpaca server, if you wish, but then you're programming a server.  Same principle - take the deficient driver as input, fix the deficiency, then spit out proper results - whatever "proper" means to you.

 

 

Idea 2: mount makers should support variable rate tracking commands, because by doing so we could make mount modeling and unguided tracking an open source functionality. Client imaging programs can also implement adaptive guiding or other means as well as automatic model updating. There is a standard for models.

Way off the mark on this one!  There is no standard for modelling, so one can't access a random mount's model in a generic way.  If you want to be sure of what the mount's model is, build your own model, then use that.

 

[ButterFly]

Here are some pieces I certainly agree with:

 

 

Idea 1.

... variable tracking rates [with sufficient granularity] ... [and] moveaxis ...are functionally equivalent. 

 

Idea 2: mount makers should support variable rate tracking commands ... .

 

Part of the issue is that even if a mount says something like "I can support a moveaxis command with rates between 0 and .75 degrees per second and rates between 0.9 and 5 degrees per second", there is still no way of knowing how fine those input rates can be.  Is an input rate of 0.6557 going to be any different from an input rate of 0.66, or even 0.67?  One really has no way of knowing from anything that gets spit out of axisrates.

 

Various protocols do in fact specify the granularity.  ZWO, for example, lets on input axis rates as a multiple of sidereal, and actually tells you that the number is good to two decimal places.  See Command: “:Rvnnnn.nn#”.  So 7.89065x is the same as 7.89x, or 7.90x.  With other serial protocols, if it doesn't say anything about granularity, it doesn't say anything about granularity - that's all that one knows.  The rest is testing, or guessing.

 

So I'll go even further with the above portion of Idea 2, and say that mount makers should also tell you how granular those rates can get, and how they round.  That certainly limits any feedback you're sending to it, and knowing which way it's rounding helps avoid flip-flopping.
 

[555aaa]

Tpoint is the standard for modeling because the terms have been published. If you buy PRISM or TheSkyX you will generate the same model terms. PointXP produces very similar or identical terms. There’s about seven main terms you need for unguided imaging. Once you have these, plus atmospheric data, you can compute the tracking rate adjustments for RA and Dec and send them to the mount. I wrote a piece of code to do this already for any mount.

[ButterFly]

The vast majority of amateur astro mounts don't use TPoint, or anything like it. That's very far from a standard.

[Bob Denny]

I am a little curious what the standard says about how to treat these [RA and Dec rate commands] for alt az. 

No difference, nothing special. An alt/az mount tracks equatorially, holding the RA and Dec constant (or it's useless for astronomy right?). An applied rate causes a secular change in RA or Dec at the given rate. It's up to the mount controller to translate to alt/az motions to accomplish this. Or did I misunderstand? 

Edited by Bob Denny, 06 April 2025 - 11:13 AM.

[Bob Denny]

Tpoint is the standard for modeling because the terms have been published. If you buy PRISM or TheSkyX you will generate the same model terms. PointXP produces very similar or identical terms. There’s about seven main terms you need for unguided imaging. Once you have these, plus atmospheric data, you can compute the tracking rate adjustments for RA and Dec and send them to the mount. I wrote a piece of code to do this already for any mount.

Add-on pointing models are limited to correcting for slew destination.

 

TheSky uses T-POINT which is a professional standard, and it not only provides slew destination correction, but also dynamic pointing corrections while tracking, taking into account mechanical flexure as the mount follows the apparent motion of the sky. Its author Patrick Wallace consults to professional observatories including Keck. Software Bisque has an exclusive license to T-POINT for commercially sold mounts. Many more than 7 "terms" are estimated and modeled to accomplish this.

 

Astro-Physics and Planewave also have their own pointing and tracking correctors, independently developed, which do the same thing and with "terms" appropriate to their construction and optic assemblies. The corrections are applied dynamically from within the "inner loop" of the mount controller, improving both pointing and tracking. Planewave uses absolute encoders, and Astro-Physics can optionally use encoders. They virtually eliminate the pointing and tracking errors of the mount, leaving only the mechanical flexure of the optical assembly and instrument chain (camera, focuser, filters) to model and correct for. 

 

I went to the PRISM site and the Help link is broken so I can't be certain, but I don't think it integrates T-Point because PRISM is not a telescope control system it talks to mounts via ASCOM or "native" commands. Also Alcor-Systeme would need to license T-POINT from Software Bisque. Thus it cannot apply dynamic flexure corrections while tracking.

 

For tracking satellites, dynamic flexure correction is desirable. However, for tracking over a short arc (orbit estimation etc.) you can probably get away without it. Where it comes into play is with optical (laser) communication where the satellite needs to be tracked over a large arc, where mechanical flexure becomes significant. 

Edited by Bob Denny, 06 April 2025 - 11:50 AM.

[ButterFly]

 

For tracking satellites, dynamic flexure correction is desirable. However, for tracking over a short arc (orbit estimation etc.) you can probably get away without it. Where it comes into play is with optical (laser) communication where the satellite needs to be tracked over a large arc, where mechanical flexure becomes significant. 

 

 

That "dynamic" is the biggest limit of better and better pointing models for satellite tracking for professional setups.  We really don't need to go that far with our setups.  Even the biggest, heaviest, and floppiest things are going to leave ample enough room on a chip to get the job done.  Worst case, you're looking at subs from the main camera every so often and comparing it to the auxiliary cameras, for differential dynamic flexure.

[Bob Denny]

That "dynamic" is the biggest limit of better and better pointing models for satellite tracking for professional setups.  We really don't need to go that far with our setups.  Even the biggest, heaviest, and floppiest things are going to leave ample enough room on a chip to get the job done.  Worst case, you're looking at subs from the main camera every so often and comparing it to the auxiliary cameras, for differential dynamic flexure.

This would be true for "rigs" that have "wide" field of view. Unfortunately, many have a narrow field (less than 15 arcmin) and this stuff becomes significant. I'm just pointing out the potential issues. 

[555aaa]

I have PRISM and TheSkyX and PRISM has the same Tpoint terms as TheSkyX. PointXP is very similar. The reason is that if you actually want to physically model where the terms mean something you're going to end up with the same basic terms which are a couple of offsets, the two polar misalignment terms, the optical collimation term, and the axis non-perpendicularity term. You can then add two flexure terms. The other modeling approach is to abandon any link to the physical world and use a fit to observed values, which can be expressed in harmonics or any number of mathematical representations.  It's very useful to use the physical approach because the values are actually diagnostic of something that's happening in your system which you can improve.

 

The thing you are talking about in terms of licensing is the code that generates the model coefficients from a set of observations. That's proprietary. But the math behind the model isn't because it's just the way the physical world works. So anyone can consume the output of PRISM or TheSkyX or whatever proprietary tool there is to generate both pointing and rate corrections.

 

In terms of satellite tracking, having a mount that accurately reports where it is is important. And to make this whole approach work, there has to be a way to communicate to external software (the software collecting the sample points for modeling) when modeling is on and when it's off, because to make the model it has to be turned off but when you are controlling the scope via an app NOT for modeling it has to be on, just like you need to know the epoch and if refraction is corrected.

 

The satellite tracking code doesn't need access to the model at all, but it needs to know if the positions being reported are J2000 refraction compensated, Jnow compensated for refraction, or not compensated. If we are talking about blind tracking systems here, you need the reported position accurate and timely enough so that the error is much less than the field of view of the system.

 

ETA: I was watching one of the skytrack video and I see that it has its own modeler which is basically an arc track modeler. It does a good job of showing how valuable modeling is.

Edited by 555aaa, 07 April 2025 - 12:20 PM.

[555aaa]

No difference, nothing special. An alt/az mount tracks equatorially, holding the RA and Dec constant (or it's useless for astronomy right?). An applied rate causes a secular change in RA or Dec at the given rate. It's up to the mount controller to translate to alt/az motions to accomplish this. Or did I misunderstand? 

OK I understand the intent. 

 

So out of curiosity, when skytrack is using an alt az mount via ASCOM (as in the OP's question), is it using the reported alt and az as the error term when it drives moveaxis rates? Or is it using RA and Dec reported. Because moveaxis is going to apply to alt and az rates, not ra and dec rates.

[bosh60]

OK I understand the intent. 

 

So out of curiosity, when skytrack is using an alt az mount via ASCOM (as in the OP's question), is it using the reported alt and az as the error term when it drives moveaxis rates? Or is it using RA and Dec reported. Because moveaxis is going to apply to alt and az rates, not ra and dec rates.

When SkyTrack connects to a mount via ASCOM and detects that it is Alt/Az, it calculates the satellite rate of movement in terms of Alt/Az and uses MoveAxis (as well as adjusting the rates to close any current gap between satellite position and mount position). 

[Bob Denny]

The thing you are talking about in terms of licensing is the code that generates the model coefficients from a set of observations. That's proprietary. But the math behind the model isn't because it's just the way the physical world works. So anyone can consume the output of PRISM or TheSkyX or whatever proprietary tool there is to generate both pointing and rate corrections.

Thank you for the clarification. I didn't know this. It makes sense.

 

I was unaware that PRISM can inject rate corrections into a non-Alcor mount. I also was unaware that TheSky can inject rate corrections into a non-Bisque mount.  Thanks for that info as well.

 

And thanks for all of that other info. It's actually really interesting.

[ButterFly]

This would be true for "rigs" that have "wide" field of view. Unfortunately, many have a narrow field (less than 15 arcmin) and this stuff becomes significant. I'm just pointing out the potential issues. 

If the difference between static flexure (scope stopped and pointing somewhere, as can be modeled easily) and dynamic flexure (scope moving and pointing somewhere else, as can be modeled with much more difficulty) is one the order of arcminutes, it's probably better to not construct the telescope out of rice noodles, or to at least not cook them first.

 

For professional systems that are acquiring maser payloads, the difference between the two can matter quite a bit.  Arcminutes' worth of noodling is not tolerable in a system like that, or in amateur systems either.  No one is getting arcminutes' worth of difference between dynamic and static flexure.

[Bob Denny]

If the difference between static flexure (scope stopped and pointing somewhere, as can be modeled easily) and dynamic flexure (scope moving and pointing somewhere else, as can be modeled with much more difficulty) is one the order of arcminutes, it's probably better to not construct the telescope out of rice noodles, or to at least not cook them first.

 

For professional systems that are acquiring maser payloads, the difference between the two can matter quite a bit.  Arcminutes' worth of noodling is not tolerable in a system like that, or in amateur systems either.  No one is getting arcminutes' worth of difference between dynamic and static flexure.

LOL, but "inexpensive" scopes are frequently long focal length (narrow field) and mechanically weak and shaky. 

 

Douglas George's Law: More money yields more data per unit time. 

[555aaa]

Thank you for the clarification. I didn't know this. It makes sense.

I was unaware that PRISM can inject rate corrections into a non-Alcor mount. I also was unaware that TheSky can inject rate corrections into a non-Bisque mount. Thanks for that info as well.

And thanks for all of that other info. It's actually really interesting.

you are right, both PRISM and TheSkyX won’t send rate corrections to non proprietary mounts but I wrote a piece of code that does this for you. So you take the model terms and copy them to this piece of code, which is an ASCOM client, and it connects to the mount and injects (sends the corrected rates) for you, and this code could be in any tool, provided that the connection to the mount is via a hub or via ASCOM remote.

Edited by 555aaa, 08 April 2025 - 02:06 PM.

[Bob Denny]

Very cool!! Does this tool read the mount's RA/Dec, convert to local (Alt/AZ) and then use RightAscensionRate and DeclinationRate to make the tracking adjustments? If so that's a brilliant idea!!! 

 

I just looked at your web site. Wow! I noted that you mention Python to Alpaca via ASCOM Remote. I wonder if you know about our >Alpyca Python package<.

Edited by Bob Denny, 08 April 2025 - 04:49 PM.

[555aaa]

Very cool!! Does this tool read the mount's RA/Dec, convert to local (Alt/AZ) and then use RightAscensionRate and DeclinationRate to make the tracking adjustments? If so that's a brilliant idea!!!

I just looked at your web site. Wow! I noted that you mention Python to Alpaca via ASCOM Remote. I wonder if you know about our >Alpyca Python package<.

It reads the mount RA and Dec and uses the site location and time to build the astrometric constants used in the ASCOM astrometry transform functions. It uses those to perform the refraction compensation (which needs alt az) and then the rate compensation is calculated by determining the relative change in modeled sky position between a pair of sky points and then calculating the axis rate to null out that change. For example, you take the current sky location, model it, and then model the point ten minutes in the future. Say that point is ten arc seconds north of the correct location. That means the correction rate for declination is one arc second per minute. Same applies for a difference in ra (difference on hour angle minus the delta sidereal time), that becomes the RA rate correction. The code is on GitHub, I can share it for non commercial

Edited by 555aaa, 08 April 2025 - 08:41 PM.

[555aaa]

I do know about alpyca but it was after.

[Bob Denny]

I do know about alpyca but it was after.

But anyone can use it to talk to your mount from any Platform. It has been deeply tested for compliance. Just so you know in case someone you know wants to know about it. Anyway  your "stuff" looks great!!

[ButterFly]

The satellite tracking code doesn't need access to the model at all, but it needs to know if the positions being reported are J2000 refraction compensated,

 

 

It reads the mount RA and Dec and uses the site location and time to build the astrometric constants used in the ASCOM astrometry transform functions. It uses those to perform the refraction compensation (which needs alt az) and then the rate compensation is calculated by determining the relative change in modeled sky position between a pair of sky points and then calculating the axis rate to null out that change. For example, you take the current sky location, model it, and then model the point ten minutes in the future. Say that point is ten arc seconds north of the correct location. That means the correction rate for declination is one arc second per minute. Same applies for a difference in ra (difference on hour angle minus the delta sidereal time), that becomes the RA rate correction. The code is on GitHub, I can share it for non commercial

Even though it's not needed, this is exactly how knowledge of the model can help.  It allows one to make prospective corrections, rather than solely reactive corrections.  If you know how the mount's reported RA/Dec will change with a to-be-sent motion (here, displacement over time), you can know, beforehand, how to correct the to-be-sent motion to better get to where you want to go.  Of course, as always, if you are relying solely on reported positions, then the reported positions had better be accurate.

 

Refraction is indeed the biggest issue, getting worse and worse closer to the horizon.  Unless the model was developed very shortly before the pass, there really is no guarantee that formerly modeled refraction is the same right now as it was when modeled.  It helps a lot to have something actually looking at where the telescope is actually pointing, or a proxy for that such as a guide scope.  The LDT, for example, can acquire data as low as five degrees above the horizon!  You have refine pointing that low.

[555aaa]

But anyone can use it to talk to your mount from any Platform. It has been deeply tested for compliance. Just so you know in case someone you know wants to know about it. Anyway your "stuff" looks great!!

Thanks. Yes we started using Python with ASCOM remote before there was Alpyca. BTW you could add the same model to tracking rate correction into Alpyca

[555aaa]

Actually Bob now that I think of it you can do this whole satellite tracking thing in Python / Alpaca / Alpyca. I have some Python code that generates the sky ra, Dec, alt, and az positions from a satellite TLE, by time. The Python code I have uses Skyfield so it’s only like 100 lines or so. It’s easy.

[Bob Denny]

Hi -- I want to keep Alpyca strictly as a Python package providing the ASCOM Alpaca API. 

 

BTW, I just released a new version of Alpyca - 3.1.0 with some convenience features and a change to discovery that avoids netifaces (which has choked on some platforms and is abandonware). You can see the changes here in CHANGES on GitHub.