You're looking for TARGET_EOD_COORD

defXXX is to DEFINE properties, setXXX is to UPDATE already defined properties values. If you receive defXXX for a property that was already defined in your model, then you can safely ignore it and move on to the next INDI message.

def* is declaration or redeclaration (e.g. to change constraints, labels, etc.), set* is value assignment. If you want to make it really simple, ignore defSwitch* and wait for setSwitch*. It will not work in general, but can be used for CONNECTION property.


OK, but don't suppose that mount will start tracking on setting this property, it will wait for next *_COORD.


*_COORD_REQUEST properties are not used anymore, *_COORD and read/write now.


Yes, wINDI polls the position every second. But EQUATORIAL_COORD_REQUEST was request to change the property, not to read it. INDI was always event driven.


Mount can report coordinates by EQUATORIAL_COORD, EQUATORIAL_EOD_COORD or HORIZONTAL_COORD depending on what it is, you may need to check or control parking state, read telescope info to show proper FOV, synchronize time or observatory position. Every version of INDI driver and every INDI server can send messages in slightly different format, but still valid XML. I don't think, it is a good idea Peter

Hello Peter,
Could not find any setSwitch* in your log up to now. Will investigate again.

I tried some requests 2 days ago, but couldn't get a response from (w)INDI and simulator. I could not find the correct information in the developers manual & white paper. It also doesn't tell you if you can read or write it or both. In fact, I distilled most information from the (w)INDI log. Could you give me a complete client XML request example which will generate a response from the telescope simulator containing the RA,DEC??

I think it will be helpful to have some more XML style examples of INDI communication at indilib.org It relies for the documentation much on the C source code which handicaps programmers in other languages (Pascal) like me.

I thought it was driven by the RA noise. This a different behaviour than the library 1.2.0 server. Is it wise the differentiate? What if you have TCP/IP link between a Windows client and a Linux server? The Windows client could expect a continous stream of telescope information but will not get it.

Han

There is one, it follows all other messages:

2016-06-13 19:02:26.58 HANDLER#0 < <setSwitchVector device='ASCOM Simulator Telescope' name='CONNECTION' state='Ok' timeout='0' timestamp='2016-06-13T19:02:26.5' message='Connected...'>
2016-06-13 19:02:26.58 HANDLER#0 < <oneSwitch name='CONNECT'>On</oneSwitch>
2016-06-13 19:02:26.58 HANDLER#0 < <oneSwitch name='DISCONNECT'>Off</oneSwitch>
2016-06-13 19:02:26.58 HANDLER#0 < </setSwitchVector>



wINDI returns only EQUATORIAL_EOD_COORD now, but other server with other driver can define ANY mentioned property.


Sorry, I probably don't understand. Server can send any message anytime. It is asynchronous from client point of view. Client can use getProperty request to force update, but response is asynchronous again.

Peter

Peter,

1) Okay but how does a client request the RA/DEC position? I can’t find it. Do you have an sample XML request?
2) If a client wants to access the device driver directly, do you only have to change the address in TCP? If so is there a device simulator suitable for testing this?


wINDI is sending continuous the RA/DEC position. I a windows client is developed using wINDI, it could fail later if connected to a Linux server via a TCP/IP link. The client needs to keep the last position in memory and that is not demonstrated using wINDI. I noticed this after moving the client to Linux. So I’m suggesting not to do polling by the server or to make it adjustable.

Han

Last night and tonight didn't made much progress. Tried to install libary 1.2.0 on a different Linux edition. Links at:
indilib.org/download/ubuntu.html
are all dead !
Managed to get an older library as follow:
sudo apt-get install indi-bin
This gave me version 0.9.7 from April 2014. Same in synaptic.
Tried this one, but noticed in my logging that it uses in the message format DRIVER_INFO rather then DRIVER_NAME., Made my code more flexible knowing this variation.
Looked into the source to get a clue how the client could request the telescope position but it is difficult to follow without a debugger.
Tried in Ekos the "indiserver" logging function -l to see how Kstar would make requests, but the log is only containing events and not the complete communication. Would be nice to have the full communication log.

So I still don't know how the client can request the telescope position. Tried several XML request variations to the device driver, but none was accepted. Will leave it for the moment and focus on other topics.

Secondly a working link to the Ubuntu binaries of library 1.2.0

Han
.

Look on way of indilib installation on fresh Ubuntu 16.04 (64 bit):
cd ~
cd /usr/bin
ls indi*

There are no links in that URL, they're commands you run to download and install the package. As it says, only packages for Ubuntu 15.10 and above. Also, the client never requests a telescope position, it is sent by the driver (property EQUATORIAL_EOD_COORD) via the server to the client. There is no request/response mechanism in INDI.

You can get latest code and build it yourself as well on INDI GitHub

Okay no library 1.2.0 in my Trisquel edition. Still would be nice to have binaries to download. Compiling did not work for me in an other Linux edition. Too many errors and missing files.

>>polakovic wrote:
>>*_COORD_REQUEST properties are not used anymore, *_COORD and read/write now.
>>Mount can report coordinates by EQUATORIAL_COORD, EQUATORIAL_EOD_COORD

I understood the coordinates where read/write. So read only. Confusing. No problem can live with that

I tested the java server &simulator. Noticed again different message after (<getProperties version="1.7"></getProperties>) . The only way to reliable detect devices is the look for device="Telescope Simulator" The label='Name'> doesn't show up in the java response. I hoped to have a clear XML syntax but that is now fading.

Han

It can be done as a side effect of redefinition request (page 8 in INDI protocol spec) by

<getProperties version="1.7" device="XXX" property="EQUATORIAL_EOD_COORD"/>

but it is wrong approach, THERE IS NO REQUEST/RESPONSE MECHANISM IN INDI!!!


Sorry, I don't understand. What does it mean to access the device driver directly?


No, this is correct way how to do it. If client will be developed using INDI standard, it will work. Server can update coordinates anytime it wants or needs and wINDI wants to send them every second, that's all. THERE IS NO REQUEST/RESPONSE MECHANISM IN INDI!!!


The syntax is correct and any INDI client should understand it. IMHO the only reliable way to do anything is to implement INDI protocol parser instead of catching random strings in the stream Sorry, Peter

Hello Peter,

>>Sorry, I don't understand. What does it mean to access the device driver directly?

Connection directly between client and device without a server. See page 2 white paper:
INDI Architecture, The diagram below represents the simplest possible INDI configuration: one Client connected to one Device: So working without a server.

>>The syntax is correct and any INDI client should understand it
Slew and read the telescope position is easy. The only problem was to detect the devices available in the server. The Java server didn't responded with label='Name'>Driver Name< I was using that to find the available devices.

Han

You can use wINDI only over TCP, there are no drivers you can access directly. Peter