If I'm not interpreting the indi configuration panel wrong, there's a special mode you need to select when you have more than one zwo cameras.

Have you investigated this possibility?

Read More...

Please double check you're using the right goto command. There's one to go to the highlighted object but there's also one to go to the cursor position, which I'm assuming is what you selected.

Read More...

Fabio Papa replied to the topic 'Slew to target never completes' in the forum. 4 months ago

If this is similar to the Vixen Skysensor issue, you might have a tolerance setting in the mount driver configuration panel. The skysensor one needs to be bumped up quite a bit or else the software never detects the end of the movement.

Try to look up that config, if present, and up it a bit.

Read More...

Fabio Papa replied to the topic 'Plate solving and PA not working' in the forum. 4 months ago

It's because of a known bug that is hopefully being solved by the next kstars release (3.5.7).

Read More...

I can't be really sure because I don't know this exact model, but all qhy cameras don't have a resident firmware fixed in the hardware.

What happens is the firmware included in the driver installation gets loaded inside the camera every time it's powered on. So you only need to make sure you have an up to date version of the indi driver to have the latest firmware.

Please anybody correct me if I'm wrong.

Read More...

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. 9 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. 9 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...