I now think the problem is in SGP/Elbrus. I now think ASCOM and TheSky are both just passing the coordinates along and assuming they are JNow equinox.
The real problem (my current guess) is that Elbrus is outputting the solution in J2000 equinox - and that is what is used for the sync. That explains everything. ASCOM/TheSky happily sync to those J2000 coordinates as if they were JNow - and that is where TheSky says the scope is pointing. But the center of the image has those coordinates correct only for J2000.
This doesnât explain why Maxim works better when syncing using J2000 coordinates - but maybe there is a similar confusion.
So please check what equinox Elbrus is using. The default is J2000 for Elbrus - apparently.
Just to be clear on the geometry and magnitude of this problem - the center of the precession axis is in Draco at around 18h +65d. The sky rotates around that point every 25000 years, so 90 degrees away the stars are moving 0.86 arc-minutes per year - amounting to 13â in 2015 or nearly 1/2 moon width.
As it happens, in the pleiades example I show above, the region is nearly 90 degrees away from the precession pole - and precession is nearly at maximum rate there - resulting in a nearly 13â offset of the cursor from the image center. Some parts of the sky will have a much smaller impact - so it has an insidious element to it.
Iâm pretty sure I tried it both ways and it had no effect. My impression was that the various settings in the separate elbrus window did not affect what sgp received by dde or whatever. I could have made a mistake though. I tried pushing buttons everywhere I could and did not see a change - but I may have missed something.
It is cloudy here and hard to test things without a real sky.
OK - I was able to do some more testing and I think it makes sense and SGP does indeed need to precess the values it gets from Elbrus because it appears SGP only gets J2000 values from Elbrus.
There are settings to control what equinox elbrus uses to sync the telescope - but elbrus isnât syncing at all - sgp is. And sgp uses the values it gets from elbrus - and none of the settings in elbrus appears to change the values sgp receives, in terms of the equinox. It appears only to send j2000.
I believe the most common default that sgp should use for syncing is JNow rather than J2000. But ideally it would either allow a setting for the particular mount - or it would use the right one for the mount.
I also realized why I had a similar confusing issue in maxim. It is a very similar situation. I think Pinpoint provides J2000 coordinates to maxim just as elbrus provides j2000 to sgp. When you sync in maxim there is a button asking for j2000 or JNow. To my surprise, J2000 works best - and that made me think TheSky expected them in J2000. But instead - the button in maxim means âwhat equinox are these ra/dec sync values in?â And since they came from PinPoint they are J2000 - and so maxim will precess them to jnow if you use the setting j2000 - and everything works.
If you look around the web you will find a lot of similar confusion regarding coordinates being passed around for other apps. The key thing is that it doesnât matter at all what equinox is used by the sender or the receiver - but the receiver must know the equinox the sender used and precess as needed.
I donât know if there is a similar issue with other plate solvers used by sgp - but sgp does need to do the right thing. This isnât just a cosmetic issue of the cursor being offset in TheSky. If sgp is forcing a sync with a big offset due to the wrong equinox - it will reduce the accuracy of the GoTo when the object is changed from that location.
Frank, can you describe the exact setup you use to do these tests please. Iâd like to see if I can work out what is happening and need more than your conclusions.
This is what I can come up with:
SGP doesnât do anything with the epoch. It takes the numbers it is given.
This is how it works:
SGP sends a slew to the target position, the mount slews there.
The mount reports the position it goes to as the target position but because of various pointing errors it is actually looking at a different position.
SGP takes an image and passes it to the plate solver.
The plate solver solves the image and returns the position.
SGP sends a sync to the mount giving the position reported by the
plate solver. That should cause the mount to report itâs position as
the position the plate solver reports.
SGP sends a slew to the target position. The effect of the sync is
that the mount should now point at the correct position, or at least
closer to it.
This does not involve the epoch at all. SGP is using the plate solver and the mount sync to adjust the position but doesnât know where these positions come from, or what they are.
The plate solver must use a particular coordinate system and so the plate solve and sync will force the mount to use that coordinate system, at least locally.
If the target position uses the same coordinate system as the plate solver then everything should be fine.
If the target position is in a different coordinate system then you will see a consistent error of the difference between the two systems.
So if your plate solver uses J2000 use J2000 for the target position and if your plate solver uses JNow then use JNow target positions.
There is one other possibility and that is that the sync command isnât working. If sync is working then after a sync the position reported by the mount should be the same as the sync position.
Iâve checked that with the application connected to TheSkyX and TSX connected to the mount using the ASCOM Celestron driver. Sync is fine, after a sync the position is reported as the same as the sync position.
Are you seeing this? You originally mentioned that sync does not move the cursor in TSX. Iâm using the current build of TSX but if you are using an old version this may be where the problem is.
As long as ascom isnât doing anything with the coordinates - everything is consistent with the explanation I have provided and ascom is not in the loop on this problem. If ascom is doing anything weird with the coordinates please let me know.
I have already indicated here that the cursor does in fact move on sync - but it moves to the j2000 coordinates. Once it is solved and syncâd there - the cursor will no longer move because it is already syncâd (incorrectly). I had hard information from David Bisque in the bisque forum that he thinks nexstar mounts use j2000 - and that would explain the problem - but apparently that is old information and incorrect - even though it is from the horseâs mouth. It never ever mattered at all what equinox TheSky used or if it is topocentric or not - what matters is what equinox it thinks it should use when interacting with a mount and doing the needed precession.
The other red herring was the fact that maxim wants to plate solve a celestron mount with j2000 coordinates - but that is an ambiguity of the user interface and in fact is correct. It isnât asking if the sync should happen in JNow - it is asking if the coordinates themselves are jnow. They came from pinpoint, so they are j2000 - and apparently it knows to do the actual sync in JNow. That appears to be the situation with sgp and elbrus - but the coordinates do not get precessed before the sync as they should.
As long as ascom is not changing the values it is given in a sync, it is out of the loop here. SGP apparently does not do any special handling of the equinox and it needs to for best treatment of the mount model, since it is doing the sync - not Elbrus. But if it only uses images to determine target locations - and it uses syncs to refine the pointing - then it can work nearly perfectly in a different equinox from the mount. It solves the reference image in j2000, it points in j2000, it centers in j2000, and it syncs to the fresh image in j2000. Users would never know this was happening unless they looked at the actual coordinates the mount was pointing to after the sync - and realized they were j2000 rather than what the mount wants - which is JNow.
But if you sync with an offset in one part of the sky to force a different equinox, the pointing will be affected in other parts of the sky - so it should be avoided even if you arenât using a separate planetarium program.
My only need on the ascom side is to confirm that it is not altering the coordinates on a sync. If it is, that opens another can of worms, but the basic principles are pretty simple in terms of matching equinoxes on every handoff of coordinates. I am ignoring nutation, aberration, and parallax - which can also be handled properly with enough care, but are ok to gloss over with a sync because they are small, unlike precession.
I wanted to bump this topic because it has prevented me from doing plate solves in my work with SGP - and plate solves plus auto-centering were key features that led me to purchase SGP.
The simple form of my request is that SGP allow syncing a mount either with JNow or J2000 equinox. It would be fine for me to ignore the role of nutation, aberration, and parallax at this stage - but they could be included later. I am not clear how many mounts want to be syncâd in j2000 - if any - so a simple solution would be to change the current default from J2000 to JNow.
One of the best overall write ups I have seen for getting these coordinate transformations handled properly between a device and a planetarium program is the manual for sidereal technologies:
That is the operations manual draft 1.1 for Sidereal Technology. They use the terms âcookedâ and âfully cookedâ to describe the various degrees to which coordinates can be transformed and how they make sure they are handled consistently. They talk about planetarium programs tending to work with J2000 - and that may not apply to TheSky - but it doesnât really matter as long as all devices and apps know the nature of the coordinates being exchanged - and do the proper transformations accordingly.
I am away from my equipment for a few weeks, but hope to continue working with sgp and exploiting the plate solving ability - while at the same time interacting with the telescope via TheSky.
We have this filed away. We are currently in the Beta phase for 2.4 and this means that we will only add new features (improve existing ones) if they present no / very little risk of regression. This change is a bit more invasive. We have some ideas on how we want to handle it, but they will need to wait until the first 2.5 beta for experimentation.