Guide star and mount communication lost

Not sure if it belongs here, but would like a resolution to this. I keep losing the guide star at seemingly random times. It happened only once last night, but has happened several times before. I’m using a Mach 1 w/ a TMB130 and an OAG w/ an Ultrastar. The SNR of the star last night was very high. I am pretty sure that it’s not environmental as there were very calm winds last night and I have a well managed cable system. I’m using APCC and PHD2 w/ SGP, and haven’t had a hiccup like this before aside from the two most recent nights. The only piece of software I’ve changed was SGP from the previous release to The event occurs from 12:08-12:15am.

After losing the guide star, SGP and APCC locked up and I noticed the telescope box had ‘Unknown’ for the RA and Dec. There apparently wasn’t communication between the two programs. I had to reboot to clear the issue and after starting up PHD, SGP, and APCC I could get them all talking to each other again and resumed the night. To be safe, the rest of the night, I turned of dithering and it ran w/o an issue. However, I’m not certain that fixed it, and want to be able to use dithering in my sequences.

Notes from the logs:

  • APCC has a gap in time from 12:08:20 - 12:12:20 and then again until 12:14:20 and 12:15:09. Very strange.
  • At 12:12:29, SGP reports a failure of integrating one of my light frames. This has also happened in previous logs.

Here are the logs of SGP, PHD2 and APCC:

I would appreciate any help or advice you might have for me. Thanks!

Gabe - do you have the star mass detection enabled in PHD2? It is designed to prevent PHD2 flipping between two close stars of dissimilar brightness. In practice, I found it more trouble than it is worth and my guiding became more reliable with it disabled. I don’t know if this impact the other part of your issue but I have known ASCOM pulse guiding to screw up my mount communication in the past, especially during a dither operation.
Lastly, you might enlarge the search box area as a precaution in the PHD2 brain settings.

1 Like

Thanks for the reply buzz.

  • Star mass detection is enabled. I’ll turn it off to see if it helps, but I don’t think that wouldn’t affect the locking up of APCC and SGP.
  • I enlarged the box to 30 pixels last night, up from 15 before
  • The star I was guiding on was the brightest in the frame, but it was not saturated. The other cases where I guided and a problem came up were w/ isolated guide stars.

I also posted this in the PHD forum and got a comment on checking whether usb selective suspend was on or off. Has anyone had an issue w/ USB ports turning off?

Buzz, I doubt it was ASCOM PulseGuiding causing the problem this time as I don’t think there was a PulseGuide operation active (and it happens asynchronously in most cases using A-P mounts with GTOCP4 control boxes like Gabe is using).

Also, at about the same time the PHD2 log has a gap, so it may be a camera USB hardware/driver issue.

00:08:20.192 00.000 3968 Enqueuing Expose request
00:08:20.192 00.000 7408 Worker thread wakes up
00:08:20.192 00.000 3968 GuideStep: 0.3 px 23 ms WEST, 0.1 px 0 ms SOUTH
00:08:20.192 00.000 7408 worker thread servicing REQUEST_EXPOSE 3000
00:08:20.193 00.001 7408 Handling exposure in thread, d=3000 o=3 r=(888,208,61,61)
00:08:23.761 03.568 7408 Exposure complete
00:14:20.719 356.958 7408 worker thread done servicing request

Gabe, you might try looking at your Windows event logs to see if there were any system or application errors at that time.

-Ray Gralak
(Author of APCC and the Astro-physics V2 ASCOM driver)

Ray - yes I should have been more specific. My remark was not about AP mounts per se.

Thanks Ray for the reply and for the suggestion of looking in the Windows event logs. Here’s an error I found in the windows event log. It’s source is DistributedCOM.

The server Microsoft.Windows.ContentDeliveryManager_10.0.17134.1_neutral_neutral_cw5n1h2txyewy!App.AppX9s1cz53zc86xn39kwrb02jyft9ecn62r.mca did not register with DCOM within the required timeout.

Not sure what I’m looking at since I’m not as familiar w/ Windows. The rest of the entries are Information level.


I am not sure that particular entry was relevant. Did you look in both the “System” and “Application” folders under “Windows Logs”?


Gabe, I don’t think that windows content delivery issue is related.

I think Buzz’s first thought about star mass has merit. Depending on the star you select, star mass can be quite problematic. I’ve lost guide stars because of it, when disabling it they were still quite guidable even with some thin cloud cover (even though those subs may be lost, guiding is maintained.)

@rgralak Yes, there was that, and an entry about APCC crashing, which was when I ended it using the task manager as it was frozen.

@jon.rista I have it disable now and will check it next time I go out. Thanks for the comment! Hope to get it sorted out - only 4 hours of imaging a night isn’t all that much, and I have to make the most out of every minute!



The long time span where nothing happens in both the APCC and PHD2 logs suggests that it wasn’t just APCC that was frozen. Something locked your computer for minutes at a time. Neither APCC or PHD2 or any regular application including SGPro would be able to do that. This was likely some sort of hardware issue, probably USB related. It seemed to happen when PHD2 was downloading an image from the camera, so I think that the PHD2 to camera connection is where you should look for a possible issue. A USB lockup can cause other USB devices to appear locked if they are on the same channel (e.g. APCC’s connection to the mount).

What looks like may have happened next is that APCC had to process many minutes of backed up commands from the driver that couldn’t be handled because of the USB lockup. So, APCC wasn’t actually frozen, just very busy trying to process a large number of commands in its input queue.



Would it be possible for you to post the AP V2 ASCOM driver logs as well? I am seeing something in the APCC logs that doesn’t quite make sense yet.


@rgralak Sure thing, but where might I find those logs. I’m not as familiar with their location.


@rgralak Found it. I’ve added it to the original dropbox link.

Thanks for taking a look!


It looks like there was the same time gap in the driver log as in APCC and PHD2. Afterwards, there still seemed to be something consuming the CPU because some commands received by APCC from the driver were not executed until a minute or so after they had been received.

BTW, I considered the possibility that the clock time had been changed on the PC, but the mount time always matched the PC’s time, so the clock time was not changed. Since the windows logs don’t show anything, I am not sure what caused this problem, but I think that the USB download from the camera is the primary suspect.


… that rings a bell

have you checked the USB suspend settings in Window’s advanced power settings? They should be disabled.

Just wanted to report back that the USB settings seem to have solved my issue. I ran last night w/ no issue at all!

Thanks for all the help! Here’s to clear nights!

@rgralak It seems last night the problem cropped up again. I’ve been imaging fine for many nights w/o an issue. This time, I verified that the USB settings were correct. The APCC / SGP communication failed again, and the RA/Dec in SGP was listed as Unknown. The APCC interface was very slow to respond to the point of it being frozen. A reboot sorted it out, but I’d like to not have to do this. Here are the logs:


Gabe, your APCC zip file does not seem to have any APCC logs or AP V2 driver logs!

If you could make sure that you include APCC and driver logs please also identify a 10 minute window when you saw the communication problem. When APCC is slow that could mean USB communication was failing (a hardware issue) or that something else was using system resources. APCC and the driver don’t usually take a lot of resources except possibly if an ASCOM client is bombarding the driver.

Also, when you had observed the slowdown, if you were remoting into the computer running APCC via a remote desktop application the user interface (and APCC as a whole) down can be slowed down by other network traffic.


Sorry about that. I had used the log zipper, but I guess I didn’t get all the files in. I’ve included the individual files now to the log folder above. It occurred right before midnight, but I see in the ASCOM logs, a no response string started around 11:49.



There are some large gaps in timestamps in your log.

0347205 2018-07-17 23:54:36.267: Debug, Command Thread, RX = ‘-232*18:51#’
0347206 2018-07-17 23:56:11.751: Debug, Command Thread, TX = ‘:HDG#’

Like before, your computer seems to get locked up for periods of time. I can’t tell you what’s causing the time gaps but I don’t think it has anything to do with APCC or the AP V2 driver.