Hmm, I'm not sure, as far as I can tell, the file I built today included this fix in the source code before building:
github.com/indilib/indi/commit/47d23904c...c5ca4e2d645cbd8935d0
and I checked that the DMG included the file that was built and they were identical (at least my computer said they were).
so I think that it should include this fix.
I can send this to Jasem and see if he has any ideas of what might be wrong.
Read More...
I agree, perhaps we can have an option that tries to solve once with using position and scale, if that doesn't work it can try again with just position, and if that doesn't work, it can do a totally blind solve.
Read More...
in typical use, the mount should reasonably know where it is pointing, it might just be a little off. For example, when I first turn on my mount, it is close to Polaris, but not quite. It is probably within 15 degrees of it, however so I use a search radius of 15 and it works fine. Most plate solves after this first one will be even closer than that to the search position.
Read More...
"Use position" gives the solver a place in the sky to start searching from. In KStars, the position comes from the way the mount thinks it is pointing right now. If the position is good, it can greatly reduce the solving time, but if the position is bad, it might not solve at all. The search radius tells the solver how far out from the starting position to search. So if you uncheck "use position" it won't use a search radius at all.
Read More...
Ok I just built one that should be based on the latest code rather than "stable". Please see if this works
www.indilib.org/jdownloads/kstars/beta/kstars-3.5.5-beta.dmg
Read More...
Ok, so then I assume that the issue was fixed, but not before the release. I think I would need to make a new beta then to get it to work for you. I can try that.
Read More...
I believe that I did. I built the version that is on the website on 7/7/21, which I think was after he made the fix. But I'm not sure if the fix would be in that version since I did the "stable" build. If he made the INDI change in the unstable version and didn't put it in the stable branch, it might not be in there. Can you check to see if it's in there? If not I could build you a new beta with the latest code and we could see if that fixes it.
Read More...
This is a good idea in theory, but there are some complications. One pretty serious issue would be that having the shutter closed for part of the image effectively changes the exposure time. I guess a solution could be to then keep the camera shutter open by a longer time at the end, but if the camera gets its information about of long the shutter should be open at the beginning of the exposure and does its own timing, then that wouldn’t work, but if the INDI driver does the timing it could work. I think different cameras do this differently. Another big issue would be that satellite brightnesses are not constant. At some hours of the night and at some locations on Earth, satellites are very bright, but at others, the sun doesn’t hit them. Also some satellites change brightness as they tumble or spin, like iridium satellites did. So this leads me to think that the best solution might be a wider field monitoring camera. This is a good idea though and should be considered.
Read More...
Did anybody try the QHY driver? I think it was updated recently and we had an issue with it before after it was updated.
Read More...
So Jasem updated the code, but I have to rebuild the whole thing for the change to be in the DMG. I will do that again before the release for sure. I was hoping that there would be a couple of more tests first and any more things that need fixing get fixed.
Read More...
I am not familiar with the Esatto issue. I am assuming it is an INDI bug? Is it just an annoyance, or does it make it not work properly? Did somebody look into it?
Read More...