The induino MeteoStation is a complete weather station with arduino firmware, indilib driver and a webinterface with current status and graphs that range back in time from 3 hours to one month.
The indilib driver is capable of issuing alerts, like daytime, clouded, frezzing and more. Indi clients will react to alerts and can be configured to close your observatory and stop the imaging session in unsafe conditions.
MeteoStation does not have a wind or rain sensor, but can be used in combination with wunderground weather trough Meta weather for an extended weather service. There is also seldom rain without the detection of clouds.

This howto will show you how to setup and build the induino meteostation.
I will use the Adafruit Trinket Pro 5v, but other compatible arduinos could be used.
Keep in mind that the SDA and SDL ports are used for the Ir and pressure sensor. Digital pin 3 is used for the humidity sensor and analog 0 for the ir radiance sensor.
For the Trinket pro we will also use ground, 5v, RX and TX of the FTDI header, as the Trinket does not support serial console over the USB port.

Meteostation can be used as a ‘standalone’ weather station for any none observatory use. This could be a raspberry pi or almost any other linux box running apache with indilib installed locally.


This python module allows you to create sequences and interacting with your devices using python scripting.

A few examples of how to use this module are in the "example" directory.


Update Feb/2018.  Before you read below, I would consider trying the Astroberry Server or AstroPi3 images/scripts that are available in the Devices section of this site.  Those efforts essentially do the legwork I describe below so you don't have to.  If, however, you're the person that wants to see it all go together and do your own tweaks along the way; then this might be for you.  Also, there have been updates to the INDI and EKOS programs since I originally authored this guide that include drivers, etc. that my instructions tell you to install.  Before you install drivers for your gear using this tutorial, I would try the setup with the pre-isntalled drivers that come with INDI and see if it works; you may save yourself some time.  I haven't taken the time as of yet to trim these instructions or update them to account for software and driver updates that have happened since Dec 2016.


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.

This tutorial shows how to install and use the Python pyindi-client on a Rapberry Pi 2 or 3 running an Ubuntu distribution. It has been made using the Ubuntu Classic image for Raspberry Pi and also the Ubuntu MATE for Raspberry Pi. Both are fresh installs and you will find my installation notes at the end of the tutorial (for Ubuntu Classic and for Ubuntu MATE). It supposes you have a configured network. It also supposes you already perform the first boot on the Raspberry Pi (first boot on ubuntu, and on ubuntu mate). Finally there are two versions of python, Python 2 and Python 3. The pyindi-client wrapper works with both versions, and both versions may coexist if you have the two versions of Python installed. As for any Python module, the pyindi-client should be installed for each version of Python you want to use. I will be using Python 3 in this tutorial as this is the default version in Ubuntu 16.04. You may download the tutorial scripts from the repository.

Building a DIY cap for ServoBlaster Cap


To summarize what we are going to go trough here, we are building a servo actuated, INDI and Ekos compatible dust cap. I will go trough the details as I show pictures of my fast tracked prototype. Some of the parts used for prototype is selected on convenience. Be creative and preferably use parts you already have lying around.

So what do we need to do that?

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 how to install indiweb and using the API, check the project's GitHub page.

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!


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!