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

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 be distibuted and platform independant, however the reality is a bit different. The only publicly used implementation is ASCOM 6.5 remote that exports ASCOM devices over the network. Native ALPACA drivers are still rare. Even more the API of ALPACA is 1:1 mapping of the ASCOM API which makes it diffucult to map other frameworks to ALPACA and straight forward for ASCOM. So in theory ALPACA is multilpatform and independant but in practice it is very tighly related to ASCOM.

Can I access INDIGO devices with ASCOM application?

Yes, via ASCOM Remote. Starting with INDIGO version 2.0-146, there is an agent - indigo_agent_alpaca, which exposes INDIGO devices to ALPACA clients, but 100% support is impossible and some advanced features are not available, because they can not be mapped to Alpaca. Alpaca is specifically designed to accomodate ASCOM not INDIGO. However, we made the mapping as good as we were able to and in the end indigo_agent_alpaca passes the ASCOM comformance tests.

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.

Is there an INDIGO user group?

Yes, it is here: http://bb.cloudmakers.eu