Nice work! It will be nice to see this included in the baseline. I've sent you a PM on another focus related subject that might be of interest. CS Doug
Hi John, I wouldn't think collaboration is required. The calculator is interesting, but unnecessary. The formula from www.goldastro.com/goldfocus/ncfz.php should suffice:
CFZ = 0.00225 · θFWHM · √τ · A · f 2
CFZ - Critical Focus Zone (micrometers)
θFWHM - total seeing (arc seconds)
τ - focus tolerance as a percentage of total seeing (unitless)
A - telescope aperture (millimeters)
f - effective imaging system f/ratio (unitless)
0.00225 - constant (micrometers per arc second per millimeter)
Given a user estimate of seeing, and their acceptable tolerance (both of which could be defaulted), and capturing system info (or having user provide) for aperture & f/ratio, the CFZ pops out. Step size is then just a fit of CFZ on the translation of motor counts/revolution and focuser travel (mm->microns) as discussed previously.
Ok, I sent a PM in reply to give you the code and offer up the config file and old GUI mockup to consider... CS Doug
Hi Matteo, ok, I understand now why you suggested max steps to reduce the measurement error. We agree that more is better in this regard. I think a tool-tip on the entry field could be useful for explaining that. The fields might be better named "focuser motor steps" and "focus travel (mm)" or similar. Then the alg should calculate microns/step, compare to calculated CFZ (based on the other params), and set the proper step size. CS Doug
Matteo and Bernd, Both of you lost me on your comments about pixel size. Camera pixel size doesn't enter the equation. Microns per motor step is the derived quantity we're trying to find, and that is found by running the focuser some predefined number of counts, and then measuring the drawtube travel. An alternative method would be to know the pitch of the focuser screw thread (a linear distance per revolution) and then factor the counts per revolution of the focus motor. Given that the average Joe observer is going to most easily move the focus motor by some number of counts (say 1000), and then measure the millimeters of focuser drawtube travel, the GUI could allow for those fields and then convert to microns per motor count. The rest is just the formula as given by the critical focus zone web link (which includes f-ratio, aperture size, a user preference for focus tolerance, and an estimate of seeing). See here:
Hi John, non-professional sites typically have seeing in the 2.5 to 3.0 (or worse) category. Folks love to claim they have sub 1 arcsecond seeing in their backyards, but well....you know how that goes. Anyway, I'd suggest defaulting to 3 and then users could change it if they want. You could also default tolerance to 10% (which should be fine).
Remember that only very fast telescopes (f2 - f5) will be particularly sensitive to the values. Those with f/7 to f/10 systems have such large CFZs that it's not going to matter much. About the thread pitch, I was being technically precise, but not implying that folks need to locate that info. The vast majority of people will simply run some reasonably large number of motor counts and measure the millimeters of focuser travel. If you allow entry of those numbers in the GUI (measured mm travel and motor steps for that travel) the alg could solve for microns/step internally to avoid that confusion for users. Measuring the focus travel is the only "hard" part; the motor spec will give counts/revolution via a simple google lookup. . Cheers Doug
Hi John, IMHO, the only step size that is "appropriate" is one that is tightly correlated to the CFZ size (in microns) for the instrument. This is what the Critical CFZ discussion I previously posted is all about. It's seeing and focus tolerance dependent after factoring f/ratio and aperture size. Whether one wants to be conservative and use a step size that is 1/2 CFZ (to always be sure to land in it), or less conservative (~1 CFZ) could be a user choice (but with potential consequences).
It would be best if the algorithm calculated step size from user input of how many microns per revolution the focus motor has, and how many microns of focuser drawtube travel occurs per revolution of the focusing mechanism. Not knowing these two values, and just "winging" a generic step size is just guessing. Folks should try to get some understanding of their CFZ and then set a step size to match the instrument. Since some will not want or know this info (or won't want to go to the trouble to find it), the guess may need to be allowed. But a better solution would be to allow for a precise calculation when the parameters are known.
A couple thoughts for you. I like the approach, it has a BIG advantage over the current linear alg in that it doesn't "pull up short" which has previously been described by prior posts on the subject.
My only suggestion is to consider whether you want to make the same mistake Linear Alg made in the Mechanics tab. Picking an "Initial Step", and "Out Step Multiple" has created a lot of unnecessary confusion for folks. In reality, the "proper" way to define the step size and out step multiple is to calculate those parameters from other system info as it relates to CFZ. Knowing the focus drawtube screw pitch and motor scale would ensure the correct step-size is used. Alternatively, not knowing these parameters creates the conditions for step-size exceeding the CFZ (jumps over), or too small (wasting focus time). This is completely avoidable. You might want to consider at least having an option to calculate the step size, correlating to CFZ, motor scale, and focuser thread pitch size. See the following info which might help:
Cheers, and good luck, Doug S
Hi Collin, there was some prior work done on this topic, but it failed to move forward due to the lack of GUI. Otherwise, it was completely developed and utilized a config file. You might want to look at this post for some details:
I've sent you a PM to see if you might like to work together. You should have it.
Some quick feedback on your approach is that logging additions have already been added in Ekos (released) to prep for figuring out the function coefficients for temperature (and altitude residuals). Another function has been written to analyze the focus log and produce the needed coefficients automatically. In most cases, the temperature relation is best thought of as a quadratic and not a simple linear function. Having used my own version of temperature compensation software for well over a year, and having 800 focus runs as the "database" for analysis, I find that the function's zero offset can change over time (not completely sure why, but it might have something to do with my EAF not having a "sure" reference position through power cycles). The slope is very stable (once enough samples are obtained). FYI, I did add the ability to update focus between exposures, and that allows me to keep focus at f/2.2 for hours even in dropping temps (verified by running unnecessary focus runs to compare). I consider doing focus runs by delta T, and/or after N time expiration to be a complete waste of exposing time. Finally, knowing the temperature, the focus algorithm (currently only linear) can be "seeded" with a proper starting guess so outrageous amounts of time aren't spent in "donut" territory.
As I said, if interested, read your PM and send a PM in return. Best wishes,
Hi Phil, Not sure I fully understand where you're going with the question, but beyond the lower right control for size, you can always use the mouse roller and click/drag to upsize the Ekos drift plot graph to only show whatever size circle you want. That includes preventing (for example) the outer red circle from being seen to emphasize only the inner yellow (or green) areas. I'm not sure you can get this to "stick" across sessions (i.e. you may need to do it each time you start up), but at least you'll be able to size the graph to closely approximate what you see with PHD2 if that's what's desired. On your second question, I believe the answer is no. CS Doug
Hi James, I can appreciate the frustration that comes with problems like you're seeing. We spend so much time getting past bad weather, and then it's terribly frustrating when things go wrong in software. That said, it's wise to have a better backup strategy. In my case, I ALWAYS keep a second PI4 with the last known working config on it (just in case). I don't update that config until I've checked out any new feature I want (and I don't update SW often now that I have what I need). That backup Pi4 has saved my butt a few times. The kinds of problems you're seeing may be frustrating, but are foreseeable and avoidable! For the low cost of maintaining that backup HW/SW combo, having it at the ready (just in case) is well worth it. Something to consider. CS Doug
Hi Ron, no need to spend too much time on the seeing issue. Unless you live on a mountain top, you won't experience 1 arcsecond seeing very often (and possibly never). Most amateur sites are in the 1.5 (best) to 3 (or worse) arcsec seeing regime. If you set up CFZ for ~2 arcsecs seeing, you'll be fine with that 1/2 mark discussed previously. Then, if by chance you get lucky and get 1.5 arcsecs or better on that rare occasion, you're still likely to be fine. Hope that helps, Doug