Steps in Centeing

Still working on getting a working setup with my gear.

What are the steps to a center.

  1. Get image based on exposure settings in Control Panel
  2. Plate solve
  3. Send correction to scope
  4. Validate

In #3 what is the correction? Does it do a “Slew to RA:DEC” as the correction or is it a telescope nudges? How do you determine what is a good amount of pixels for error? Is this based on te size of the pixels, ie 50 pix for a 9um pixel or 100 for a 4.5um pixel? Any guidance here? I’ve tried several settings but can’t sem to get this below 100pix error with the SX35.


Can you post your logs? What mount? Are you using all Jnow or J2000?? Usually when I see this problem it’s because I messed up sending Jnow.

It syncs the mount at the plate solved location then issues a slew to the reference location.

This really depends on your setup as for what is “acceptable”. Maybe if you post your camera, mount and scope you’re using we can help with some guidance here.


Okay so it’s the deficiencies of the ASCOM driver yet again:
Here’s the Center portion of the log:
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Center telescope message received…
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Solving with Plate Solver Astrometry.NET
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Setting filter for auto center…
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Setting filter position 4…
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Filter position 4 is already set. Skipping…
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Performing auto center step 1…
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Skipping step 1…
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Auto center reference frame solved successfully…
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Performing auto center step 2…
[5/7/2015 10:42:29 PM] [DEBUG] [Telescope Thread] Created full file name: C:\Users\Michael\AppData\Local\SequenceGenerator\Temp\
[5/7/2015 10:42:29 PM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE message received…
[5/7/2015 10:42:29 PM] [DEBUG] [Camera Thread] Collecting FITs headers for plate solve frame…
[5/7/2015 10:42:29 PM] [DEBUG] [Camera Thread] Collecting FITs headers for plate solve frame…
[5/7/2015 10:42:30 PM] [DEBUG] [Camera Thread] SetAscomNormalSpeed…
[5/7/2015 10:42:30 PM] [DEBUG] [Camera Thread] Cannot set readout speed, not supported by camera…
[5/7/2015 10:42:41 PM] [DEBUG] [Camera Thread] Created full file name: C:\Users\Michael\AppData\Local\SequenceGenerator\Temp\
[5/7/2015 10:42:41 PM] [DEBUG] [Telescope Thread] Capture complete, attempting to plate solve image C:\Users\Michael\AppData\Local\SequenceGenerator\Temp\
[5/7/2015 10:42:41 PM] [DEBUG] [Camera Thread] =========== Save file took 359 ms
[5/7/2015 10:42:41 PM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE complete…
[5/7/2015 10:42:42 PM] [DEBUG] [Telescope Thread] Astrometry.NET convertedAstrometry.fits path: C:\Users\Michael\AppData\Local\SequenceGenerator\Temp\convertedAstometry.fits
[5/7/2015 10:42:42 PM] [DEBUG] [Telescope Thread] Astrometry.NET - File is too large, resizing
[5/7/2015 10:42:42 PM] [DEBUG] [Telescope Thread] Astrometry.NET - Saving file
[5/7/2015 10:42:42 PM] [DEBUG] [Telescope Thread] Astrometry.NET using endpoint: http://localhost:8080/api/
[5/7/2015 10:42:42 PM] [DEBUG] [Telescope Thread] Astrometry.NET - Calling Async Solve
[5/7/2015 10:42:43 PM] [DEBUG] [Unknown] Astrometry.NET uploading file: C:\Users\Michael\AppData\Local\SequenceGenerator\Temp\convertedAstometry.fits
[5/7/2015 10:42:53 PM] [DEBUG] [Unknown] Astrometry.NET - Upload complete
[5/7/2015 10:42:53 PM] [DEBUG] [Unknown] Astrometry.NET - Waiting for solve to complete
[5/7/2015 10:42:53 PM] [DEBUG] [Unknown] Astrometry.NET - Job successfully solved
[5/7/2015 10:42:53 PM] [DEBUG] [Unknown] Astrometry.NET solve done in 10 seconds.
[5/7/2015 10:42:54 PM] [DEBUG] [Telescope Thread] Astrometry.NET - Solve Completed
[5/7/2015 10:42:54 PM] [DEBUG] [Telescope Thread] Astrometry.NET - Solve Successful
[5/7/2015 10:42:54 PM] [DEBUG] [Telescope Thread] Auto Center scope frame solved successfully…
[5/7/2015 10:42:54 PM] [DEBUG] [Telescope Thread] Telescope: Syncing to RA: 12.4288000814 Dec: 12.8848538022
[5/7/2015 10:42:54 PM] [DEBUG] [Telescope Thread] ASCOM Telescope: Error in Park : Method ASCOM.UniversalMeade.Telescope SyncToCoordinates is not implemented in this driver. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Method SyncToCoordinates is not implemented in this driver.
— End of inner exception stack trace —
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 443)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 478
at ASCOM.DriverAccess.Telescope.SyncToCoordinates(Double RightAscension, Double Declination) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 1133
at ah.Sync(Double ra, Double dec)

ASCOm Conformance check yields:

Can Properties 
09:14:35.996 CanFindHome                   OK       False
09:14:35.996 CanPark                       OK       False
09:14:36.011 CanPulseGuide                 OK       True
09:14:36.011 CanSetDeclinationRate         OK       False
09:14:36.027 CanSetGuideRates              OK       False
09:14:36.027 CanSetPark                    OK       False
09:14:36.042 CanSetPierSide                OK       False
09:14:40.894 CanSetRightAscensionRate      OK       False
09:14:40.894 CanSetTracking                OK       False
09:14:40.894 CanSlew                       OK       True
09:14:40.910 CanSlewltAz                   OK       False
09:14:40.910 CanSlewAltAzAsync             OK       False
09:14:40.925 CanSlewAsync                  OK       True
09:14:40.925 CanSync                       OK       False
09:14:40.941 CanSyncAltAz                  OK       False
09:14:40.941 CanUnPark                     OK       False

Which shows the telescope can’t sync which is then, obviously, our problem here. :CM# over the serial port causes the scope to sync to the slewed RA and DEC. Sad how easy that is yet it’s not implemented. Of those, only CanSetPierSide should be false for the LX850.

The Lx200gps driver supports Sync but not side of pier but uses an older form of the GetVersion (:GF#) to find the firmware version so it can’t connect to the LX850.

Sigh. Ironically, Neko Case is playing “There’s No Need To Cry” over my headphones right now.

Since it just uses the standard LX200 instruction set can you use a different Meade ASCOM driver? There are a handful out there.


It’s not strictly speaking a deficiency of the ASCOM driver. There’s no requirement that a driver implements sync, just that the behaviour of CanSync and Sync match.

SGP has additional requirements other than that drivers are ASCOM compliant.

BTW it would be nice if SGP were to check CanSync, then it could disable the functionality that requires Sync.

I’ve watched numerous attempts to implement drivers for Meade scopes over the years, most of which seem to have come to nothing. Most of the current ones date back to the original LX200.


Understood, Chris. You can implement what you choose as the author. So maybe it’s not fair to say “deficient” because the driver does slew and allows guiding. It obviously provides the functionality the author needs. And as I believe you pointed out, it ought to be up the Meade to write a driver or a work with someone that is willing to do the full job. But as a software engineer that has written Meade controllers in the past I know how simple it is to use and not providing something as basic as sync seems kind of crazy.

It is my fault for choosing a OS that I have no tools or skills. SGPro was just too cool to pass up and it is awesome. If I had a good driver it would sublimely awesome.

If I recall this has already been implemented in 2.4, I can double check later. However all it does is not sync the scope. We don’t compute any slew vector based off of the current position and the incorrect data that the mount has. So really it doesn’t offer much benefit. It is unlikely that this will change.


I have been a Meade user about as long as the LX200 product line has existed but I can’t excuse Meade’s indifference to their lack of support for a robust ASCOM driver for the LX850 mount. When I decided I wanted a bigger scope than my 10" LX200-ACF, I decided to stay with a Meade OTA but moved to an Astro-Physics mount.

The AP mounts have a fully featured ASCOM interface that I believe was written by Ray Gralak ( ). The AP command set is based on the LX200 command set so Ray would have a kind of head start on developing a new ASCOM driver for the LX850. Perhaps a group of frustrated LX850 mount owners could band together and contract with Ray to produce a robust ASCOM interface for the LX850?

I fully agree that Meade should step up and do this but how long do you want to wait for them?

What I do for Celestron mounts that don’t implement Sync in hardware is calculate an offset between the current position and the sync position, then apply that to all subsequent positions and slews.

SGP could do exactly the same when drivers don’t implement sync.

Fortunately, a fellow SGPro users is lending a hand and we’re going to remedy the situation. Perhaps I’ll learn enough VBasic to handle this myself in the future.

If you have an option use C# over VB.


The only source I could get is VBasic. I can at least get template code from it. That’ll be a steep enough learning curve as it is for me. I’m only a C/C++ programmer. C# is probably a completely different animal from C.

Visual Studio Express 2012 or Visual Studio Community Edition is a free download that provides the tools to develop drivers in C# or VB. ASCOM provides templates, support code, documents and videos.

I’d suggest C# as well. VB6 was really good but while VB.NET retains much of the look it seems to have lost most of the benefits.

Good luck with your driver. On the face of it it shouldn’t be too difficult but a lot of good people have announced they are doing this and very little has emerged.