×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Canon 60D, ASI 120MM Download, CEM60 Slew Issues

  • Posts: 5
  • Thank you received: 0
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 172.16.0.6
Exportable USB devices
======================
 - 172.16.0.6
      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`
CONFIG_USBIP_CORE=m
CONFIG_USBIP_VHCI_HCD=m
CONFIG_USBIP_HOST=m
# CONFIG_USBIP_DEBUG is not set
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 172.16.0.6 -b 1-1.3
timtrice@timtrice-300E4C-300E5C-300E7C:~$ sudo /usr/lib/linux-tools/4.4.0-28-generic/usbip attach -r 172.16.0.6 -b 1-1.5
timtrice@timtrice-300E4C-300E5C-300E7C:~$

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).
7 years 8 months ago #9213

Please Log in or Create an account to join the conversation.

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.

Yes, logs from the CEM60 is necessary. The "Sync" is KStars telling the mount that it is pointed at the current RA/DEC coordinates. Solving near Polaris is not useful, never solve/sync near the poles. I'm not sure how CEM60 exactly deals with SYNC (i.e. whether it modifies its internal model or does something else). 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.

Regarding astrometry and canon, perhaps Rob has more experience in this matter as I don't use DSLR for imaging. I'll check the crash, it was reported before and will try to reproduce it.
7 years 8 months ago #9215

Please Log in or Create an account to join the conversation.

  • Posts: 5
  • Thank you received: 0

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...

I just ran this sequence under the same conditions as last night where everything was on the RPI and I was connected via Ekos.

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.

I will try to recreate what happened and provide the log.

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.
Last edit: 7 years 8 months ago by Tim Trice.
7 years 8 months ago #9216

Please Log in or Create an account to join the conversation.

Time to create page: 0.508 seconds