×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Align tab doesn't compute FOV anymore

  • Posts: 1957
  • Thank you received: 420
Recently I noticed, when I use my Canon DSLR and primary scope, that Ekos doesn't display the FOV in the Align tab anymore. This means I have to take an additional pic to get the FOV and this sometimes leads to the offline solver to fail. I can enter the FOV manually and then the solver succeeds. When I use my secondary (guide) scope and the guide cam then Ekos does display the FOV. When I select the DSLR and Primary Scope in the Guide tab then the FOV is displayed correctly. Is this intentional or is this a regression?
5 years 10 months ago #25740

Please Log in or Create an account to join the conversation.

This is a feature, not a bug! This is only done once per Profile+Camera+Telescope combination, after which the information is saved to the database. Did you happen to install KStars 2.9.5 before it was officially released? If yes, then you might need to edit your userdb.sqlite table.
5 years 10 months ago #25766

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Thanks! No I didn't install KStars 2.9.5 before it was officially released. This is on my RPi3 with Ubuntu Mate using the stable PPA. In any case, I'll be happy to edit the userdb.sqlite if you explain me how to :)
5 years 10 months ago #25767

Please Log in or Create an account to join the conversation.

Then there is nothing to edit. It's just the first time (if it shows 0) that the solver would take longer to solve, and then after the effective FOV is determined, it should be faster.
5 years 10 months ago #25769

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
OK I see. However, it is not! Or rather, when I switch to the main telescope + DSLR, the FOV is not filled even though I did take an image with it and solved it with the internal solver after installing KStars 2.9.5. Anyway, thanks for the info. I will (try to) reproduce it and will provide logs here if the issue persists.
5 years 10 months ago #25770

Please Log in or Create an account to join the conversation.

Maybe then it's an issue with the table. Get any SQLite editor and try to edit this file ~/.local/share/kstars/userdb.sqlite
Go to the version table, and change the version to 2.9.4 and save. If you see any table named 'effectvefov', delete it as well. Then restart KStars and hopefully it works then.
5 years 10 months ago #25773

Please Log in or Create an account to join the conversation.

  • Posts: 5
  • Thank you received: 0
The astrometry indeed fills the fov.
But once it is entered manually or retrieved from the astrometry, it is not modifiable anymore.
I would expect a mean to correct a wrong manual input. Something more user friendly than diving in the database. I did entered it manually yesterday and I felt stuck not being able to correct my mistake.

thanks
5 years 10 months ago #25801

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Apart from that, I don't really see the need for taking a picture and plate solving it to get the FOV. This is perfectly well computable from the CCD and telescope parameters. Doing a plate solve without FOV set either takes a looong time or it fails because it times out. So, what was the reason for introducing this feature?
5 years 10 months ago #25802

Please Log in or Create an account to join the conversation.

Fine, I made it read only in 2.9.5 to prevent users from messing it up and then forgetting about it. I'll enable direct read-write mode again (should be in 2.9.6). The computed value is displayed in the tooltip so you can use that value there. This is a one time operation! The reason it was introduced is in many cases, the computed value can differ quite a bit from the actual value due to any element in the optical train that may affect the final focal length.
5 years 10 months ago #25804

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Jasem, sorry I didn't mean to upset you. For me the field doesn't have to be editable as long as it contains some value at first and not "0' x 0'". You are absolutely right that the computed value can be different from the real value. As a matter of fact, it is a situation I had a few months ago.

Wouldn't it be an option to fill out the computed value when a new profile is created and then require the user to have it updated with a first plate solve action?
5 years 10 months ago #25810

Please Log in or Create an account to join the conversation.

But having a computed value that could be wrong would make the solver fail and the user has no idea why. Now the field is editable and the computer value is shown in the tooltip so you could enter it and then forget about it.

Though I just found another issue which is now fixed in the database itself.
5 years 10 months ago #25812

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
True, it could be wrong and the solver could fail as well. Though if the user copies the computed value from the tooltip then they may run into the same problem. It is a difficult case to solve properly.

Thanks as usual for the quick feedback and for your flexibility :)
5 years 10 months ago #25816

Please Log in or Create an account to join the conversation.

Time to create page: 0.354 seconds