Oh and also, I'm currently not using dithering (I don't need to since there's drift this big ;)

Read More...

phomer60,

I'm using PHD2. No issues there.
This isn't game breaking, but I'd re-center if I could. There's about 110 arcsec drift I think from the start to the end of the session. Attached an image to show the amount.

I realize a feature like this would touch a lot of internals of Ekos and I'm not sure if it's worth the effort in the end though, unless there are a lot of others that feel that this would be a much needed feature.



Read More...

Yeah, I did not find a way.

Queuing the same job multiple times seems to mark the following jobs as "Invalid". Running the same job in a loop does not run the alignment every time the job runs which of course makes sense most of the time when you have a sequence like 1xR, 1xG, 1xB frames and you just want to repeat that. I don't think looping multiple jobs (1,2,3 -> 1,2,3...) is supported either, so taking a "garbage frame" in between as a job to force alignment wouldn't work either.
The problem does indeed get quite apparent when dealing with a smaller field of view and seems to be even worse when there are issues with seeing. It's currently not a deal breaker but being able to re-center would be ideal, since my sessions are often hands-off once I've set up the scheduler.

Thinking feature wise, perhaps it would make sense to have an option to run the solver every N frames to see if the centering is still within limits - if not, it would run a re-center.

Read More...

So I was wondering, is it possible to run align in the scheduler after each job repeat, or perhaps always after capturing N frames?
The issue I'm having that in a long session I'm having a noticeable drift of the imaging area, and I'd like to make sure it stays on target as much as possible. So, say after 10 frames it would run the solver again to make sure we're still right on target, kind of like the way we can have dithering every X frames.

Read More...

Robusto replied to the topic 'Memory Leak' in the forum. 4 years ago

I suspected as much - when did the thread sync issue get fixed, which commit hash? It is present in the current release, 3.3.9 (Build 2020-01-02T08:17:38Z).
I did try to re-produce that yesterday from the latest sources but failed, so it does seem like it has been fixed (can't be 100% sure since I was testing on another computer) but I can't exactly find which commit did that.

Read More...

Robusto replied to the topic 'Memory Leak' in the forum. 4 years ago

Indeed, those two settings do the magic - but this is probably not just about getting memory filled as this happens even with a handful of captured frames.
This is very disappointing, I finally bit the bullet and upgraded my KStars to the latest and this is now practically unusable the way it is.

Also, brief rundown on how to reproduce the problem:

- Using simulator devices: CCD sim, telescope sim, guider sim
- Created a new sequence (3x lum, 3x red) and saved it
- Opened the scheduler, chose M 34 (I doubt this matters), selected the sequence
- Did not touch the sequence conditions
- Add and run the sequence

A crash will most likely occur at some point (had one happen at 2 frames, one happen at 3 frames, etc).
I doubt this is even exactly a simple memory leak since it happens so quickly, and my machine has 8GB of RAM, a pair of simulator camera frames hardly make a dent.
As said, disabling those two options act as a workaround, so this is definitely FITS viewer related.

Attached a verbose log.
The crash happens right after "Reading FITS file buffer".

I tried the bug reporting tool but unfortunately it failed to get anything useful out of it, so I tried running it with gdb, and that perhaps gave out something useful:

Thread 14 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa1cc2700 (LWP 8338)]
0x00005555557d7878 in FITSData::loadWCS (this=0x55555b2185e0) at ./kstars/fitsviewer/fitsdata.cpp:2444

And backtrace for thread 14:
Thread 14 (Thread 0x7fffa1cc2700 (LWP 8338)):
#0  0x00005555557d7878 in FITSData::loadWCS (this=0x55555b2185e0) at ./kstars/fitsviewer/fitsdata.cpp:2444
#1  0x00005555557b01c2 in QtConcurrent::StoredMemberFunctionPointerCall0<bool, FITSData>::runFunctor (this=0x55555ba61720)
    at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:189
#2  0x00005555556748e5 in QtConcurrent::RunFunctionTask<bool>::run (this=0x55555ba61720)
    at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentrunbase.h:108
#3  0x00007ffff21dc2b2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff21df17d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff14ab6db in start_thread (arg=0x7fffa1cc2700) at pthread_create.c:463
#6  0x00007ffff026788f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

And backtrace for Thread 1:
Thread 1 (Thread 0x7ffff7f9a440 (LWP 8321)):
#0  0x00007ffff14b19f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x55555ba01d90)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55555ba01d40, cond=0x55555ba01d68) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x55555ba01d68, mutex=0x55555ba01d40) at pthread_cond_wait.c:655
#3  0x00007ffff21e05ab in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff21d30e0 in QFutureInterfaceBase::waitForFinished() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00005555557bbd72 in FITSView::loadFITSFromData (this=this@entry=0x55555b9fef10, data=data@entry=0x55555c239000, inFilename=...)
    at ./kstars/fitsviewer/fitsview.cpp:309
#6  0x000055555590f53c in FITSTab::loadFITSFromData (this=this@entry=0x55555b10b650, data=data@entry=0x55555c239000, imageURL=..., 
    mode=<optimized out>, filter=<optimized out>) at ./kstars/fitsviewer/fitstab.cpp:478
#7  0x00005555558f6715 in FITSViewer::updateFITSFromData (this=0x7fff48001c30, data=data@entry=0x55555c239000, imageName=..., 
    fitsUID=<optimized out>, tab_uid=tab_uid@entry=0x7fffffffd560, filter=filter@entry=FITS_NONE) at ./kstars/fitsviewer/fitsviewer.cpp:538
#8  0x00005555558d3786 in ISD::CCD::processBLOB (this=0x555557c64380, bp=0x7fff7c0186d0) at ./kstars/indi/indiccd.cpp:1722
#9  0x00005555558c0656 in INDIListener::processBLOB (this=<optimized out>, bp=0x7fff7c0186d0) at ./kstars/indi/indilistener.cpp:435
#10 0x000055555586b1d4 in INDIListener::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>)
    at ./obj-x86_64-linux-gnu/kstars/KStarsLib_autogen/FRI4DANIHA/moc_indilistener.cpp:189
#11 0x00007ffff23ec645 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00005555558389a2 in ClientManager::newINDIBLOB (this=<optimized out>, _t1=<optimized out>)
    at ./obj-x86_64-linux-gnu/kstars/KStarsLib_autogen/FRI4DANIHA/moc_clientmanager.cpp:363
#13 0x00007ffff23ed1b2 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007ffff384283c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x00007ffff384a104 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007ffff23bd9c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007ffff23c013d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007ffff2417353 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007fffed8f3417 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007fffed8f3650 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007fffed8f36dc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007ffff241697f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007ffff23bb9fa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007ffff23c4aa4 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#25 0x000055555562a412 in main (argc=<optimized out>, argv=<optimized out>) at ./kstars/main.cpp:333

I hope this'll help in investigating this.

Read More...

Answering to my own post :)

1. Icons were indeed missing. Installing kdelibs5-data seemed to fix the issue.
2. I just realized that you can open the CMakeLists.txt in Qt Creator, which parses the CMake file and opens it up neatly as a project. Learn new things every day!

So I now have the project debuggable in Qt Creator, which is what I was aiming for.

Read More...

I was thinking of taking a look at the source and generally getting a dev environment set up so that I can compile, run and debug KStars and Ekos. Googling and following instructions got me to run cmake and successfully compile KStars. Icons seem to be missing though - perhaps I'm missing some package?

Anyway, in order to do something meaningful I'd like to set up an IDE to get comfortable. Documentation mentioned Qt Creator and KDevelop as potential IDEs. I've got Qt Creator installed but there doesn't seem to be any kind of project files in the whole repository. So I'm kind of wondering, what is the preferred way of developing and debugging KStars? I'm familiar with different IDEs and used to the "project file" concept and I'm kind of lost when there's no IDE involved. So how are you developing the project? What is the recommended environment and IDE/tools to do it with? Obviously Qt Creator is the (or at least a) tool of choice given there are Qt UI files around. Anyway, I'm not very familiar with Qt and C++ development in Linux anyway but I'd love to give it a shot... but I feel a bit lost here and would love a little help and a few pointers.

- Robusto

Read More...

You're right, I could enable OpenGL from raspi-config. Testing it directly with a monitor it now works - however I still have a problem with XRDP which is the main use case anyway as I'll be operating on it remotely. I haven't found a solution for this yet. But yeah, this is a non-Ekos problem... I wonder if anyone else has run into this before.

Oddly enough, glxgears does run just fine under XRDP. When starting KStars however I'm getting the errors:

QXcbConnection: Failed to initialize XRandr
libEGL warning: DRI2: failed to create any config

And then when it crashes:
Xlib: extension "XInputExtension" missing on display ":10.0"

And in the kstars log file:
[2018-08-19T14:24:49.942 EEST WARN ][                       default] - QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
[2018-08-19T14:24:49.943 EEST FATL ][                       default] - Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile  0) 

So, definitely OpenGL and XRDP related issue. Now I just need to scour the internet to find a fix... :S

Read More...

First of all, I can't start without saying that KStars/Ekos is a fantastic piece of software! Thank you Jasem for developing it and for the continuous support!

I've now been testing Ekos on my RPI 3, at first I just used it as an INDI server but now that I got myself a new camera which has a rather large resolution, the size of the files I have to download by network can become an issue especially in star parties where network infrastructure is shared and can be under heavy load - hence it then makes a lot of sense to run Ekos on the RPI as well and just operate it with remote desktop. Mostly things work well, I've had a couple of crashes for unknown reasons, but now I've found that the telescope mount control always crashes Ekos on RPI.

Looking at the log output, the last message is:

QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile  0) 

Now, since this is RPI I don't think OpenGL is supported. This is probably the issue - but why does the mount control need it? Everything else works just fine.
This is a bit annoying since sometimes it would be handy to move the telescope from my screen instead of operating the hand control.

Other than that, my experience has only been positive :)
It's great to see that the software runs on RPI and is completely usable.

Read More...