I'm experiencing the issues again. Obviously no rush on this but wanted to give the clear sky a shot and see how it went. This is my first attempt since my last post above.

Log is attached but noted time is after 1:03.

It continued saying it could not find an auto-star. When I would select a star it seemed to attempt to begin calibrating before failing, stating I should increase box size (I did to 128) and/or reduce pulse (I did from 1000 to 750 then 500).


All I've done is set the scheduler. I've enabled Track, Align and Guide. So, after alignment it goes to the guiding process where it just keeps repeating this issue. I've tried changing the box size and hand-picking a star but to no avail.


Solver fails when Solving Method is set to Internal Solver. When I change to Local ASTAP it works but this setting is not saved on restart/reboot.

Guiding also "Failed to select an auto star." and continuously fails. If I disable Auto Star and click a star Auto Star re-enables itselv and the entire process repeats itself. I'm also told to enlarge the Box but it's already at 128.

At one point after alignment is successful, it should stop where guiding takes over. However, both alignment and guiding were running at the same time. I did not have logs enabled for this part and am unable to repeat it.

I just updated to the latest yesterday via apt. Now running KStars 3.5.0. Log file attached.

File Attachment:

File Name: log_01-49-29.txt
File Size: 95 KB

File Attachment:

File Name: log_01-49-29.txt
File Size: 95 KB


knro wrote:

Why are you using USB-IP? I believe it's a lot slower than direct USB. Run INDI server on RPi and connect to the cameras in the RPi.

Jasem, this is the output running 2x5s sequence:
2016-07-09T16:13:34 Received image 2 out of 2.
2016-07-09T16:06:47 Capturing image...
2016-07-09T16:06:47 Received image 1 out of 2.
2016-07-09T16:01:31 Capturing image...

Referencing this forum post last year I wanted to give USBIP a shot to see if it worked (as it seemed to have helped as described). However, it does not - at least, in my instance. So I'm looking to see how I can speed up the download times or at least not have the download of one image delay the capture of another.
knro wrote:
Yes, logs from the CEM60 is necessary.

I will try to recreate what happened and provide the log.
knro wrote:
Since you have programming experience, this would be a good opprotunity to extend the driver to use INDI Alignment Subsystem. There is already a couple of drivers using it (e.g. EQMod, Synscan), so you can implement proper modelling in the driver itself which you can use later on.

My programming background is more working with data but I'll certainly take a look and see if it's something I can contribute.

Thank you for the quick response.


Let me first state I just recently learned about this project and am very eager to help out as much as I can. I have some programming background but not sure if it'd be beneficial (still need to look).

So, yesterday I set up a RPI 3 on Ubuntu Mate. At the moment it runs a Canon 60D, ZWO ASI 120mm and iOptron CEM60 mount.

The two main issues I'm concerned about are download times of images and mount operation.

Regarding download, I've been working on this all morning and do not believe I am making any progress. Last night I ran everything through RPI but today I worked through binding the two USB's for both cameras to my laptop. The download times have not improved.
This is how I open the cameras on the RPI to local laptop:

timtrice@RaspberryPi3:~$ sudo /usr/lib/linux-tools/4.4.0-28-generic/usbip list -l
 - busid 1-1.1 (0424:ec00)
   Standard Microsystems Corp. : SMSC9512/9514 Fast Ethernet Adapter (0424:ec00)

 - busid 1-1.3 (04a9:3215)
   Canon, Inc. : unknown product (04a9:3215)

 - busid 1-1.5 (03c3:120a)
   unknown vendor : unknown product (03c3:120a)

timtrice@RaspberryPi3:~$ sudo modprobe usbip-core
timtrice@RaspberryPi3:~$ sudo modprobe usbip-host
timtrice@RaspberryPi3:~$ sudo /usr/lib/linux-tools/4.4.0-28-generic/usbipd -D
timtrice@RaspberryPi3:~$ sudo /usr/lib/linux-tools/4.4.0-28-generic/usbip --debug bind -b 1-1.3
usbip: debug: usbip.c:141:[run_command] running command: `bind'
usbip: info: bind device on busid 1-1.3: complete
timtrice@RaspberryPi3:~$ sudo /usr/lib/linux-tools/4.4.0-28-generic/usbip --debug bind -b 1-1.5
usbip: debug: usbip.c:141:[run_command] running command: `bind'
usbip: info: bind device on busid 1-1.5: complete

The bind it to my laptop:
timtrice@timtrice-300E4C-300E5C-300E7C:~$ sudo /usr/lib/linux-tools/4.4.0-28-generic/usbip list -r
Exportable USB devices
      1-1.5: unknown vendor : unknown product (03c3:120a)
           : /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5
           : (Defined at Interface level) (00/00/00)

      1-1.3: Canon, Inc. : unknown product (04a9:3215)
           : /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3
           : (Defined at Interface level) (00/00/00)

timtrice@timtrice-300E4C-300E5C-300E7C:~$ grep USBIP /boot/config-`uname -r`
timtrice@timtrice-300E4C-300E5C-300E7C:~$ sudo modprobe vhci-hcd
timtrice@timtrice-300E4C-300E5C-300E7C:~$ sudo /usr/lib/linux-tools/4.4.0-28-generic/usbip attach -r -b 1-1.3
timtrice@timtrice-300E4C-300E5C-300E7C:~$ sudo /usr/lib/linux-tools/4.4.0-28-generic/usbip attach -r -b 1-1.5

With both cameras, previews take quite a bit of time and even sequences take nearly as much time to download as they do to capture. Previews take even longer. This even after attaching the USB to my laptop. I've attached the log for review.

I come from using BackyardEOS which, at most would take maybe a minute to download a capture. Previews were nearly instantaneous. The main difference was that it seems when Ekos is capturing it does not start the next capture until the first one has downloaded whereas BYEOS started the next capture right away. IMO this is a loss of valuable imaging time.

What else can I do to speed this process up?

I've attached the kstars log which was set to verbose for FITS, INDI and Capture though seems pretty small to me.

My issue with the CEM60, I'm not sure if it's INDI or the drivers. I've had similar experience with Sky Tools 3 but I had worked it out when I updated the ASCOM drivers. Unfortunately I do not have logs for this but can generate some tonight.

I did an astrometry solve near Polaris to make sure the program and the scope were synced up together. I selected 'Sync' rather than 'Slew to Target" or 'Nothing'. So once the image was downloaded (this is what tipped me off to the long download times) I selected Mizar and told the scope to slew via the pop up menu. The scope then proceeded to move to near zenith and continued backwards until a piercing grinding noise scared the hell out of me. I immediately shut down power to the mount and manually reset the scope back to zero.

I reattempted alignment except this time I solved on Mizar (slewing the scope via the hand pad) and told kstars to sync (I presume this means the mount is telling the program where it is pointed rather than the program telling the mount where it is pointing). I had also done this on the first attempt. I got the little crosshairs both time in the approximate position so I believed my assumption was correct.

Once solved I sent the scope to Arcturus via kstars and again got the same issue.

So, as I don't have logs I don't expect resolution on this right away. But my questions are:

1. How can I absolutely prevent the mount from doing that again. The hand pad has a setting for meridian flips (I do not give it any leeway). I read in another forum post something about altitude limits but if the program thinks the scope is pointing somewhere else, which it seemed to by sending the mount completely backward, would this even work?

2. What is an ideal working pattern to perform an initial astrometry alignment, send the scope to a second position, solve and align, then send to third, etc.? Did I miss something?

Lastly, occasionally when I disconnect the camera then select Stop INDI from Ekos, it shuts down kstars. It didn't do this when I disconnected the Canon the stopped INDI a few minutes ago but it did when I disconnected the ASI (and repeatedly several times since).


  • Basic Information

  • Gender
  • Birthdate
    06. 07. 2016
  • About me