I have a long list of drivers that I have developed in C over the years starting in the early Elwood Downey days. I just installed a new fresh ubuntu 22.04 and the latest indi from the mutlaqja PPA.. My drivers build okay.. I had to change some include paths.. no biggie. When I run them in indiserver and connect using phd2 or xephem, they don't show up in the list of drivers.

Here is my tests so far

First I started indiserver:
indiserver ./indi_vatt_guide

While indiserver was still running I used netcat and did this:
echo \<getProperties version="1.5"/\> | nc localhost 7624

netcat returns:
indi_vatt_guide: EOF

So I stopped the indiserver and tried running it standalone. I tried this:
echo \<getProperties version="1.5"/\> | ./indi_vatt_guide

again I got back
indi_vatt_guide: EOF

I tried changing "version=1.5" to "version=1.7", I repeated the above tests, and got the same results.

I tried with a few of the bundled 3rd party drivers and they all worked... so I wasn't sure what to do.

I had a similar issue a few months back on the raspberry pi that a fresh build of indi solved... so I downloaded indi and indi_3rdparty from github and built fresh. My drivers now work... I didn't have to rebuild my drivers... they just worked correctly with the freshly built libindi(1.9.7). Could there be some missing dependency for the mutlaqja PPA? or maybe some outdated lib?

Read More...

thanx, Jasem. I found a feature that I didn't see documented that is a huge help. I always thought starting in fifo mode made it fifo only... but I was wrong. It turns out I am able to start indiserver in fifo mode AND add a regularly started driver in one line... like this:

indiserver -f /tmp/indiFIFO "ZWO ASI294MM PRO"@10.0.0.2

So I can have all of the drivers, local or not, connected to a single instance of indiserver... and I can load and reload all of the local drivers. At the moment I have that ZWO driver just running static and I can login remotely and reload it. I think I may do something with socat.

YEars ago you helped me with an apogee camera indi driver but I don't know if it was on this forum. the login didn't seem to like any of my email addresses... so I started from new. Its been long enough ago that I am now replacing that apogee with this ZWO so an account might just not exist. I appreciate all the support you've given. You really should consider taking indi and kstars scheduling to the astrorob conference one of these years. I bet you would get a lot of interest.

CJ

Read More...

I have a question regarding dynamicly starting and stopping of indi drivers that are running on a remote server.

We currently have a bunch of indi drivers running on our local machine. We start them dynamically by creating a fifo, starting indiserver with the '-f' option, and sending the paths of the various drivers to the fifo. Some drivers are more reliable than others so we have a nice little bash script that astronomers can use to start/stop/restart each of the drivers individually.... This works our really well and has minimized late night calls.

I am at a point where I need to split up my indi drivers among multiple indiservers on different machines... for example we are now installing a zwo asi camera as our autoguider. The camera is really far away from the control computer so I put the indi driver for that camera on a pi board colocated with the camera, and phd2 is on the control computer talking to it remotely... This wotks fine, but I'd like to be able to load the indi driver dynamically, on the pi, from my main control computer.

If I start the indiserver on the pi in fifo mode, is there a way to communicate between indiservers to tell a remote server to start/stop/reload a driver? for example.. can I do something like:

echo "stop /usr/bin/indi_asi_ccd@10.0.0.2:7624" > /tmp/indififo

I tried that and it didn't seem to like it. Is there any functionality like this available? I know I can cobble something together with SSH, or maybe I can forward indififo with socat.. but sometimes its better to ask whats available and see what others have come up with.

Read More...