Guiding

[Gary]

Hi,

2 nights ago I was guiding fine, 00:40 I changed target, sharpcap should have commanded PHD2 to stop then restart on target (I can't tell if that's possible in the log viewer?)

After restarting its like it couldn't find a guide star (I didn't have diagnostic images enabled but I do now), and when it did it would send a huge correction, any idea what's happened?

Log attached below

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

Also, last night I updated PHD2 and tried to recalibrate it wouldn't have any of it, I tried guiding assistant that also wasn't working, it was like my mount wasn't getting any pulses from PHD2 (when it was doing nudge the mount/star position on screen just wouldn't move). How do I check if my mount is receiving pulses? Is there an easy way to test? EQMOD itself could control mount ok

Setup: EQ6 Pro, EQMOD, first issue I've had like this. All balanced, no snags etc

[Bruce Waddington]

Most of your problems stem from not being able to get usable guide stars in different parts of the sky.  You've made star-finding unnecessarily difficult with some of your operational choices.  You haven't created a dark library or a bad-pixel map which means you are vulnerable to choosing sensor noise, so that needs to be dealt with right away.  You also need to disable 'star mass checking' on the Guiding tab in Advanced Settings.  The guide star candidates that were being returned from Auto-find were generally pretty puny, often with peak pixel values of 50 or below and low snr values.  I don't know if this is a general characteristic of the guide camera on your setup or if you were having sky transparency problems.

It also looks like your problems were sensitive to pointing position.  The only decent results you got were for the 2 hour period starting at about 22:00, that was pointing at Dec = 13.  Immediately prior to that, you were pointing at Dec = 42 and were getting lots of wild excursions in Dec (green):

These are not caused by guiding, in fact the Dec motor wasn't even running when they began.  These things are normally caused by problems with the payload - cabling routing problems, something moving around on its own, etc.  

Regards,

Bruce

[Gary]

Thanks, wow the amount of information you can find is great I didn't know all that information could be found on the log, I will be sure to thoroughly check all the available features. 

In response to your findings, understood I will disable the star mass detection, RE guiding on bad pixels etc I didn't suffer issues with this in the past but I will look to create a dark library.

22:00 - 00:40 I was shooting M99 - 

00:40 the mount slewed to M63 which I think is when the big issue occurred and that's it's like there was no guide star available which is strange because there's usually a couple and I've shot this target before.

It seems it did pick a guide star which kept getting lost (its SNR was probably too low), can PHD2 not automatically re evaluate the guide stars available and re choose? If you look at the log the mount was making huge corrections with little explanation, when this happened the pointing was getting thrown way out, surely at some point a good guide star would have came into view and PHD2 could then use that?

With regards to the puny guide stars, that's understood for my setup, my FL is 1200mm, I use OAG, an 8mm prism and a IMX290 sensor, understandably my guide FOV is tiny my choices are small but still I've never had an issue with guiding.

Do you have any thoughts about the second part, I tried to run guiding calibration the night after the first issue and it just wouldn't guide, it's like my mount wasn't getting guide pulses, do you know how I can check if my mount gets the pulses and what could cause it?

Any other setting recommendations given my setup welcomed, dark library is one of them. I'm not in a position to be able to change my guiding hardware unfortunately

[Bruce Waddington]

The "second part" you're asking about shows that your session manager app never directed PHD2 to do anything as part of the slew - no command to stop guiding, no command to resume guiding.  So all that happened in terms of guiding is a long list of lost-star events that your session manager app then ignored. There is an option in PHD2 to stop guiding when the mount slews, but you haven't set that.  Bottom line, the automation process for this target switch was apparently fouled up.

The handling of lost-star events is described in the User Guide:

https://openphdguiding.org/man/Trouble_shooting.htm#Problems-_Lost_stars

If you're new to remote imaging, you probably have some work to do.  First, you need to have some way to judge what the sky conditions are and whether you have transparency issues that can interfere with guiding.  Forecasts don't cut it, you need live information.  You should also expect that automated sequences you define will have mistakes in them, so figuring that out will require you to be reasonably conversant with the various log files that are produced by the software stack you're using.  Although these files may be long and tedious, they are generally human-readable.  For PHD2, the LogViewer app is the best way to see what PHD2 was doing. When you recognize a problem, you will often need to look at several log files, find the relevant time periods in each of them, and see what each application was doing and what problems it noted.

Bruce

[Gary]

Thank-you, interesting that the imaging app (sharpcap) didn't tell guiding to stop (and then resume after slew) as that is in the sequence and I've used it multiple times and it's never failed me, I will dig more into that.

Also I didn't know I would need to set stop guiding when the mount slews as it should stop anyway as commanded by sharpcap (or supposedly should)

Thanks again,