m link to standard properties
→‎INDI: updating indilib.org links for new website, adding XmTel link
Line 5: Line 5:
It can be regarded as an abstraction layer, like Ascom on Windows, but to many device types and it can communicate over the network.
It can be regarded as an abstraction layer, like Ascom on Windows, but to many device types and it can communicate over the network.


[http://indilib.org/index.php?title=Devices List of devices supported by INDI.]
[http://indilib.org/devices.html List of devices supported by INDI.]


INDI drivers communicate with devices. The INDI server optionally offers an INET socket link to INDI drivers, and thus makes the relay between clients and drivers, as show below. Clients can request a description of devices and their capabilities (called Properties), which will allow them to interact with the devices. They can get the current value of properties, modify them, or be notified when the value changes. Graphical clients should generate dynamic GUIs according to the description.
INDI drivers communicate with devices. The INDI server optionally offers an INET socket link to INDI drivers, and thus makes the relay between clients and drivers, as show below. Clients can request a description of devices and their capabilities (called Properties), which will allow them to interact with the devices. They can get the current value of properties, modify them, or be notified when the value changes. Graphical clients should generate dynamic GUIs according to the description.
Line 11: Line 11:
[[File:INDI_arch.gif|frame|250px|center|The INDI architecture]]
[[File:INDI_arch.gif|frame|250px|center|The INDI architecture]]


[http://indilib.org/index.php?title=Clients List of clients using INDI.]
[http://indilib.org/about/clients.html List of clients using INDI.] Not present in this list is [[Cartography:Main#XEphem|XmTel for XEphem]].


The INDI protocol is simple and uses XML. Properties can be of the following types: Text, Number, Switch, Lights, and BLOB. Switch is the boolean value, Lights is a feedback type defined with 4 states (idle, OK, busy, alert), and BLOB is the binary large object.
The INDI protocol is simple and uses XML. Properties can be of the following types: Text, Number, Switch, Lights, and BLOB. Switch is the boolean value, Lights is a feedback type defined with 4 states (idle, OK, busy, alert), and BLOB is the binary large object.


Even if GUI can be dynamically generated, it's only useful for user interaction and not for complex programming like autoguiding or autofocus. That's why INDI has specified standard INDI drivers, which are a [http://indilib.org/index.php?title=Standard_Properties list of properties] related to a type of device. For example, the [http://www.indilib.org/api//classINDI_1_1Telescope.html Telescope standard] has a <code>Goto</code> function. Some interfaces, like the [http://www.indilib.org/api//classINDI_1_1GuiderInterface.html Guider Interface] will probably be useful too. Obviously, if a device supports more functionalities than the standard interface, the INDI driver should not be limited to it.
Even if GUI can be dynamically generated, it's only useful for user interaction and not for complex programming like autoguiding or autofocus. That's why INDI has specified standard INDI drivers, which are a [http://indilib.org/develop/developer-manual/101-standard-properties.html list of properties] related to a type of device. For example, the [http://www.indilib.org/api/classINDI_1_1Telescope.html Telescope standard] has a <code>Goto</code> function. Some interfaces, like the [http://www.indilib.org/api/classINDI_1_1GuiderInterface.html Guider Interface] will probably be useful too. Obviously, if a device supports more functionalities than the standard interface, the INDI driver should not be limited to it.


[http://www.indilib.org/api/index.html Link to INDI API.]
[http://www.indilib.org/api/index.html Link to INDI API.]

Revision as of 02:40, 18 December 2012

INDI

INDI (Instrument-Neutral Distributed Interface) is a distributed control protocol designed to operate astronomical instrumentation. INDI is small, flexible, easy to parse, and scalable. It supports common DCS functions such as remote control, data acquisition, monitoring, and a lot more.

It can be regarded as an abstraction layer, like Ascom on Windows, but to many device types and it can communicate over the network.

List of devices supported by INDI.

INDI drivers communicate with devices. The INDI server optionally offers an INET socket link to INDI drivers, and thus makes the relay between clients and drivers, as show below. Clients can request a description of devices and their capabilities (called Properties), which will allow them to interact with the devices. They can get the current value of properties, modify them, or be notified when the value changes. Graphical clients should generate dynamic GUIs according to the description.

The INDI architecture

List of clients using INDI. Not present in this list is XmTel for XEphem.

The INDI protocol is simple and uses XML. Properties can be of the following types: Text, Number, Switch, Lights, and BLOB. Switch is the boolean value, Lights is a feedback type defined with 4 states (idle, OK, busy, alert), and BLOB is the binary large object.

Even if GUI can be dynamically generated, it's only useful for user interaction and not for complex programming like autoguiding or autofocus. That's why INDI has specified standard INDI drivers, which are a list of properties related to a type of device. For example, the Telescope standard has a Goto function. Some interfaces, like the Guider Interface will probably be useful too. Obviously, if a device supports more functionalities than the standard interface, the INDI driver should not be limited to it.

Link to INDI API.