My objective was to set up and run a bare-bones test sequence on M67 consisting of 240s exposures, with 15 L, 5 R, 5 G, and 5 B. Follow on tests will incorporate autofocus based on star HFR changes.

I checked the sky conditions at sunset (1739) and saw some clouds low on the western horizon, but the sky was otherwise clear. Some clouds were starting to roll in when I went to get the equipment powered up and ready at 1825. The forecasts suggested that the clouds might roll back out at around 8pm.

The temperature was 62 degrees when I went outside. It took me just twenty five minutes to power up, polar align, star align, focus main and guide cameras and do a rough slew to M67. Prep work that I didn’t need to do was a drift polar align using PHD and I did not need to a PHD calibration because the optics were not disturbed after the last one.

I have had an interesting polar alignment revelation. Based on results from 2022-02-08, I questioned whether PHD’s measurement of a 34’ (yes, minutes) polar alignment error was a false reading related to whatever mount issue was preventing a valid calibration, or if the 34’ polar alignment error was an actual error that remained after the PoleMaster alignment. If the latter were the case, I would be unable to trust PoleMaster. I had intended to cross check the PoleMaster result with a PHD drift alignment on my next time out (2022-02-10). On that night PoleMaster asked for an ever so slight elevation adjustment from the night before (certainly not 34’). I attribute the adjustment to the soft ground and that I had been working on the mount earlier in the day. PHD gave me a good calibration, so I went to the PhD Guiding Assistant tool was reading a polar alignment error of less than 1’. It seems to me that the work that I did on the mount that day permitted valid calibration (even though it flagged Dec backlash as 1000ms). The valid calibration enabled the Guiding Assistant tool to correctly read the polar alignment error. So, the revelation is that mount tracking issues can cause invalid PHD calibrations, and invalid polar alignment error readouts.  

After coming back inside, I was ready to run the a test sequence that I had previously set up in NINA, but the clouds had rolled in by then (1850). I monitored the cloud situation remotely. The sky cleared at 2100, at which time I initiated the test sequence without needing to go back outside.

I posted the first frame of the sequence to flickr with very slight and rough processing. I noticed that there were several dust motes in the image.

At about hour and 11 frames into the test run, my remote connection dropped. I was not able to restore it over wifi, or by going outside to make a physical Ethernet connection. I could see that the remote computer was powered on, but I didn’t know if it was still running the sequence, so I shut it down and packed it in for the night. In the clear light of day, I realize that I could have checked the OneDrive folder to see if frames were still coming in (and they were), in which case I could have let the session run to completion. Other than seeing if a restart of the remote computer will let me establish a connection today, I don’t know how to figure this one out. Hopefully it is a one-off.

This was another good night for me. I think that I have reached an understanding of the hard problems that I faced when I attempted to return to DSO imaging in the early fall. I have made good progress with these issues, and I feel that I have a good handle on additional tracking and guiding improvements that can be made. Interestingly, the planetary work that I did during the summer, which included manual guiding, did not reveal any of these problems. DSO and planetary imaging are two different animals.