Hello people!

Last sessions are giving me some headaches about kstars giving up after a meridian flip. I'd like to denote that  the flip it self works very well, but after the procedure kstars is crashing or eventually it doesn't restart guiding.
A friend of mine has the same exact issue and it seems to be related to the internal solver, after he switched to astrometry he's reporting no more issues.
Now to mine, I switched to astrometry to solve pictures, but it seems to have a lot of issues, the most important is that it freezes my kstars process.
At first I think it was the version (astroberry ships with 0.76) but after a bump to 0.85 the behavior is still the same, the cli seems to work good enough and pretty fast if the RA/DEC coordinates are given (see   ) so I am not sure what is going on within kstars; here you can see a screenshot of my options:





I am not sure why astrometry doesn't work as expected, I suppose this may be a matter of options? attached also the entire log from the astrometry solve-field   (90% of the file is Quad match is out of bound)

Hello Mattia!

I'm not sure, but for me this sounds very similar to my own problems, see here:  Capture and solve problems . I don't have the problem during meridian flip, but perhaps only due to my simple workaround. I have the problem, that Capture and solve does not work at all when I use my Canon 700D for imaging - it does not matter, if I'm using my primary scope or a simple lens. Even when no filter is on front of the camera, solving the captured image always failed. I really tried all possible settings. The internal solver does never work, using a locally installed astrometry.net also does not work, but has slightly different behavior. When using "automatic downscale" astrometry.net returns immediately with the message, that there are not enough stars found in the image, switching "automatic downscale" lets astrometry.net run for a very long time - after 5 minutes it stopped without results. In the preview image I don't see so much stars. I tested with Vega centered on the image, but even with 60s exposure time (seems to be the maximum time for this) Vega was a very small dot and only very few stars are shown - I would expect Vega as a very large dot with lots of stars around.
Interestingly, when I switch to my ASI ZWO 120mm Mono Guiding camera it always works: using my guiding scope with 240mm focus length and also using my primary scope with 600mm. This means: the internal solver now works fine and also the locally installed astrometry.net works great. And using this camera I can see lots of stars in the much smaller image after 2-3s exposure time. Within 3-4 trials the mount is moving to the correct position even with an accuracy of 5 arcmin. This is my workaround - and I'm trying to align my guide scope as good as possible with my primary scope - this works a little bit.

See my screenshots to compare your settings with my settings. What I can retry is your combination with SmallScaleSolving, I'm not sure if I tried this with local astrometry.net too or only with the internal solver. On the first image I have enabled WCS and Overlay, the second image is only of interest if using the locally installed astrometry.net or ASTAP. On the third image: I have values for low and high (which I did not enter myself), in your screenshot these values are both 0.0. Maybe this changes after one successful solving?!  I also installed all required index files as well as all recommended index files. (I also tried installing all files, no luck - but I did find a hint to not install all files as this could take longer). It is also interesting, that I can use any captured raw image from my last nights session to solve - that works, because there are stars. And it seems there are also some stars in the image when using capture and solve, but maybe the algorithm fails for some hot pixels?

I'm running kStars on a MacBook Air and connected via WLAN to a Raspberry PI 4 with latest Astroberry version installed and Indi server/INDI Web Manager running. All devices are connected to the RPI4 and guiding is done via PHD2 on the RPI4. In June I was able to solve the NGC7000 position where KStars was running on the RPI4 too, however only with my Canon 700D and a lens - because for longer focus lengths it took too long or failed I decided to change my setup and now I'm using KStars with the remote connection instead of using VNC to show the RPI4 desktop. 

What I would like to know is: do you perhaps also use a Canon DSLR for capturing the image to be solved? Perhaps, if we are using comparable equipment we can also compare our settings more detailed to find some common and different settings in the hope we can find that issue this way? Finally, I'm planning to create a dark library for my camera with Ekos, maybe this helps - hopefully, I will find this out next Friday, but this depends on the weather.

Regards,
Jürgen 
  
 

Hi Juergen and thank you very much for your precise answer!

To answer to your questions: I am not using a DSLR, I am using a ASI 533 when solving, the stellarsolver works and works pretty fast, but I have crash sometimes and that's why I am trying to make astrometry.net working, also I'd like to point out that even with the simulator I can't solve anything using astrometry.

BTW
I changed to smallscalesolving (the 0.0/0.0 has changed now, it was 0 after a reset to defaults probably), I restricted the radius search to 10, I decreased the timeout to 60 (Which anyway is not respected!) and it seems it can solve some pictures, the timing is unacceptable anyway, it thinks for ~5 minutes before giving me back a pair of coordinates so probably some options, when using astrometry.net, are not respected/optimized?

I've seen libstellarsolver crash, but haven't be able to reliably repeat the crash yet. If you have an image that causes a crash, please share it.

on the same boat, this is very hard to catch and debug, personally I have never seen that happening on normal routines, it failed randomly sometimes when loading and slew or just after a meridian flip (which I supposes is still because of the load and slew) and not in a consistent way