Doug S replied to the topic 'Celestron focus motor' in the forum. 9 hours 2 minutes ago

Yea....you're probably right. I had a similar question for Celestron Tech support when I fit my ASI EAF motorized focuser to my RASA 11. They told me it was 0.75mm. It's entirely possible that they've used the same pitch on most of their scope sizes, but I wouldn't bet my life on it. I suspect if you use 0.75mm for your calcs, you're not going to be very far off....

Read More...

Doug S replied to the topic 'Celestron focus motor' in the forum. 9 hours 47 minutes ago

Hi Mohamed, I got the thread pitch info from these sources (not authoritative, but the info seems trustworthy):
agenaastro.com/articles/guides/miscellan...reads-explained.html
agenaastro.com/articles/guides/focusers/...ser-on-your-sct.html
Cheers, Doug

Read More...

Hi Const....no need to interrupt your observing at all! Just observe as you normally would, preferably over multiple nights even. Use autofocus whenever desired (as you normally would). The only thing you need to do is enable focus log debug. The output of those autofocus runs will be stored in the autofocus debug log (see the original post again for the details where these are stored). Build up a dataset over however much time you want. Whenever convenient, go back and snag those logs and plot them. The only caveat is that you shouldn't mess with your focuser (like take it off the scope). If you do, make sure you index so you can get back to a consistent location. Simple! Cheers, Doug

Read More...

The condition you describe is one of several situations where autofocus gets off the "sweet spot", then struggles to recover (potentially impacting scheduling). This is exactly why I've suggested we need to think about temperature and elevation focus compensation to improve starting seed position for the autofocus loop. Just remembering the last successful position won't work for several situations. I don't want to hijack this thread; I'll just note another topic for those interested. Cheers, Doug

www.indilib.org/forum/ekos/7626-temperat...us-compensation.html

Read More...

Hi bdavis. I think you're driving toward a much more complicated automation regime than what I've suggested (i.e. elimination of autofocus). I fear that would be very unlikely to ever get implemented (unless you write and test it yourself). What I have suggested in this thread HAS been implemented at multiple large observatories. I know this because I personally worked on the temperature and elevation compensation model at the Large Binocular Telescope, and a similar strategy (lookup tables) was employed at Keck where I worked before LBT. I have used the data I posted for my own f/2.2 RASA 11 (highly sensitive to focus) and it works great. Whether I can convince you of the suggested approach is moot. The proof is in the results and is available to everyone. For the unbelieving, a better question might be: "how and why could this improvement approach possibly work?". So let me try and address that just a bit more.

The temperature component works because the dominant error we're beating down is structural (lateral shift of optics due to changing temp of the OTA). The next component (residual of the temp function) has complex / multiple underlying reasons, but airmass (target el) empirically correlates against the residual to beat it down. Together, these two available variables get us within the ball park to improve focus management. The key to why this simplicity works is that we're NOT doing a one-time blind position update. We're not replacing the closed loop autofocus routine. We're only "seeding" the autofocus loop's start position. The autofocus loop is still responsible for resolving best focus position. Therefore, all the discussion about spread and CFZ size is misdirected. Ok, now to the next suggested higher automation level (updates between exposures). In that scenario, any position update would use the function outputs as integration OFFSETS from the base position determined by prior autofocus. Those offsets are small and driven by trendline direction. Here, the spread isn't as important as having the trend SWAMP the spread so the direction and magnitude keep us within the CFZ and REDUCE our need for another autofocus run. I mentioned to Bart that I'm not sure I would trust a blind update for a large elevation difference slew (and I still believe that). Bottom line: The work needed to do a one-time blind offset and ELIMINATE autofocus runs is well beyond the scope of this thread. So, whether or not I've convinced you, I hear you. I suggest if you want to discuss a "predictive focus tool" that eliminates the autofocus loop, please open a new thread for that topic. I'd like to keep this thread within the bounds of improving and reducing the existing autofocus loop interface (as opposed to eliminating it). Cheers, Doug

Read More...

Hi fewayne, FYI at the time of the post (7 months ago), the info was correct. The guide log compatibility issue with PHD LogViewer has since been addressed. There's still a couple of points unaddressed from my earlier post, but multistar makes up for it and then some. Ekos is much better for having all this new capability added in the last year! Cheers, Doug

Read More...

@alacant: re: "Are we now saying that shorter exposures are better?"

If you're referring to my post referencing shorter multistar exposures vs longer single star exposures, as I said, "it's complicated". The alignment/coverage/scale of the guide setup, geometry of the multistar constellation, star separations, SNR, the extent to which the mount is polar aligned, any oscillation behavior in the mount, etc., etc all play in the error budget. A well distributed, balanced, fast and bright multistar constellation should outperform a slower single star setup. In practice, there's likely to be one or more other issues in play, so bias errors could be adversely magnified. The answer to "go faster or slower" is likely going to be widely variable among users, and likely variable for the same user/gear on different targets and nights. That said, the anecdotal evidence being suggested by users thus far is pretty encouraging! I think experimenting a bit with exposure durations in the multistar config could be worth the effort. Cheers, Doug

Read More...

Hi Wouter, You've overestimated the distance that two stars must be apart before differential seeing takes effect. The scale is arcsecs vs arcmins. See this post for a really good discussion of this:
www.cloudynights.com/topic/694739-autogu...imultaneously/page-2 (note that you should scroll down to comment #48...to view the most relevant material).
Whether or not our algorithm implementation has correctly averaged the independent contributions of multiple stars is a different matter. In principle however, a multistar guide algorithm should perform better with increasingly shorter exposures. For progressively longer exposures, seeing is of course being averaged out. Whether we can get exposures short enough to cross-over and outperform a long(er) exposure single star approach is TBD. Star constellation geometry and other factors will likely play roles too, so it's likely complicated (of course). In any case, it's a really interesting topic. The testing needed to drive out conditions/constraints where multi-star might outperform single star guiding would be interesting. This is good full-moon engineering time fodder! ;-)

Read More...

Doug S replied to the topic 'Celestron focus motor' in the forum. 2 days ago

@mhammady: The 8SE appears to have a thread pitch of 24 threads/inch or 0.94488 threads/mm (1.0583mm/thread(or 1 rev)). You're at F10, so your CFZ is on the order of 2.44*10^2 (244um). If you were to use the Celestron (1k cnts/rev), the math works out to 1.058um / count or 230 counts "length" for the CFZ. The ASI has 5760 cnts/rev, which works out to 0.1837um/count (1328 counts CFZ width). That's overkill unless you know you'll be adding a focal reducer. As Bart indirectly points out, at F10 and 200 counts/rev, you'd have a CFZ length of 45 counts. That seems "skinny" to me. 400 counts/rev would give you 90 counts CFZ length. 1000 would give you room for that focal reducer you're going to want ;-) . My 2 cents. Cheers, Doug.

Read More...

Doug S replied to the topic 'indi_celestron_aux' in the forum. 4 days ago

Hi Fabrizio, I read with interest item #2 above (Plate solver sync). I have a CGX-L, and use the standard Celestron Indi driver. Some time ago, I was asking if platesolved sync's were sent to the mount to help build up a pointing model. If I remember right, I was told that the driver couldn't do this (no way to provide the offsets/updates to the mount). What do you mean by "add all required sync points"? Is this just for Kstars/Ekos use, or is it for the mount's internal pointing model (typically provided by N star alignment via HC)?

Read More...

@Bart: Re: "would you consider to focus during imaging or quickly adjust the focus in between lights?"

Well, the data for my fast (f/2.2 setup) indicate that I "could" change the focus by 60 counts per degree F change, and ~21 counts per degree elevation change. It's tempting to think about an experiment with this and do a build where an auto update is done between exposures. I also do short (30-40 second) subs, so an autoupdate might keep me from having to do an autofocus run (expensive!) so often at the start of the night. Whether I'd trust it for a big elevation difference slew is another topic, but it would be an interesting test. Eventually, and assuming a stable focuser with well controlled backlash, it might be quite effective at reducing the need for autofocus runs.

Read More...

Hi BDavis. Ok, we've come well off the intended scope of my post, and we disagree on too much in your latest post for me to comment further. FWIW, I'll hold the line that Bennett's graph definitely plots refraction as a positional offset vs apparent altitude (in units of arcminutes). Refractive index is dimensionless, and is a term itself dependent on other terms (temp, pressure, humidity, etc). Main takeaway: I accept that you believe refractive index is the driving function changing focus. We just need to disagree amicably.

My original post is simple: Two readily available variables in Ekos (temperature, elevation) can be used to dramatically improve focus control. I've shown a relationship of temperature to focus. I've also shown that once factored, residuals of a temperature function can be correlated to elevation. The data speak for themselves. Anyone who wishes can verify or refute the suggested relations by characterizing their own focus behavior via the focuser debug log. I am not stating that these two functions are the perfect and complete academic explanation. Rather, these two variables are readily available in Ekos, and serve particularly well to prevent poor auto-focus starting position, offset focus position between exposures, or prevent poor focus position after slews of large elevation difference. We're trying to remain close to the focus caustic. KISS can work well here. Cheers, Doug

Read More...