Thanks Jasem, that's fantastic.
Is the plan for this change to be included in the 3.5.6 release automatically? Or would you like me to test it?
I'm not set up for compliling on the machine that I run KStars on, and the weather here looks cloudy for as far as the forecast goes at the moment, so it may take a while...
Jasem, yes that's what I mean.
Giles, I'm not referring to auto-focussing (although I did initially try that), I'm referring only to the change in focus due to the filter offset. Algorithm choice, max travel, etc doesn't come into it
Yes, that's true that of course both cameras move with the focusser.
The magnitude of the offset is very small though, I'd be surprised if it makes much difference to the guide camera directly.
I've definitely got to get one of those helical focussers, I didn't realise they made them as an add-on for the smaller ZWO OAG.
So what do I do? At the moment as far as I can tell the guide cam is focused as well as I can get it.
When the focus moves, guiding temporarily goes crazy, with large adjustments, that take a while to settle out again, meanwhile the imaging cam exposure that just started, is aborted due to the large guide error.
Once the (erroneous?) large guide pulse has settled out, guiding continues correctly and imaging restarts, but I've lost a significant amount of time.
A delay option, or an option to suspend guiding while moving for filter offsets would fix the problem, but unless I'm missing something there doesn't seem to be such an option. There is when auto focussing, but that doesn't work here.
The OAG is in front of the filter wheel, the filter selected won't have any effect of the image in the guide cam.
The OAG is one of the ZWO ones where the focus is only set by sliding the guide cam up and down and locking it with a grub screw. So acurately setting the focus is really fiddly, but it won't be changed by changing the filter. As demonstrated by the fact that guiding isn't affected when changing the filter from the EKOS EFW tab, or when changing filter from the capture tab with no focus offset. It only fails when changing filter from the Capture tab with an offset set. That's why I assume it's related to the focusser moving.
My filters are supposed to be par-focal too, but my scope is a SW 80DS Pro, which is a doublet and not great for chromatic aberation.
This was the first time I tried setting filter offsets, but either with or without an auto focus run, the guiding issue still happened either way. It seems that there's an issue with the guide cam taking images while the focusser is moving, just between filter offsets is enough to be a problem. It didn't need to actually run auto-focus, although if I do, I think it's OK as there's an option to suspend guiding while focussing, but that doesn't apply to focus offset changes triggered by filter changes.
Removing the offsets between filters fixes the problem from the Capture tab.
Hi Jasem, thanks for the reply.
I don't think the issue is actually the changing of the filter, it's the associated change of focus (due to a filter offset) that seems to break the guiding.
Changing the filter from the EKOS EFW config page works fine, but changing filter from the Capture tab causes guiding to go crazy in both axis.
Has anyone else noticed this, it can't be just me surely.
Is there a way to introduce a pause between changing filter and starting the next exposure?
I noticed a problem a couple of nights ago, and worked out what it was last night.
I'm using a filter wheel, auto focuser and an OAG.
For the first time I had set a filter offset for some of my filters, and I (finally) realised that everytime the filter was changed, the focuser would move, which would cause the guiding to report large errors, which in turn would abort the subsequent capture.
There is an option to suspend guiding when running a full auto focus routine, but is there an equivalent to suspend when changing filter offset? Or some sort of filter change settle time?
My fresh VM works fine, so it had to be a problem with the PC I use for EKOS.
Doing the following has fixed the problem for me:
apt purge kstars-bleeding indi-full
apt install kstars-bleeding indi-full
It's a bit odd as I had already tried apt removing indi-full, either the purge made a difference or removing kstars did
Thanks for the help
No, I've only ever installed from the PPA, no local builds
It's libasi that provides the libASICamera2.so file, that's why I wondered about the version numbering, but it seems to be correct that libasi 1.18 provides libASICamera2.so.1.19
Thanks that's good to know.
I've installed a fresh VM on another machine, I'll give that a go later and see whether that works, if it does, and it's working for you then I have no idea what the problem with my real machine might be.
Having been using KStars/EKOS for a while with few issues for a while, I've just make the mistake of trying to do an apt-get update on my machine, now the ASI driver crashes whenever I try to connect.
I've seen a couple of threads on here from a month or so ago regarding similar issues in nightly builds but I've only ever used the stable PPA.
It looks to be a version mismatch as the logs report an undefined symbol as reported here www.indilib.org/forum/ccds-dslrs/10003-i...n-connect.html#73460
This is x86_64 running Ubuntu 20.04.
I've tried running apt remove indi-full, and apt autoremove, which sure enough removes indi-asi and libasi too.
Reinstalling indi-full results in the following versions being installed:
indi-full = 1.9.1-202106280946-ubuntu20.04.1
indi-asi = 1.9~202106280200-ubuntu20.04.1
libasi = 1.18~202106271742-ubuntu20.04.1
ls /usr/lib/x86_64-linux-gnu/libA* reports /usr/lib/x86_64-linux-gnu/libASICamera2.so.1.19 though.
Does anyone know if those versions are correct? The libasi version looks suspicious
What libasi version is indi-asi expecting? Can I just force an installation of the correct version.
Surely the ASI driver dependencies haven't been broken for over a month in the PPA have they?
Any help would be much appreciated.
Ah, thanks. I hadn't seen that one before.
Is that the only time that the mount would attempt to auto-park? Is so, then that's the only option I need.
I have an iOptron CEM25p and I can never get parking to work reliably.
Once or twice it has worked, but usually it doesn't and any time the mount attampts to park (like after a polar alignment) I have to be there poised over the stop button to prevent the mount from being driven into the tripod legs.
I'm starting to leave sessions running when I go to bed now, but I'm worried that at some point something may try to park the mount and it might spend hours grinding the gears as it smashes the mount into the tripod before I'd realise it had happened.
Would it be possible to add a "Disable Parking" option that would prevent a park command from ever being issued?
Or better yet an option to "Use Goto Home instead of park" as that does work properly?