Save Crash

First up, I noticed when running KStars from within XFCE on Debian sid that any time I open a file load/save dialog (for example take a preview image then try to save it), ekos loses connection to the libindi server and then when you click ok in the save dlg, kstars segfaults. This does not occur on the older kde4 version in Debian Jessie.

I believe this bug is the same (symptom wise at least) as the one in this thread . Whilst browsing the forum I've also noticed this thread .

This is repeatable and I'll try to get a stack trace or some more useful information after work. As a workaround, I installed the KDE Plasma desktop. KStars/Ekos worked fine under that.

Polar Align

For a couple of nights I've been trying to get the Ekos polar alignment module working. The reported polar error seemed to be pretty random. After doing a new debian sid install on a spare disk to use a later version of kstars/ekos than the one in Debian Jessie, I encountered the same problem. However, due to the addition of the preview checkbox, I noticed a possible reason why.

Ekos takes an image, solves it correctly then slews 30" in RA before taking and solving a 2nd image. This second solve takes quite a while and looking at the preview there's a significant amount of star trailing. It looks like it performs the exposure whilst the mount is still slewing the 30".

Is there any option in Ekos that I've missed, to add a custom delay between scope slew command and the 2nd image taking.

Save File Name

This one is a little odd and I've yet to reliably recreated it. I was taking a sequence of lights and my tracking started to mess up, so I stopped the sequence, reset the guiding and started the sequence again. The first file saved with the correct frame number, one after the last frame it had previously saved, e.g 4. However each image in the sequence from then on saved with the same frame number 4.

This happened a few times throughout the night when new sequences were saved into the same directory as existing Lights. For example if 1..10 already existed, then it would save the first in a new sequence (that had same temp/duration/filter) as 11, but then save all remaining in that sequence as 11 too.

As a workaround I ticked the date/time box too to ensure the file names were unique regardless of the sequence number.

Hi Gary. Sorry about your troubles. Unfortunately I cannot provide useful support for KStars/Ekos on stock Debian. The only useful support I can provide is for the latest KStars. So there are two options here:

1. Install Ubuntu or any of its flavors (16.04) and use my PPA
2. Compile latest KStars/INDI from GIT on your Debian box.

Only then I can try to diagnose and solve any issues. There isn't just enough man power to support even slightly older versions. Thanks for using INDI/Ekos!

I've installed git version of lib indi + 3rd party drivers and kstars. So far I've only had chance to look at the mount slewing whilst taking 2nd polar alignment exposure.

Looking at debug logs for lib indi, it seems as soon as a goto is issued with the indi_lx200autostar it will report back that the slew is complete even though the scope is still moving at max rate across the sky to the target.

I had a quick play with minicom and my lx90 serial connection and manually issued the ":d#" command that isSlewComplete uses. It returns a non printable character whilst slewing and after the slew has finished it returns a "#". Looking in drivers/telescope/lx200driver.cpp in isSlewComplete it has

I switched those around so it returns 1 when the character matches "#" and now I can slew the scope around in kstars and it doesn't report isSlewComplete in the debug log until the lx90 stops (and the autostar handset display flashes).

My question is, is this a quirk with my lx90 or a bug in the lx200driver?

IIRC, this was working a few years ago when I tested it. Can you run the same test again but turn debug log on in the driver (Options tab, include all checkboxes in logging)? Then attach the debug log here.

I've just packed up for the night but I'll have a look tomorrow.

I did check manually via a minicom connection to the LX90 though and it only output a "#" when the scope had completed a slew or was otherwise idle/tracking. Any time I did a goto it would output some unprintable character to the terminal with each ":d#" query and then "#" would be returned once the mount had finished the slew.

When I looked at the debug log earlier, it would show the slew complete line (can't remember the exact phrase atm) almost as soon as it started the slew. Doing a goto from East to West, it was pretty clear the scope was still in motion.

FWIW, the save crash no longer occurs in XFCE with the latest git version. Although I encountered a new issue (made a separate post for that).

Edit: Just checked the Serial Telescope Protocol info from 2007 and it says

(note it's actually : and D but keeps getting replaced by smilies )

I assumed at first by null it meant a null terminated and in this case empty string, however the command above mentions

So it looks like "#" is used as the terminator so a string that contains "#" as character 0 would be a null string and a null string signifies slew complete. The bar, (not sure which character that was, it was unprintable in my terminal) represents a slew in motion. That would tie up with what I've seen over minicom and with the switched return values.

So anytime you issue :d# you get only one character back, i.e. the bar? Then when slew is complete and you send in that command, you get in '#' only? If this is indeed a bug, I'm utterly surprised no one reported it during all these years especially since it is very obvious kind of bug!

EDIT: It looks like that isSlewComplete function blocks for 5 seconds (LX200_TIMEOUT) until it encounters a '#' then returns timeout error. Can you please that it indeed blocks? Can you also check that if the mount already finished slewing by a second or two, and then you issue :d# then you also get back "#" ?

Yes, well I get the "bar" character, I don't recall if it also had a "#" after it. When the scope stops slewing though, I get back just a single "#".

I'm not sure how noticeable it may actually be. I've used ekos for a while and never noticed this until doing the polar alignment where it took a 2nd exposure straight after a slew and had star trails in it. That led me to looking at the debug log for indi and noticing that even on a large goto where it takes several seconds to slew, the log indicated slew complete when the scope had only just started moving.

When I was just using kstars to do a goto, I relied on the telescope cursor stopping and finally snapping into place to know the slew was complete.

I'll check this tomorrow for you. If I'm reading that code correctly though, as long as there's activity on the file descriptor, it'll keep looping forever until it receives a stop character "#" or there's no activity on the fd during any single loop iteration for 5 seconds. If that's the case, the timeout might never fire if the LX90 replies promptly and it terminates the single "bar" character (or multiple "bar" characters for lx200) with a "#" (I don't remember if it did or not, I'll check tomorrow).

I'm writing :d# to avoid smiley processing, it should be an upper case D.

I added a bit more logging in to see exactly what the data[] is that's returned.

During a slew it returns 0x7f 0x23 (and then 6 more bytes of garbage. char data[8] = {0}; avoids that). That corresponds to DEL and then #

After a slew it returns 0x23 only which is #.

I did a bit of searching and found this thread it confirms that the LX90 returns a single 0x7f and then # whilst slewing and just a # otherwise. The LX200 will return, according to that thread anyway, a series of 0x7f's and a # whilst slewing.

NOTE: The debug log does a print of data using %s, so when it tries to log the 0x7f 0x23 + garbage it display a hash then garbage, the 0x7f is "lost" as it's not printable.

Regarding the timeout, the select in tty_timeout receives activity on the fd before the 5 second timeout expires so it returns TTY_OK. I'd have to add some timing code in to see exactly how long it takes to get a reply, but whether it's blocking for just a tiny fraction of time or not, it's receiving data correctly and returning.

Issuing :d# whilst slewing gives a "bar" and a "#". Once slewing has stopped, :d# returns only a #. Doesn't matter how long I leave it, I'll get a single # back as long as the scope is just idle/tracking and not actively performing a goto.

Thanks for the clarifications, I pushed the changes to GIT.