Jared or Ken could you explain what exactly the Sync command does to the T-point model in the SkyX if you are using a Paramount? Is it the same as if you just use the Sync command in the SkyX? Also if you disable the Sync setting in the Ascom SkyX driver will you still be able to center/rotate your object using plate solving in SGP or will it only just be able to slew to your object? What about meridian flips if sync is disabled in the driver?
This is probably better asked on a forum that supports TPoint. I’ve personally never used it or TheSky, so I can’t answer this question. Maybe someone that has can.
As far as Sync is concerned it does just that. It just syncs the mount to the locations found in the solved image. We don’t actually check if the mount can sync at the moment, so I’m guessing if you disabled this in your driver that 1 of a couple of things would happen:
- SGP would throw an exception
- It would go through and potentially mess up your TPoint model
- Nothing.
If you don’t want to use sync it’s probably best that you don’t do things in SGP that will sync your mount. This also means that you’re completely trusting the model in you rmount (which may work perfectly) and means you have no reason to sync as it’s “100%” accurate. To do this just use slews for centering rather than “center on”.
Thanks,
Jared
My take is that it does exactly the same thing as synch in TheSkyX does. I have enabled synch (unchecked the box to inhibit) with my Paramount ME and disabled the T-point model that I had made. I have found that with an even halfway decent polar alignment one simply does not need a T-Point model to use with SGP since the solve and synch makes it totally redundant.
With my permanent mount ME, and a polar alignment of around 2 arcmin, SGP can get dead on (< 5 arcsec) with one solve/synch and micro-slew about 95% of the time. Mileage may vary, this is at 1000 mm.
Bottom line, dump T-Point models and allow (do not check inhibit) synch, works like a charm. I feel your pain from dumping the carefully made model, I felt that way too (spendy T-point and 150 point model) but it really is not needed.
What has to be done is at thesky/tpoint side :
-two synch behavior should be done :
-sync to add a point to the model
-sync to sync the whole model to a specified offset
This is how it is done on 10 micron hps mounts and the user can choose this behavior when launching the ascom driver.
This way the pointing model is not messed by sgp, and the user can benefit from sgp sync function.
So this should be asked to SB.
I’m not permanent so I will have to run at least a small t-point run each night to get my polar alignment set up and I use the FMW to set up my image and usually center and rotate before the start of imaging. So I’m not sure how this is all going to work.
If you have an existing T-point model and then Sync again it forces you to choose between a full calibration, re-cal or sync into existing model. I wonder if this dialogue box comes up after SGP issues it’s sync command and then choosing sync into existing model will work.
I’m thinking I should run a short T-point model to get polar aligned, then dump it and use SGP with sync as normal. I guess I might as well see what happens with the other various options and report back as no one seems to know for sure.
I have used T-Point and AAG automapper to do polar alignments on the ME but have found I like PEMPro’s method better and I think it is quicker. My buddy that is portable swears by it. I also think PhD2 has a polar routine but have not used it. He easily gets close enough with PEMPro for SGP with no model to work just fine and with a polar scope plus PEMPro it typically takes him between 10 and 20 minutes.
My opinion is that it is very desirable to use the TPoint modeling even if it isn’t needed for pointing accuracy. The reason is that ProTrack will proactively make corrections that minimize the need for guiding. And it is much better to prevent errors than correct them.
My opinion is also that if SGP wants to find wider adoption by those using Paramounts and/or TheSkyX, one of two things (or both) would be VERY desirable:
-
The Frame and Mosaic wizard as well as the popular platesolvers (Astrometry and Elbrus) are J2000 centric. Provide translation to Topocentric that is wanted by Paramounts, mounts using TheSkyX, and some other mounts (Astro-Physics comes to mind).
-
Implement the ability to use calculated offsets instead of using sync to do centering. Some other automation tools provide this and not surpisingly, they are popular with those using Paramounts.
I really like SGP, and have turned more than a few people to it over time. But it doesn’t work particularly well with Paramounts without neutering some of the things that make Paramounts desirable. It works as well with Paramounts as with other mounts. BUT, it does neuter some desirable aspects of the mount (like anything having to do with TPoint).
Whether or not this matters to the developers is their business call, and I can respect a decision either way. It is possible they simply make the decision that the Paramount market simply is not big enough to bother with. I will say with the advent of the MyT, there are likely to be more Paramount users than in the past that would like to use SGP. I’m one of them.
1 Like
Well said Madratter. Almost every time someone posts a question on the Software Bisque forums regarding any issue that might exist with the Paramounts and SGP, they’re told, by other users, to switch to one of the other automation programs such as CCDAP or ACP and you won’t have any of these issues.(It’s actually kind of annoying). Like Madratter I love this program and have recommended it strongly to many others on the SB, CN and Celestron forums (my other mount). If these issues can be resolved I think Paramount users would flock to this program like crazy.
well guys, we are at a point difficult to say : what is the responsability of sgp about paramount mount behavior ?
does sgp will had to comply with evry mount/camera/whatever specification possible ?
Is that not SB that first should permit a sync behavior which does not destruct the model ?
Did you , ask to SB their point of view about this ?, what did they say?
What you say is technically correct but IMHO not that significant on an image quality or production level. Synch takes such a small amount of time that unless one is switching targets dozens of times per night (maybe survey work or such) the time savings one would have by avoiding it are probably less than a single short image exposure on an average night. In other words from a time savings POV it is not significant. As far as guiding, with a decent polar alignment and PEC plus PhD2, I am easily able to stay within an arcsec circle for 95% of the corrections at 1000 mm, in my case that is the size of the imaging pixel. RMS a lot lower than that. This is more than adequate for short to medium focal lengths and long ones are better off with AO units anyway from a practical POV.
Can’t comment of the frame and mosaic wizard, I don’t use them. I have found it is easier to find an image of the object on the web, crop it to your desired position and FOV, then do a blind solve to place the center of your image using the cropped web image as a reference. This also takes no imaging time as the setup is done during daylight at one’s leisure - once again just practicality - It just works.
I suspect that Paramount users are indeed not a primary concern to MSS as most of them tend to use the likes of MaxIm/FocusMax/ACP/CCD Autopilot, and the other “old school” software. I know I used to until I tried SGP.
Although all software can use improvement (and I have suggested some of my own) I am very happy with SGP as is. I will leave it to those who view my images to decide if that is a reasonable conclusion (as long as they note that only my recent images were done with SGP 
).
The Issue with Sync is not the time it takes to do it but the fact that it pollutes the T-point model used with the Paramounts. The Framing and Mosaic Wizard, is in my opinion, one of the features of SGP that set’s it apart from the others and what ultimately sold me on this program. To be fair, you can still use it as long as you abandon T-point but then, as Madratter pointed out, do give up some functionality of the Paramounts. I believe you are correct in your assessment of the typical Paramount users, up to now, but the introduction and apparent very successful launch of the MyT mount is bringing new, less experienced users into the fold who are not interested in the complexities of the Maxim/FocusMax/ ACP/CCD autopilot programs. On the other hand, it can be hard to swallow that you just laid out $6000 or more for a premium mount and can’t take advantage of all that it has to offer, if you want to use SGP.
Now whether MSS or SB holds the key to making this work is beyond my level of knowledge, but the other automation programs mentioned apparently do work well with T-point so presumably it’s possible to make SGP work well with it too.
Indeed. That was my point in the previous post. T-Point added little or nothing to the final result or the speed compared to SGP w/o it. I used T-point for several years along with ACP. In fact, it is just one more thing I do not need to spend time on maintaining or redoing each time I work on the mount or alignment.
This is coming, likely as a maintenance release to 2.4. It’s too widespread to put it in the beta. It will be application wide and not just the Framing and Mosaic Wizard. We’ll be doing coordinate transformation between all solvers and telescopes for all slews and syncs.
This kind of seems like a hack to me. If TPoint doesn’t know exactly where the scope is and how to get it to where the application requested it to go, then what’s the point of it? I thought that was the entire point of TPoint that you could say “GoTo X, Y” and it would get you there with arcsecond resolution? If it can’t do that then why use it as opposed to the centering routines build into SGP? As I mentioned before I’ve never used TheSky or TPoint, so maybe I’m missing something?
The idea of sync is that it’s correcting (locally) for an incorrect model. It’s up to the ASCOM driver to handle what it does with sync. So if it’s a bad idea to sync a mount connected to TheSky then it should set CanSync to false and throw an exception when Sync is called. Simple as that. But if neither of those are true then we have no way of knowing that we can’t sync the mount. SGP doesn’t currently check if CanSync is enabled or not, but I could see us adding something to the Auto Center routine that checks for this and just doesn’t sync the mount. This would allow us to reslew the mount to the solved coordinates but since it still has a bad model it would likely continue to fail…garbage in…garbage out.
Like I said earlier you can easily never sync in SGP. Just disable the “Auto Center” in favor of “Slew” for your targets and we’ll never sync the mount.
Thanks,
Jared
You are missing something. TPoint has several functions. One has to do with pointing. How well it can do that job depends on how repeatable the system as a whole is. For example SCTs with their moving mirrors are inherently less repeatable. By having the JNOW translation of coordinates (thanks for looking into this - its implementation will be very much appreciated), it will allow syncing to occur that won’t pollute the TPoint model.
And that brings up its other functions. First, ProTrack, a subsystem of TPoint proactively makes changes to the tracking of the mount based on the TPoint model. It can help compensate for such factors as refraction, and flexure and make needed corrections before guiding needs to guide them out. That potentially leads to better FWHM.
Finally with some systems it is good enough that it allows you to do unguided imaging. On my system, so far it looks like I can go unguided for about 5 minutes at an image scale of .93 arc-seconds.
Bottom line is that TPoint is not just about pointing accuracy.
I can do that w/o it. I will not further beat this now mostly dead horse but the bottom line for me is that making changes to SGP that will have minimal effect for a minimal number of users may not something that is an ideal use of programming effort. Not to say there might not be benefit as technically there could be, maybe would be. The real question is of practicality. As always, what is done or not is up to MSS, of course.
With that I will exit, stage right. 
1 Like
The TheSky ASCOM driver does exactly that. There’s an option in the setup dialog that allows the user to specify if sync is available or not and if it isn’t CanSync will be false and Sync will throw an exception.
I don’t have TPoint but if I did I would consider using that as my primary pointing method. People seem to be able to get pointing to within 15 arc seconds or so with TPoint. Does turning TPoint off and using SGP’s solve and sync get closer than that?
However I would prefer it if SGP was less invasive. It’s purpose is to automate acquiring images and precise image positions could be achieved with solve and slew to offset just as well as solve, sync and slew.
I’m particularly uneasy about the pier flip process where there’s a solve and sync, then pier flip. That sync, which is designed to make pointing better locally to the pre flip position, could very easily make things worse for the post flip position. As far as the mount is concerned the pre and post flip positions are separated by 180 degrees on the hour angle axis.
Chris
Sorry, but as my post seems not clear enough : why sgp should change its behavior about one of its main
core action (sync/positionning made easy) because of a problem related to bad sync management in paramounts mount ?
Ask before to SB to correct for this should be the first thing to do :aslk them to implement in the ascom driver these two tickable options :
-sync to add a point to model
-sync to align model
What is done in maxpilote about this is a kind of hack but maybe Jared or ken Can contact Laurent, the writer of maxpilot who knows well the paramouts mounts to get the whole picture about the sync trick ?
Here’s the discussion on CN , please read from post N°217 :
When you use the Sync command in the SkyX with a T-point model in existence, these are the options you are presented with automatically:
-Sync and start a Recalibration Run
-Clear the existing calibration data and start a new Calibration Run
-Synchronize mount into the existing model
Is this not what you are asking for?
Not sure about this, the last option is alike but in fact the whole model should be sync to a point, that is the same as align the model to a point like a generic offset .
So the proper action should be named "Sync the model to a plate solved position "
More over if this option exist properly in the sky, it should be presnet in the ascom driver.
I’m not aware how the paramount is driven in sgp, does it relie to an ascom driver ? or does it pass through the skyX ?
I really think that matter needs SB point of view, did someone asked them ?
This said, and as this is something complex, i just show here an exemple of how it is done on a 10µ mount driver :
http://astro.frejvall.se/assets/6.4.1.png
The synch behavior let the choice between refining a model (equivalent of Tpoint building model)
and align model, the last i use when going with SGP …
So : proof is this can be done in ascom driver.(the driver can also convert on the fly j2000 to jnow, very useful…
This seems to have degenerated into a SB bashing thread.
If you look at this from the point of view of the mount manufacturer SGP is demanding the ability to corrupt their mount pointing model using some data about which they have no knowledge of it’s provenance or quality.
You will do far better to contact SB and discuss this on their forum. You probably won’t get a fix but you may get some understanding why there’s more to this than you think.
Chris