A couple warnings for the upcoming beta

This is just a heads up… this information will be communicated again upon release of the beta, just starting now to minimize impact and possible confusion.

Setting Overhaul

The settings system in SGPro has grown a bit awkward over time. SGPro 2.5 will make the first steps toward amending some of the issues that make management of SGPro a little confusing (especially for new folks). The primary issue stems from a general confusion between settings that belong to profiles and global settings. A good example of this is something like “Software Binning on AF frames” for Canon DSLRs. This is a global setting. Not for any good reason… just that SGPro’s setting system implementation made it difficult to store settings that belonged to a specific device and not the class of device. This means that no matter what profile you are using, no matter what sequence you have loaded, Canon DSLRs are always bound by this setting for AF behavior. There are dozens more of these examples (QSI fan settings, SBIG ports, Astrometry.NET location, etc.). There is no good way for the uninitiated to know the difference between the two types. Does my setting apply only to this sequence, does it apply to a profile, is it global? All good questions.

SGPro will attempt to clarify / rectify this confusion by:

  • Enhancing the current settings system to support the general storage of device specific properties. This means that when you choose something like a camera and click on its settings icon, you will be modifying the camera’s settings (just like you are used to), but these adjustments now belong to a profile or sequence and are no longer global. As an example, you may now have one profile (or sequence) that software bins Canon DSLRs at 2x2 and other that does nothing at all. If the setting is equipment related, it has been moved to the equipment profile. As you’d expect, device “settings” buttons have been added to the profile manager so that you may set or adjust device specific setting in your profile.
  • Moving all global settings to the SGPro options dialog. If it’s in here, it applies to everything all the time (eg. Recovery time limits). This is the only place you will find global settings.

General Rule for Settings

  • If it’s not in the SGPro options dialog and you can change it, the setting can be attached to a profile.

How does this affect you?

Well… it makes things a little harder, but clearer (the pros outweigh the cons here). You will need to visit each of your profiles and essentially reset device specific settings to be whatever you had the old global settings at (you may want to visit them now and make sure you know how you have them set… will return them to their default states). This is a little more work, but it provides a new flexibility (and clarity) that will make it much easier to support multi-camera environments (and other things too). Keep in mind that you can open an equipment profile, tweak a couple things and save it under a new name. This will effectively prevent you from having to take a deep dive into settings for every new profile.

While it may be tempting to ask, I would prefer not to design a system that can use the new settings system or optionally continue to use SGPro like it is now (with global device settings). I think this setting is rooted deep in confusion and will immediately strip these changes of any benefit.

The beta will not have it at first, but the final release will attempt to auto-detect old sequences and automatically port the old global settings into the new equipment profile settings to make the transition easier.

Changes to Recovery

The recovery system has several spots in it that chuck all assumptions out the window and forfeit the PHD2 calibration. @Andy has pointed out that there is almost never any reason to do this (in another conversation). I had to think about this for a bit… meaning if it’s not needed, why is it in there (the code was not accidental, it is explicitly asking PHD2 to recalibrate). I cannot think of any good reason that it exists in it’s current state and my best guess as to why it was implemented in this manner stems from interaction with older incarnations of PHD(2). In the past, we were forced to make “blind” calls to PHD. This means that if we asked PHD to do something like flip the calibration data, we just asked it and hoped (we got no response indicating success or failure). This type of interaction led us to be overly cautious and do stuff like this. Now that we have stable communication with PHD2, we can probably remove the need to recalibrate PHD2 for failure to settle.

The one area I am concerned with is failure during target centering or meridian flips. If we fail here, we will attempt to recover, but we do not currently keep track of how far we got in the process before failure. This means that we might have flipped cal data, then failed. The recovery process, still under the notion that the last action caused a meridian flip will likely attempt to flip the calibration data again (to its original state), then we are in a mess… recovery will fail and we will never settle (which is actually one reason why we just say screw it and re-calibrate). I need to take a look here to see how to better track state during recovery.

I’m also wondering if PHD2 has the ability to repair itself with respect to stored calibrations. If a calibration was stored on a particular side of pier is it possible to ask PHD2 ro re-apply the calibration and determine how to flip (or not flip it)? In the case of unsaved calibrations or ST-4 connections, maybe we ask PHD2 to recalibrate in this case? I’m not sure…

I would like for recovery to limit (or eliminate) explicit recalibration of PHD2. I am just not sure how to do it right now… Changes are incoming and this is something beta users should keep an eye on in SGPro and higher.


Pier side calibration confusion would only be an issue for users with no ASCOM connection to the mount at all. Even folks who prefer to use ST4 guiding can use an ASCOM Aux Mount connection in PHD2 for scope pointing. If there are any SGP users who have no ASCOM access to the mount then they are not able to do meridian flips through SGP anyway!

For scopes that do have an ASCOM connection in PHD2 (either Mount or Aux Mount), SGP sending calibration flip commands is essentially useless. PHD2 knows which side of pier the calibration was done on, and which side of pier the scope is currently situated. If there is a mismatch, the calibration data is flipped. When SGP tells PHD2 to flip calibration, the command is honored, but when guiding starts PHD2 will check the parity and correct it if necessary. If SGP sent no flip commands or extra flip commands it would not matter… PHD2 would correct the situation automatically before guiding started.

The only risk of removing the calibration flip command from SGP would be if there was somebody out there who was using ST4 guiding and had not yet setup an Aux Mount ASCOM connection.



I am sure I am in the minority , but I can not use ASCOM for PHD2 as my ASCOM driver will not allow more than one
connection i.e SGP has first place
fortunately I have a fork mount and flips are not required :smile:


If anyone else is in Harry’s situation where their mount driver only accepts one connection then the ASCOM POTH component will help because it is a hub and allows multiple connections.
Select POTH in both PHD2, SGP and any other applications that connect to the mount.
In the POTH setup select the real driver. You only need to do so for the first set up.

@Andy it’s always a bit uncertain what needs to be set when a mount flips, it can depend on how the mount or driver implement the guide directions when the flip is done and if the guide camera is involved in any camera rotation.
Would a meridian flip calibraton wizard help? This would do a calibration, then prompt the user to move to the other side of the meridian and do another calibration. The two calibrations can be used to sort out what needs to be changed.

Even though meridian flips are a non-issue for you, you could still get some benefit by setting up an Aux mount in PHD2 using POTH as Chris described. Having an Aux mount would allow PHD2 to transparently adjust RA guiding based on declination. This would allow you to switch targets (change declination) without having to recalibrate. Knowing the Declination also allows PHD2 to do some sanity checking on calibrations.

The only unknown we have is whether or not the dec output needs to be reversed after a meridian flip. You are right that this information could be determined by a pair of calibrations with a meridian flip in the middle. I’ll add a feature request into our issue tracker (#504).

cheers for the advice , I did not know that :open_mouth:

I will have a go and see it works


It seems there are large improvements afoot ( I approve )
but as there might be few teething problems , can I install the new version side by side with the old till I get the feel of the new




Just tried to select local A Net and then settings and got this ??


Thx. Fixed in (out tomorrow)


So I select a plate solver like pinpoint --where do I find the option to select the local AN port ??


Well… when you select Pinpoint and click settings, you get Pinpoint settings. When you select Astrometry.NET and click settings you get Astrometry.NET settings. So… you will want to pick Astrometry.NET option from the drop down and click settings. From here you can configure it… local, remote, ports. Then, of course, you will want to switch back to Pinpoint.

This is another awkward growth… At some point we would like to allow users to select the backup solver in a different area and not mess with the primary solver at all…

It would probably be a good idea right now to place a “Settings” button next to the option to use a backup solver.

Ok I see I think :smile:
To me it would seem easy to have one box for your primary setup and another for your secondary solver
to a old fart like me would be clearer , and IMO these settings should be in the options box as it would seem to me a one time set up for all equipment


Yes… this is essentially what I was saying in my post above. This is a bit of work that we would prefer not to incur right now. Instead, will compromise here and provide a “Settings” button next to the “failover solver option”. This way you can adjust how astrometry.NET works for you without having to change your solver temporarily and then change it back.

I am sure you will find time sometime :smile:


This is great news! Thanks.

We though so too (in the beginning). Turns out this is not always true. A couple examples:

  • Pinpoint: A profile using long FL gear will want to have the catalog set to USNO, wider fields will want GSC. We could provide a place to enter paths for all catalogs and try to pick one for you based on other params in your profile (unfortunately, these params are not required though).
  • Astrometry.NET: One profile may prefer use of the remote version (because long FL gear will require too much space to download all of the indexes). For a shorter FL profile, you may wish to use your local ANSVR install.

Hi Ken / Andy,

I have just installed and still getting the error message "error creating profile…value can’t be null…’ this happens with the old profile, I have since created a new one from scratch with same details and it worked fine.

However, after installing the latest and switcheing back to old profile as default the above error re appears

Thought I’l let you know


1 Like

I have found this also.

Please provide the offending sgf of sgp files and we’ll take a look.