New option for well aligned mounts


#1

I have been using a camera lens system and a well aligned Paramount with a large model and Pro Track. It is able to track well enough so that at 200 mm I can get nice round stars even on 20 minute exposures so do not need to guide that system and therefore use SGP’s “dither by mount” which works very well and is very fast. No PhD there at all.

I also have, on the same mount, a 1000 mm refractor with a guided camera (STT 8300 self-guide). With that well aligned mount and Pro Track, even at 1000 mm, moderate length unguided images are possible (although only limited testing done so far as to possible maximum times - but probably less than 5 minutes).

So that begs the question:

Is it possible, instead of having PhD dither by guider, to have SGP randomly bump the mount as in “dither by mount” and just order PhD to reacquire the guide star instead of a conventional dither? Conventional dither often fails with extremely long guide times (30 seconds and up) or at the very least takes a very long time.

Andy at PhD where I first posted the suggestion, thinks it more easily done in SGP than PhD and said:

“SGP could command PHD2 to stop guiding (send the “loop” or “stop” server command), do the “dither by mount”, then tell PHD2 to start guiding without any settling delay.”

The reason for all of this is that I would like to go for guide times as long a 2 minutes - this would allow excellent averaging of seeing and fewer corrections - It is very clear from watching PhD guiding at such long guide times with the well aligned and Pro-Tracked mount that this works great. The problem now is that the conventional dither works poorly and/or takes too long in terms of settling to work with the guiding as presently done.


#2

I’m not entirely sure how this is different than a dither done in PHD2 with the settle set to 0? Is it because you’re guiding at such a long interval?

Thanks,
Jared


#3

Yes, I think it is the interval that is causing issues. Too long (more than 20 second guide times) often seems to trigger error recovery or worse. I can try zero settle and see if that works but dither by mount is so darn fast and effective with the cam lens setup that it occurred to me that doing that and just restarting PhD as in the first exposure might be better for this.


#4

Are you taking 30s - 60s exposures for guiding?! Seems that would not provide the best data? Like what you’d really want to do in PHD2 is set a 2-5s image and a 55s delay?

I mean the “Dither by mount and restart guiding” option would likely work. But it just seems link a clunky way to solve the problem. SGP does expect a “heartbeat” from PHD2 but I don’t believe that has anything to do with the length of the guide exposures. I’ll have to double check that.

Thanks,
Jared


#5

Indeed. 2-5 seconds is (and has been for the 20 plus years I have imaged) sorta the “standard” guide time. That is clearly required for probably 90% of mounts since most are either not good quality or not precision aligned and/or modeled (often due to many of them being portable setups).

OTOH, the big flaw is that 2-5 seconds does not even come close to being long enough to average out the effects of seeing. Just watching one’s guide graph on an average night should convince anyone of that. Sometimes there are many (2-5 sec) passes with almost no corrections and then one sudden jump (or more). Maybe wind, maybe seeing, maybe a bit of gear grit, the possibilities are many.

In order to swamp the sometimes somewhat large excursions (large being relative the the on-sky size of the imaging pixel), you really need the long guide integration time and for that not only the precision mount and adjustment but also the software configurations that can deal with the longer times. I suspect because the first is so uncommon, the second has never been developed to any degree.

The problems that arise from using long exposures are really twofold. One is that stars become saturated (not good for guiding) - but PhD or the user can deal with that by choosing a dimmer star. The second is that the softwares are pretty much not designed to handle such times so can tend to throw errors for various reasons.


www.mainsequencesoftware.com