I assume you were using the CCD Simulator to simulate position information? If so, I would do the "goto" command on the simulator to fake the position and then move the scope manually. It is important that whatever system is being used for the position information is actually accurate to where the scope is pointing to the use the position option. If you uncheck the position then this won't matter, but it will be much harder for the solver to solve. It will take longer, it will use more power, and it will be more likely to fail in the solve.
If you are regularly getting crashes when you are trying to solve, I would suspect that you have an issue with your option to "load all indexes into memory." That is an option in the profile. You might edit whatever profile you are choosing to use and uncheck that box then save the solver profile. Some people are running KStars on a system that misreports the amount of memory it has available. That would be by main guess. So if you are getting crashes while using the internal solver, try unchecking that box.
Read More...
The important point is that certain settings, like which profile to use, or whether to use position, or whether to use scale, can certainly speed up the solver, they also come at a cost. If you tell it to use the scale or position, but the scale or position you give it is really incorrect (outside the range of error your profile considers acceptable) then it will not solve at all. So if you find it is not solving, then unselecting or changing those parameters can allow it to solve. My suggestion is to use the profile that tends to work best for you, and to leave the scale and position options turned on. But if it does fail to solve, uncheck them and try again.
If I had to take a guess based on the RA and DEC in the file you posted, what you may have done was that the scope thought it was pointing north, but then you moved it to the target without a slew command perhaps, so it thought was still pointing north but really it was not. This is just a guess. As a rule I turn on my mount in the home position, then I slew to a bright star, then I plate solve, then I go to my target and plate solve again.
Read More...
I just took a loot at your file.
The reason it fails to solve is because the position information in your file is way off. In your file it says the coordinates are:
RA 23:58:43
DEC 89:52:24.6
I did a blind solve (uncheck the "use position" option and it solved almost instantly. The coordinates are:
RA: 03:43:08.552
DEC: +23:59:15.135
Also note that I would have used my LargeScale option because the scale looks really large in your image, the solver agreed, it said:
942.405 x 630.679 arcminutes
But that being said, you did have a reasonable scale in the fits file. It said 7.9 - 11.99 arc seconds per pixel and the solver said it was actually 10.4" per pixel. So unchecking use scale would have had no effect, since the scale was fine.
So I would use the large scale solving option, and either correct your coordinates or uncheck "use position"
Thanks,
Rob
Read More...
Sorry I haven't had a chance to look at this recently. I'm very busy right now with work related stuff and I'm behind on some of my personal projects like this, but I think in the next month or two I should have some more time since we are getting to the part of the year when I tend to have more time.
Thanks,
Rob
Read More...
So there were still a few issues with it and I will have to come back to it. Over the last couple of weeks we had bigger issues to solve, there were some issues with a few drivers and I revised the macros for checking library linking with drivers. Then we had to fix the build on binary factory and fix some recipes to get that working again. So I have been a little sidetracked from this issue. But I do hope to come back to it soon. Now, I have the builds working properly on Binary Factory again which is good news:
binary-factory.kde.org/view/MacOS/job/KStars_Nightly_macos/
So I think if this is all resolved, I should be able to look into the windows issue again.
Read More...
Yes, that did work. But then there was a linking problem for the library. It could not find -lXISF. But this change fixed that on my system.
this line:
target_link_libraries(${PROJECT_NAME} indicore Qt5::Core XISF)
changed to:
target_link_libraries(${PROJECT_NAME} indicore Qt5::Core ${LibXISF_LIBRARIES})
After I made the changes you suggested and changed that other line it built and linked just fine. So did you want to update it with a PR, or should I?
Thanks,
Rob
Read More...