New order of sequence start events (3.1 beta)

seems like prior to 3.1, SGP would slew, solve, sync, start guider, autofocus and then start imaging.

under the 3.1 beta i see that it slews, focuses, solve/syncs, starts guider and then starts imaging.

i think this is an improvement for OAG since i’d often find that my last focus position from the night before was not good for the new temperature at the start of the current night’s imaging. under this new ordering PHD2 finds a star and starts up more reliably and quickly. in the past sometimes i’d have to fix the focus manually as PHD2 was trying to start up.

i did notice though since the solve/sync is set to happen thru my L filter, and the first target happened to use my SII filter, that the change in focus position for the L filter defocused the OAG enough that the guidestar was a little mushy until the SII filter was called for after the guider started up. on systems with less parfocal filters i imagine you could get into the same problem as mentioned above.

does it make sense to switch to the imaging filter (and thus move back to the proper focus position) right before starting up the guider, rather than right after?

thanks,

rob

In some cases this makes sense, but in the case where the last filter of the night is the same as the first filter of the night, I think what is called for is a type of “between runs / nights” temperature compensation. Ideally you could turn this compensation on without being forced to use the between frames temperature compensation

Yes, indeed. Since I didn’t get a reply to a personal message I sent three days ago I cite what I then wrote:


In my view now there is one point that needs to be worked on urgently: Automatic adjustment of focus position BEFORE the first AF run is started. This topic is also related to temperature compensation.

This proposal has been made in the SGP forum several times before by different users, e.g.:
“Auto Focus Option: Function of Temperature” Auto Focus Option: Function of Temperature
“Minor feature request for when you run out of other ideas” Minor feature request for when you run out of other ideas
“Autofocus routine based on temp” Autofocus routine based on temp ).
“Focuser zero intercept” Focuser zero intercept

The aim is to avoid failing AF runs due to a too large distance from best focus at the beginning of a capturing session.

In my view, the best solution is the one suggested by Ben Kolt: the user shall provide a temperature / best focus function. This could be a linear function, fp = a x T + fp0 or a polynome, grade 2, fp = a x T^2 + b x T + fp0. (In the course of evaluating the Quadratic Fit method we encountered a case [Jerry’s refractor Televue NP 127is] where the dependence of best focus of temperature could not be properly described by a linear equation, QUADRATIC best fit Focus routine TESTING - SEND LOGS .)

SGP then would have to calculate the focus position from the current temperature using the given function, move the focuser to this position and then start the very first AF run. Currently some users, me included, do this manually. When I am doing so, I never have a failing AF run. However, sometimes I forget to calculate and move the focuser – then usually the first AF run fails. If SGP performed this task, this would not occur any more. It is up to the user to provide the appropriate function. When no function is given, this service is not offered by SGP. When the function is given, it shall be used for temperature compensation as well.


Bernd

Yes, sorry… I don’t often check that DM area for this forum.

that’s definitely true… i almost always have a failure of the first focus run of the night due to temperature differences. the image is not out-of-focus enough at the start of the curve and there are not enough points on the right to establish a proper V (for the old method) or quadratic for the new method.

Hi,

I am having an issue with the sequence begin order. If you are in a remote observatory and are parked in a position that the sky is blocked in, then autofocus canceled -> scope slewed to target-> scope centered -> Integration begins. Can we have the slew happen before autofocus again?
Logs attached; first log included as is was a random crash second shows the sequence order.

sg_logfile_20191017212121.zip (26.5 KB)

hm for me the slew is happening first, then everything else… i have “center on” and “slew to” checked in my targets. i think in the past this is what would cause a slew to happen before a solve, but maybe it also forces a slew before anything else?

1 Like

@HomerPepsi

It looks like you need your targets to differentiate between slewing and centering. It seems like you do not have slew turned on. Initial auto focus will always occur before centering, but after slew. Make sure that, in target settings, both check boxes are ticked.

1 Like

Roger that. Will try tonight. Thanks!

D’Oh! That was it.

Thanks, @Ken

@Ken i think there is kind of a problem with starting the guider before the filter is set (with OAG of course) -

just now PHD2 happened to pick a very bright star that didn’t look saturated since it was defocused, but when the filter changed back to the imaging filter the guidestar was in fact saturated. i had to manually put it onto another star…

It would depend on how you’ve mounted the OAG, mine is before the filters, so won’t be affected by filter changes…

not true, if your filters are not parfocal then the focus position change will defocus the OAG a little bit.

at any rate it just seems like good housekeeping and proper to switch to the imaging filter before starting the guider. i can’t think of any cost to doing this since the next step is to begin imaging thru that filter.

Yes, my filters are not parfocal, but then my OAG guider is close, but not perfect, to the same focal point as per the main camera, when using the Luminance filter only.

Any additional small discrepancy when changing filter\focus position, I find, is irrelevant, and has no detrimental effect on guiding.

did you read my post? SGP selecting a star that becomes saturated when focus is returned is most certainly detrimental to guiding. i didn’t think this was a big problem either until this happened. again this is mostly about good housekeeping; if you are going to do all the focusing before attempting to guide, then you might as well not guide until focus is correct.