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

[Richard Kline]

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

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

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 
using a Motorola Atrix phone lapdock with some adapter cables as 
battery, display, keyboard and track pad plus a USB trackball with 
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.

Performance
The Raspberry Pi can just barely run Kstars
CPU usage immediately pegs at 100%, but the program is usable.
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 to a new object 
takes only a few seconds and is not objectionable.  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 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).

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)

Regards,
Richard Kline