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 3.0.2.82 to 3.0.2.91. 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
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.
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.
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.
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.
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.
@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.
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.