Gary's profile

I built everything on Debian 10 about a week ago using the latest stable tagged branches from each repo. Should you choose to do it manually rather than via the script above the main issue is installing all the dependencies you need Assuming you already know how to use git that is. If not, have a read about how to checkout a repo and switch to a named/tagged branch and you'll be all set.

If it's of any help, here's what I built and iirc the order I did it in:

IndiLib "v1.9.0" (and 3rd party + MUPAstroCAT)
StellarSolver "1.5"
KStars "stable-3.5.3"
PHD2 (v2.6.9)

One tip is to first install "GNU Stow". Then for each of the above items when you run ccmake, for example with indilib, change the install prefix to "/usr/local/stow/indilib-v1.9.0" then configure/make/make install as normal. You can then as root cd into /usr/local/stow and "activate" the indilib install with

stow indilib-v1.9.0

now make/install/activate the indilib 3rd party, then stellar solver and so on.

The beauty of this is, when a new release of any of the software comes out or you want to test the develop version, you build it as normal but set a different install prefix "indilib-dev" or "indilib-v1.10.0" etc and then cd into /usr/local/stow and deactivate the old version, activate the new.

stow -D indilib-v1.9.0
stow indilib-dev

That way if in an imaging session you encounter new bugs, you can simply stow -D indilib/kstars/stellar/phd2 and stow the last version you know worked fine. Takes a few minutes and makes experimenting with new versions less risky

Also fwiw I had to build PHD2 with USE_SYSTEM_* OFF. I'm not sure which lib it was, but it didn't play nicely with the latest system versions and would fail to connect to my equipment via indi.

Read More...

I have a fork mount LX90 scope with a long enough optical train that I can't image any object within around ~25 degrees of polar home without a mount crash.

Is there anyway to add a circle around Polaris with a given degree radius so I can determine when an object is getting close to risk a slew? Also, any way for Ekos to refuse to slew to an object within X degrees/minutes of polar north?

Read More...

The indi 3rdparty SX drivers for Starlight XPress cameras appears to be failing to build under v1.9.0 of indilibThere's a few deprecation warnings and then errors over setInterlaced on PrimaryCCD and GuideCCD. Looking at the current git source setInterlaced appears to have been commented out?

github.com/indilib/indi/blob/a6ffc654e24...e/indiccdchip.h#L300

Has v1.9 being released before all the 3rd party drives have been updated?

Read More...

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.

Read More...

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?

Read More...

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?

Read More...

mcgillca wrote:

1) I generally focus manually with a Bahtinov mask

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

2) I didn't sync at all, which left my pointing~ 2 degs away from the correct spot. Of course, platesolve sorted this out (though I sometimes needed multiple moves to get to the right location). Again, is there a recommended way to e.g. Sync to one star first, then use platesolve, or to automatically Sync then move to the right location?

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.

3) I managed to create a scheduled imaging session - track, align and capture. That worked well, but I had two problems: a) I could not find a way to reset the job (I double clicked but when I reran the job, I was just told it was completed). Secondly, I set up a series of different exposure times as a sequence file. This worked well from the Camera tab, but when I used it as part of a scheduled run, Ekos only took the first set of images (I had 4 sets of 2 images each of different exposure lengths). Am I doing something wrong?

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,

Colin

P.S. Apologies if this is posted twice - I can't see it in the forums.[/quote]

Read More...

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?

Read More...

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.

Read More...

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.

astrocat-slide1-thumb.jpg

Read More...