Well, I only have this one RPi and I need it in the field, so in part is to preserve it for the job I bought it for.
But also, out of curiosity, just to see if it's feasible at all.

Read More...

Hi all,
pretty much what the title say: can I setup an environment where I can compile everything needed from git and/or sources to get Ekos up and running on the RPi, without using the RPi?

Thanks!

Read More...

Hi Rob,
thanks for the detailed answer. I'll try to reply to some of your remarks:I wrote that incorrectly. The correct way of putting it is, there's no way for me to force Ekos to do a blind solve easily. All of this started because I had an unsolveable image on my hands, which later turned out to contain wrong coordinates. I wanted to blind solve it, so to discard the FITS info. It isn't currently possible to do so. Load and solve will use the info and there's no way to make it ignore them safe from deleting the info from the actual image. Not sure if the option to blind solve would be useful in many cases, though. But this is what I meant. And as you can see from this answer Jaseem gave me indilib.org/forum/ekos/10035-non-solveable-image.html#73667, the Use Scale and Use Position not being read while Load and Slew is used has fooled him too...And this is why I want a server to run for these kind of requests.I understand your remark, but the radius limitation, as far as I can see, goes into the profile which is used always, including load and slew. Now, if I tri to blind solve, wouldn't a limit on the radius limit the blind solve as well? Or is it ignored in case of an image without info, say a JPG?
Also, in what way is it better to limit the search radius? To get back to my problematic image, setting the search radius to 180 solved it, even if it had those wrong coordinates. Leaving it at 180, all my other images solved quickly anyway, so I'm failing to see the downside of upping it to 180 or so.

Thanks again, also for the github thread!

Read More...

Fabio Papa replied to the topic 'Internal guider questions' in the forum. 4 months ago

Your image is really puzzling. You cannot have backlash in RA.. Are you 100% positive you're actually pulsing the right axes? Ie, when pushing RA+ the actual DEC motor is absolutely silent? Because looking at that image, it would be perfectly normal if the labels were reversed.

Read More...

Fabio Papa replied to the topic 'Internal guider questions' in the forum. 4 months ago

Hi all,
sorry to get involved but I wanted to understand things a bit better.
For how I know guiding, backlash in RA is meaningless as you never reverse. Or you shouldn't. RA is always moving, so the motor is always working against a weigh. Now, the guiding pulses should always be accelerating or slowing the motor, but never running in the opposite direction, as is the case with DEC. So that's why you shouldn't bother with backlash in RA.
Now, even in DEC, you shouldn't either. DEC errors account for polar alignment inaccuracies. In a perfect world, a perfectly aligned mount would leave the DEC motor off for the entire session. Of course this being impossible to achieve, the next best thing should be figure out where the DEC drift is heading (N or S) and correct only in the opposite direction, disabling the unwanted direction. The DEC should only have a drift, hence why you need to correct in one direction only.

Please verify what I'm saying is right, I always like to learn :)

Also, question to Alfred: are you positive the same amount of pulse moves your mount differently in RA+ and RA-? If so, please check that your mount have maybe a different guiding speed per direction? It sounds strange but you never know.

Read More...

You could try looking up what package contains the file /usr/lib/x86_64-linux-gnu/libASICamera2.so.1.19. dpkg can do that, I just don't remember the right switch.
If everything checks out, I'm out of ideas, but I suspect there's a stray file here.

Read More...

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.

Read More...

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.
 

Read More...

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.

Read More...

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.

Read More...

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.

Read More...

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.

Read More...

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.

Read More...

Hi,
Ekos is trying to download the log of the solve operation from nova.astrometry.net even if I've input a different (and local, in my case) host as the solve server.
All the rest is solving, this is the final hurdle, please help me!
Thanks

The log says:2021-08-17T17:37:51 Error transferring nova.astrometry.net/joblog/12 - server replied: Internal Server ErrorBut as I said, I'm not using it...

Read More...