Hej Doug,

I'd say that isn't uncommon for standard rack&pinion focusers. And there's no real issue with that, IMO. That is why we use a stepper motor that has no problem doing single step accuracy. The 10:1 is for "clumsy fingers", but always has the chance of inherent slip, so it's really not recommended if you want reproducible focus-by-number. There's no gain of accuracy in having 'big numbers' when using a stepper motor.

As for the low 0.75μ/rev, that sounds to me like it is the movement of the main mirror, not the movement of the focus position, so that would get a magnification of about 10 from the secondary re-imaging, depending on your type of optics. Would still lead to quite large numbers, but that is really just focuser specific. A Crayford likely also has smaller step sizes than a R&P.

Cheers & Happy New Year!

I run my refractor (140mm, F/6.5) with a step size of 20, and the Linear 1P algorithm. The NCFZ for my setup/site is 31μ, or 11 steps. The chose step size stems from the first linear implementation that did the second run at half step size. I didn't change that when switching to L1P, but at least for me the interpolation it does usually leads to very good results.

As you mention, it is somewhat crucial to have a good start point, even without the donut problem (refractors don't have that). I think the (L1P) algorithm has improved in that respect, still it is (IMO) highly recommended to do an initial manual focus (I use a bright star and video mode). Doesn't have to be extremely accurate. And for automated AF, definitely use filter offsets if you use a filter wheel.

Thanks @Doug and @Peter.

Indeed, I use a refractor with the RnP focuser and indeed, its very long in comparison to the NCFZ, but I think it's for the purpose of accessories I can attach.

Speaking of the accessories, I don't have the filter wheel and also have no mono camera yet, but only the Canon 6D. I use 2" filters and I think about the filter wheel to simplify my work. I.e., I think now to use an OIII filter to extract more oxygen from nebulas. But I don't understand the offset, what is it in the context of the focusing? I remember from the documentation that I can set fixed number of steps that I can add or subtract from the given by the algorithm value, am I right? Shouldn't I need to refocus then?

Martha

Hi Martha,

yes, the long available range is to allow various optical configurations. Like adding a star diagonal for visual, various correctors, barlows or reducers etc. that require changes in back focus. If you only use one configuration it will stay at one position almost all of the time.

As for filter offsets, if (once...) you use a filter wheel there is the option to have a list of relative focus positions for each filter. You have some sort of reference (like L, or in case of RGB, G), and for other filters that table tells how much the focus differs from that value. If you then change to another filter EKOS will compute the needed focus change, and apply the difference, so that a consecutive AF run will already start at focus. Or you trust that, and start imaging. (I'm wary, and always do AF on filter change).

With manual filter changes that won't work, so forget about it for now.

And careful with the OIII filter - they are not really suited for color cameras, as many pixels will not get any light at all. There are special dual-band or triple-band filters made for color cameras. I have no experience with them, though. But my guess would be for a normal (photo) camera they might also be sub-optimal, as those cameras often block the light of Hα. So better ask around before taking (a lot of) money in your hands...

Thanks @Peter.

I already have the L-eXtreme and the Baader OIII filters. I agree that the OIII filter is not designed for the DSLR camera. But I experimented with separating the Red (in the grayscale) as Ha and the G+B (both in the grayscale) as OIII and I have to say that the results look very positive. I know what the RGGB mask is and I'm very optimistic in the idea that the double G and B can collect some significant amount of proper photons. My Canon 6D is modded, so it collects too much red light, so the separation and balancing the layers are difficult. But I am considering adding a stack of the extra OIII subs to the G+B channels. Just look at my pics of the Heart and the Soul nebulas post processed in the typical way and in the new approach:

www.astrobin.com/users/Vroobel/

Finally I know why the pre-focusing as best as possible before the run of the focusing is so crucial. I'm going to find the best initial position using a Bahtinov mask that I designed and printed (satakagi.github.io/tribahtinovWebApps/Bahtinov.html). Since then my routine will be as follow:

1. Zeroing the position with forcing the real zero at the EAF as well,
2. Moving to the position defined experimentally with the Bahtinov mask,
3. Running the focusing procedure.

I found that after positioning the focuser at the real zero, the end of the travel through all the length of the tube each time takes nearly the same number of steps, so I assume that the initial position for the focusing procedure will also be nearly the same each time.

As I wrote, I'm going to compare the linear algorithm with the polynomial one.

Martha

Hi all,

I'd like to share results of my first focusing with the EAF and the linear algorithm: I love it!

All calculation works perfectly. I didn't use the Bahtinov mask, just positioned the EAF at the calculated position taken from the previous session without the EAF: 7600 step. After five attempts it began behave properly and I found highly repeatable focus position: 7715 steps. Every time I go back to the zero position and then I position it again at 7715. Moreover, all the time I had a proper number of stars in the area 25%-75%.

I promised to compare the algorithm with the polynomial one, but please, not today. I have several hours without the rain, so I must to use the opportunity.

Look plesae at the animation of the process, the V-curve is iconic!



My setup:
Altair 102/715 EDT Triplet APO and Canon 6D

My Ekos settings:
Auto Select Star | Ful Field | Annulus: 25% 75%
Detection: SEP | Algorithm: LInear | Tolerance: 5%,
Initial step: 16 | Max travel 250 | Settle: 1s

Hi Martha, Not that it made too much difference, but you may want to loosen just a bit the tolerance to the routine. If you notice, it didn't stop at iteration #14 when it probably should have). I'd set that at 7% or so and see if that doesn't get you a slightly more efficient answer. To my eye, the routine overshot just a hair (not enough to be outside the CFZ), but enough to cause a few more iterations than necessary.... I was also a bit surprised that the ramp on the left side was muted. That didn't look quite right to me as I would have expected it to ramp quickly (as quickly as the fall on the far right side).... In any case, these are nits, glad you have it working. CS Doug

I'd like to share results of my first focusing with the EAF and the linear algorithm: I love it!

Hehe, who would have thought that

If you have time, definitely also gibe Linear 1Pass a try, using the 'Parabolic' or 'Hyperbolic' methods, including weighting. For me, that is even more stable than simple linear.

For the comparison with polynomial: Keep in mind that that one doesn't do any backlash compensation, and does move in both directions. So to do it justice, you'll first have to measure BL, and activate BL compensation in the driver - else the results will be very random...

Thanks @Doug and @Peter,

@Doug, the presented V-curve is not the most weird, look please at the one below. I began at 7715 and finished at 7715, the HFR is even better, but the shape is not. Can you try to explain this behaviour?
I'll try the 7% next time and then will also try to shorten exposures with higher ISO value. Now I used 15s at ISO16000 (IDAS LPS-P2 filter), I'd like to drop it to 10s or less, because it takes time as well.



@Peter, I cannot find the Linear 1Pass. I have only the following algorithms on the list: Iterative, Polynomial and Linear. Is the Linear 1Pass algorithm introduced in the most recent version?
I know that the polynomial algorithm doesn't take the backlash into account by default, but I don't know how to measure it. It must be a long cloudless night to test everything, without the rush and risk that darks or flats may fail because of sudden rain. I expected the rain at 5am, thankfully a tree appeared in the frame, so I stopped doing subs and finished at 3am. God, my location teaches me humility...

Hi Martha, I can't explain that motion. Notice 6 final 2nd pass measurements were taken between two of the 1st pass measurements to end the routine. That is odd. The last multiple measurements are below the HFR poly fit. My first question would be was the guiding stable during this time? If the guiding isn't remaining stable during the routine, you can get some odd shapes on the poly fit. Backlash can also cause odd behavior (especially in the beginning of the 2nd pass because the routine thinks it commanded N backward counts but due to backlash it's not delivered, so the HFR measurement is lower than it should be). In any case, there's not enough info to explain those last 6 measurements. That said, I know what I don't like when I see it, and I don't like a focus run like that. At f/2, I would run that focus again until it produces a "cleaner" answer. At f/7 maybe it doesn't matter quite as much. Are you using an averaged/multiple HFR reading in your settings? If not and you get this kind of result often, I'd suggest using an averaged 2 HFR measurement setting. It takes a bit more time, but it takes what it takes. Good focus is ESSENTIAL!

Just a note about backlash. You don't need to test backlash outside. You should definitely test that inside. Run the motor in a direction while watching the coupler set screw position. To initialize the test, first run in one direction until you see the coupler set screw move. Note the motor count position. You are now ready to start the test(s). Reverse direction and run until you see the coupler set screw move again, noting how many counts occurred during no motion. Reverse direction and run again until you see the coupler set screw move again (and note count again). Do this test multiple times in both directions until you are reasonably confident you know the # of counts of no motion. This is your backlash count value. Don't be surprised if different directions give different backlash counts; just average the number or pick the highest number (they should be reasonably close to each other). If they aren't very close to each other, I'd use the inward value (to match the algorithm's behavior). As I indicated in a prior post, expect between 80 and 100 counts for EAF; that's what I have experienced and have heard from other EAF owners.

@Martha: What version of kstars do you run? L1P was added in July (git), and was in the 3.6.0 release, so I had just assumed most people run it by now. My fault . No worries, just keep in mind to test it once you update to something >= 3.6.0

As for measuring backlash:
Make sure the BL compensation in the driver is off.
Do two focus runs (with linear), note the average value. Then go to the INDI tab of the EAF. There's a 'Reverse Motion' Button. Toggle that, and repeat the focus runs, twice again. The difference of the two values should be a quite good starting point for the BL compensation.
If clear sky is too expensive to waste you can also do it inside, but you need a good caliper. Just step the EAF in one direction in small steps, and with each step measure the position of the focus tube relative to the OTA. Once the change is linear, step in the other direction, again noting the focuser tube position. Continue until that one changes linearly.
If you plot those (position vs. EAF reading) you should see two straight lines, maybe some deviations in the start and turn area. Draw a horizontal line through a region where both are linear, and look up the EAF readings for the two positions were the horizontal line crosses the two sloped ones. The difference is your BL.

@Doug, @Peter, thanks for another guide.

I realised that I should have literally very accurate caliper to be able to measure a difference caused by the movement like i.e. 10 steps. I have two calipers with digital displays and one vernier caliper which I prefer because of its absolute indications. The "digital" ones like to lose their zero position by accidentally pressing the zero or other buttons. The impossibility of making a very accurate measurement prompted me to place my own method based on interpolation here, maybe someone else would like to repeat it. It gave me a very probable result, similar to the results already mentioned in this thread.

Right, so I assumed steps equal to 100 ticks and beginning at 10,000 I performed 31 steps. Every measure, especially a difference between the actual and the previous ones, even affected by errors related to the inaccurate reading, are summarized and divided by 31 that gave me an average difference between positions equal to 0.37mm for every 100 ticks. I made a chart giving me three positions of the tube where the backlash seems the same: 38mm, 40mm and 42mm. To be honest, I don't know why the backlash looks smaller in the right area of the chart.



Knowing that, I interpolated the values of position of the tube as equal 1/20 their theoretical positions in relation to a 5 ticks step (1/20 of the 100 ticks step) for the three areas. I found values closests of the 38mm, 40mm and 42mm both for the outwards and inwards directions and found respectively values of the backlash: 80, 95 and 95 ticks. Thus the average value is 90 ticks. Doug wrote that it should be between 80 and 100, so it's exactly in the middle between them.



You probably guessed that I like Excel.

Anyway, thanks for encouraging me to perform the experiment and now I'm ready to try the polynomial algorithm as well.

BTW I just checked the version of the Kstars/Ekos which I use, it's 3.5.9. I already performed the "update | upgrade" procedure to be able to test a patch in the INDI driver for OnStep firmware. Unfortunately, after the successful upgrade (observed) I found that both the Canon DSLR driver and the ZWO CCD driver didn't recognise my cameras. I always have at least two microSD cards for my RPi, just to quickly swap them i.e. if file system crashes (often happens in the RPi 3B+, RPi 4 seems OK yet), so I checked whether the cameras work. I described the problem here:

www.indilib.org/forum/ccds-dslrs/12804-i...asi-ccd-crashed.html

As long as the problem is not solved, I don't touch the higher version. It's enough for me to use the linear algorithm interchangeably with the polynomial one.

So, thanks for all now and let's see how it will behave.