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 2.5.0.8 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… 2.5.0.8 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 2.5.0.8 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 2.5.0.8 and higher.
