Difference between solving/syncing with application and with API

I am using an external program to solve and sync. This program uses the SGP API to solve and then uses the ASCOM driver of the mount to sync the mount with the RA and Dec from the API call. This, however, is always slightly off. In this instance the RA and Dec that the SGP API has produced are the same as what the mount shows after the sync has been completed.

However, when I use the SGP application and connect the camera and mount through that the result produced from SGP’s solve is not what the mount displays after syncing; it is also not a constant difference between different areas of the sky. This does though actually sync the mount to the correct location.

Between the two solving methods the application and the API produce the same RA and Dec for the same location in the sky.

So is there a way to know either what the modifications SGP does between producing an RA and Dec and syncing the mount to an RA and Dec, or is there some way to get the API to produce the coordinates after the modifications have been done?

Thanks,
Mitchell

Out of curiosity, what application are you using?

Is it an epoch difference? SGPro always display solve results in J2000 and maybe your mount is showing its position in JNow?

The only modification we perform on solve results is for epoch conversion.

Thanks for your response Ken.

I am part of a team that is writing a custom java software to control the mount to do research.

We are using an AstroPhysics 1600GTO, would you happen to know if this uses a different epoch than SGPro?

Thanks,
Mitchell

If the difference is arcminutes then it’s probably an equinox issue: jnow vs j2000. But if it’s less than an arc minute it may be more subtle and due to nutation. In that case it would be hard to get two systems to agree.

Do you really need the two systems to agree exactly?

If you could create an image if the star field you want and tell sgp to centre on it - it should succeed. But the ra dec values it thinks are there may be a bit off.

As an aside the issue here is really equinox and how it’s calculated. Not epoch.

Frank