Connections via usb hubs do cause all sorts of problems, often erratic problems at that. I would eliminate the hub and connect to your mount directly from a usb port in your pc. This is quite critical for reliable overall performance I would suggest.
As I said I’m not familiar with Celestron mounts, however, as an experiment I would select another mount start option so you do not have to carry out the two star alignment as this is contrary to the standing SGP advice and could well be the cause of your problem.
From reading your post, I think you are using the ‘Centre On’ in the Target Settings when target starts, ie SGP takes a plate solve frame before slewing to the target and then centring, is that correct? Have you tried the ‘Slew and then Centre’ option, ie slew to target location and then plate solve and centre? If you have, is the mount behaviour the same?
Have you tried posting in a forum for Celestron users?
Now that there is a longer thread running, it may well be useful to post up your recent log that shows the strange centring behaviour (I realise you have done this some time back in your previous post) and the developers may well take a look. There are other knoweldgeable users who may well also look and help.
I’ve been following this thread with interest, but haven’t posted until now because I am still a bit of a newbie. However, I have a few comments which might help. Firstly, I am a CGX user and have been running SGP for about a year. I recognise some, but not all of Lawrence’s problems. Sorry in advance for this being a bit long-winded.
I have a good PA and a 2-star plus 3 calib star alignment which I did about 3 months ago (I’m pier mounted in an observatory). I use a USB hub (scope mounted) which carries everything, Camera, guide cam, filter wheel, focuser and Mount (which is connected into the Nexstar+ handset and not the mount itself) - so I have a single USB feed from hub to laptop (running Win 10 and SGP 2.6.0.23). I use the POTH hub to connect to CGX and my dome. I use Stellarium (usually) for target selection, copying and pasting the target from Stellarium into SGP. I use PS2 and local ANSVR for plate solve.
POINT 1. Check that you have the latest Celestron CGX ASCOM driver (I can find a link if needed)
POINT 2. Check that you have the latest CGX Firmware
My system was hopeless before I installed both of these.
My start-up routine is as follows:
Launch SGP, POTH, Stellarium on the laptop
Power the USB hub (on the mount) and all other kit (but not the mount itself)
Hook up the hub cable into the laptop and then plug each piece of kit into the hub
(assuming a new target), select New Sequence with Profile
Connect each piece of kit in SGP Sequencer (except POTH Hub) checking functionality as I go (camera, filter wheel etc)
Switch on the Mount, press enter twice (to go to switch position), set date, time, etc. and Use Last Alignment.
When the handset reports CGX Ready, connect the mount (handset) into the USB hub.
Connect POTH in SGP.
Paste target coordinates from Stellarium into target in SGP Target Settings and populate Target Name
(IMPORTANT) ‘Use Save Sequence as’ to save current settings and create a completely new Sequence
I’m now ready to go.
Use Slew Now in SGP Target Settings
At this point the mount/dome will grind around. I then do a quick frame and focus to check the camera, and run auto focus.
If all looks ok I then do Centre Now (which finally gets me to where Lawrence is having trouble). The first pass of Centering/solving reveals pointing errors of several hundred pixels - I think this is because my original star alignment is a bit off - but this is fine. My second (and occasionally third) pass of centering brings the target to within 20 or thirty pixels (I have it set for 4 attempts and to get within 30 pixels). I can now set up guiding and proceed to image capture.
POINT 3 I think there is a bit of a bug (from way back) in SGP to do with the whole business of naming and saving sequences. I haven’t got to the bottom of it but sometimes I find that if I create a new sequence and fail to save it early on using Save Sequence As, then I sometimes have a subsequent problem where the sequence has correct name but somehow does not have correct content. This has manifest itself in incorrect names given to saved images and to slewing to the wrong target location.
I go through the somewhat pedantic process because I have found it reliable. It avoids the problem of (sometimes) a piece of kit failing to be recognised by the laptop and necessitating a complete restart, and also the problem of corrupted sequences throwing everything off.
I said it would be long winded, but I hope it helps.
That response is a bit telling - and may be part of the issue. Is there an Epoch setting in the ASCOM driver? If SGP and the mount are assuming different Epochs, they will not converge.
The other gotcha concerns pointing models and sync method. The pointing methods have been explained before and can conflict with sync commands (especially if sync commands are used to build the model in the first place). One possibility to side-step the ASCOM synch command is to try one of the other SGP sync options, like one of the offset methods.
Further to my post above, I don’t think epoch is a problem. SGP uses J2000 whereas the CGX uses Jnow, but something somewhere does the conversion for you (probably the CGX ASCOM driver). I’ve read in the log (cant’ remember if it was the SGP log of the CGX log a statement along the lines of "slew to (J2000) coordinates … mount requires Jnow… Doing conversion"
I don’t have any problems with this. Even copying and pasting J2000 from Stellarium into SGP works fine.
I’ve done a bit of reading and may have stumbled upon the problem (yes, it’s raining here). One of two possibilities. Firstly, if you are slewing to the target using CdC, and then Centring on target within SGP Target Settings, have you checked that the CdC coordinates and the SGP coordinates in Target Settings are the same? If not, then CdC will take you to one point, and then SGP will centre you on a different point.
The second possibility (which is more likely, but my be wrong if my understanding of how SGP works is wrong), is that whatever coordinates you paste (or type) into SGP Target Settings will be assumed by SGP to be J2000 coordinates. When you hit Centre Now these coordinates are given to the mount, which, as I illustrated above, will convert them into JNow. So if you inadvertantly paste (or type) JNow coordinates into SGP and these are interpreted by the mount as J2000 and subsequently converted then you will end up being centred in the wrong place.
It’s still raining.
I was about to respond to Barry when the forum software told me to reply to others rather than keep responding to Barry so I thought that I had better comply …
I have posted the log file from a few days back in the hope that you can instantly spot from the file, exactly what went wrong (and goes wrong every time). My search for “terrible” produced no results.
Meanwhile Barry, I shall go through your detailed replies and take notes for the next session,
I’ve been following this thread with interest, but haven’t posted
until now because I am still a bit of a newbie. However, I have a few
comments which might help. Firstly, I am a CGX user and have been
running SGP for about a year. I recognise some, but not all of
Lawrence’s problems. Sorry in advance for this being a bit long-winded.
I have a good PA and a 2-star plus 3 calib star alignment which I did
about 3 months ago (I’m pier mounted in an observatory). I use a USB
hub (scope mounted) which carries everything, Camera, guide cam,
filter wheel, focuser and Mount (which is connected into the Nexstar+
handset and not the mount itself) - so I have a single USB feed from
hub to laptop (running Win 10 and SGP 2.6.0.23). I use the POTH hub to
connect to CGX and my dome. I use Stellarium (usually) for target
selection, copying and pasting the target from Stellarium into SGP. I
use PS2 and local ANSVR for plate solve.
POINT 1. Check that you have the latest Celestron CGX ASCOM driver (I
can find a link if needed)
POINT 2. Check that you have the latest CGX Firmware
My system was hopeless before I installed both of these.
I have been checking; my USB hub carries only the camera(s), not the
mount, which plugs in directly to the laptop. I understand that Carte du
Ciel acts like a hub as well. I do the rest as you do. I now have a
good alignment (proved by its recent use!).
My start-up routine is as follows:
Launch SGP, POTH, Stellarium on the laptop
Power the USB hub (on the mount) and all other kit (but not the
mount itself)
Hook up the hub cable into the laptop and then plug each piece of
kit into the hub
(assuming a new target), select New Sequence with Profile
Connect each piece of kit in SGP Sequencer (except POTH Hub)
checking functionality as I go (camera, filter wheel etc)
Switch on the Mount, press enter twice (to go to switch position),
set date, time, etc. and Use Last Alignment.
When the handset reports CGX Ready, connect the mount (handset)
into the USB hub.
Connect POTH in SGP.
Paste target coordinates from Stellarium into target in SGP Target
Settings and populate Target Name
(IMPORTANT) ‘Use Save Sequence as’ to save current settings and
create a completely new Sequence
I’m now ready to go.
Use Slew Now in SGP Target Settings
At this point the mount/dome will grind around. I then do a quick
frame and focus to check the camera, and run auto focus.
If all looks ok I then do Centre Now (which finally gets me to where
Lawrence is having trouble). The first pass of Centering/solving
reveals pointing errors of several hundred pixels - I think this is
because my original star alignment is a bit off - but this is fine. My
second (and occasionally third) pass of centering brings the target to
within 20 or thirty pixels (I have it set for 4 attempts and to get
within 30 pixels). I can now set up guiding and proceed to image capture.
I can easily change the parameters to do this. My ultimate question
remains as to why SGP doesn’t apparently like being almost spot on. Only
analysis of the log file can identify this …
POINT 3 I think there is a bit of a bug (from way back) in SGP to do
with the whole business of naming and saving sequences. I haven’t got
to the bottom of it but sometimes I find that if I create a new
sequence and fail to save it early on using Save Sequence As, then I
sometimes have a subsequent problem where the sequence has correct
name but somehow does not have correct content. This has manifest
itself in incorrect names given to saved images and to slewing to the
wrong target location.
I go through the somewhat pedantic process because I have found it
reliable. It avoids the problem of (sometimes) a piece of kit failing
to be recognised by the laptop and necessitating a complete restart,
and also the problem of corrupted sequences throwing everything off.
I said it would be long winded, but I hope it helps.
@Buggs that does read like quite a convoluted process and I guess one you’ve arrived at after trial and error.
When I used to use a SW NEQ6 or after that an Avalon Linear FR I too could have connected to the mount via the handset, however after reading many posts of the issues that this causes, like many users I simply connected directly from the PC to mount.
With this direct connection you could leave the USB cable plugged in and simply power all your kit up at once, ‘Connect All’, no need for any alignment that might corrupt plate solving and slew to your target.
Sorry for my ignorance of all matters Celestron but is this not possible with Celestron mounts? Do you have to connect via the handset?
@Buggs </u/buggs> that does read like quite a convoluted process and I
guess one you’ve arrived at after trial and error.
When I used to use a SW NEQ6 or after that an Avalon Linear FR I too
could have connected to the mount via the handset, however after
reading many posts of the issues that this causes, like many users I
simply connected directly from the PC to mount.
With this direct connection you could leave the USB cable plugged in
and simply power all your kit up at once, ‘Connect All’, no need for
any alignment that might corrupt plate solving and slew to your target.
Sorry for my ignorance of all matters Celestron but is this not
possible with Celestron mounts? Do you have to connect via the handset?
Yes. The connection is in the base of the handset. Works fine. That is,
I don’t plug in the other end (handset cable) until the scope is powered
up, otherwise it takes a feed from the laptop USB!
Thanks for your comments Barry. However, in part you have misunderstood (or I didn’t explain it clearly). With the CGX (and possibly other Celestron mounts), there are two USB ports, one on the mount itself and the other at the base of the handset. The mount port is used solely with Celestron software (such as CFM), while the handset usb port is the one you use to connect the mount to third-party software, such as SGP. I’ve read some posts where people have been unable to get a CGX to talk to SGP and it’s because they are connected to the wrong port. I connect this to a (expensive) hub in order to minimise the number of cables and hence the chance of drag.
As for my pedantic process, I’m sure you are right in that I can probably plug everything in and do a ‘connect all’. However, as a relative newbie I experienced many glitches along (up) the learning curve through various combinations of faulty leads, missing drivers, and operator error. So I devised a step-by-step approach which basically said "step 1, test, if ok proceed to step 2, etc’. I would advise all beginners to do this as it becomes fool-proof and teaches a lot about this dark art.
I want to get to the point of ‘fully remote-controlled, all-night (safe) imaging’ and hopefully I am close.
I saw on a cloudy nights post that there is now a driver for both USB ports: "PWI 1.1.0 Beta 1 creates an ASCOM driver named Celestron PWI. I am able to connect TheSkyX Pro directly via the CGX-L USB port using the ASCOM PWI driver, but only when the PWI software is running. I hope to get enough clear skies this week to be able to see well this work.
_ _ One thing I did notice however, the Celestron PWI ASCOM driver does not allow TheSkyX to set tracking rates or jog the telescope, and although the PWI software allows to stop/start tracking it offers no other rates. Without the ability for TheSkyX to monitor or control tracking, I suspect there may be some issues with Closed Loop Slewing and Tpoint runs.
_ _
_I am looking forward to the ability to bypass the HC."
The other thing that occurs is the use of POTH. One normally uses a hub if the ASCOM driver itself is not a hub. Most of the mounts I have used have ASCOM drivers which act as hubs in their own right. Might be worth checking out as it eliminates further complications.
As for trying to center - if the mount has backlash it is doubtful that you will center perfectly. Some mounts, like my Avalon, always do a backlash compensation slew after the main slew but I don’t know about others.
Look at the specific eqmod advice regarding stored models and there have been quite a few posts from Losmandy G11 users (maybe other mount users too?) about this issue over the last few years.
buzz, a few comments.
I got quite excited when I explored PWI - it looked very promising and created a good alignment. However, try as I have I can’t utilise this alignment when using SGP and the handset usb connection - also, I can’t get SGP to talk to the mount via the mount usb port, even if I have PWI running in the background. If you figure out how to do this let us know because it would be great to use the mount port rather than the handset port which is messy from a cable perspective. The other advantage (of PWI) is that the conventional alignment method with the CGX requires visual rather than camera-based operation since you can’t (or at least I can’t) connect SGP to the mount (via the handset) until I have been through the alignment process, or used the ‘Use last alignment’ setup. As far as I can see, the fundamental problem appears to be that the mount and the handset are two separate units and both seem to have their own alignment software/memory/stuff.
Regarding POTH, I use it to hub/integrate the mount and the dome - it works well and though the mount might driver might function ok as a hub I’m in the mode of ‘if it works and is hassle-free then leave it alone and work of the things other problems’.
Re backlash, my CGX has a lot of DEC backlash (measured at 40’odd pixels (80 arc-secs, 5,000 ms) in PHD), but it regularly centres to within sub-30 pixels after the first attempt and occasionally sub 10 pixels. I’ve checked the worm gear spring tension as per the manual - also I’ve measured the worm-gear backlash with dial guages and it’s actually zero (the spring tensioner is doing its job and the backlash is actually in the spur-gearbox of the motor). However, I regularly guide with a total rms error between 0.6 and 0.8 arc-sec and I’m pretty happy with the 20 minute subs I get. The only problem I seem to have is every now and then (once every 5 or 6, 20 min subs), at high elevations, DEC throws a wobble of 6 to 8 arc secs and causes the image to restart. I’m experimenting with slightly unbalancing things but need some clear sky.
I’ve just chanced upon this thread and can report that I am having similar experience with erratic behaviour during target centering at Sequence start.
I am using an Avalon M-Zero mount, StarGO, SGP v2.6.0.24, Astrometry.net.
I have SGP set to perform a SYNC after a successful plate-solve.
I attach a file with extracts of an SGP logfile that contains three unsuccessful atempts on centering on M33. I have annotated the log extract with what I think is happening. Basically I believe that when calculating the corrective action following a successful plate-solve, that the move is calculated using the frame centre location PRIOR to the most recent SYNC. Thus for example there is sometimes a significant error in the mount positioning and accordingly the mount slews such that at the next plate-solve it is quite close to the desired location. Now instead of a small corrective move the mount now makes a further signifiacant move to a position way past the desired position. The level of the error is such that I think the second move is being calculated using the original start position rather than the up-to-date coordinates determined by the plate-solve. I have annotated the log-file to show what I think will be the osition at the next-plate solve based on use of the earlier location and I find this is generally quite close to the actual position at the next plate solve.
My initial thought has been that StarGo has been slow updating its positioning following the SYNC command but do not know if this is correct.
I wonder if instead of SYNC I should use one of the other options SYNC Behaviour options on the mount TAB but not sure what impact this would have.
Having issued a SYNC command is there anything that can be done in SGP to delay the next centering request to allow the most recent SYNC information to propagate successfully fully to StarGo (if indeed StarGo is the issue).
Thoughts and suggestions welcome
Regards
Mike
Attachments:
a) My edited down and commented version of SGP logfile
b The full SGP logfile in two parts
so I thought that I had better comply …
