There are multiple sessions in the log.
The first one or two had only the mount device with focuser connected via AUX port. Some focuser properties are reported in the log by the Celestron AVX device. OT drop down showed no focusers.
After some tinkering I re-connected the focuser with a USB cable, added the Celestron SCT device to the profile, and it became available in the OT configuration. This is how it worked for the rest of the night. It works fine this way, except cabling is less convenient.

Read More...

It just got worse with the last release of KStars. Optical trains configurator does not recognize the focuser presense. So both trains have no focuser rendering Focus module unusable. Focuser tab is there under mount's INDI device and I can tinker with it directly.

File Attachment:

File Name: log_23-33-32.txt.gz
File Size: 89 KB


Read More...

Here is more detailed log from last night. KStars made it almost to the end but still crashed at 5 AM :)

File Attachment:

File Name: log_19-10-35.txt.gz
File Size: 971 KB


The stack trace is exactly the same. I can share core dumps if anybody wants to look. Again, when I run GDB on those dumps, no helpful stuff (local variables, links to source files, etc.) appears despite the KStars debug package is installed. Do I miss some important step?
My imaging computer has only 2 GB of RAM. KStars itself takes over 1 GB. I tried running it under Ekos Debugger. GDB takes another 1.5 GB and things get really tough, though it doesn't die right away.

This time it again happened when Focus just started. Another interesting fact is that guiding is still running (Focus has been only doing a test exposure (why do I have it enabled?..)) Apparently, two cameras finished their exposures really close to each other and here the story ends.
My both cameras are ZWO now. Until about a week ago I used SX Lodestar as a guide camera and got similar crashes. I only have terse logs from the past. Here is one.

File Attachment:

File Name: log_19-11-18.txt.gz
File Size: 14 KB

It ends during normal capture cycle. Guiding exposure was 1s. I do see a good chance that main and guide cameras finished at the same time.

Read More...

This is the latest version from PPA. Similar crashes have been happening to me over several last months. Though I cannot promise it is the same spot.
On some nights it is going solidly. On others, with the same config, it's tripping multiple times. Last night it crashed after 3 hours of running. I restarted it and it crashed again in 2 hours.
INDI server and drivers keep running after crash, it's only KStars itself gets a segfault.

See the log, the focusing is just started. It is likely starting an exposure or receiving the image.

File Attachment:

File Name: log_00-51-28.txt.gz
File Size: 58 KB


Here is the stack from coredump. I can't see more details despite the kstars-bleeding-dbg package is installed.
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:131
#1  0x00005644b84ca49f in INDI::BaseDevice::setBLOB(_IBLOBVectorProperty*, xml_ele_*, char*) ()
#2  0x00005644b84caf37 in INDI::BaseDevice::setValue(xml_ele_*, char*) ()
#3  0x00005644b84ceed7 in INDI::BaseClientPrivate::dispatchCommand(xml_ele_*, char*) ()
#4  0x00005644b84cfe4c in INDI::BaseClientPrivate::listenINDI() ()
#5  0x00005644b84d01c9 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<std::_Bind<void (INDI::BaseClientPrivate::*(INDI::BaseClientPrivate*))()> > > >::_M_run() ()
#6  0x00007fd6742f52b3 in std::execute_native_thread_routine (__p=0x5644bf908640) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:82
#7  0x00007fd673f7cb43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#8  0x00007fd67400ea00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

I have a guess from my overall experience. I focus at 2x2 binning (and align at 4x4) to speed up things on my slow computer. Main capture is with no binning. So, Ekos has to switch binning back and forth. Occasionally I see an image with wrong resolution in some module. Like CCD get binned image or Focus gets an unbinned one. Furthermore, sometimes focus images get into main Ekos preview or even trigger a FITS viewer pop up, even though that is disabled. So, there may be some races that are mostly benign, unless it is around changing binning...

I should perhaps enable more logs for capture and focus next night.

Read More...

If absolute focuser means that it can move to specific position directly rather than moving in or out then Celestron's focuser is absolute.
I second everything Ron said above. A few versions back it worked fine and displayed the activity correctly as a short bar. Then it broke and now focuser activity is displayed only when session is read from file. Also, as it appears to me, all the bars start at the session start and end at different times when each focus procedure actually ended. So they effectively overlap and look like one long bar.
As a quick guess, can it be that the live session does not show the focuser because there is no dedicated INDI device? It goes via the mount device.

Read More...

I have a Celestron AVX mount and Celestron SCT focus motor.
When the focuser is connected with an AUX cable via the mount, Ekos Analyze module appears to think there is no focuser. So it doesn't show its actions on the time line. Focus tab and all other functionality work fine. If I open the analyze record later, all focuser activity is there and displayed. Only current live session is affected.
When the focuser is connected with a USB cable directly to the PC, everything is fine, except cabling gets more awkward, so I don't want to do that.

Read More...

Proper versioning is the answer to the problem. Say, if the new version of INDI would not work with previous version of drivers, as it is usually the case, its version number should be bumped high enough to not match the drivers' dependency lists. Then, in case of Launchpad slowness, you as a user would see nothing (in Software Updater UI), or some conflict warnings (from apt CLI). At worst, it may offer you to upgrade INDI and uninstall drivers, which is still suspicious enough so that most users would cancel that.
 

Read More...

Konstantin Baranov replied to the topic 'recovery from brief clouds' in the forum. 1 year ago

I would love extra resiliency too. Until then, there is an option to re-align at the beginning of each job. So you simply have short sequence and let the scheduler repeat it indefinitely or until certain time. In case when guider locks in wrong direction, you would only have a few remaining subs misaligned, then it re-aligns and continues nicely. My sequences are like 18×60s or 36×15s. Once in a while I get that cloud and the scheduler recovers soon enough.

Read More...

That is what I read on the internet about high speed mode too. Funny enough, I do not see the ADC width reduction with my ASI294MC (that is MC, not MM). I kinda see a slight difference in dark noise patterns with high speed enabled or disabled. But in both cases the data numbers seem quantized at 14 bit. I guess, this is why I had this mode enabled, apparently harmless. Better disable it for good.

Read More...