SX-AO PHD2 connectivity options

[John Rightten]

Hi guys, so I have the following setup on which I have a question

I have a guidecam connected to PC via USB which is connected to the mount using ASCOM driver and I can do guiding using PHD2 no issues.  I also installed starlight xpress adaptive optics unit. AO connects to the computer using serial/usb adapter (its an older version AO), AO also has an ST4 port that can connect directly to the mount guide port and issue "bump" commands when mirror reached the limits of correction. But it looks like "bump" commands can also be issued using a guide cam--PC ASCOM--mount connection...so can I use either one in this case...or one is better then the other...what is preferred choice here?

so I am essentially doing rapid corrections using AO mirror, but my question is in case of SX-AO can a bump command come from the guidecam, or it has to be comming from AO ?

[Bruce Waddington]

Mount bumping needs to be handled by PHD2, don't connect the AO to the ST4 port.  There is quite a bit of information in the User Guide:

https://openphdguiding.org/man-dev/Advanced_settings.htm#Other_Devices_Tab

https://openphdguiding.org/man-dev/Supplemental_Info.htm#AO_Devices

Bruce

[John Rightten]

I think in both cases they are issued by PHD2, SX-AO does not have a stand alone capabilities star signal gets acquired by the guide cam in both cases and gets analyzed by PHD2 soft inthe computer..when PHD2 decides to "bump" the mount it can either do it through SX-AO---ST4---mount rout or USB--ASCOM---mount rout. I tried both routs recently and even thought the first rout is harder for me to make it work for separate issues, when it does work I have better guiding success on the same target (M101) good 180 sec exposures at 2000mm FL. If I don't connect AO to the mount so PHD2 uses second rout to issue bump commands the guiding quality deteriorates (I can barely get 2 exposures 120 sec each before loosing good guiding) on the same target. I have both days logs...so maybe someone can take a look and let me know....I did read multiple posts that ASOM pulse guiding is better than ST4 protocol guiding, but in my case its the opposite...so I wonder why and what settings need to be adjusted

thanks, ALex

[John Rightten]

So I am attaching a link below for Guide and Debug logs from both days:

Mar 24 I had SXV-AO connected to the mount using ST4 and to the computer using USB/Ser adapter, had a much better guiding using this configuration

Apr 9 I had SXV-AO connected only to the computer  using USB/Ser adapter, had worse guiding then above..not sure why , same target on both nights

would greatly appreciate the input what needs to change...

https://openphdguiding.org/logs/dl/PHD2_logs_7FCr.zip

On Sunday, April 12, 2026 at 3:16:06 PM UTC-7 bw_m...@earthlink.net wrote:

[Bruce Waddington]

I think we need to clarify how this stuff works.  When PHD2 is connected to the mount directly - via ASCOM in your case - 'bump' operations are routed directly to the mount through that interface.  The AO never sees any of that and your ST-4 cable isn't being used.  I suspect you might not believe this so here's the excerpt from the debug log file for a 'bump':

23:17:30.394 00.000 8412 starting a new bump
23:17:30.394 00.000 8412 AO travel limit exceeded, using large bump correction
23:17:30.394 00.000 8412 Scheduling Mount bump of (3.026, -8.476)
23:17:30.394 00.000 8412 ScheduleSecondaryMove(100EBFD8, x=3.03, y=-8.48, opts=4)
23:17:30.394 00.000 8412 Enqueuing Move request for scope (3.03, -8.48)
23:17:30.394 00.000 8412 move complete, result=0
23:17:30.394 00.000 8412 worker thread done servicing request
23:17:30.394 00.000 1208 Worker thread wakes up
23:17:30.394 00.000 1208 worker thread servicing REQUEST_MOVE scope ofs (3.03, -8.48) opts 0x4
23:17:30.394 00.000 8412 Worker thread wakes up
23:17:30.394 00.000 8412 worker thread servicing REQUEST_EXPOSE 2000
23:17:30.394 00.000 6728 GuideStep: -21.7 px 8 ms EAST, 22.1 px 17 ms SOUTH

In the parlance of PHD2 and AO operations, the "primary" mount is the AO driver and the "secondary" mount is the ASCOM mount driver. So the ST-4 cable shouldn't be connected and simply provides another potential source for cable snags and drags.

Given this situation, we wouldn't expect there to be any statistically meaningful difference in results between 3/24 and 4/09 unless the sky conditions were different.  And that's what the data show.  Your results for the 4-hour guiding session on 3/24 showed a total guiding rms of 1.25 arc-sec while the longest guiding session on 4/09 had a total guiding rms of 1.18 arc-sec - not a statistically significant difference either way.  So your perception about a difference was mistaken, possibly because you're just trying to judge results in real time.  That's why it's important to use the LogViewer and pay attention to the statistics over reasonably long intervals.

At this point, you should probably be focused on improving the overall results which aren't particularly good.  Operationally, you need to start following all the recommended procedures: update to the latest release (2.6.14), use a dark library, bin the camera to 2x2 if possible, use the Calibration Assistant in the correct part of the sky while following all its instructions, run the Guiding Assistant, etc. Until you get the system stabilized, you should also keep your guide camera exposures at 1 second or greater.

Regards,

Bruce