Sync does not move cursor in TheSkyX with ASCOM scope

I’m not sure if this is working as designed - but when I do a plate solve/sync with Elbrus in SGP - I don’t see the telescope cursor jump when also connected to the mount with TheSkyX. In other applications, when the mount is sync’d I would see that reflected in TheSkyX. As it is, SGP appears to be able to center objects well and it knows where things are - but when it centers an object and syncs, the cursor in TheSkyX is some distance off mainly in RA.

I noticed this in 2.3 and the 2.4 beta. I am using TheSkyX with a cge-pro mount and ascom driver. In TheSkyX I am connected to it as an ASCOM mount. So both SGP and TheSkyX are independently connected to the ASCOM mount driver.

I tried changing settings in Elbrus for J2000 and for ASCOM vs. DDE mount - but nothing seems to help. Is there a setting I am missing? If it plate solves and actually syncs the mount - then all apps should see the telescope pointing suddenly in the right direction. I couldn’t find a J2000 vs. JNow button in SGP itself.


Hi Frank, I think we will need the exact versions of everything involved.

I’ve just tried it wth CdC and TheSky connected to NexRemote using the ASCOM driver and there’s no problem. A sync in either affects both - and the HC.
This is using HC version 4.21 where the sync is a HC function. Earlier versions of the HC don’t have Sync as a RS232 command and in this case the sync is done in the ASCOM driver. It may be that different driver connections have their own sync.



I’ll just summarize that I am using the handcontrol and not nexremote - and it has very recent firmware. I think a key distinction is that when I do the sync it is only via the plate solve system - with a fresh image and plate solve via Elbrus. So my question is at the level of SGP and Elbrus and what they are doing - and if they even send a sync command to the ascom driver.

Note that I used to use a different imaging app that would do plate solves and syncs - and everything was fine with TheSkyX and ASCOM. But this is SGP and Elbrus.

So I can proceed to debug this in more detail and I suppose I can turn on tracing in the ascom driver or something - to see if it is getting a sync message. But I thought I would ask here first since I may be missing a setting somewhere. I am also puzzled by the somewhat hidden settings in Elbrus regarding a mount being DDE or ASCOM. I think the default is DDE. Is that what it should be with SGP? It didn’t seem to help either way. Does the J2000 setting matter in Elbrus?


Yes, SGP will send a Sync to the mount whenever “Solve and Sync” or “Solve and Sync Blind” are clicked. You shouldn’t have to worry about any changes in Elbrus as Elbrus does NOT do the sync. The sync is called through SGP. You shouldn’t even have your mount connected in Elbrus.

You’re correct that if the sync happens that it should update all connected applications fairly quickly.

SGP does not have a JNow or J2000 option. We currently pass the coordinates through from the plate solver directly to the mount. So both your mount and solver need to be set to the same epoch.


Thanks for the reply Jared. Well that is weird because the centering process seems to work in SGP/Elbrus - and when I tell it to plate solve and sync - it doesn’t give an error - but the cursor does not move in TheSkyX.

Is there a way to do a plate solve on an image - and then just say “sync the mount to this image center?” I can only seem to sync by requesting a fresh image, plate solve, and sync. Maybe you don’t want people to sync on an old image.

If the Epoch of the solver matters - then I guess I should uncheck “J2000” in Elbrus - because I think the celestron driver wants JNow. Anyway - its setting should matter based on what you said - and one is right while the other is wrong.

Well - this is weird. It should be a clear night here so I will test more. Unfortunately I am having horrible hardware/firmware issues with my focuser and I cannot do fully automated test runs - which I want to do.


Can you post a SGP log? Do you see a dialog that pops up saying that the solve and sync was successful? You should see something like this:

No, like you mentioned there should be no need/want to do this on any “random” image. It should be fresh. I think the right answer is to figure out what’s happening with the Solve and Sync process and go from there.


Also it may be worth watching your ASCOM driver rather than TheSky. It’s up to the connected application to poll the device to get the coordinates. So it could be that TheSky isn’t polling it all that often or ever? What happens if you just slew the mount? Does the position update in TheSky?


Yes - slewing and everything is fine and there is little latency. It may be that there is an offset due to an Epoch conflict. Well - I will look into it in more detail. It sounds like everything should be working as I expected - which was my main question. Everything should be looking sync’d after a sync.


Sorry - I didn’t see your earlier message. Yes - I did see a happy dialog saying the solve was good and the scope was sync’d.

I dug around and found the log from last night. It has a lot of failure messages about the !&$#@ focuser, but it also has what look like happy statements about solving and syncing.

I may be unusual in using MG for imaging - so I have no connection to other autoguide software which also makes me different.

Let me see if I can attach a log

sg_logfile_20141214210559.txt (732.2 KB)

OK - I have more info. The cursor does move on sync - but it is offset from the true center. So this looks like an Epoch issue.

Attached is an image of an area near the Pleiades. The rectangle shows the true location of the image based on the star pattern, and the yellow circle cursor is where the cursor moved to after sync.

The Elbrus window says the center is at 3:48:19 and 23:46:03

In TheSky, the coordinates of that cursor are
3:48:22, 23:45:51 in JNow
3:47:26, 23:43:10 in J2000

The center of the image in TheSky is approx:
3:49:20, 23:48:14 in JNow
3:48:25, 23:45:34 in J2000

So it looks like Elbrus is outputting JNow and ASCOM or something is interpreting them as J2000.

Actually this is consistent with what I saw in another imaging utility. It had the option of outputting either J2000 or JNow - and what worked best with a celestron mount was J2000 - which surprised me.

I tried both Epoch settings in Elbrus and they had no effect that I could see.

It looks to me like the celestron driver is interpreting inputs as J2000 but I’m not sure. If all mounts are expecting JNow and this is an exception - then I guess the driver should change. But if some are J2000 and some are JNow, then I think SGP should allow a choice.

I could be missing something - but I think this is what is going on.


The Celestron driver is expecting positions in JNow. There’s an EquatorialSystem property that returns EquatorialCoordinateType.equLocalTopocentric so an application could check and adjust.

I think that if you sync a position to it’s J2000 position you will get approximately J2000 positions close to the sync position but not a long way away.

I managed to get this working by specifying the position in SGP in J2000 and plate solving in J2000. The first slew moved to the J2K position which was incorrect because the mount used JNow. The plate solve gave the J2000 position of that JNow position and the sync did a crude conversion of the mount coordinates from JNow to J2000. The correction slew then moved to the J2000 position and the subsequent plate solve showed the position to be correct. Hope that’s not too confusing.

BTW, I’m thinking of adding an option in the Celestron ASCOM driver to change this. Positions used by the driver would be J2000 (or B1950 or J2050) and the driver would convert to and from what the mount needs. It may help with this sort of thing.

As we get further from 2000.0 we are having to be more aware of this, I’ve seen the frequency of reports of pointing error because of this increase a lot in the last year or so.


1 Like

I think that if I’m reading you correctly, Elbrus/SGP output JNow and the ascom driver also works in JNow - and the problem is that TheSkyX is assuming the coordinates from the mount are in J2000 - and that is where the discrepancy lies. Is that correct?

I guess my main question is how this can be solved - and if it affects other mounts. I think you are saying it can only approximately be solved by having SGP output J2000 - because the ascom driver does in fact expect JNow. So that isn’t the real solution.

It seems like TheSky needs either to check the info it receives because the Epoch is specified in the driver - or the driver itself needs a switch to accommodate old apps that assume J2000. Unless I am misunderstanding something.

For my imaging session last night - I had to slew the scope to a target location by visually compensating for the offset - which is not ideal. I don’t think there is a better method when using the mouse to point the telescope - but at the same time, SGP is designed to use images to provide aiming information - and I think that is all self consistent and would work. But when it does point the telescope there - the cursor will be off.

For my use case, I rely on a manually oriented FOVI to frame the image and then I point the telescope to the center of that image with the mouse. So things really need to be precisely in sync to hit the target with the desired framing based on the FOVI - and to also hit the OAG guide star with a given rotator angle.


SB are the best people to give accurate answers about what epoch TheSkyX uses and how it handles data from a mount it is connected to. From a quick check using the ASCOM driver I think the display uses JNow but it looks as if the coordinates output by TheSky ASCOM driver are J2000.

Unfortunately the EquatorialSystem in the TheSky driver says they are Local Topocentric. I’m going to need to change that. Do you know if your applications check the EquatorialSystem property?

SGP doesn’t care. All it does is pass positions through. Elbrus used to be J2000 but may have an option, I haven’t checked.

A search of the SB forum just says the epoch used is mount dependent. The displayed coordinates are both JNow and J2000. When you enter in coordinates manually - you can specify the epoch. In an obscure dialog of the telescope setup in TheSky there is something about atmospheric correction - and it has an entry for the epoch - but even though I am allowed to enter in a date, the dialog doesn’t seem to work for me and I think it requires TPoint for it to operate. When I reopen the dialog, the date I entered is forgotten.

It seems as though they have it hard-coded for each mount. If the celestron mounts used to be j2000 and now they are jnow - this may be a casualty of the change. I can go ahead and ask on their forum - but I am not paying for their updates so I wouldn’t get any changes if they did make the change.

For me in MetaGuide - I don’t insist that when I ask the mount to move east the mount moves east. I just figure out what it does and accommodate the actual behavior. I think the sensible thing in this situation - which other apps and drivers do for Epoch issues - is allow a choice and have a sensible default for maximum flexibility.

For now, if sgp users with celestron mounts notice this in a planetarium software they should see if that software allows setting the epoch of the mount to jnow - and if they can’t - I don’t think there is a workaround and the cursor will just be off.


It sounds like this isn’t an issue with SGP and the epoch. It sounds as if the issue is more of a problem between TheSky and the Celestron ASCOM driver. Even if we allowed a choice in SGP this still wouldn’t fix the issue within TheSky.

It sounds like you have 2 options to fix this:

  1. Set the epoch to J2000 in the Celestron driver
  2. Set the epoch to JNow in TheSky.

Unfortunately it sounds like neither of these is possible…? Being able to change the value in SGP wouldn’t affect how TheSky reads the data from the mount. The mount would still be reporting JNow which TheSky would be reading in expecting J2000.

Moving forward SGP will read the epoch from the scope and the solver and translate between the two. Most of this implementation is complete but it still won’t fix this issue.


I’ve looked at log files of the Ra/Dec positions read by TSX from a Celestron mount and those reported through the TSX scripting and they are slightly different. I’m currently in email conversation with the Bisques about this. They say they use topocentric for the mount positions and that matches what I see. My guess is that they transform to J2000 for the scripting.

I was wrong, the positions haven’t been transformed from topocentric to J2000, they remain approximately topocentric.

But I found that the positions reported by the Celestron driver to TSX are a little different to the positions that TSX reports using it’s scripting interface. I’m seeing a difference of 20.75 arc seconds in Ra and 34 arc seconds in declination. It’s not huge but could be enough to affect how SGP does it’s centring.
I’m also not sure how the sync command that SGP will send to TSX through the scripting interface and TSX will pass on to the mount will be affected.

I’d try to minimise the number of layers that are used if possible.

I’m not sure what you are saying - topocentric refers to the vantage point and things like aberration. J2000 refers to the equinox. The tiny differences you are seeing sound like aberration and nutation - which are separate from the equinox in use. Those terms can be ignored compared to the huge error here caused by different coordinate systems (equinoxes). The Epoch would include physically dynamic things like proper motion, which are also small, along with nutation and so forth. And the aberration would depend on the user’s velocity - which would be different on the planet’s surface vs. in the center. You should also be able to see Ra/Dec vary during the day when using non-topocentric coordinates - and they vary during the year with topocentric - both due to aberration. I think TheSky even handles parallax for nearby stars.

I don’t like copying things directly from one forum to another - but I searched again in the bisque forum (you have to be a member, which I am) and there is a note from Daniel Bisque in 2010 that says explicitly - TheSky works in J2000.0 coordinates - as do NexStar compatible mounts. When I used Maxim, it has a switch that allows synching the mount either in JNow or J2000. The default is J2000 and I explicitly switched it to JNow because I thought that was correct - but the cursor in TheSky was wrong. So I tried J2000 and it worked fine.

In summary - I assume TheSky is expecting the celestron mount to work in J2000 and that is incorrect - for current mounts anyway. The correct fix is to change either TheSky or the celestron driver to allow specifying the equinox. At the same time - it would also work for SGP to allow an option for JNow or J2000. During a sync operation, the coordinates are just passed down the pipeline and handed to the mount - so this would work fine as long as the values don’t get munged. Many apps including Elbrus allow specifying the equinox used - and I think that flexibility is a good thing for all apps and drivers to support.

The main issue here is the equinox of the coordinate system. Not the vantage point (topocentric) or the physical Epoch (proper motion, nutation - etc).


I got this by email from Matthew Bisque:

On 16/12/2014 20:30, Matthew L. Bisque wrote:

TheSky uses topocentric coordinates for mount control.


On 16/12/2014 21:37, Matthew L. Bisque wrote:

Again, TheSky uses topocentric coordinates for mount control. There is no conversion as you are suggesting.

This seems pretty clear, If you want clarification you will have to take it up with SB.

Recent Celestron mounts report coordinates as JNow. They didn’t in the past but now they do.

There’s nothing more I can do.

Topocentric is separate from the equinox in use - and it is the equinox that is the problem - not the viewpoint. No solution is possible at the +/- 30" level if the exact details of the plate solver are not specified - but the plate solver does specify the equinox and even allows an option for J2000 or JNow - and if that were handled properly this gross error would go away.

Both notes from the Bisques sound correct - TheSky uses topocentric - fine. TheSky uses J2000 equinox - fine. TheSky expects NextStar mounts to want J2000 equinox - not fine for recent mounts and the recent celestron ascom driver where it has switched to JNow - and a big error results that impacts usability with planetarium programs expecting J2000.

Technically if there are celestron mounts out there that are J2000 and some are JNow - and if TheSky connects to them without the ascom celestron driver - then a change in the driver would not help. Celestron mounts can behave either as J2000 or JNow. But most if not all nowadays would be JNow.

I suggest that SGP allow specifying the equinox used when syncing the mount - and this would largely solve the problem. SGP would need to do the conversion - with no need to bother with topocentric. It is a simple transformation. In addition - SB should allow TheSky to regard the mount as either J2000 or JNow - because such a thing should not be hard-coded per mount in the first place - since it could change - and it did. So I will contact SB directly to make sure things don’t get lost in translation.

In the meantime, celestron/TheSky users will see this discrepancy and should be aware the problem is known and there is currently no workaround other than to visually offset all mouse clicks for a slew to a particular sky location - and to get used to the cursor being offset from the true location.