I have the same behaviour since forever. It seems the end of movement comes from the mount when the breaking starts instead of when the target is really reached.
As stated, just increase your settle time to something like 5000 or more.
I want to change the folder structure Ekos uses to store images during capture. The default is to create a subfolder for every filter and then mix the objects in all those folders.
Now, while this might work for someone, I really am puzzled as to why this has been chosed as the default.
What this forces me to do is find the object I need in every folder and move them together in a separate folder.
Is there a way I can change any of this?
Hi all,while not strictly a problem, I'd like to use my Meade DSI attached to a 50mm finderscope for polar alignment as this would provide a wide enough FOV.
Now my issue is I cannot get the system to solve an image taken this way. I attached an example to this post.
Can anybody tell me if this is feasible at all?
If I'm not interpreting the indi configuration panel wrong, there's a special mode you need to select when you have more than one zwo cameras.
Have you investigated this possibility?
Please double check you're using the right goto command. There's one to go to the highlighted object but there's also one to go to the cursor position, which I'm assuming is what you selected.
If this is similar to the Vixen Skysensor issue, you might have a tolerance setting in the mount driver configuration panel. The skysensor one needs to be bumped up quite a bit or else the software never detects the end of the movement.
Try to look up that config, if present, and up it a bit.
It's because of a known bug that is hopefully being solved by the next kstars release (3.5.7).
I can't be really sure because I don't know this exact model, but all qhy cameras don't have a resident firmware fixed in the hardware.
What happens is the firmware included in the driver installation gets loaded inside the camera every time it's powered on. So you only need to make sure you have an up to date version of the indi driver to have the latest firmware.
Please anybody correct me if I'm wrong.
Well, I only have this one RPi and I need it in the field, so in part is to preserve it for the job I bought it for.
But also, out of curiosity, just to see if it's feasible at all.
pretty much what the title say: can I setup an environment where I can compile everything needed from git and/or sources to get Ekos up and running on the RPi, without using the RPi?
thanks for the detailed answer. I'll try to reply to some of your remarks:I wrote that incorrectly. The correct way of putting it is, there's no way for me to force Ekos to do a blind solve easily. All of this started because I had an unsolveable image on my hands, which later turned out to contain wrong coordinates. I wanted to blind solve it, so to discard the FITS info. It isn't currently possible to do so. Load and solve will use the info and there's no way to make it ignore them safe from deleting the info from the actual image. Not sure if the option to blind solve would be useful in many cases, though. But this is what I meant. And as you can see from this answer Jaseem gave me indilib.org/forum/ekos/10035-non-solveable-image.html#73667, the Use Scale and Use Position not being read while Load and Slew is used has fooled him too...And this is why I want a server to run for these kind of requests.I understand your remark, but the radius limitation, as far as I can see, goes into the profile which is used always, including load and slew. Now, if I tri to blind solve, wouldn't a limit on the radius limit the blind solve as well? Or is it ignored in case of an image without info, say a JPG?
Also, in what way is it better to limit the search radius? To get back to my problematic image, setting the search radius to 180 solved it, even if it had those wrong coordinates. Leaving it at 180, all my other images solved quickly anyway, so I'm failing to see the downside of upping it to 180 or so.
Thanks again, also for the github thread!
Your image is really puzzling. You cannot have backlash in RA.. Are you 100% positive you're actually pulsing the right axes? Ie, when pushing RA+ the actual DEC motor is absolutely silent? Because looking at that image, it would be perfectly normal if the labels were reversed.
sorry to get involved but I wanted to understand things a bit better.
For how I know guiding, backlash in RA is meaningless as you never reverse. Or you shouldn't. RA is always moving, so the motor is always working against a weigh. Now, the guiding pulses should always be accelerating or slowing the motor, but never running in the opposite direction, as is the case with DEC. So that's why you shouldn't bother with backlash in RA.
Now, even in DEC, you shouldn't either. DEC errors account for polar alignment inaccuracies. In a perfect world, a perfectly aligned mount would leave the DEC motor off for the entire session. Of course this being impossible to achieve, the next best thing should be figure out where the DEC drift is heading (N or S) and correct only in the opposite direction, disabling the unwanted direction. The DEC should only have a drift, hence why you need to correct in one direction only.
Please verify what I'm saying is right, I always like to learn
Also, question to Alfred: are you positive the same amount of pulse moves your mount differently in RA+ and RA-? If so, please check that your mount have maybe a different guiding speed per direction? It sounds strange but you never know.
You could try looking up what package contains the file /usr/lib/x86_64-linux-gnu/libASICamera2.so.1.19. dpkg can do that, I just don't remember the right switch.
If everything checks out, I'm out of ideas, but I suspect there's a stray file here.