I can now confirm DerPit's backlash comment. My EAF has tested today @ 95+/-5 counts of backlash. I definitely didn't expect that much! This has likely added spread in my dataset, reducing sensitivity, but even so, the story is pretty clear. It should be easy to tune and get a tighter dataset from here forward. I guess focuser BL tuning should be considered mandatory for low f-ratio systems!

Read More...

Now that you mention the 10/1 avoidance, I think I read that too somewhere. Still, that's a big thread. 0.13um for my setup is more resolution than I need, but I preferred this to the Celestron offering which was only ~1/5th (or less) the resolution. I wasn't thinking about HFR instability on V curve fit when I did this.....but regardless, I'm still happy with the EAF (or will be until I measure the BL).

Read More...

I'm going to need to think about what you've said. Using the CFZ formula from here (www.goldastro.com/goldfocus/ncfz.php), it seems you should not be able to tell any difference in 20um of change if already well positioned in the CFZ. Your CFZ size for 1, 1.5, 2, and 3 arcsecs seeing (10% tolerance) is 42um, 63um, 84um, and 126um respectively. I guess the real question is how did you arrive at 2.8um / step for your system? We're both using EAF. My Celestron focuser thread pitch is 750um/rev (0.13um/step). You've calculated 21x coarser threads (seems hard to believe, but I couldn't find the thread pitch for your focuser to confirm). Were you forced to not use the 10/1 fine focus on your setup, or have I screwed up somewhere in the calc?

Read More...

Thanks for the BL report; I'll definitely check mine for comparison. What focal ratio are you operating at? It would seem that 84 counts on an EAF shouldn't produce that visible of an impact unless you're operating at low f ratio....but it's an interesting data point....so thanks for commenting!

Read More...

I haven't yet measured my EAF focuser backlash, but it's on the list of things to confirm this month. I'll use a caliper and manually drive focus to check it. I'm a bit uneasy about the flexible coupler ZWO uses (between motor shaft and focuser shaft), but I think it likely is ok and shouldn't add significant BL. I suspect EAF, Pegasus, and other similar focuser offerings are going to be well enough behaved to ignore BL. Just thinking out loud, I would guess that BL related skew would bias measurements without altering overall trendline slope. The integrator already addresses prediction bias (back to autofocus position); it should cover BL bias too. It's a beautiful theory that could be wrong, but early testing seems to bear this idea out.

Honestly, I'm much less worried about BL than I am with position errors introduced when linear autofocus pulls up short. That kind of error needs to be addressed. Beyond the obvious logged position error, introducing AFC would have the effect of "freezing" that bad relative position offset and holding it, resulting in AFC being less ideal than if multiple sloppy AF runs were done (assuming that some of those AF solutions would be good). I need to talk to Hy offline about what these charts suggest regarding sufficient precision of linear AF solutions, and how that might lead to some improvements. More later.... Cheers, Doug

Read More...

I've updated the charts in the OP (now ~1 year, 350 autofocus runs at night). The temperature data now slightly favors a weak quadratic fit (but I'm still showing a linear). The temp ranges from 20F to 70F. I've also examined focus sensitivity for different systems against seeing (1.5 to 3 arcsecs, f/2.2 to f/10 setups). For ease of understanding, I have attached two graphs, one showing a CFZ perspective (microns), and the other using an EAF quality focuser (5760 counts per revolution) combined with a 750um focuser thread pitch (resulting in focus counts). In case it's not obvious, f/10 or f/7 setups won't need Adaptive Focus Control (AFC for you football fans). In good/best seeing, f/4 might benefit. In all cases, f/2 and f/3 need AFC. Those of us with f/2 or f/3 systems know intrinsically what the charts are saying; the current focus adjustment controls (think scheduler, time/temp deltas) do not suffice. I've also attached a temperature chart from this month to support that assertion.

This month, I used a stand-alone program to manage an autofocus "integrator", and manually offset focus between exposures as temperature and elevation changed. Manually intensive, but the results were very satisfactory! There appears to be no Ekos "gotchas" for updating focus between exposures. Adjustment could be coexistent with download, dither, or exposure delay timing. I was easily able to maintain focus in my f/2.2 rig as temperatures rapidly changed. One good seeded autofocus and then occasional updates between exposures will keep focus well managed. Only 1 autofocus needed per target!

So a couple of thoughts. My 7 night January run had some bad seeing in it. Autofocus has difficulty when HFR readings are bouncing all over the place. This adds to spread in the logged data. Linear autofocus tends to pull up short of the bottom of the V curve in bad seeing, especially if the last HFR reading (averaged or not) is marginally higher than the prior HFR reading. Getting one good autofocus result, followed by AFC updates, seems like a better approach to managing focus than risking N funky autofocus results. Bad autofocus endings skew the log data; not sure how to adjust for that yet. Finally, while I started this idea thinking that a seeded autofocus was the goal, it now seems clear that AFC between exposures IS the goal. A seeded autofocus start is still desirable, but realized AFC between exposures is a "can't live without" kind of feature for f/2 & f/3 systems! So work will continue.... cheers, Doug




Read More...

One thought for you that might help avoid trouble in the future is to ditch the SD card in favor of an SSD boot. Those SD cards have a definite lifetime, and SSD is both faster and more robust. Search for "Zippity" in the forum posts and follow the directions. I've done this and it has worked out very well. No more SD card to worry about. FWIW, having an SSD in the config is nice for local image storage too (no night-time network/wireless transfers). Cheers, Doug

Read More...

Doug S replied to the topic 'Powered USB Hubs' in the forum. 7 days ago

FWIW, I use Crucial SSDs and they work fine in cold temps (-12 C in the last few days):
Crucial BX500 120GB 3D NAND SATA 2.5-Inch Internal SSD, up to 540MB/s - CT120BX500SSD1Z

Read More...

Doug S replied to the topic 'Option to avoid DEC reverse motion?' in the forum. 1 week ago

Hy,

Thanks for all your work on this. I tried to switch back to the internal guider from PHD2 the other night, but was halted by DEC backlash issues during calibration. I took my scope down and have chased this to tune it up a bit, but I also wonder whether there shouldn't be an option to disable reverse DEC moves during calibration. This still allows the calibration angles to be set, but avoids getting stuck by DEC backlash. Forward calibrations would work normally, and reverse motion on RA would still function the same. Not doing a DEC offset back to original position would force the user to resolve (if desired), but that seems minor. This could open more doors for folks with DEC backlash.

Now that I think of it, I'm not sure there's an equivalent option as in PHD2 to set or disable the DEC guide direction. Do we have that? That feature would be desired too (so some folks could intentionally misalign PA, forcing DEC motions to be unidirectional. Anyway, just a couple of thoughts to possibly make this handle some bad cases slightly better.

Cheers, Doug

Read More...

You have options, but probably best to run the internal guider (using multistar). You could run PHD2, but if you did this, you'd want to run it on the Pi4. With the latest updates to the internal guider, there's no real benefit to using PHD2 unless you can't see polaris (so need drift align from PHD2). The internal guider implements multistar guiding, Periodic Error prediction, and logs in a format compatible with the PHD LogViewer. So, probably best to just use the internal guider. The major difference you'll notice right away is that the calibrations are shorter in Ekos (but these are configurable if you so choose). You also won't have a "guiding assistant", but most folks don't really need that. Cheers, Doug

Read More...

I'm wondering if anyone has a good trick for setting the desired initial file sequence number for captures. If I've previously captured up to #100 and moved them out of the folder, but now want to capture another set (starting at file 101), how do folks typically do that? I think I can manually force this by leaving the last captured file in the folder, but is there an easier way to set the starting sequence number that I'm missing? Thanks.

Read More...