If you find errors or have suggestions for this guide, please let me know.  I am user u2pilotjt in the INDI forums. 

PURPOSE: Provide a relatively detailed, simple set of instructions for configuring a Pi3 for the purposes of controlling an astronomical telescope and imaging system with the use of INDI/KStars software.

What is needed (this is NOT a headless install):

  • Pi3 computer
  • Computer monitor with HDMI input and HDMI cable
  • computer keyboard and mouse (USB)
  • Ethernet cable (preferred, but WiFi will work) and internet access
  • Micro SD card (16Gb minimum, 32Gb or larger preferred)
  • Separate Windows PC or laptop capable of reading/writing to a micro SD card or SD card adapter for the micro SD
  • A powered USB hub.  The USB ports on the Pi3 will likely not provide enough power for the items you have that require USB power. In my case, the SSAG needs power for sure.  I have a 4-port powered USB 3.0 hub plugged into the Pi3 and it works fine.  There are a lot of posts about setting static port addresses for the USB ports but I have not found that necessary so far with this setup.

AUTHOR'S COMMENTS: The following are the steps I documented over the course of more than a month of trial and error as well as long hours spend on the INDI forums and elsewhere in the process of configuring my Pi3 to use with my Orion ATLAS (controlled via EQMod) , Canon 6D and Star Shoot Autoguider (SSAG) imaging setup.  I want to thank INDI forum member “rlancaste” for providing me with the starting point via his personal notes.  I also have to say that Jasem Mutlaq was invaluable in getting this together and goes out of his way to help.  My primary reason for writing this guide is the hope that I might (in my small way) pay the community back. I hope you find it useful. There is an assumption that you are reasonably proficient with a computer.  I'm going to speculate that you wouldn't be messing with a Raspberry Pi3 if you weren't.  If you are like me, you are: a very proficient user (both Mac and PC in my case), aren't afraid to tinker and take slight risks with your computer setup, already have an operating, computer-controlled (via my Windows laptop) astronomical imaging setup and are looking to switch to INDI and have never used Ubuntu before.  My goal was to make these instructions as easy to follow as possible with a eye toward the things that I, personally, had to struggle to get done due to my unfamiliarity with both the Ubuntu operating system and the INDI/KStars software.  If you know your way around Linux, you might find these instructions on the simple side.  Lastly, keep in mind that this is how I set the Pi3 up for MY use.  I'll explain why I did what I did along the way but you will certainly want to tailor your installation to your needs and your equipment.

MAKE YOUR SYSTEM SD CARD:   Download Ubuntu MATE for Raspberry. As I’m writing this, you need version 16.04.  I downloaded via torrent, but take your pick.  You will need a way to write to a micro SD card in order to use this on the Pi3.

https://ubuntu-mate.org/download/ to download Ubuntu MATE.  Go to https://help.ubuntu.com/community/Installation/FromImgFiles for help on making a bootable SD card from various operating systems.  I used Windows. Google/download Win32diskimager (links on the pages above) and it works fine.  Unzip the xz file with the Ubuntu image on it, format it via instructions on the web pages above and install the image with Win32diskimager.  Make ABSOLUTELY sure you have the correct drive letter for your SD card selected under the “device” pull downs (use your file browser window to verify).  I found the online instructions easy to follow.

BOOT THE Pi3 AND GET STARTED:   1) Install the micro SD with the MATE image on it into your Pi3 with everything connected to the Pi3 and power it up.  Boot it up and let it install.  It runs pretty much like most new computer startups I've ever been through.  I have to admit, I have had a stall or two during my various tests with these instructions.  Powering down and starting the Pi3 again always resulted in it continuing past the problem.  Seems pretty robust.  2) After the install, you will see a MATE Welcome screen.  On the bottom right corner of that screen is a red box that says “Raspberry Pi Information.  Click on it.  Now, resize the file system using the tool that you see in that section.  It will free up all of the space on your SD card for Ubuntu to use.   I would read the rest of the information on that screen.  I have read some discussions about weather or not to update the Raspberry Pi (rpi-update command) or not, Kernel update issues, etc.  I did do the Kernel update using the terminal window and the commands posted on that page.  It worked at first, but I did another one later (after everything was installed) and it caused INDI to stop recognizing all of my equipment and I was only able to solve the problem myself by re-installing a backup I had.  So, I would consider NOT doing the Kernel update at this time.

Note: If you are completely new to all this, the MATE Terminal is located under the “Applications/System Tools” menu located on the desktop. You’ll need to use it a LOT. You can find it in the pull-downs and simply click and drag a shortcut for it onto the tools bar or the desktop so you have a quick link to it.

Now is a good time to play around with your new mini-computer.  Find things and get familiar with what you can do. It will save you time and aggravation later.  At the end of these instructions I have some information about additional things you might consider doing to open up more space on your SD card, etc. by removing unwanted software.  3) Screen Resolution: Eventually, you may want to have nothing connected to your Pi3 but the Ethernet cable and the powered USB hub (or simply the USB hub and go wireless) and remote to the Pi3.  In that case, you might find it handy to make the screen resolution coming from the Pi3's video card static so it matches your remote computer resolution and fits better.  I've seen some stuff online about “virtual” desktops as well but I haven't played with that.  Do this step later if you want, or even skip it totally.  I found that I was up and running fine here and really didn't need this step until I started remoting into the Pi3.  Even then, it's not “required”, just convenient.  I want the resolution of the video the Pi3 is putting out to match the screen resolution on my laptop so when I remote in, everything fits nicely.  The Pi3 will do fine on it's own, but if you don't do this, your Pi screen will show up funny on your remote computer if things don't match.  However, once this is done – the Pi3s screen is now stretched with a monitor connected directly to it.  So there's a slight trade-off.  So, to do this, go to your intended remote computer and check the screen resolution.  Mine is 1366x768 at 60hz refresh.  

  1. Open Terminal on your Pi3 and type: sudo pluma /boot/config.txt (it will ask you for your admin password).  Assuming you have the same Ubuntu software I have, it will open up the config.txt file for you to edit.  Be careful here!  A bad step can mess things up.  Next, scroll down the file until you find the line with the following text:  #hdmi_force_hotplug=0 (I found it at line number 89 on mine).  Delete the “#” from in front of the text (the hash makes it a comment and not executed) and change the 0 to a 1.  So make it read: hdmi_force_hotplug=1  Continue to find the following lines and delete the “#” from in front and change the value so the lines look like the following:
    1. hdmi_group=2 (I found this at line 195)
    2. hdmi_mode=39 (I found this at line 297).  Now this last one needs a bit more explaining.  See that table of screen resolutions just before this line of code?  The numberson the right side are the group 2 numbers.  Find your desired screen resolution and that's the number you put as the mode.  Mine is 39, which give me 1360x768 at 60Hz.  You will need to put the mode number that works for your setup.  You can always come back and change these back if you want.  Do a reboot so it all takes effect.

GET ON INTERNET/UPDATES AND SOFTWARE:  Now, you will need to be on the network at this point for sure if you aren’t already.  I found Ubuntu MATE to make that pretty easy; about like any other computer I use.  In fact, the Pi3 at this point, was already on the internet and ready to go.  You should see a little Up/Down symbol on the tool bar on the upper right of the screen – that's the internet connections symbol.  You can right click on it and open/edit the internet connections if you want to see what you have going.  If you don’t have an icon you can navigate to “System/Preferences/Internet and Network/Network Connections” from the menu bar on the desktop and add what you need.  I found it to be painless and no steps needed to be taken.  Later will you want to use the network connections menu to edit your Ethernet port for a static IP address to make connecting to a remote computer a consistent process.  You may end up doing the same with the WiFi as well to use as a hotspot.  You are going to be downloading software off the Internet as we move forward.  I read several posts regarding software downloading and installing and Synaptic Package Manager was recommended as a good program to use to, not only download programs for the Pi, but easily and completely remove programs you do not want (I'll talk about that at the end of the document).  You can download it from the MATE Welcome screen's software tool or you can use command line: sudo apt-get install synaptic in Terminal and install it manually (what I did).  Along those same lines is something you may want to add to the Firefox browser (there should be an icon on your desktop menu bar for Firefox).  Open Firefox and click on the top right tools menu and find the add-ons icon.  In the “Extensions” section find an add-on called “DownThemAll” and install it.  It’s a download manager recommended by several web sites I visited for use with Firefox.  Frankly, I got frustrated trying to find that add-on the first time.  If you find yourself running in circles - try to get to a basic, Firefox start page and navigate to the bottom of the page and see if you can't find a link to add-ons and try going from there.  Another download app that seems to be recommended is Gdebi Package Installer.  The latest MATE install I did had this already included, so I don't think you'll need to get it.  I found it in the Applications/System Tools/ menu and it also shows up on Firefox whenever I click to download a .deb file as a download method.  So it's already there as near as I can tell.  If not, you'll need to go find it and download it.

Now that you're connected, you’ll want to do some systems stuff and get the software you need/want.   Open that MATE Terminal window.   To update the Kernel (SEE NOTE FIRST!): sudo rpi-update  NOTE: I did this command after I had been running my Pi3 for a couple weeks.  AFTER I did this, INDI server stopped recognizing all my equipment.  After starting a fresh install and NOT running this command, everything is fine.  I suggest you DON'T do this one. It's your call.

Update the Pi3 software via Terminal (grab a drink, you'll be sitting there a while).  Run the following commands and wait for them to finish doing their thing before proceeding to the next one:

  • sudo apt-get update
  • sudo apt-get upgrade
  • Download the INDI and Kstars programs http://www.indilib.org/download/ubuntu.html for info:
    • sudo apt-add-repository ppa:mutlaqja/ppa
    • sudo apt-get update
    • sudo apt-get install indi-full
    • sudo apt-get install indi-full kstars-bleeding
    • sudo apt-get install kstars-bleeding-dbg indi-dbg
      • Note: The last one is optional but recommended for debugging.
      • Note 2: Later you will want to do updates to both your Ubuntu software and the KStars and INDI software.  To do that, you simply repeat the apt-get update and apt-get upgrade commands like you did earlier.  However, Jasem from INDI, says there can sometimes be problems with the KStars updates and he recommends to do the following to update Kstars: sudo apt-get update && sudo apt-get -y dist-upgrade  I don't see any reason you can't run that command at this point just to be sure (I did). •
    • Install General Star Catalog: sudo apt-get install gsc
    • Install Astrometry. You can use Astrometry online but it’s slow, so you'll probably want this.  http://indilib.org/about/ekos/alignment-module.html is the place to start for information on this step.  Also, the Astrometry web page is at http://astrometry.net if you want to do some research there.
      • Install Astrometry: sudo apt-get install astrometry.net 
      • The index files have to be downloaded and installed. The INDI web site explains how to download the debian packages (Gdebi comes in handy here).  The packages get installed into the Astrometry program once you have them on your computer.  The web page explains how to pick which packages and where those files are located on your Pi3.  One interesting thing I ran into was that after I downloaded a couple of the fits index files and tried to move/copy them from the downloads folder into the Astrometry folder – it wouldn't let me.  I had to right click on the Astrometry folder and select to open it at a administrator before I could copy files into it.
    • If you want to share files between computers on the network, you might want a specific app to help with that.  Caja is already on your Pi3 at this point (found in Applications/System Tools).  I found at this point that I was able to find and connect to other computers on my LAN without installing anything else.  Of course, you will need to make sure your other computers are allowing access, etc.  This instruction isn't going to cover all that.  I understand some folks use Samba for file sharing.
    • If you are going to use PHD2 to guide, see the web site at http://launchpad.net/~pch/+archive/ubuntu/phd2 :
      • sudo apt-add-repository ppa:pch/phd2 
      • sudo apt-get update 
      • sudo apt-get install phd2

SWAP FILE (optional):   Now, I ran into problems almost immediately with my Canon 6D (full size sensor) on Ekos when trying to capture images.  It crashed or locked up.  I did some looking around, did some research, and decided to install a 2Gb swap file on my drive.  A swap file is artificial, extra RAM.  The Pi3 only has 1Gb.  It’s very easy to do and you can read where I got my info from at https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04  If you read the comments on that web page (at the end of the article) you’ll find a guy that wrote a script to make it all super easy, https://github.com/CraftThatBlock/SwapUbuntu is the link.  Read the page, use the terminal commands he provides and it's done in a flash.  Reboot.  It stopped the problems.  I posted this solution on the INDI forums and a couple other users told me they tried it and it helped.  Can't hurt!  I can verify that Ekos is, in fact, causing the Pi to utilize the swap.  Although I've never seen anything close to the full 2Gb being used.

VNC SERVER:  There are lots of options for setting up remote access if you want to run the Pi as a headless server or control the scope remotely.  I am only interested in local control, not anything over the internet from far away.  This is what I did to establish a connection to my laptop.  I have three options: Ethernet cable connected directly between the Pi and Windows PC, wireless across my LAN or wireless via a WiFi hotspot created on the Pi itself.  I installed RealVNC viewer on my laptop to use to VNC into the Pi3. https://www.realvnc.com/docs/raspberry-pi.html#raspberry-pi-legacy  Read through the page.  Of note, I can use RealVNC Viewer on my iPad as well to control the Pi! Cool.  You have numerous software options for setting up a VNC server on your Pi.  I've tried two of them: Vino and RealVNC.  Vino works fine but I'm having trouble getting a WiFi hotspot working with Vino running the server.  RealVNC also works fine and I've been able to get a hotspot to work while using RealVNC with absolutely no trouble.  So, I'll cover what I've learned about both of them here and you can choose for yourself (or choose something completely different!).  

  • VINO:  To install, run sudo apt-get install vino
    • Then run: vino-preferences (to set your preferences for login)
    • Lastly, create a startup program in the startup applications (System/Preferences/Personal/Startup Applications) with the command: /usr/lib/vino/vino-server and it will start when the Pi is started.  That way, Vino will start automatically when you boot the Pi (handy if you are headless – the Pi3, not you!).
    • If you run into login problems from the remote computer due to encryption – run: gsettings set org.gnome.Vino require-encryption false  It will cause Vino to be unencrypted and you'll get nasty messages when you remote into it.  For my application, with the Ethernet connected directly between the laptop and the Pi3 - who cares.
  • REALVNC:  Go to this page ( https://www.realvnc.com/docs/raspberry-pi.html#raspberry-pi-connect ) to find all the information I'm about to provide for installing RealVNC.  I'll explain the Hotspot option later. •
    • To install RealVNC manually (I think this is probably more direct), go to Terminal and run the command:
      • curl -L -oVNC.tar.gz https://www.realvnc.com/download/binary/latest/debian/arm/
      • Then run: tar xvf VNC.tar.gz 
      • After you run the previous command, you will see the file name of a debian package it created. Copy that full file name (it will have a .deb file extension) and insert it into this command in place of the <VNC-Server-package-name> part and leave out the carrots:
        • sudo dpkg -i <VNC-Server-package-name>.deb [<VNC-Viewer-package-name>.deb]  That's it.  It's installed.  
    • Now, you have a couple options here.  You can manually start and stop RealVNC or you can just set it up to start automatically (which is what I've done).  But be sure you don't have Vino running at the same time!  You may need uncheck it from the startup programs if you did that earlier.
      • To start it, run: sudo systemctl start vncserver-x11-serviced.service 
      • To stop it: sudo systemctl stop vncserver-x11-serviced.service (see a pattern?)
      • To have it start automatically when you boot, just put the work “enable” in the previous example in place of start or stop and if you want to turn off automatic startup, use the word “disable”. For once, some programmer did something that was intuitive!

STATIC IP:  This part can get a bit deep if you haven't messed with this before.  I am going to mention Port Forwarding and talk about manual IP assignments.  I'm going to simply tell you what I established as the steps that work for me.  Your mileage may vary and the LAN address information I'm using as my example may not match yours; particularly if you're on a MAC system.  If you plan to remote across your LAN or with a direct Ethernet cable running from the Pi3 into your computer – port forwarding won't be needed.  If you are going to remote into your Pi3 using the WiFi local network in your house, you won't need to port forward.  BUT, if you want to remote into your Pi3 from somewhere else or (in my case) have someone like Jasem remote into your Pi3 from across the world so he can show you what you're doing wrong or help you troubleshoot – you'll need to port forward.  That will need to be done in your router.  I used the web site https://portforward.com to assist me and managed it on my own.  I'll leave it at that.  Don't mess with port forwarding at this point unless you know you'll need it.  Even then, I think you'll want to do the following steps first anyway.  For a static IP assignment on your Pi3, you'll need to start with a little research.  You can Google a million pages that will assist you with setting up a static IP address and I suggest you look around; you'll get more info than I am about to provide.  You will need the following information:  Your current IP address for you Pi3, your router Gateway and your router Subnet Mask.   The direct approach here is to open the Terminal on your Pi3 and type ifconfig and hit Enter.  In that string of information, find the section for your Ethernet connection and have it handy.  Wireless info is also here in case you want it for later.  

  • Right-click on the internet connection symbol on the Pi (or go to System/Preferences/Internet and Network/Network Connections from the menu bar) so you can see your network connections.  You should see (at a minimum) an Ethernet, Wired connection there.  Highlight it and click Edit.
  • First off, it might be handy to write down the Device Mac address you see on the first screen you see.  It's helpful for finding the Pi3 on your router if you go there to set up port forwarding later.  On the other hand, if you are successful at setting up a static IP address, your Pi3 will be easy to find in your router settings since it's IP address will be already assigned.
  • Go to the IPv4 Settings tab.
  • In the Method drop down, select Manual
  • Click on the Add tab on the right to add a manual IP assignment to the connection.
  • Here's where you'll use the information from the ifconfig command you used earlier.  Enter the IP address your Ethernet is currently using (shows as “inet addr” in ifconfig screen), the Netmask (shows up a “Mask”) and the Gateway (you can get this one by going to your windows PC and typing ipconfig in the command prompt window – it's listed as Default Gateway).  Tab down to DNS Server and use the same address as the Default Gateway.  SAVE and exit.  Done.  
  • You might want to pause and try to get onto the internet and make sure this all worked.  Reboot and see if everything is still working OK.



BACKUP!  Now would be a really good time to backup that SD card if everything seems to be working OK!  Cloning the SD card is simple. Just follow these steps:

  1. Get everything set up just the way you want it on your Raspberry Pi, whatever you're using it for.  Then shut down the Pi and remove the SD card.  Insert the SD card into your windows computer.
  2. Start up Win32DiskImager, a program that you probably have from when you first set up your Pi.
  3. In the "Image File" box, enter the path of your soon-to-be image file.  For example, I put mine in C:\Users\James\Desktop\Pi3backup.img
  4. Under the "Device" box, select your SD card.
  5. Click the "Read" button to create the image file from your card
  6. When it's done creating the image file, you can eject your SD card and put it back in your Raspberry Pi. Keep that IMG file in a safe place.
  7. Backup often!!
  8. Now, if anything ever goes wrong with your Pi (and if you fiddle around enough – it will!), you can restore your fully-set-up image using the reverse instructions:
    1. Insert the SD card back into your computer.  Follow the same, exact steps you used when you created the Pi SD card in the first place but install your backup image file instead of the Ubuntu MATE image file.  

Now, if everything at this point has gone well, you should be at a point that you can start testing things.  The steps I have provided to this point are, I think, just about the minimum steps you need to take to run INDI/KStars on your Pi3 and do it remotely (if you want).  At the end of these instructions, I've provided some additional how-to's I used that are equipment specific and some other tweaks you might want to try.

If you have already installed a VNC viewer on your remote computer, you should be able to connect across your local network by entering the [now static] IP address of your Pi3 in the VNC viewer address.  Depending on how you set Vino or RealVNC preferences up, you may need a password, etc. and you may see warnings about unencrypted connection, etc.  But it should work.

  1. Start KStars.  If you haven't found it already, its in the Applications/Education drop down from your Pi3 menu bar.
    1. Note: Now, here's where, if you haven't done it already, you need to go to Indilib.org and start watching tutorial videos, etc. and learn how to use the software.  I'm about to tell you, from my perspective, what you need to do to get up and running at a BASIC level.  If you run into problems from this point forward with INDI or KStars, you need to get onto the INDI forums and start looking for help.  I won't lie; this is the part where I started pulling my hair out.  However, it turned out that many of my problems were caused by me trying to make things more complicated than they need to be.  Others were driver or other errors that Jasem seems to be fixing at a rapid pace as users report them.  Additionally, your equipment is probably not the same as mine.  SO, cross your fingers here, grab a beverage of choice and lets move forward and hope things go well!
    2. KStars Setup:  I'll assume that you have done your homework with INDI and KStars before you move on.  At least watch a few videos so you have the idea.  I'm going to step you thought the most basic initial steps that I did so you can get started.  When you start KStars the first time, it's going want to run you through a setup wizard.  Just follow the steps.  Pick the nearest big town for your location (you can edit this later to be more precise) and download whatever extra data files you want (again, you can get this stuff later as well).  I clicked on several data files at once and it looked like it choked, but give it some time and it will be fine.
      1. Note: Before you proceed, I would have all of your telescope equipment connected to the Pi3 and powered.  In my case, my USB (shoestring astronomy) serial adapter cable for my Atlas EQ-G, the USB to my Canon 6D and the USB to the SSAG are all plugged into the 4-port hub and turned on/powered.
        1. CAMERA NOTE: See the Appendix information at the end for my Canon Camera info before you proceed here if you're using a 6D.  Also, regardless of what camera you're using, the Pi3 will automount the camera when you turn it on.  You will need to “unmount” the camera before INDI can connect to it.  You can do that manually (if I recall you just right click on the camera icon on the desktop and unmount it).  The appendix info tells you how to configure the Pi so that it does not automount the camera (if that's what you want).
    3. Find the Ekos icon on the KStars tool bar, find Ekos in the tools drop-drop down, or simply type Cntrl+K and the Ekos-KStars control panel will open.
    4. Create your Profile and select the appropriate equipment.  In my case its:
      1. Mode: Local
      2. Mount: EQMod Mount
      3. CCD: Canon DSLR
      4. Guider: QHY CCD (Now this might seem funny since I'm using the SSAG. But the QHY CCD driver runs the SSAG since they are, apparently, the same hardware more or less).
      5. Save
      6. Hold your breath and press, Start INDI.  In the INDI Control Panel that pops up, you should see a tab for each piece of equipment you have connected.  You can connect to each from here or you can go back to the Ekos control panel and press the Connect button and connect all at once (that's what I'm doing).  Now, if you hit Connect and everything connects with no warnings....CONGRATS!  You are where it took me over a month to get to (probably because I'm not smart). GOOD LUCK!


Now that you're all connected, here are some of the things you may want to do if you're using the same equipment as me.  If not, maybe this information will carry over to what you're using.


  1. For imaging, put the camera in Bulb mode. If you're in manual, it will just snap images at whatever shutter speed you have set on the camera.
  2. The Camera will automount to the desktop if you don't turn automount off.  You can leave it on if you like but you will be required to unmount the camera before starting INDI each time.  To do that:
    1. Go to Applications/SystemTools/dconfEditor
    2. drill down to org/gnome/desktop/media-handling
      1. uncheck: automount-open and automount buttons
  3. Go to the Canon DSLR tab in the INDI Control Panel that opened when you started INDI.  You will see a bunch of other settings tabs for the camera, starting with Main Control.  I'll walk you through what I know. 1.
    1. In Main Control, you should see a little green light next to connection if you have connected.
    2. Don't touch anything else on this page....except.....if you want to use Mirror Lockup when you are imaging, you will need to come to this tab and go to the Mirror Lockup setting at the bottom and set the delay time between lockup and shutter release on the right side there and press Set.  This setting can get you a bit confused if you have it set when you don't need/want it.  You also MUST be sure you have mirror lockup enabled in the camera menu to use this setting.
    3. Don't touch the Options tab for now.
    4. Image Settings. You can set up some default settings here.  I have set the ISO I always like to use and the Capture Format is set to RAW; the rest I left alone.  At the bottom of that list the transformation format setting - default is FITS.  If you select Native, Ekos will leave the images as .cr2 files when it saves after taking a picture.  You will find that if you let Ekos transform the photos to FITS, it will take a while (currently about 30s with my setup).  Leaving them in Native takes less time (about 5s).  Play with it and see.  Ekos also tended to lock up during this process before I created the swap file; after that it tended to work better.
    5. As for the rest of the settings tabs across the top – I haven't played with any of them and left them alone.  The Image Info tab will self-populate with information the first time you take a photo.
    6. Lastly, here's a suggestion from the forums to help speed the image issue along.  In KStars, go to Settings/Configure KStars and then down to the Advanced tab.  Uncheck the 3DCube and Auto-Debayer options.  I'm told that will help (and it appears to work in my case).


PHD2:  The following is a set of instructions on how to install and use PHD2 on a Raspberry Pi3 using INDI/Ekos (KStars).  In the example, the EQMod driver is used for Mount control and a Star Shoot Auto Guider (SSAG) is the example guide CCD.  Obviously, you will need to substitute your own gear in the setups.  I also assume in these instructions that you already have KStars installed and have already figured out how to start INDI server and connect your gear as well as open and use Ekos.  And you already have a working knowledge of PHD2.  This is simply instructions for making PHD2 work within the Guider Module of Ekos.

First, you will need to install PHD2 onto your Pi3.  In my case, my OS is Ubuntu MATE 16.04, which is recommended by the INDI web site and forums as the most stable for this application.  The web site https://launchpad.net/~pch/+archive/ubuntu/phd2 is a good place to start reading.  It contains the terminal commands to download/install PHD2 on your Pi.  If you don’t know how to use PHD2, you’ll want to visit the PHD Open Guiding web site and get the instructions.  Once installed, you can use it with Ekos.  

Here’s what to do to make it work.  Please note – the default settings along the way are best left as-is.  Messing with them is what got me in trouble when I first tried using it.

  1. Start PHD2 in Terminal by simply typing PHD2 and pressing Enter.  Do not connect anything at this point, simply get it open so you know it’s working.  
  2. Start KStars, then INDI/Ekos and get the INDI server running and everything connected.  At this point I would open the Guider Module in Ekos and check to make sure you have a working connection to your guide camera.
  3. Now go back to PHD2 to connect/configure a camera and mount.  Click on the USB icon on the bottom left of the PHD screen.  Select INDI Mount and INDI Camera as your equipment.  Name the profile what you want, I named it “INDI”.
  4. Now, confirm the camera and mount are set up properly within PHD2.  Click on the setup icons next to the connect buttons. With INDI server already running and everything connected in Ekos, you should be able select your CCD guide camera in the dropdown for the camera driver and your mount type in the dropdown for your mount driver.  In my case with an SSAG camera and EQMod mount, I select QHY CCD for my camera and EQMod Mount for my mount driver.  Don’t touch anything here.  Of course, you should see your equipment in place of mine in the screens.  Close these screens and hit “Connect All” on the PHD2 connect equipment screen.  

Now go into the Ekos Guider Module and click on the Options button there near the middle.  In the Options window select PHD2 for the guiding option and don't change anything else.  Notice that the port in the Options window is 4400.  You may have noticed the port listed iN PHD2 was 7642 – that’s OK!  They are the right numbers, do not be tempted to change them.  At this point hit “OK”, close the options window you should be good.  Notice, if you’ve used PHD before, you might be tempted to go back to the PHD control panel and start looping the image like you normally do when it’s stand-alone.  Don’t do that.  Ekos will start PHD2 when you click “Guide” in the guider module.  Of course, you DO need to go into PHD2 and configure the guiding options the way you want.  Good luck.

Notes: 1) Start Ekos first so PHD2 sees the drivers.  2) Leave everything at the defaults.  3) Let Ekos start PHD2 imaging, calibration, etc.  Don't do it in the PHD2 panel.


OVERCLOCKING:  Don't take my word for any of this.  All I know is what I've found on Google.  The Pi3 can be overclocked.  The settings are right there in the same config.txt file you may have edited earlier to set your monitor/screen resolution.  I can tell you this....I'm overclocking my Pi3 right now with moderate settings and it's stable and works fine.  I “believe” I've seen a performance gain in Ekos during image capture. I think it chopped a good 15 seconds off the transformation time when capturing in FITS.  I have no scientific data to back that up – just my observations.  Rather than me throwing numbers at you, I suggest you Google the subject and make your own decision here.  Here's what I'm using right now.  I did have issues with some settings and some settings have worked with one SD card and not another.  So if you play with this, be prepared to have potential issues.  If you lock your Pi up so it won't start due to bad overclock settings - put your SD card in another computer and edit the overclock commands out of the config.txt file on that computer and then you'll be able to start the Pi again.  Again, do this at your own risk and research it first!

  • arm_freq=1300
  • gpu_freq=500
  • core_freq=500
  • sdram_freq=580
  • over_voltage=4
  • Over_voltage_sdram=5
  • sdram_schmoo=0x02000020
  • dtparam=sd_overclock=100
  • disable_splash=1
  • disable_overscan=1

MAKING DISK SPACE:  If you've explored your new MATE operating system, you probably saw a bunch of programs and some games, etc. on there that you don't want.  Given that I set my Pi3 up exclusively for telescope operations, I needed nothing else on there – so I went at it with a big ax.  The Synaptic Package Manager that I suggested installing earlier comes in real handy here.  If you open it, you can search for programs and it will delete the entire package for you.  What I did was go through the menu of apps and look for stuff I know I won't use the Pi3 to do and deleted it.  You'll get the idea if you use it.  One trick I learned was to find the “-common” file associated with the program and select it for removal and it usually finds every other file in the system that is associated with it and marks it for removal as well.  I opened up hundreds of Mb of space on the card doing this; making room for all of those Astrometry index files.  As a side note: I'm seeing about 24Mb of free space on my 32Gb SD card with a bunch of Astrometry index files installed.  That may give you an idea of space needed/available.  You can delete index files that Astrometry isn't using; there's instructions on the internet for doing that if you Google it.  I can see running out of that space pretty quick with my Canon 6D taking a bunch of images.  SO....I'm now running a 64Gb, 90Mb/s whopper on my Pi3.  With the swap file and overclocking, it's a tad quicker than my previous card and I've got room to spare!

CONNECTING REMOTELY TO THE PI3:  OK, so if you've set your static IP address and installed Vino or RealVNC Server (or a substitute) on your Pi3 and installed some kind of VNC viewer onto your intended remote computer, you're set to connect.  I would first try connecting with your Pi3 connected to your local LAN.  Open your VNC viewer and type in the static IP address you set for your Ethernet connection on you Pi3.  You should get connected.  If that works, take the Ethernet cable from the Pi3, disconnect it from your LAN and plug it into the Ethernet port of the computer you want to use as your remote (you might have to disconnect the Ethernet cable from your computer to do this).  You should be able to VNC connect to your Pi3 using the exact same IP address you just used to connect through the LAN since the Pi3 IP address is static.  If this works, you now have the ability to start your Pi3 without a monitor, keyboard or mouse connected to it (headless).  You just boot the Pi3 and the VNC into it with your remote computer and do what you need to do from there.  Of course, it's nice to have the option of starting your Pi3 with a monitor and stuff connected when you have some serious business to attend to on the Pi.  

HOT SPOT:  It is possible to create a WiFi hotspot from your Pi3's wireless and connect to it via WiFi and do away with the Ethernet cable completely.  Again, I have to thank rlancaste (from the INDI forums) for the information that got me to a successful conclusion here.  The key for me was using RealVNC instead of Vino.  I tried everything I'm about to tell you with Vino and it wouldn't work.  I'm still not sure why RealVNC worked for me and Vino didn't but I suspect it's an encryption issue of some sort.  I found this to be pretty straight forward at the time I did it.  First thing you need to do is actually create a WiFi Hotspot on your Pi. To do that:

  1. Navigate your way to the Network Connections window (System/Preferences/Internet and Network/Network Connections) to create a new WiFi Hospot.
  2. Click Add to create a new connection
  3. Select WiFi as the type of connection from the drop-down
  4. Now: ◦
    1. Give your connection a name at the top (mine is AstroPi)
    2. Use that exact same name as the SSID
    3. Change Mode to Hotspot
    4. Go to the Wi-Fi Security tab and change it to WPA Personal (if you want a secure connection; recommended) and establish the password you want.
    5. Hit Save, your done here.
  5. Now, you need to be able to start that hotspot when you want it.  On the desktop, right-click and select Create a Launcher.  Name it something like “Start Hotspot” (your choice here) and insert the command nmcli connection up in the command field.  So for me, that command is: nmcli connection up AstroPi.  Hit OK and that's done. Just double click on that launcher to make the WiFi hotspot happen.  On my system, I can tell the hotspot started because the little up/down arrow for my netork connection in the toolbar goes away.  I'll get that back later when I shut the hotspot down.  Now, when you start the hotspot, you can look for that WiFi connection from your remote computer and see the SSID you created (AstroPi in my case) and connect to it with the password you specified just like any other WiFi connection.  Click properties on that connection and check out the IP address your remote computer was given by the hotspot.  That will give you a clue to the IP address you need to use as the address in VNC viewer in order to connect to the Pi.  In my case, the IP address assigned to my laptop by the Pi3 is So that means the Pi3's address is (just replace the last number with 1) and that's what I put in the VNC viewer to connect.  Works great.
  6. Now, rlancaste also suggested a couple other launchers for the desktop that you can do here, if you want.  Some systems are having problems with the nm-applet and it needs to be restarted.  So a launcher with nm-applet as the command line can be created to do that.  My up/down arrow on the desktop that indicates a network connection sometime just disappears.  This launcher will bring it back.  This isn't a critical thing.  I generally don't care if the network arrows are there or not under normal circumstances.  The second launcher will turn off the hotspot and go back to normal network operations.  That launcher needs the command line: gksu systemctl restart NetworkManager.service and I used the name that was suggested to me of “Restart Network Manager Service” as the name of the launcher.  So, if you do all that you will have a launcher to turn the hotspot on, another to turn it off and go back to normal and a third to restart the nm-applet when it decides to stop working.  I suppose you could create a startup command in your startup programs to automatically start the hotspot when the Pi is turned on if you are going to run it headless and via a hotspot.  I'm connecting with an Ethernet cable directly to start with and I can activate the hotspot if I like from there.

The following is a video tutorial on how to get started with INDI & Ekos under Windows 10. To use INDI under Windows, download Ekos VM and use Ekos to manage your devices. When using Raspberry PI to connect to your devices, simply set the Raspberry PIs IP address in Ekos and you can connect to it and control it transparently.

INDI Web Manager is a simple Web Application to manage INDI server. It supports multiple driver profiles along with optional custom remote drivers. It can be used to start INDI server locally, and also to connect or chain to remote INDI servers. It is especially useful to install on remote Raspberry PIs installations where you can easily startup INDI server without needing to SSH into the device. Furthermore, the Web Manager provides a RESTful API where you can issue simple calls to start and stop INDI services over the network.

For more information on the API, check the project's GitHub page.

  • Download

Download the INDI Web Manager zip file. Extract the zip file:

unzip indiwebmanager-master.zip
cd indiwebmanager-master

Install pre-requisites:

sudo apt-get -y install python-requests python-psutil python-bottle

Copy the servermanager folder to your $(HOME) (e.g. on Raspberry PI it is /home/pi) or any folder where the user has read and write access. The following command copies the servermanager directory to your home directory.

cp -rf servermanager ~/

You can perform all these operations in any file manager (e.g. Dolphin) as well. You can use the console commands where you do not have a graphical access on the target system.

  • Usage

The INDI Web Manager can run as a standalone server. It can be started manually by invoking python:

cd servermanager
python drivermanager.py

Then using your favorite web browser, go to http://localhost:8624 if the INDI Web Manager is running locally. If the INDI Web Manager is installed on a remote system, simply replace localhost with the host name or IP address of the remote system.

  • Auto Start

To enable the INDI Web Manager to automatically start after a system reboot, a systemd service file is provided for your convenience:

Description=INDI Web Manager

ExecStart=/usr/bin/python /home/pi/servermanager/drivermanager.py
ExecStart=/usr/bin/python /home/pi/servermanager/autostart.py


The above service files assumes you copied the servermanager directory to /home/pi, so change it to where ever you installed the directory on your target system. The user is also specified as pi and must be changed to your username.

Copy the indiwebmanager.service file to /lib/systemd/system:

sudo cp indiwebmanager.service /lib/systemd/system/
sudo chmod 644 /lib/systemd/system/indiwebmanager.service

Now configure systemd to load the service file during boot

sudo systemctl daemon-reload
sudo systemctl enable indiwebmanager.service

Finally, reboot the system for your changes to take effect:

sudo reboot

After startup, check the status of the INDI Web Manager service:

sudo systemctl status indiwebmanager.service

If all appears OK, you can start using the Web Application using any browser.

  • Profiles

The Web Application provides a default profile to run simulator drivers. To use a new profile, add the profile name and then click the plus icon. Next, select which drivers to run under this particular profile. After selecting the drivers, click the Save icon to save all your changes. If you check Auto Start, then the profile drivers will be started on system boot up.

INDI is by design a distributed control protocol where multiple INDI servers may span different hosts and on different network topologies. This enables an N to N communication between front end clients and backend servers. When operating a local or remote observatory, it might be necessary to run INDI servers on multiple devices. If you are using Ekos as your client of choice, then it is necessary that all remote INDI servers are chained, that is, they should all be linked together as to appear at one INDI server to Ekos.

Thankfully, INDI servers support chaining among themselves. In this tutorial, we shall explore a hypothetical scenario where you have two Raspberry PIs over the local network (WiFi or LAN) and each Pi is connected to several devices.

First and foremost, you have to decide which device should act as the primary INDI server host. If you have two identical devices, then it shouldn't matter which is which, any device can be the primary. As a general rule of the thumb, the more powerful device with faster and reliable connection should act as the primary device. In our example, Raspberry Pi #1 is the primary device. For each device, it is recommended to use an alias for the IP address. Raspberry Pi #1 alias is starpi and has an IP address of On the other hand, Raspberry Pi #2 alias is astropi with an IP address of

We have the following devices connected to each Pi:

  1. starpi (
    • Joystick
    • EQMod Mount
    • Canon DSLR
  2. astropi (
    • Robo Focus
    • ZWO CCD

In order to refer to the devices by their alias, we need to add them to the /etc/hosts file on the PC/Device running Ekos, and also on the Raspberry PIs. So on each device, you can run the following commands:

sudo echo "   starpi"  >> /etc/hosts
sudo echo "   astropi" >> /etc/hosts

Now when you run ping starpi, you should see it is pinging

Since astropi is the secondary device, we start the INDI server there first because we will connect to it later from the primary device:
indiserver -m 100 -vv indi_robo_focus indi_asi_ccd

It is important to note that in order to chain this INDI server to the primary server that we shall create later on, we need to know the device names. For most devices, the device name is static and does not change. While other devices get their name at run-time according to the actual model detected. For Robo Focus, the device name is always static RoboFocus, but for ZWO CCD, the actual device name depends on the model of the camera you have. The device name is also the same name you get in the INDI control panel. If you start indiserver with with -vv option above, it will display more verbose information including the device names. You only need to use the -vv argument if you don't know the exact device name.

2016-02-23T13:07:42: startup: indiserver -m 100 -vv indi_robo_focus indi_asi_ccd 
2016-02-23T13:07:42: Driver indi_robo_focus: pid=10202 rfd=3 wfd=6 efd=7
2016-02-23T13:07:42: Driver indi_asi_ccd: pid=10203 rfd=4 wfd=9 efd=10
2016-02-23T13:07:42: listening to port 7624 on fd 5
2016-02-23T13:07:42: Driver indi_asi_ccd: sending 
2016-02-23T13:07:42: Driver indi_robo_focus: sending 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: snooping on Telescope Simulator.EQUATORIAL_EOD_COORD
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: snooping on Telescope Simulator.TELESCOPE_INFO
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: snooping on CCD Simulator.FILTER_SLOT
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: snooping on CCD Simulator.FILTER_NAME
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 

Here we can see that the actual device name is ZWO CCD ASI120MC. Now, we login to starpi and start INDI server:

indiserver -m 100 -v indi_joystick indi_eqmod_telescope indi_gphoto_ccd "RoboFocus"@astropi "ZWO CCD ASI120MC"@astropi

This will start INDI server on starpi and chain it to the INDI server running over at astropi.

In Ekos Setup, select Remote mode and then select all your devices as illustrated below.

Next, open Ekos options and change the host to starpi and port to 7624. Now you're good to go! Simple click Start INDI and it will connect to to the remove devices. You should see all the devices popping up in INDI control panel.

Next simply click Connect in Ekos Setup and all your device should come online so you can start using Ekos right away!

You can accomplish remote startup and chaining of the INDI devices in a simple Python script. You run the the script on the same machine running Ekos, and it can SSH into the remote devices and start the corresponding INDI servers. For the script to work, you must be able to login to the Raspberry PIs using PKI authentication (SSH Keys) and not password.

Numerous astronomical devices still communicate with the venerable RS232 standard despite the wide adoption of Universal Serial Bus (USB) protocol. Since modern PCs/SBCs no longer support connecting to RS232 via the traditional DB9/DB25 connectors, USB serial adapters are often used to pass the RS232 data to the host via a USB stream.

On Linux, USB serial devices are created incrementally on the /dev file system and often appear as /dev/ttyUSB0, /dev/ttyUSB1, ...etc.

This device port is needed in many INDI drivers in order to communicate with the device, but the problem is that the device designations are not persistent. If you reboot the device or unplug/replug the USB device, you are very likely to end up with a different device designation under /dev. When you attempt to connect to the device again, you'd be surprised as why INDI is having trouble connecting to it, only to realize that the port mapping changes. This situation is indeed quite frustrating and completely unacceptable especially when operating remote automated observatories. Wouldn't be nice if we can have /dev/mount and /dev/focuser all the time?!

Linux offers a method to make persistent port mappings across reboots and disconnections! It's called udev and it is a device manager for the Linux kernel. When you connect your serial device, udev creates a device node in /dev. To overwrite its behavior, we need to write a udev rules file to have persistent names for our devices.

All USB devices have a Vendor ID and a Product ID. Running lsusb in Ikarus Observatory's Odroid, I get the following:

Bus 006 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. 
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 054: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 053: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 075: ID 1278:0507 Starlight Xpress Lodestar autoguider
Bus 003 Device 052: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 057: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 003 Device 060: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 003 Device 056: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 059: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 003 Device 055: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 051: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 050: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 049: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Most serial devices seem to use the FTDI FT232 as seen above which has a Vendor ID (VID) of 0x0403 and Product ID (PID) of 0x6001, so we can't distinguish among the devices alone by the VIDs and PIDs. How can we tell which is which? Fortunately, to uniquely differentiate USB devices, we can use Serial identifier. Of course, if you have multiple Serial-To-USB adapters that have different VID:PID combinations, then there is no need for a Serial identifier, it is only needed if you have multiple adapters from the same manufacturer which is often the case.

To find out the serial ID, run the following command against the device node. For example, the find the serial id of the device connected to /dev/ttyUSB0:

udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1

In my case, I got the following:


To get all the serial numbers, it is recommended to connect each device by itself i.e. no other device are connected, and then run the above command to obtain the serial number, along with the VID:PID. In Ikarus Observatory, the following devices are connected via USB Serial connectors:

  • EQMod Mount
  • MoonLite Focuser
  • Flip-Flat
  • Vantage Vue Weather Console

Vantage Vue INDI driver already installs a udev rules file that creates a symlink at /dev/vantage. For the rest of the devices, I created a file in /lib/udev/rules.d/99-observatory.rules:

# MoonLite Focuser                                                                                                                                                                                                                          
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A501T0P9", MODE="0666", SYMLINK+="focuser"                                                                                                            
# Flip Flat                                                                                                                                                                                                                                 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A8YNLO6X", MODE="0666", SYMLINK+="remotecap"                                                                                                          
# EQMod Mount                                                                                                                                                                                                                               
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTG8H6RX", MODE="0666", SYMLINK+="mount"

Therefore, when the mount is plugged, the device symlink /dev/mount is created and remains consistent across reboots. After saving the rules file, it is recommended to reboot the device/PC so that the udev rules take effect.

Ekos powerful Capture Module recently added support to automated capture of flat field frames. Using the capture sequence queue, it was always possible to capture flat images with manually-specified exposure times, and now completely automated flats are supported!

Once you select a flat frame from the Type drop-down list, click the Calibration Options button to open the flat calibration options dialog. In the dialog, you can set the flat field frame Source and Duration as following:

  • Manual: The flat field light source is set and turn on/off manually by the user.
  • Dust Cap: Use a dust cap device (e.g. FlipFlat) as the flat field light source. Ekos will park (close) the dust cap if it was not already parked when capturing the flat frames.
  • Wall: Before capturing flats, slew the telescope to a specific Azimuth/Altitude position on the wall where an evenly-illuminated panel is installed. If the light panel is controllable and is connected as an INDI device, Ekos will turn on/off the panel light as needed.
  • Dawn/Dusk: Future options reserved for dawn/dusk flats but might not be implemented due to the unreliability and limited time of dawn/dusk flats.

After selecting the flat source, you need to specify the flat desired duration:

  • Manual: No changes shall be made to the flat exposure duration. The user specified duration in the capture module shall be used.
  • ADU Percentage: Analog to Digital Units (ADU) are the dynamic range of pixels values in your CCD. For a 16bit CCD, the maximum possible ADU is 65535. The actual maximum ADU depends on your CCD. ADU count is proportional to the electrons excited by incident photons and CCD gain. Set the desired ADU % and Ekos shall adjust capture time until target ADU % is reached. When using this setting, it is recommended to set the exposure time to 1 second and Ekos will adjust it accordingly.

Optionally, you can select to park the mount and/or the dome if required before the flat frames are captured. Please note that this will suspend any ongoing guiding process. Furthermore, once parked you cannot capture any light frames, so capture the flat frames either at the beginning of the session or at the end.

Tip: Using a controllable flat field light source (e.g. Flat-Man) can save a lot of time since light intensity can be adjusted per filter thereby reducing exposure times for narrowband filters considerably.

Hubble-like super wide field images of galaxies and nebulae are truly awe inspiring, and while it takes great skills to obtain such images and process them; many notable names in the field of astrophotography employ gear that is not vastly different from yours or mine. I emphasize vastly because some do indeed have impressive equipment and dedicated observatories worth tens of the thousands of dollars. Nevertheless, many amateurs can obtain stellar wide-field images by combining smaller images into a single grand mosaic.

We are often limited by our camera+telescope Field of View (FOV). By increasing FOV by means of a focal reducer or a shorter tube, we gain a larger sky coverage at the expense of spatial resolution. At the same time, many attractive wide-field targets span multiple FOVs across the sky. Without any changes to your astrophotography gear, it is possible to create a super mosaic image stitched together from several smaller images. There are two major steps to accomplish a super mosaic image:

  1. Capture multiple images spanning the target with some overlap between images. The overlap is necessary to enable the processing software from aligning and joining the sub-images.
  2. Process the images and stitch them into a super mosaic image.

The 2nd step is handled by image processing applications such as PixInsight, among others, and will not be the topic of discussion here. The first step can be accomplished in Ekos Scheduler where it creates a mosaic suitable for your equipment and in accordance to the desired field of view. Not only Ekos creates the mosaic panels for your target, but it also constructs the corresponding observatory jobs required to capture all the images. This greatly facilitates the logistics of capturing many images with different filters and calibration frames across a wide area of the sky.

Before starting the Mosaic Job Creator in Ekos Scheduler, you need to select a target and a sequence file. The Sequence File contains all the information necessary to capture an image including exposure time, filters, temperature setting...etc. Start the Mosaic Job Creator by clicking on the icon next to the Find button in Ekos Module.

On first use, you need to enter your equipment settings including your telescope focal length in addition to camera's width, height, and pixel dimensions. Finally, you need to enter the rotation of the camera with respect to north, or the position angle. If you don't know this value, start Ekos and slew to to your desired target then use the Align module to solve the image and obtain the position angle.

Next, enter the desired number of horizontal and vertical panels (e.g. 2x2, 3x3...etc) and then click Update. The target FOV shall be calculated given the number of panels and your camera's FOV and the mosaic overlap shall be displayed. By default, the percentage of the overlap among images is 5%, but you can change this value to your desired value. You can also move the complete mosaic structure around to fine tune the position of the mosaic panels. When satisfied, click Create Jobs and Ekos shall create an observation job and a corresponding customized sequence file for each panel. All the jobs shall be saved to an Ekos Scheduler List (.esl) file that you can load on any suitable observing night and it will pick off where you left. Before starting the Mosaic Job Creator, check that all the observation job conditions, constraints, and startup/shutdown procedures are as per your requirements since these settings shall be copied to all the jobs generated by the Mosaic tool.

With Ekos Scheduler, multi-night imaging is greatly facilitated and creating super mosaics has never been so easy. Get started with Ekos now and don't forget to post your results to INDI forums!

When operating a remote observatory, complete control of the devices rest with the remote INDI servers and drivers. In case of a communication loss, the observatory should be capable of performing a graceful shutdown until communication is established again by the client.

Since the actual shutdown procedure can be unique to each observatory, the user should be able to configure the exact required shutdown procedure. But for most users, the usual shutdown procedure involves parking the mount followed by parking the dome, if one exists. Using INDI WatchDog driver, the user can secure their remote observatory by setting a heart beat timeout threshold. A heart beat is a signal from the client to the watchdog driver to inform it that communication is OK. The user can configure the heart beat timeout in minutes in the WatchDog driver. If the driver does not receive the signal after the heart beat timeout threshold, it initiates the shutdown procedure. To disable the heart beat check, set it to zero.

The shutdown procedure is currently composed of the following steps in order:

  1. Park Mount: The mount driver specified under Options tab will be commanded to park. After parking is successful, the driver proceeds to the next step, otherwise it aborts the shutdown procedure.
  2. Park Dome: The dome driver specified under Options tab will be commanded to park.
  3. Execute Script: Execute a custom shutdown script as specified in the settings property. The script must be executable and exits successfully for this operation to be considered successful.

To park the mount and dome, the driver needs to act as a client as well in order to issue such commands. You need to specify the indiserver host and port where the dome and mount drivers are running. This is usually localhost at port 7624 which is the default value. The shutdown script can be used to perform any additional shutdown functions (e.g. turn off power, send email...etc). You can use Python INDI Client library to command devices, or INDI's built in scripting tools. All values can be saved in the config file by going to Options and clicking Save under the Configuration property. On subsequent runs, all values shall be loaded automatically on start up.

 Tip: When starting INDI server on a remote PC/Raspberry PI via SSH, make sure to run indiserver in the background so that if you get disconnected, the indiserver is not terminated. This is accomplished by using nohup command. For example: nohup indiserver -v indi_watchdog indi_simulator_ccd indi_simulator_dome indi_simulator_telescope > /dev/null 2>&1 &

 Getting Started

As more Single-Board-Computers such as the Raspberry PI, ODroid, Beaglebone..etc become more powerful with every release, they become closer to replacing the traditional desktop PC for trivial non-graphic intensive tasks. One of the nuisances of astrophotography is the necessity to be in close proximity to your equipment during the typical astrophotography workflow. Your telescope, CCD, focuser..etc are usually connected to a desktop or laptop running your favorite astrophotography software. In addition to freezing temperatures you might encountered in your neck of the wood in winter, it is often far more convenient to operate everything remotely from the comfort of your living room, and it's even better if it's done wirelessly.

Nowadays, the hardware and software technology stacks make this possible thanks to INDI/Ekos and cheap Single board Computers. INDI is the software that talks to your devices and controls them. INDI is a server and does not require a Graphical-User-Interface (GUI) nor a powerful PC, and hence INDI can run on devices such as the Raspberry PI. Ekos is the graphical client used to control the devices exposed by INDI. It offers powerful capabilities to capture, focus, guide, and plate-solve your images. Ekos requires a modern Linux distribution with KDE. Any desktop or laptop that can run Ubuntu/Kubuntu can run Ekos without any issues.

DBUS is a very powerful and versatile inter-process communication system used in Linux and other OSes. DBUS replaced DCOP in KDE4 and has since became the standard for IPC messages in KDE. With KStars (>v.2.3.0), it exposes a new INDI DBUS interface in addition to the existing KStars's DBUS interface giving you a fine control over most of KStars functionality.

In this tutorial, we will learn how to perform basic control of a telescope and CCD using DBUS and Python. We will utilize an external FITS viewer fv, you can install it in Ubuntu:


There’s always point where you have to decide in any expensive undertaking, such as amateur astronomy, where it’s best to apply your hard earned currency. For any given piece of equipment, you have to determine what feature set is required, decide what commercial products, if any, suit your needs and finally, what your best purchase option may be. For me, there’s always been a desire to see if I can build a more cost effective solution first, before I proceed to purchase.

With that in mind, it’s been my goal for some time, to complete my automated and remote solution for my personal astronomical observatory. Not having found a cost effective remote focusing solution on the market, I decided to see about low cost DIY alternatives. During my search and evaluation I turned to the INDI platform for ideas.


3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!