Thanks for your reply, but what I want is not local solve.

Not as in, locally on the kstar/ekos machine.

A bunch of us are running raspberries in the field and sometimes need blind solve. The integrated solver cannot blind solve, sometimes not even on powerful machines, let alone on raspberries, and hence I'm trying to setup a nova clone on a VM I own which is reacheable from the observatory through the internet.

Of course, my VM operates on an address different than nova.astrometry.net. The requests come in, the solve is done, the answer is read but ekos insists looking for a log file of the solving from nova.astrometry.net, even if the host has been specified in the configuration.

I hope I cleared things up a bit.

Got it, ok, not sure what your issue is.

FWIW, I do blind solves frequently with my RPi4. I usually use ASTAP, and it seems to work in under 1s, and I've also done so with the internal solver, though it might sometimes take a bit longer (<10s). For the internal solver, you should allow it to downsample, e.g. 2x2 for an ASI1600.

Hy

Are you sure those are blind solves? Under 1 second blind requires a huge amount of power, not even possible as far as I know.
Chances are your images contain coordinates in them in the headers.

Well, of course I could be tricked, as you say, but my impression is that the solves are "blind", e.g. I uncheck "Use Scale" and "Use Position" buttons.
For instance, see this post from ASTAP: stargazerslounge.com/topic/323797-blind-solving-with-astap/
and this merge request for StellarSolver into Ekos: invent.kde.org/education/kstars/-/merge_requests/98

Both claim "blind solving" in seconds.

FWIW, you can experiment with either one on a RPi4 by using their stand-alone programs. That is, if you run the ASTAP binary directly, it comes up with a UI that allows you to load fits files and solve them (so you can remove any fits header lines you want). Ditto for the StellarSolver_tester program that's part of the StellarSolver package.

Hy

I'll make some more tests, it can maybe lead me to good things.
Thanks for the idea.

Running the ASTAP solver itself can mislead, as I tried this a few months back, but the behaviour is very different compared to the binary launched from ekos because of the parameters used.

PS: I've read the first link you posted and maybe found what drove me off ASTAP in the first place: it doesn't play nice with proper exposures. It works well with short exposures, not full exposure ones. But anyway, some times has passed so I can try and verify with current releases and see where I can get. Will report back.

Fabio: Looking forward to what you find.

Also, of course, if you discover that Ekos/StellarSolver is passing suboptimal parameters to ASTAP,
please let us know, and hopefully we can improve things.

Hy

Will do.

But also, let's not lose sight of the bug I found, which is still true: ekos calls an internet address regardless what you set in the configuration.

Got it. I took a quick look, and I'm pretty sure this is related to StellarSolver (as opposed to Ekos).
Not sure if that currently allows changing urls for the solver.
@rlancaste: are you able to take a look? (I'll send you a side email too, in case you don't see this).
See github.com/rlancaste/stellarsolver/blob/...nlinesolver.cpp#L325 where nova.astrometry.net is hardcoded.

Well, in Ekos there is a field where you can input the host and in fact, it does request the solve to my server.
It's just after it's done it asks for the log to the wrong one.

Update: yes, Ekos is fooling you. Even if I deselected both Use Scale and Use Position, the astap binary gets called with arguments passed of both scale and position, and search radius too.
I think this is ultimately why it's so quick, but those are definitely not blind solves.
And maybe this is another bug, it seems the ASTAP interface completely ignores some of the settings.

EDIT: I find ASTAP really frustrating. It's very good that it can do blind solves by mouth of its author, but it would be nice if they explained HOW. All the software does, and it tells you as much when you hover over the Solve button, is search in a radius from a starting point, which seems to be a requirement, and after it reaches 20deg off, it stops. I can't find a settings page despite the program offers me the option to save them (???). I seem to recall there was an option to start with some different parameters but I can't find them now.

EDIT2: ok, I managed it, by specifying -r 180 on the command line. It was relatively fast, 20 seconds but with a 12 core Xeon. I doubt this will be useful on a RPi4. As I expected, real blind solve is just slow and requires a good amount of power.
 

I finally had the time to test on the RPi. I found a way to make it work, using ASTAP, but it hasn't been easy for a couple of reasons.

First, let's address the Use Scale and Use Positions switches: they don't work. The scale and position gets passed on to the solver, no matter what these switches are set to. At least, using ASTAP. The only way to really get a blind solve is to strip those info from the fit file itself.

Now, having done exactly that, I tested and confirmed that ASTAP can blind solve, and it's quite fast too. The most problematic image took 40 seconds on the RPi, which I think is fantastic. But another problem bugged me for a while. It seemed like Ekos liked to pass the "-r 15" parameter to ASTAP no matter if I changed the max radius search option. This was because I was changing another profile, not the one I was actually using. I think that part of the Ekos config could use some work, it's easy to get lost.

But finally I have a solution that can work on the RPi for blind solving images.

I'm still going to try and put up a nova like server, with the help of rlancaste I hope to be able to succeed. I also hope this thread is going to help somebody with problematic images in the future.

BTW: is there any specific reason the default search radius is so small? Upping it to 180 doesn't slow down anything if coordinates are close enough, just a thought.

Sorry that I couldn't log in here before, something was wrong with my password, but I have now fixed it.  Hopefully I have provided helpful feedback in the GitHub site.  I think I have fixed the first problem, the hard coding of the nova site should now be fixed.  If you are using a package manager to install stellarsolver or if you are using Windows with embedded stellarsolver, there will be a delay to update it.

I think there were a couple of questions here I didn't address on the other site, so I will try to answer them now.  

I am not sure what you mean by the internal solver can't blind solve, because that is one of the main things I worked really hard on last year during the pandemic, and one of the best features of StellarSolver is now that it can blind solves an image in less than a minute, often just a few seconds (depending on the image and computer of course).  It manages this by doing several things that really can speed up solving such as parallel threads on multiple cores.  Yes it can use a decent amount of energy and processing power, which is why you should only do a blind solve if it doesn't solve any other way.  Even the raspberry pi can do it, but it isn't as fast as other computers.

I agree that under 1 second true blind solve on a Pi as you stated is not likely at this time.  I typically use my laptop for solving images and controlling the session, where the PI is used for acquisition.  My main computer solves images with scale and position information in about 0.3 seconds or so, the pi might take a few seconds (unless it is a pi 4).  For blind solves it really really depends on the image.  Here is an example of StellarSolver solving an image in less than 2 seconds on my main laptop.   This is mostly a blind solve since the file is a JPEG, it has no idea about anything about the image.  The only information it has is that it should use the parameters in the "ParallelSolving Small Scale" options profile.  This profile does limit the scale to telescope sizes which makes it a bit faster, but if you don't limit the scale, it doesn't increase the time that much.  Other images will have different solving times since blind solving is blind, but typically it is less than a minute.  For a PI, the time estimates would be larger of course.

  

To answer the question of why 15 degrees, most users are using the internal solver or astrometry.net in some form and limiting the search 15 degrees does make a difference in those methods.  15 is typically the recommended parameter value.  If your telescope is off by more than 15 degrees, there is a problem and you should be doing a blind solve and maybe check your equipment.

Did this answer all the questions?

Thanks,

Rob