Yes, I had seen that 'Nothing' was checked as action for the pole solve, just wanted to be sure.
But the 'update' rang a bell. Are you sure that all components are 'in sync', especially the libindi and indi-3rdparty versions? The eqmod driver isn't part of the main indi, but it has to be compiled against the version used.
I personally also recompile kstars when I change the INDI version. Not sure if that is really needed though.
Just two quick comments:
If you have perfect PA that does not mean that automatically your main camera will be centered on the NCP. Errors in home position and things like cone error can easily put you off. Those errors don't matter for the PA process, PA itself is correct. So I would not call it a substantial error per se.
The other thing is that the poles are singular points in RA, and even tiny remaining errors in PA can lead to huge offsets. I strongly recommend to not use any plate solve close to the pole to sync your mount. Just go to some place further away from the pole to do a sync.
No, I think things are sorted out fine. Especially, for you the effect of the BL might be much less than for me, as you use the 10:1 fine control. It seems most of the BL (also mine?) is intrinsic to the EAF. In itself a good thing IMO, as then it very confined and one should be able to reproducibly correct it.
Maybe just one note: Watch out for drifts in your focus position that could indicate issues from creep using the 10:1 drive.
Sorry for the silence. No news here, the clouds are back, and the road to up above the clouds is closed due to landslides
Your explanation of the deviation seems very sound! I agree that the test was really a challenge, especially as my compass is in the observatory, and not here . But such extreme settings often help to pinpoint problems.
I absolutely agree that it's not really needed to change the plotting. If one gets such large corrections an iteration is needed anyhow, and that one will have better matched movement paths. So all fine for now. I'll pester you again once I find more silly ideas
glad you could improve your focusing experience
About the uncertainty: It is linked to remembering in which direction the last focus move went. That means as long as the EAF is powered(*) it will not lose steps and all positions should be absolute and repeatable. Shifts only occur if you, e.g., do the last move outwards, then power cycle the unit and reconnect. IIRC it will initialize with 'focus inward', and your next move command would introduce an error of 1 BL value. At least that what my conclusions were when watching it.
Since I switched to using Linear AF basically all moves always end moving 'inwards', and focus values are stable since then
(*) I think it is the EAF, but it might also be the driver. Not really sure...
I'm indeed not using the 10:1 fine focus. The reason is that those are friction-driven(*), and, like crayfords, are sensitive to slip. One can usually hold/fix the coarse knob on the opposite side and then turn the fine knob, and will be able to move it. I think I even read somewhere in a manual (maybe from the Pegasus? don't remember) to explicitly not use the fine gear for motor focusers.
And if the CFZ is around 50μ, a step width of 0.13μ sound like clear oversampling, isn't it?
(*) at least those that I know; they use an outer cup, an inner axis, and three steel balls as "gear". Don't know if there are others that have a real planetary gear for this.
dmsummers wrote: 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!
I'm afraid you are over optimistic there. The BL of my EAF is 84 units. An error of 20 already produces a slightly visible loss of sharpness (I do have good seeing though). But 80 produces doughnuts (well, not really as I don't have central obstruction...). So a correction that reverses direction would completely set off my focus without proper BL compensation. Well, rather it wouldn't do anything before BL is eaten up by corrections.
dmsummers wrote: 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.
It has improved substantially IMO. And it is insensitive to BL. Without compensation, at least for me the polynomial AF routine is close to unusable, and leads to errors larger than the position errors I get from linear. That one quite sometimes is 10 units short, very rarely 20.
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.
More later.... Cheers, Doug
Ah, you were still looking at something to read FITS, just not really 'lightweight'
RT starts and runs, even on my Pi3 (not Raspbian but Tumbleweed). Not really usable though - needs minutes to decode a RAW...
The FITS viewer from ASIStudio is very nice. Unfortunately the don't seem to offer this for ARM
I did have some clear sky down at sealevel last night, so I decided I have a try using the new PA with my Star Adventurer and the ASI183MC with an Canon 135mm lens.
The sky view from my terrace is hugely limited, basically only ENE to SSW and up to zenith But enough for testing PA.
I had to use the telescope simulator, as the mount doesn't have any connection to the computer, and switch off position hinting for the solver. Amazingly, even with only image scale limits it was blazing fast, solving in a second or so. But without a compass or view to polaris, my initial orientation was largely off.
Without mount control/info I had to use the 'manual slew' option, and hand-turn the SA to various positions.
As it was the first time using refresh/move it took me three tries before I touched the Alt/Az knobs, and re-did the measurement a few times with different pointing positions. The nice outcome was that the determined PAE was quite consistent - though at 17 degrees.... It took me several additional rounds of measure-align, including repositioning the tripod because I hit the alignment limits of the mount. I eventually got the error down to 15'. Trying better was somewhat futile, due to the (in)stability of the photo tripod I used. But all in all a very pleasant experience
One thing I noticed was that - especially for the large error - the movement direction of the star when tuning the mount orientation did not really match the guide lines plotted. So I wondered if there might be still some (small) error in the coordinate conversion that shows up at larger offsets. However, while writing this, I realized that I had used the observation coordinates of the observatory, some 30km away from here. Would that affect things? In principle I'd say no, as you can PA without knowing where you are?
So if weather cooperates I'll try that again tonight, with proper location and the new code. Because of course as soon as I had finished PA last night the clouds rolled over again...
I didn't have debug on, so I assume the logfile isn't too helpful..
Very interesting! Thanks for sharing.
One thing that keeps me from 'blindly' adjusting focus based on temperature is focuser backlash. How do you handle this, especially how did you measure it (assuming you do have some)? One of the reasons I do like Hys focus routine that is insensitive to (at least small) BL.
An EKOS module to automatically compute focus backlash would be a nice thing
Sorry, but your plot has several errors. Then math doesn't help. But I'm out here now....
kengs wrote: Here's a picture to explain the rotation. As I said, having done the maths it is not a big problem but one should always do the maths to be sure.