Hi all, I've got the solver setup and index files installed in kstars 3.3.6 via the snap package, but when I try a load and solve it returns
2019-10-01T21:20:20 Solver failed. Try again. 2019-10-01T21:20:20 Starting solver... 2019-10-01T21:20:20 Solver iteration #1 2019-10-01T21:20:20 Using solver options: -O --no-plots --no-verify --resort --downsample 2 -3 202.591 -4 47.1381 -5 15 2019-10-01T21:20:20 FITS header: cannot find FOCALLEN (keyword not found in header).
If i try the solver outside of kstars with the settings copied out of the options box, it will complain about not been able to find the astrometry.cfg, adding the --config flag then gives:
/snap/kstars/45/usr/bin/solve-field -O --no-plots --no-verify --resort --downsample 2 -3 203.012 -4 47.0956 -5 30 --config /home/gary/snap/kstars/45/.local/share/kstars/astrometry/astrometry.cfg Light_30_secs_2018-05-09T01-48-31_006.fits
and the file solves correctly.
On the off chance there was an issue with config path when running inside kstars/snap, I added the --config line above to the custom astrometry options but the result was the same.
In addition --config /path/to/astrometry.cfg did not show up in the log file as a used option. This is also the case with the search radius. Options dialog shows -5 is set to 30 and the options edit box in the solver options also shows -5 30.
-O --no-plots --no-verify --resort --downsample 2 -L 14.402 -H 18.003 -u aw -3 202.642 -4 47.0878 -5 30
However when run the log shows:
2019-10-01T21:59:56 Using solver options: -O --no-plots --no-verify --resort --downsample 2 -3 202.524 -4 47.1485 -5 15
why is the radius showing in log as 15 when options specify 30? Are other params including custom not been passed through too like --config ? Is there any way to get more output from the solver to be logged to troubleshoot this further? -vv in custom options doesn't appear to do anything, unlike on cmd line.
I hadn't realised it was just a warning rather than a configuration error and the makefile was still able to be generated. I've set a build off now.
It looks like that package isn't in debian stretch and I it doesn't look like it'll be buildable without a newer version of QT than stretch ships with.
What is it that is making use of datavis?
I'll be doing a build of this and latest stable indilib tonight so no comments on the 2.9.3 itself, however, when I went to check the git repo out, the tags are a little confusing.
Latest stable is v2.9.3 yet there's v3.x.x and v4.x.x as well as v16/17 etc. I assume the latter are for ubuntu but what are the v3.x and v4.x tags? They're several years old so not the latest, which makes the version numbering odd?
Not sure about that one, I'm pretty sure when I used to use my Bahtinov mask that it worked with my imaging setup too, but now you have me wondering
When I use platesolve, I tend to do the solve & sync option so that the scope has accurate settings and kstars updates to show the actual scope position, then I'll click slew to object once more if it's further out that I'd like and do another plate solve. There is an option to plate solve and slew to target which I believe will slew, solve, slew, solve several times until it's within a given margin of error from the target. I've not tried that though.
I've not tried using the scheduled session, but I have noticed when I abort or pause a existing job then remove it and add new, the old will seem to continue before the newly added job even if it's the only job in the list. This doesn't happen all the time though. It may be worth trying to do a session that is just exposures during the day to establish if there's a set of steps needed to cause it to act oddly, it could be a bug.
Thank you again,
P.S. Apologies if this is posted twice - I can't see it in the forums.[/quote]
Is there a way to have the guide graph continue to update when rapid guide mode is in use?
Also, what do the other options on the guide cam tab such as "auto loop" do?
Just in case there's an issue detecting the slew complete, try turning on the driver debug messages and doing a slew and see if there's a message logged for slew start and slew complete.
If you see those messages (I can't remember if they're in by default or if i added them when I was testing a similar issue with my lx90 and the autostar driver) then set the scope to slew over quite a large area that will take several seconds to complete. Then monitor the debug output and see if it reports back that the scope has completed the slew whilst the scope is still visibly moving.
Won't solve your issue but might help determine if there is some issue with reporting slew complete or not.
I recently completed a project to build a "hat" pcb for the Raspberry Pi 3 to drive a Moonlite focuser via the PIs GPIO pins and a DRV8805 controller. As I use Ekos/INDI for my imaging I also wrote a new focuser driver for it.
On the off change this is of any use to anyone else the hardware is available under the CERN OHL and the driver is available under the GPL3.
There's more information about the project on my website along with links at the bottom of the page to several blog posts that cover the issues I encountered during the project and mistakes made (quite a few ).
If you just want to see the driver it's on bitbucket in the indi_driver/indi-mupastrohat/ directory.
Sadly there's only been one night of clear skies since finishing the project, so whilst I managed to test the focuser out and know everything works, I've yet to get time to take any images with it Fingers crossed this month is better than December was.
When building indilib on debian testing using a fresh checkout made today, I get the following error:
[ 68%] Linking CXX executable indi_wunderground_weather /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcurl.so: undefined reference to `libssh2_scp_recv2' collect2: error: ld returned 1 exit status CMakeFiles/indi_wunderground_weather.dir/build.make:154: recipe for target 'indi_wunderground_weather' failed make: *** [indi_wunderground_weather] Error 1 CMakeFiles/Makefile2:1546: recipe for target 'CMakeFiles/indi_wunderground_weather.dir/all' failed make: *** [CMakeFiles/indi_wunderground_weather.dir/all] Error 2 Makefile:127: recipe for target 'all' failed make: *** [all] Error 2
As this is a module I do not need, I've just edited the cmake file to not build it but thought I'd let you know of the build error. It may be worth exposing a few cmake config options to enable/disable building of this module if the curl lib debian is using is going to be an issue.
Whilst I think on, I built kstars earlier on debian testing too and it needed Qt5X11Extras adding to target link libraries and libqt5x11extras5-dev package installing.
I read that earlier, but it didn't really cover what the parameters did or how they might impact guiding so whilst I can adjust them I'm not really sure what a higher or lower value would mean or even what range is likely to be sane.
Thanks for updating the docs I'll take a look when you're done
My guiding with Ekos is currently a little hit and miss, although I'm putting that down to a combination of polar alignment and dec motor issues. That said, there's quite a few options with the ekos guider that can be tweaked but I can't find any real documentation about what these settings do.
For example, guide speed. I'm using pulse mode guiding with an LX90 which I believe works at 0.5x sidereal in pulse mode. Should I set the guide speed box to 0.5x in that case? I noticed by default it was set to 0.100 and the label to the right says p=xxx, where as when set to 0.5x the label reads p=133.3 which matches the proportional gain entry.
What are the parameters "proportional gain", "integral gain", "derivitive gain" etc How do they alter how the guiding works?
Minimum Pulse I assume means Ekos won't send corrections until the error requires at least this minimum pulse duration to correct? Likewise "Maximum Pulse" ekos won't try to correct with a value above that ?
Does calibration need to be done only once in a session, or after slewing to a new object is another calibration run useful?
Is the "guiding delta" the arc second error that needs to be corrected overall or just based on comparing the last two images?
What is the "sig(*)" values? Is this the RMS error?
I had a search through the forum and didn't find any real answers to the above (apologies if I missed one). I also looked for information on linguider but the "official" site seems to be a source forge page with the code releases. If there's any user documentation available can someone point me in the right direction?