Thank you for that cross check!

Now I know that it makes no sense to reinstall astroberry or anything like that. The problem seems to be the fits-file itself or or the large scale of the combination of 135mm lens with full frame sensor!

Compared to my previous version of kstars this one seems to suppress any debugging information of the alignment module, even if verbose mode is selected. That makes it hard to figure out the problem...

I am considering to use a local ASTAP or Astrometry installation instead of StellarSolver. Although StellarSolver should be based on Astrometry, solving my image on online Astrometry is no problem.

Hi Ben!

I thought I'd give the puzzle a try. I set up a simulator configuration with the specs for the Canon EOS 6D (I'm not a Canon shooter so apologies if I got some of this wrong). I originally set things up with the sensor specs for the Mark II assuming a 4x3 aspect ratio and the Solver solved the image. When I looked at the FITS header for the file you provided it appears that you are actually using the original 6D which has different pixel dimensions of course. When I input those specification, the solver failed each time. It never took longer than 30 to 60 seconds to fail - I didn't seem to have the problem of it running without stopping. I'm not sure what the INDI control panel shows for your camera but, based on your reported FOV, mine was pretty close (after I put in the 'correct' sensor data into the simulator) at 906.0' x 606.0'.

Can't explain why it seemed to work when I had the wrong sensor spec in the simulator. The solution the Solver achieved was very close to the information in the file's FITS header. I'm using 3.6.3 FWIW.

Good luck!

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

Rob - your post got me to try this again. This time I did it with the right sensor data to begin with and I got a solution in under 3 seconds (I can't explain why it failed with these settings when I tried it earlier). But, my answer was very different from yours. Then, to simulate what you did, I unchecked "Use Position" and I got an answer very similar to yours.

In a strange outcome, I selected "Use Position" again and Solver failed almost immediately. Then I again unselected "Use Position" and I got an answer right away.

Do you have any guidance on when to select "Use Position"? From the tool tip, it indicates that selecting it should speed up the solver although it seems to create some challenges of its own.

Thanks!

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.

I followed Rob’s advice on your behalf Ben. I unchecked “use position” - and the solver completed after 41.11 seconds!

Thank you for putting so much work into my problem! I really appreciate your results!

Unfortunately I cannot reproduce them, because KStars keeps crashing if I disable "Use Scale" or "Use Position". I think you found the problem in my file, but it seems that I have another problem with my installation. Are all of you running KStars 3.6.3? For me, 3.6.0 is the latest version it wants to upgrade to.

The reason for the wrong coordinates in the file is, that I made this image with a Star Adventurer setup without goto. So as you suggested I moved manually to this position while Kstars was pointing to another position.

Ok, just right now it solved instantely using "LargeScaleSolving" and "Use position" disabled! After that it crashed again, but now I have the first solved image today!

I really do not know why, but when I use the options you recommended and additionally switch the solving method to "Local Astrometry" it seems to work without crashes!
So this seems to work for me:



Thank you very much for the help!

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.

Yes, I am using the CCD Simulator, when I use Astroberry with my mobile equipment. I will try the goto command next time, to get simulation and reality close to each other. I was not aware that the position of the mount is stored in the fits data. Normally I am working with the raw files from the SD card of my camera.

In an earlier version of Kstars the verbose mode created a lot of information. There it said, that I have enough RAM to store all indexer files. But when this information was wrong, this could cause a RAM leakage and that would be a good explanation for this behaviour! When I unchecked that option it never crashes again!

But I really wonder how this could happen. When I type "free" in the terminal it says that I have 8GB RAM and 700MB of them used. The sum of the downloaded files should not exceed the free RAM, because I did never download the files for the smaller FOVs. But the result shows that you are right!