Lock Position Adjustments
Lock Position adjustments are being tried during guide settling in order to overcome issues with Dec backlash & backlash overcompensation.  In situation where guide star starts out on the wrong side of zero line for planned uni-directional guiding or where first guide pulse pushes the guide star onto the wrong side of the zero line, a simple adjustment of lock position can be used to quickly bring the guide star 'back' to the zero line without any of the side effects of swamping the Dec Guide Mode only to swap it back later on, with the extra uncertainty that brings to Dec position.

During S944 session the lock position adjustments were initially being made in the wrong direction leading to Dec Guiding RunAway. After fixing that issue it was found that  3 or 4 times the required number of adjustments were being made, leading to overadjustment.    This was fixed in the Astrom 3.48.10 version.

During te S945A sessionn attempt it was found that extra adjustments were being made before the impact of the initial adjustment had fed through and impacted the new guide error values.  This caused the star position to be over adjusted by factor of 2 or 3. A new lock position adjustment should either wait a minimum time (eg. 5s) or wait for associate star lock change event to be received.  Relying on reading lock position isn't sufficient.

In the following chart Dec position jumps from +4.0 to -8.0 as a consequence of the accumulation of 3 lock shift adjustments (indicated by short purple line markers at around 17:23:25)

Looking at AstroMain's log file (see extract below) it seems that although New Lock Positions are reported at 23:26.67,  23:27.54,  23:28.51, the G.dy values of 3.97" and 4.47" at 23:26.79 and 23:27.66 are clearly associated with error calculations that don't use the new lock positions.   PHD2 events recording 'LockPositionSet' aren't  apparently received until 23:28.51 to 23:28.75.  Three adjustments (3.63, 3.85, 4.34 = 11.8 px total) explains why the Dec Error jumped from +4 to -8.

17:23:25.78 | Starting Guide Monitor (17:23:25)
17:23:25.92 | Y Adjustment Required: PrincipalDecMode=North, G.dy=3.75", yAdj=3.63 px
17:23:26.24 | Calling GuidingChart.DrawFocusChange, MoveSteps = 514
17:23:26.67 | New Lock Position x: 2,168.22, y: 535.40, y_adj: 3.63

17:23:26.79 | Y Adjustment Required: PrincipalDecMode=North, G.dy=3.97", yAdj=3.85 px
17:23:27.54 | New Lock Position x: 2,168.22, y: 539.25, y_adj: 3.85

17:23:27.66 | Y Adjustment Required: PrincipalDecMode=North, G.dy=4.47", yAdj=4.34 px
17:23:28.51 | New Lock Position x: 2,168.22, y: 543.59, y_adj: 4.34

17:23:28.51 | PHD2 event during guiding :LockPositionSet
17:23:28.63 | PHD2 event during guiding :LockPositionSet
17:23:28.75 | PHD2 event during guiding :LockPositionSet

Examining the log of PHD2 client-server communications (see extract below) shows that the set  lock position at 23:26.24 was associated with GuideStep event at 23:19.24 (7 seconds earlier),   with set lock position at 23.27.10 being associated with GuideStep event at 23:21.93 (5 seconds earlier),  with set lock position at 23:28.10 being associated with GuideStep event at 23:26.08 some (2 seconds earlier).     

17:23:18.89 | Event << {"Event":"SettleDone","Error":"timed-out waiting for guider to settle",
17:23:19.24 | Event << {"Event":"GuideStep","dy":3.632,
17:23:21.93 | Event << {"Event":"GuideStep","dy":3.849,
17:23:25.08 | Event << {"Event":"GuideStep","dy":4.335,

17:23:25.92 | 92 REQUEST >> {"method": "get_lock_position", "id": 92}
17:23:25.94 | 92 Response << {"jsonrpc":"2.0","result":[2168.22,531.77],"id":92}

17:23:26.24 | 93 REQUEST >> {"method": "set_lock_position", "params": [2168.22, 535.402], "id": 93}
17:23:26.25 | Event << {"Event":"LockPositionSet", Y":535.402}
17:23:26.56 |
17:23:27.10 | 96 REQUEST >> {"method": "set_lock_position", "params": [2168.22, 539.249], "id": 96}
17:23:27.12 | Event << {"Event":"LockPositionSet", "Y":539.249}
17:23:27.42 |
17:23:28.10 | 99 REQUEST >> {"method": "set_lock_position", "params": [2168.22, 543.585], "id": 99}
17:23:28.12 | Event << {"Event":"LockPositionSet", "Y":543.585}
17:23:28.40 |
17:23:32.02 | Event << {"Event":"GuideStep", "dy":-7.722,
17:23:36.45 | Event << {"Event":"GuideStep", "dy":-7.482,
17:23:40.31 | Event << {"Event":"GuideStep", "dy":-4.446,
17:23:43.96 | Event << {"Event":"GuideStep", "dy":-2.476,
17:23:47.49 | Event << {"Event":"GuideStep", "dy":-0.691,
17:23:50.47 | Event << {"Event":"GuideStep", "dy":-0.235,
17:23:53.58 | Event << {"Event":"GuideStep", "dy":0.491,

There is a 7 second gap in GuideStep events between 23:25.08 and 23:32.02.  It is unclear if this represents a) a real physical delay between PHD2 guide step images, b) an impact/delay to PHD2 due to increased in communications/processing between server and client associated with Get /Set Lock Position requests, or c) loss of guide step event in AstroMain.

Between the two guidestep events (where dy jumps from +4.33 to -7.72) there are 3 set lock position requests that collectively move Lock Position's Y value from 531.77 to 543.58. 

Lost Star Event
Guide Run 2 suffered from a couple of large RA excursions (a 7" excursion during setting and a 5" excursion during 1st frame).  The excursions appear to have begun with lost star events. Since the SNR is fairly reasonable and doesn't change it seems unlikely that cloud caused the star to be lost. Similarly the absence of any deviation in Dec position makes it unlikely that cable hang-up was responsible.   It is hypothesised that a very fast acting error in Ra drive smeared the light from the guide star which was seen by PHD2 as a lost star.

Current algorithum deliberately suspends guide output for 20s following 'StarLost' event. This is done because guiding when there is passing cloud has been found to worse than no guiding at all.  However in this case guiding would have been clearly have been very helpful to limiting and/or correcting the RA excursion.   As a first step the suspension of guide output will not be applied when guide star SNR is > 40 or the number of continuous lost star events is < 4.