Frequently asked questions

But feel free to contact us if you have any other question.

First of all… why another standard?

Yes, there are other standards and initiatives for astronomy software development. Some of them well established, accepted by the industry, nevertheless Windows only, locked to .Net technologies and without any clear strategy towards IoT and distributed computing. And another with opposite approach. Easy to port to Unix based systems, fully distributed, but not enough standardised in many aspects, quite inefficient for large amount of data and published under license avoiding real commercial use in many situations and thus wider industry acceptance.

That’s why we begun development of INDIGO framework with the goal to take the best from the both worlds – community driven, open to everybody, portable, distributed, efficient, easy to use for developers and invisible for end-users. Why version 2.0 at the very beginning? It can use legacy INDI wire protocol version 1.7 as a fall down option and thus INDIGO protocol version started on 2.0. And unlike in INDI, INDIGO wire protocol version is coupled with the rest of framework.

What are design requirements and limitations?

This is a current list of requirements taken into consideration:

  1. No GPL code used to allow commercial use under application stores licenses.
  2. ANSI C for portability and to allow simple wrapping into .Net, Java, GO, Objective-C or Swift.
  3. Layered architecture to allow both direct linking of the drivers into applications or distributed use.
  4. Scalability from mobile devices and embedded computers to desktops.
  5. Atomic approach to device drivers. E.g. if camera has imaging and guiding chip, driver should expose two independent simple devices instead of one complex. It is much easier and transparent for client.
  6. Hot-plug support for USB devices. If device is connected/disconnected while driver is running, its properties should appear/disappear on the bus.

What are the differences between INDIGO and INDI

The most important technical difference is the architecture. While in INDI drivers and clients are connected only over a pipe or network connection and each of them is a standalone proces, in INDIGO drivers, agents and clients are connected to a software bus. In the best case (when both drivers and client are the same process) it may speed up the operations 1000x compared to INDI and you still have the possibility to make the bus distributed and to run every piece of the solution in a different process or on a different machine. More efficient architecture means less memory, less CPU usage and thus less energy consumption, if you're running on batteries in the field.

The most important non-technical difference is, that INDIGO is developed from scratch and managed to become a standard. It has a vendor friendly license to encourage not just an open source, but also the commercial development. It has a conservative project management to protect the investment of 3rd party developers to the integration. And unlike INDI it is not tied with a single client application.

What are the differences between INDIGO and ASCOM/ALPACA

The most important difference is, that INDIGO is multiplatform, distributed and asynchronous system by its nature, while ASCOM is Windows/.Net only framework for synchronous control of local devices. ALPACA promises to make it distributed sometime in the future, but it will be still tied with Windows/.Net.

Can INDIGO client or application use INDI driver?

Yes, INDIGO wire protocol adapter has the ability to fall down to legacy INDI wire protocol version 1.7 to maintain backward compatibility with INDI drivers. In this mode also property and item names are mapped to INDI standard corresponding to version 1.2.

If you want use linked driver option or to use different wire protocol, you have to use INDIGO driver.

Can INDI client or application use INDIGO driver?

Yes, if client or application will initiate communication over INDI wire protocol, INDIGO driver will simulate behavior of INDI driver with common base set of properties.

Can INDIGO client or application use ASCOM driver?

Partially, INDIGO client or application can use INDI Server for Windows as ASCOM-to-INDI bridge out-of-the-box, but probably much more efficient ASCOM driver wrapper for direct linking will come soon.

What platforms are supported?

Currently on Linux and MacOSX both client and server components are supported. On Windows only a client side is implemented.