PHD2 star finding inconsistent with OAG

[Ar Bit]

Hi

Quick summary of setup and problem is below:

Setup:

Scope:6 inch RC at 1370mm focal length.

OAG : ZWO OAG, prism 8x8mm, clear aperture 7x5mm (approx). OAG located scope and filter drawer, so no impact of filters.

Guide cam: ASI290mm (pixel size 2.9um, size5.6x3.2mm), Bin 2

Focus: achieved through helical focuser to get minimum HFD.

Multistar: Always on

Calibration: Usually done start of each session followed by GA.

Star shapes: seem reasonable : see attached photos

Imaging cam: ASI533MC, 3.75um pixel size. Imaging scale 0.565 as/px

Imaging: 2 targets / night - unattended (hence no manual intervention possible)

Problem:

The original setup was with Bin1. This led to several drops due to low SNR, so switched to BIN 2.

With BIN 2, stars are quite visible and most of the time, PHD2 will find and lock onto multiple guide stars.

However, for some reason, at times it will just say star not found. Eg last night, a star is visible and seems to meet criteria, but is not recognised.

On manual selection of the star, it then works fine for guiding

On meridian flip, the same set of stars are usually recognised without issue automatically.

I can check this when starting the session, but the problem usually comes at night when the sequence moves to another target.

Note that there is significant light pollution near the horizon, so the sessions usually start at 45 degrees plus. The 2nd target, which is when the problem occurs, is always near midnight and generally above 45 degrees as well.

Questions:

Is this a setting issue?

If so, what would be the recommended settings for my setup?

Thanks in advance

Ar Bit

Notes on attached log and images :

The first guiding session starts in the evening and is okay.

The sequence switches to second target at 00:40, which is when PHD2 fails to lock. 

The debug log for this starts at 00:40:19.008

Around 03:24, the star was selected manually. It then guided fine.

After the flip, it locked onto stars automatically - no problem.

The images are from an earlier session (sorry but was too sleepy at 4 am to tak snapshots:-) ). The first shows no multistars selected though stars seem available. Second shows auto-selection after the flip. 

So the consistency is missing.

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

[bw_msgboard]

Hi Ar.  The statistics in the debug log indicate the guide camera images are really poor, Nearly all of the stars that are found have single-digit SNR values and those are going to be very prone to star-loss.  The star you chose manually at 03:25 had been rejected because it was very close to a different, dim star.  We reject those because it makes the guiding prone to hopping back and forth between star, especially when large moves are being made like dithers.  I see two things you've done that are a problem: 1) you're only using 1-second guide exposures and 2) you've reduced the gain from the recommended 95% to 75%.  Why?  It's also not clear to me whether you created separate profiles for bin-1 and bin-2 operation.  You should always keep them separate, changing it on the fly is not a good idea.  You simply can't assume that a meridian flip is going to successfully find stars with such a low exposure time.  Fortunately, you can see exactly what happened because PHD2 saves the guider images when an Auto-Find fails.  If you look in the logging directory for PHD2 - that's shown in the 'Global' tab of Advanced Settings if you don't know where it is - you will find a bunch of folders with names like this: PHD2_CameraFrames_2022-02-12-003942.  Each folder will contain a .fits image of the data PHD2 was trying to use - un-stretched, un-compressed, a raw image.  The folder and file names include strings that identify the time the auto-find failed, looking like YYYY-MM-DD_HHMMSS.  I think you should examine these images and see whether you think they contain high-quality star images - my guess is they will not.  Don't be faked out by hot pixels or clumps of pxel noise.  If you disagree, you should post them on a cloud-service of some kind and send us the shared links.  But I suspect you will need to improve the quality of the data if you want to run un-attended imaging without fear of not finding usable guide stars.  Lots of people, including me, do unattended imaging like this and don't have problems finding guide stars even in small fields of view.

 

Regards,

Bruce

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Ar Bit
Sent: Friday, February 11, 2022 10:43 PM
To: Open PHD Guiding
Subject: [open-phd-guiding] PHD2 star finding inconsistent with OAG

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/fc8e3812-3747-4f32-8144-da62483bb87an%40googlegroups.com.

[Ar Bit]

Hi Bruce,

Thanks very much for taking the time to go though the logs and the detailed analysis.

To answer your questions:

1. The BIN2 was done at the beginning of the session and PHD2 recalibrated after that. So I don't think that should be an issue. Thanks for the tip on separate profiles for BINs.

2. The gain was 75 because when I selected the star manually, it was saturated, so I dropped the gain to compensate. I now see that would cause problems in auto-selection, so will move it to 95.

3. The 1 s guiding period is because GA stated drift limited exposure of 1.5 sec that session. Hence I put it to 1 sec. My mount is CEM26 which has a periodic error of 20as peak to peak.

4. As you suggested I checked the saved file in FITS, and the stars are poor. To the extent that Siril could not identify any for PSF determination!

5. I also ran the same OAG and guide-cam with a 700mm focal length yesterday and had absolutely no issues, either with selection or multistar.

So, the cause does seem to be poor quality stars caused by a combination of small FoV (1370mm fl) coupled with the 1mm exposure time. 

I will try again with gain at 95.

The only question I have now is how much I can set the guide period compared to the GA? So far my assumption has been that if GS says 1.5 (for example), its better to set it slightly lower. Is 1.5, or even 2, okay?

Thanks again

[Ar Bit]

I should add another point. First half of the night the guiding ran smoothly for 4 hours.

The difference was that the first target was in a star rich area, the second in a sparse area.

I suppose settings should cover the worst case, as PHD will anyway find non saturated stars easily in a rich starfield?

So 2 questions really

1. As above, how do you use the GA drift limited exposure to set the guide exposure period?

2. If covering areas with different star densities in a night, should settings are set for the worst case?

Thanks 

[almcl]

Short answer to question 1 is you don't, but see the second post this topic for a better (and more expert explanation) :

https://groups.google.com/g/open-phd-guiding/c/_h_oc7pLIL8/m/CJDMOC6gAAAJ

[bw_msgboard]

Hi Ar.  I'm traveling today but I'll get back to this tonight and give you some suggestions.

 

Bruce

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Ar Bit

Sent: Saturday, February 12, 2022 11:45 PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding] PHD2 star finding inconsistent with OAG

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/991822e9-f630-4e21-9015-face292a0bccn%40googlegroups.com.

[Bruce Waddington]

Obviously, you have to give priority to finding usable guide stars with sufficient SNR values.  For unattended imaging like you do, the "auto exposure" feature can work well because it avoids the problem of having to configure for worst-case conditions.  Basically, you give it a target SNR and a range of exposure times that you're willing to use to achieve that target.  PHD2 will use the shortest exposure time in the range to meet the target, adjusting the exposure time as needed even from one frame to the next.  You may want to set the minimum exposure time to 1 second but you'll have to figure out the appropriate settings for target-SNR and the maximum acceptable exposure time.  The default SNR for finding stars is 6, which is actually quite aggressive.  On my long focal length system, this value is too low because the seeing can cause the SNR values to fluctuate below 6 and I get too many lost-star events.  The maximum acceptable exposure time depends on your mount - at some point the guiding frequency is too infrequent to avoid trailed stars and lost images.  If you look in the debug log files, you can get a good idea of your typical star-finding statistics.  Do a text-search on AutoFind and you'll find a human-readable trace of all the stars that were detected, their locations and SNR values, and which ones were accepted/rejected and why.  This is how I deduced that you were getting low-quality guide camera frames with objects that weren't readily identifiable as stars.  You can probably figure out what SNR is needed on your system to maintain steady guiding without excessive lost-star problems.

All of this depends on the details of your optical setup, your sky background, and the sensitivity of your camera.  You may decide that you need to upgrade the guide camera to achieve better sensitivity.  Coming back to your question about the drift-limited exposure time in the Guiding Assistant: this is a pretty volatile statistic and as Brian said, it's more useful as information rather than as something you take action on.  It's basically a one-time measure of the steepest RA excursion that was seen during the course of the GA run.  It's a raw number so it can be affected by seeing fluctuations or other one-time events.  

Since your mount seems to have pretty poor native tracking in RA, your best bet would be to do a high-quality periodic error correction.  Although this wasn't possible for many iOptron mounts at some point, we've heard from multiple sources that the problems have been corrected or at least mitigated on some later versions of the iOptron firmware.  It would probably be worth your time to pursue this alternative.  You can also try using the PHD2 PPEC algorithm for RA guiding, giving it an initial period length that matches the worm period of the mount.

Regards,

Bruce

[Ar Bit]

Hi Bruce,

This is just an update on how I've got the issues sorted out - based largely on your suggestions.

1. Multistar guiding failing: 

a) The pixel search area was 50, moved it back to 20. Now it works fine. I suppose the large distance made the algorithm reject several stars within that radius!

b) Aligned the sensor with the OAG opening to maximize guidecam imaging area (it was at almost 90 degrees earlier).

2. Poor star quality: 

a) Changed exposure from 1 sec to 2.5 sec (auto on bad seeing nights)

b) Changed back to 1x1 binning. The 2x2 was too coarse maybe?

c) Increased camera gain to 80-90 (depending on transparency etc)

3. Better RA tracking : tightened the mesh 

4. Analysed the star quality, and realised it is much worse to the East where there is a huge light dome (my skies are sqm 17-17.5) which seems to be killing the star contrast. So have adjusted my imaging altitude start correspondingly.

Overall there is a huge improvement. Thank you again for your help and suggestions.

The only thing I have not had any luck with is PPEC. I tried for a 32 min session (worm period is 10 min), but didn't see any improvement. I had set period to 600 (based on the dominant frequency in the PHD Log viewer analysis), and adjust to auto. What am I doing wrong?