[Kstars-devel] Kstars use case - Deep sky observing

[Akarsh Simha]

> Since Akarsh asked people to send what they do with Kstars to the
> list, here goes.

Thank you!! Highly appreciated!!

> I use Kstars for deep sky observing with dobsonians in conjunction
> with star charts (mostly the Sky and Telescope Pocket Sky Atlas
> augmented by some printouts of freely available PDFs).  Initially

[ BTW, not sure if you saw this. Also some ad for my own side-project
with KStars: http://bas.org.in/~akarsh/Logbook-Project/ ]

> use was in a 30:70 ratio with Kstars mostly used to determine which
> way was up to turn the charts appropriately and determine where to
> push the scope.  As I have gotten used to it and tweaked things like
> the label density to where I want it in the Catalogs tab in the
> "Configure Kstars" menu, it is more like 70:30 or more that I use
> Kstars without referring to the charts.  I used Kstars running on a

I'm a visual observer too (18" dob, etc). Are you happy with KStars'
representation of star brightness, or does it seem disproportionate
with what you see in the telescope? I do feel that it is hard to
correlated brightness in the eyepiece with the size of the star in
KStars, but I haven't bothered quantifying this systematically and
trying to understand what I'm missing. Any help / feedback here is
appreciated! I suspect this also changes significantly with the star
density -- I'd prefer otherwise, because star density should only
alter the density of stars, not the magnitude-size calibration.

> Raspberry Pi and my 20" dobsonian to observe 94 Messier objects
> trying to do the Messier Marathon the night of 9-10 March this year,
> and I would have gotten at least 6 more objects if some hazy clouds
> had not moved in to the Southeast just before dawn.

Wow! You run it on a Raspberry Pi! That's an excellent idea. I might
do that too :).

I missed this year's marathon (cloudy skies). Good to hear that KStars
helped your marathon effort!

> Kstars on the Raspberry Pi
> I think the Raspberry Pi has great potential as an on-scope computer
> that doesn't require a lot of power so it can run all night.   I am

That's a very good point. Portable, and takes little power. I was
worried I'd have to switch out batteries on my laptop, and switch
between laptops even.

> using a Motorola Atrix phone lapdock with some adapter cables as
> battery, display, keyboard and track pad plus a USB trackball with

I didn't know about lapdocks! Sounds like a good idea, not too
expensive. I'm wondering if there's any other way out... I can't think
of any.

> scroll ring (a scroll wheel to zoom is highly recommended).   I am
> using a roll around laptop stand at the moment and have not mounted
> anything on the scope yet.  My ultimate goal is to combine the Pi
> with an Arduino board to read out encoders on the scope or a 3-axis
> gyro/accelerometer/compass to determine the scope orientation.

Wow! That's awesome. I was considering a 3-axis accelerometer +
magnetometer, but the problem is magnetometers aren't very reliable,
AFAIK. I'm thinking of encoders now. I guess once I get to start on
that project, I might start asking around on this list about encoders
and INDI and support for them in KStars :). Hey, maybe I can check out
INDI, finally :D.

> Performance
> The Raspberry Pi can just barely run Kstars
> CPU usage immediately pegs at 100%, but the program is usable.

Hmm. I wonder if there are any improvements that can be made. I don't
know if the Raspberry Pi CPU supports parallel operations on 4
floating points, in which case, using that parallelism to do the
precession and nutation corrections using quaternions will be of great
help to speed. They will certainly help on a modern Intel x86 PC.

Also, now that you brought this up, I just noticed that KStars
actually uses full CPU (50% on my computer, dual core) even when
idling. Something bad is going on that needs to be fixed.

If you ever find the refreshing too slow, you could try this checkbox
called "Always recomputed coordinates" in Configure KStars -> Advanced
-> General tab. If you uncheck that, you risk inaccuracy, but it
doesn't do precession / nutation etc all the time.

> For the lapdock display at 1366x768 resolution, running Kstars on a
> stock 700 MHz clock Raspberry Pi in full screen mode or with a
> window of nearly full screen size, if you press <ctrl>-f to bring up
> the find object dialog box it is >= 10 seconds before you can type
> the object into the entry field which is barely tolerable.  Panning

Another good issue. This is slow even on my laptop, but not 10
seconds! That must be annoying. One "immediate solution" is to have a
"Quick Find" box in the spirit of Cartes du Ciel, that doesn't
populate the list, and expects exact names / catalog numbers (but
could do some helpful correction, maybe).

> to a new object takes only a few seconds and is not objectionable.

Have you removed "Animated Slewing" in the "Configure KStars" dialog?

> Looking at the cpu usage with top shows that about 60% of the clock
> cycles are going to Xorg and only 35-40% to Kstars so the Kstars
> code seems to be pretty efficient and it is the screen draws that
> are the big load.  I am running now over clocked at 900 MHz and keep
> the window size at about 70-ish percent of the screen and it is
> about 7 seconds after pressing the key combo before the dialog box
> is usable which is better.  My initial thought was to stop the clock
> and just remember to press <ctrl>-e to set time to now periodically,
> but that does not noticeably help since the display seems to still
> be updated at the same rate even if the clock is stopped.  Turning

Yes, this seems to explain the 50% CPU usage I mentioned. This is
something we definitely should invest into improving. If this is
limiting, then unchecking "Always recompute coordinates" will not
really help.

> off anti-aliased drawing seemed to help a little (I have not
> exhaustively benchmarked beyond the counting one-mississippi
> two-mississippi after pressing the keys for the find object dialog).
> Switching to the OpenGL backend was much slower on the Raspberry Pi
> with a Raspbian derivative Linux distribution.  I have not had the
> time to root around in the documentation to look for other
> performance options or try to compile the code from source (and the
> Pi might not have enough memory to compile a Kde application even
> though it can run one).

In principle, you could cross-compile with heavy optimizations. I
think the right place to optimize, though, is KStars :).

> Other possible performance options
> I would appreciate if the more knowledgeable people on list think
> any of the following could be easily done to improve Kstars
> usability on a low spec machine like the Raspberry Pi:
> - Stop redrawing the screen when the clock is stopped
> - Have a clock time step of 1.5 s or 2 s (i.e. only calculate
> positions and redraw the screen each 1.5 or 2 second instead of
> advancing the clock by more than one second during each one second
> simulation step as the program seems to be working now)

Yes, I think both of these can be done. However, I have a bit too much
on my platter right now (I want to get the Hipparcos epoch bug fixed,
and then, possibly work with Rishab on understanding and improving
custom catalogs and stuff. I'm excited about catalogs at the moment so
I can get logbooks for the Hicksons, the Abells and the like; in the
process, we could deliver the sanitized Revised NGC/IC catalog). It'd
be nice if someone could work on this, otherwise, I might have to hold
it off for a while.

Hint-Hint: Potential GSoC project for those watching -- optimize the
*@#$ out of KStars.

Regards
Akarsh