Ok, thanks for the info.
I changed my script to only work with setSolverArguments(), but due to the clouds here I could only test my script with the simulators.

I found something weird coming from the getSolutionResult(). I get some weird results when using this function.

This is an excerpt from my script:
solvedcoord=ifaceekos.getSolutionResult() #ra and dec from solved
RA_solved=solvedcoord[0]
DEC_solved=solvedcoord[1]

This is what I see in the Ekos log when I do a platesolve with captureAndSolve() from the script:
2017-04-14T21:10:26 Target is within acceptable range. Astrometric solver is successful.
2017-04-14T21:10:26 Target is within 0° 00' 19" degrees of solution coordinates.
2017-04-14T21:10:26 Solution coordinates: RA (07h 33m 02s) DEC (-21° 28' 14") Telescope Coordinates: RA (07h 33m 02s) DEC (-21° 27' 54")

This is what my script output produces (from the excerpt from above). The getstatus() produced value 1 (completed).
2017-04-14 21:10:26,394 Returnstatus: 1
2017-04-14 21:10:26,394 Returnstatus: COMPLETE
2017-04-14 21:10:26,394 RA solved: 90.001477117
2017-04-14 21:10:26,394 DEC solved: 113.075466756
2017-04-14 21:10:26,395 Solve status: 1
2017-04-14 21:10:26,395 Solve function found a solution

Now, according to the documentation, these numbers are the ra and dec values in degrees. But they don't resemble the ra or dec or even the alt/az even remotely. I wonder.. what are these numbers?

Oh, and another issue, I've noticed that the sync command of the telescope simulator sometimes crashes/blocks. This is when I execute captureAndSolve(), with the setSolverAction(1) set on value "1" (slew). I tested quite a bit for debugging the script and this happened like 5% of the times. Nothing in the indi/kstars logs; except the command sync is issued. Something minor, but maybe useful to know.

Read More...

I'm also planning something similar on the long term. Mainly to escape the rainy conditions and have the scope a few 1000 km's further to the south.
I think if you have a really automated observatory, you should put more $$ in the pc's. You really need some kind of ups so you can park the scope & close the roof when power shuts down. I think you'll need some kind of stable and powerful server that is powered on nonstop.

Read More...

In the documentation, I have seen that the function setSolverSearchCoords has changed.
api.kde.org/4.x-api/apidox-kde-4.x/apido...gnDBusInterface.html

It seems, that the parameter "radius" for this function has disappeared. However, it's still in the argument-list.

void Ekos::Align::setSolverSearchCoords	(	double 	ra,
double 	dec 
)		
DBUS interface function.

Sets the solver search area options

Parameters
ra	center RA for search pattern, in hours.
dec	center DEC for search pattern, in degrees.
radius	radius of search pattern, in degrees.
Definition at line 3878 of file align.cpp.
dec	center DEC for search pattern, in degrees.

Some small update:

1) Yes, when you check "Lock", the filter DOES change for the focus. sorry, I have said nothing.

2) I had a hard crash of Ekos. This happened when I clicked the "capture" button in the capture module. Don't know what happened here. Here is extract of backtrace and log.

GDB backtrace
--------------

Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
0x0823ccc5 in FITSData::findCentroid<unsigned short> (this=0xb8540b0, boundary=..., initStdDev=<optimized out>, 
    minEdgeWidth=5) at ./kstars/fitsviewer/fitsdata.cpp:1298
1298    ./kstars/fitsviewer/fitsdata.cpp: No such file or directory.
(gdb) bt
#0  0x0823ccc5 in FITSData::findCentroid<unsigned short> (this=0xb8540b0, boundary=..., initStdDev=<optimized out>, 
    minEdgeWidth=5) at ./kstars/fitsviewer/fitsdata.cpp:1298
#1  0x082441f8 in FITSData::findCentroid (this=<optimized out>, boundary=..., initStdDev=<optimized out>, 
    minEdgeWidth=<optimized out>) at ./kstars/fitsviewer/fitsdata.cpp:1168
#2  0x0824431f in FITSData::findStars (this=0xb8540b0, boundary=..., force=false) at ./kstars/fitsviewer/fitsdata.cpp:2046
#3  0x0825260c in FITSView::findStars (this=0xad66378, algorithm=ALGORITHM_CENTROID) at ./kstars/fitsviewer/fitsview.cpp:1197
#4  0x082fad89 in Ekos::Focus::setCaptureComplete (this=0xad3a388) at ./kstars/ekos/focus/focus.cpp:1144
#5  0x081c016b in Ekos::Focus::qt_static_metacall (_o=0xad3a388, _c=QMetaObject::InvokeMetaMethod, _id=44, _a=0xbffaef54)
    at ./obj-i686-linux-gnu/kstars/moc_focus.cpp:373
#6  0xb568d66f in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#7  0xb568dbad in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#8  0x081a429a in Ekos::DarkLibrary::darkFrameCompleted (this=0xb505db8, _t1=<optimized out>)
    at ./obj-i686-linux-gnu/kstars/moc_darklibrary.cpp:148
#9  0x082995ab in Ekos::DarkLibrary::subtract<unsigned char> (offsetY=<optimized out>, offsetX=<optimized out>, 
    filter=<optimized out>, lightImage=<optimized out>, darkData=<optimized out>, this=<optimized out>)
    at ./kstars/ekos/auxiliary/darklibrary.cpp:258
#10 Ekos::DarkLibrary::subtract (this=0xb505db8, darkData=0xbdc33f0, lightImage=0xad66378, filter=FITS_NONE, offsetX=0, 
    offsetY=0) at ./kstars/ekos/auxiliary/darklibrary.cpp:186
#11 0x0829d1f6 in Ekos::DarkLibrary::newFITS (this=0xb505db8, bp=0xa9e99c98) at ./kstars/ekos/auxiliary/darklibrary.cpp:341
#12 0x081ae056 in Ekos::DarkLibrary::qt_static_metacall (_o=0xb505db8, _c=QMetaObject::InvokeMetaMethod, _id=2, 
    _a=0xbffaf144) at ./obj-i686-linux-gnu/kstars/moc_darklibrary.cpp:85
#13 0xb568d66f in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#14 0xb568dbad in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#15 0x081a6dca in ISD::GDInterface::BLOBUpdated (this=0xb32c1c8, _t1=<optimized out>)
    at ./obj-i686-linux-gnu/kstars/moc_indistd.cpp:383
#16 0x0820011f in ISD::CCD::processBLOB (this=<optimized out>, bp=<optimized out>) at ./kstars/indi/indiccd.cpp:1703
#17 0x081f4b45 in INDIListener::processBLOB (this=0xa88b3f0, bp=0xa9e99c98) at ./kstars/indi/indilistener.cpp:374
#18 0x081c082e in INDIListener::qt_static_metacall (_o=0xa88b3f0, _c=QMetaObject::InvokeMetaMethod, _id=18, _a=0xa7cb9588)
    at ./obj-i686-linux-gnu/kstars/moc_indilistener.cpp:182
#19 0xb568a3f0 in QMetaCallEvent::placeMetaCall(QObject*) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#20 0xb568e183 in QObject::event(QEvent*) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#21 0xb613c04a in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
#22 0xb614184c in QApplication::notify(QObject*, QEvent*) () from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
#23 0xb565d4ad in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#24 0xb566036e in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#25 0xb5660877 in QCoreApplication::sendPostedEvents(QObject*, int) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#26 0xb56b7e03 in ?? () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#27 0xb42ee4d9 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#28 0xb42ee779 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#29 0xb42ee844 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
#30 0xb56b81f3 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#31 0xb188a521 in ?? () from /usr/lib/i386-linux-gnu/libQt5XcbQpa.so.5
#32 0xb565adad in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#33 0xb566407f in QCoreApplication::exec() () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#34 0xb5b417b1 in QGuiApplication::exec() () from /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
#35 0xb6138cc4 in QApplication::exec() () from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
#36 0x08094a60 in main (argc=<optimized out>, argv=<optimized out>) at ./kstars/main.cpp:313
(gdb) 


Logs:
----------
==> log_09-36-14.txt <==
2017-04-11T09:36:26.416 - WARN - "Object named NGC 78 not found"
2017-04-11T09:36:26.488 - WARN - "Object named NGC 6050A not found"
2017-04-11T09:36:27.878 - WARN - "Object named NGC 4666 not found"
2017-04-11T09:36:28.526 - WARN - "Object named NGC 7318 not found"
2017-04-11T09:36:28.816 - WARN - "Object named NGC 7839 not found"
2017-04-11T09:36:29.013 - WARN - "Object named NGC 7840 not found"
2017-04-11T09:36:29.249 - WARN - "Object named IC 1127 not found"
2017-04-11T09:36:29.542 - WARN - "Object named IC 2497 not found"
2017-04-11T09:36:29.775 - WARN - "Object named IC 4703 not found"
2017-04-11T09:36:29.992 - WARN - "Object named JupiterComet Shoemaker–Levy 9 Wikipedia page not found"

==> log_21-38-29.txt <==
2017-04-11T21:45:45.543 - DEBG - SBIG CCD :  "Taking 1s exposure on main camera... "
2017-04-11T21:45:50.305 - DEBG - Focus:  "Capturing dark frame..."
2017-04-11T21:45:50.326 - DEBG - SBIG CCD :  "Taking 2s exposure on main camera... "
2017-04-11T21:45:55.213 - DEBG - fits MIN:  927  - fits MAX:  32639  - pixel range:  31712  - bin width  50.9021  bin count  624
2017-04-11T21:45:55.302 - DEBG - FITHistogram: JMIndex  0.999997
2017-04-11T21:45:55.317 - DEBG - Focus:  "Dark frame received."
2017-04-11T21:45:55.338 - DEBG - Focus:  "Dark frame saved to /home/cboy/.local/share/kstars/darks/darkframe_2017-04-11T21-45-55.fits"
2017-04-11T21:45:55.470 - DEBG - Focus:  "Image received."
2017-04-11T21:45:55.473 - DEBG - SNR:  31.3477
2017-04-11T21:45:55.473 - DEBG - The threshold level is  1031.21 (actual  1031.21 )  minimum edge width 5  minimum edge limit  3

After some time, I restarted playing with Ekos and Indi. The previous days, I had the same problems that I had a year ago. When capture a frame no star fields were shown, robofocus crashed all the time, camera crashed...
Setup: SBIG ST8xme camera w. internal CFW8 filterwheel, AZEQ6 eqmod, robofocus.

Today, I removed the whole indi+kstars, reinstalled it from the ppa, and installed the newest KDE plasma from the backports ppa of my kubuntu distro. Finally no more errors and it all seemed to work. It seemed the newest KDE plasma / Kubuntu upgrade did the trick. YES!!!

But I encountered some small issues for Ekos:

1) Focus Module in Ekos: when I choose the filter to focus and then click "capture", it doesn't change the filterwheel. When I use the sequence/capture module, or set the filter manually in Indi, the filter does change. The "Lock"-box in the focus-module is unchecked. This means, if you want to focus for a certain filter in the focus-module, you have to go to the indi-control-panel and select the filter there manually, then go back to the focus-module to focus for this filter. I think, when selecting a filter in the Focus-module, the focussing should change the filter to the filter that is set in the user interface and filter there.

It's also not really clear to me how to view the total CCD frame when I click "capture". The software seems to search every time automatically for a star. The total CCD frame appears for a few seconds, then the star is shown. If it runs flawlessly, this is probably handy, but when you work manually step-by-step and try to solve some problems, this is not very handy.

Also maybe a tip: it would be handy to have a running-wheel indicator on the capture-button to show that the image is busy being captured. I've seen this implemented in the Align-module, but not in the Focus-module.

2) Robofocus: I found that under the "settings tab", I have to set the 'Duty Cycle', 'Step delay', 'motorsteps per tick' manually. Even when the correct values were set correctly loaded and set from the loading of the driver! I had 1 time a robofocus that started to jump between values, but when I connect now and set the values manually, it works and robofocus driver seems stable and doesn't have it quirks. Maybe this is a bug, maybe not... Future testing have to make this clear.

3) Is it possible to have an extra button "warm up" button in the indi SBIG driver? Next to the cooler On/Off would be great. I know you can execute it manually in Ekos, but it would be very handy if I could warm up the CCD from the driver in the indi-control-panel.

4) In the Align-module, when the solver doesn't find the location in the first run, it will try to re-run the solver a few times again. Now, when the solver is 1st time run, you can click "Stop" in the solver control. When the solver is started again for a new attempt, then the Solver-control jumps back to the standard settings. The button "stop" is then greyed out, and "capture&solve/load&slew" are active again. This way, it's impssible to stop the solver from Ekos.

Otherwise, it's my impression that the software has improved quite a bit! Nice piece of work! I'll test further to use it on my "production" nights.

Read More...

Yes, correct. I use a textfile in the /tmp to keep a counter. Doing a platesolve for every fits-image captured would take too much time. It's only necessary every 10th or 20th file orso. There is drift, but not heavy. Because the script is launched after every exposure I have to keep the counter somewhere externally.

So the script just reads the counter from the textfile, and when the counter is 10 or 20 orso, it has to do the platesolve on the last image.
Now question is: how do I retrieve that filename? I haven't found it in the documentation. After that, I just pass it to the method.
startSolving (const QString &filename, bool isGenerated=true)

Read More...

Is there a way to get the location of the last FIT-file that is written to the disk, (using DBUS)?

I'm having the problem that I have a slow drift of my object from the chip. I try to solve it by executing a script every 10 exposures. I just keep the number of exposures in a file in /tmp directory. I execute the script for every file in my sequence. Every 10th file I execute a solve-slewtotarget sync on the last file that was written to the disk. Doing a new exposure for the platesolve operation would take too much time and would give me gaps in my timeseries. This way the object stays centered on the chip.

Basically, it's a very slow "autoguiding" on the frames that the main camera is taking.
I'm having everything figured out, except finding the location of the last written file.

Read More...

For the focusing problem: he didn't find a guidestar and I was staring to a black screen. When I took an image on the CCD capture tab, he showed a field full of stars. That's why I presume there was something with the shutter or something.
Error is here:
2016-10-05T22:00:15.476 - DEBG - Focus: "Failed to automatically select a star. Please select a star manually."

For the scheduler: I attached the logfile of the evening.
Error is somewhere here:
2016-10-05T21:53:27.162 - DEBG - Scheduler: "Found candidate job M 31 (Priority #10)."
2016-10-05T21:59:50.156 - DEBG - Scheduler: Checking INDI State...

What is the EquatorialToHorizontal note in the logs... I don't know

(ps: all the logging was on verbose)

Read More...

I could finally again play with the telescope last night. (sbig st8xme). I restarted with a fresh installation on 64bit system.

When I did the autofocus routine, he asked "Does SBIG has an mechanical or electronic shutter?".
I replied: "yes" (ST8 has mechanical shutter).
Then I only got black frames during the focus routine. I could not set it back again to normal.
What is the purpose of this function? Is it a bug?

Also, on the scheduler, when I add an object to the scheduler, and I click "play", then the status only changes to "scheduled", and he doesn't do anything further.

2016-10-05T22:10:08.163 - DEBG - Scheduler: Checking Startup State...
2016-10-05T22:10:08.163 - DEBG - Scheduler: Startup Idle. Starting startup process...
2016-10-05T22:10:08.163 - DEBG - Scheduler: Checking INDI State...
2016-10-05T22:10:08.163 - DEBG - Scheduler: Connecting INDI Devices
2016-10-05T22:10:08.163 - DEBG - Ekos: "Connecting INDI devices..."

Read More...

knro wrote:

There is maybe an issue with the dark library. See my topic on (logfile in 2nd post):
indilib.org/forum/ekos/1518-fits-viewer-...g-main-ccd-chip.html

Maybe this is only an issue with the SBIG dual chip cameras, as my other problems point out in that direction.

Read More...

And it becomes weirder and weirder. I restarted the laptop, then took an image with the guider. Then with the fits viewer open, I took an image on the focus-tab. He showed suddenly the fits viewer, then a hardcrash (log see attachment).

When I restart kstars, indi and ekos and take a manual image, it works on both the guider and the imager chip. But... he only shows a black screen (grey when stretched). This only occured after the hardcrash.

Restart on windows, and maxim-dl shows that the camera is working without a problem. Then reboot back on linux, and when I take an frame on the imager or the guiderchip, he only shows a black screen. Probably a darkframe?

The log in the attachment suggests that the issue is something with the new dark library. Maybe this is the cause of the problem?

Read More...

I have some weird phenomena since I installed the latest Kstars, Ekos, indi. Yesterday I played with the autoguiding, so I didn't take pictures with the big chip in the camera, only the autoguiding chip.
Camera is a ST8XME (dual chip).

I think using the guiding chip is somehow blocking the reading from the main chip in the software. When I take an image on the guidechip... It works. When I take an image using the main chip... he stalls.

Basically, I have the following scenarios:

1) Take flats. Go to wall postition (just position in the sky), and take flats, with ADU value 6400.
No fits viewer that is started... In the ekos main log, he only shows "capture in progress".

2) Goto object and track, focus, align.
Here too he doesn't start the fits viewer for preview. In fact... it seems like nothing happens and the program is stuck in the "focus stage".

3) On the other hand, when I use the guidechip... it seems to work!
When I do "goto object" and only select the "guide" option, then he DOES start the fits viewer and continue with the program.

4) When I click simply in the "focus" tab on "capture", to capture an image, he doesn't show the fits viewer either (with main chip)

5) When I go to exposure, make a sequence, and click on "preview", then he stucks on "downloading".
(for this I attached an attachment).