So, to keep you up to date:
I discussed the issues with my colleagues and it was agreed that recalibration before every observation night was not a feasible strategy. We are going to concentrate on optimising the dome and motor mechanics so that it will (hopefully) not slip anymore. Though I believe that it cannot be avoided to recalibrate once in a while, so your implementation to INDI is greatly appreciated.
My supervisor said that they updated INDI just today, so I hope that we can test that and the new functions for relative motion in the coming days. I, for one, am looking forward to it

Read More...

Nice to hear that you are putting in so much effort and work into making all this working properly. Thank you very much, Jarno.
Just to clarify, the dome we are using is several decades old, if not a century. We only use the ScopeDome USB Card to control our dome motor from the PC. It is therefore not a big surprise that our dome slips. I will discuss adressing this issue with my colleagues on Monday, but my guess is that regular recalibrations will still be required. I will keep you up to date on that if you are interested. Otherwise, I will come back to you if I find some more bugs or inconsistencies.
Again, thank you so much for all the help you have provided.

Read More...

Yes, I just tested your suggestion and can confirm that the Autosync Threshold also applies when not slaved. Our telescope would probably need a higher threshold because the amount of slip which the dome experiences seems to vary strongly with temperature.
I can also confirm the limits you spoke of, though I can not give specific numbers. Yours do definitely seem plausible, but the results I found are somewhat mixed. I could throw some numbers around but that would probably not be of much help to anyone else. The main issue here, I believe, is again that our dome slips and needs regular recalibration, depending on weather (or rather temperature) fluctuations.
There was one odd thing we found while testing. We used the INDI starter program to communicate with the module. What we found was that the "Dome CW" and "Dome CCW" buttons seem to crash the program so that one must disconnect the and reconnect in order to regain control over the client. If it helps, the terminal output can be found in the attached file. If I read the documentation correctly, I assume that is because the "DOME_CW" and "DOME_CCW" attributes are not implemented?
And I was also surprised that the dome move in CW direction if you set "DOME_RELATIVE_POSITION" to a value less than -180 deg and in CCW direction for values greater than +180 deg even though the documentation says

Positive degree is clock-wise direction. Negative degrees is counter clock-wise direction.

Hello Jarno,

I am writing in response to Danuvium , who had inquired about INDI implementation of the ScopeDome drivers late last year . I am happy to announce, that thanks to your work we have been able to connect our ScopeDome module to our Linux PC with little effort. Thank you very much for your work.
While we can not report on all the functionalities the box provides, all the necessary functions (e.g. dome movement and abort) are well implemented.
There are however still some problems we encounter. Most notably, the dome oftentimes overshoots its target and tries to correct for this by going back and forth until reasonably close, even with the use of an inertia table. But as the improvement is usually minimal for our dome, we would much prefer it, if the ScopeDome module would not try to correct for the overshoot. Do you happen to know, if it is possible to turn this functionality off, or to increase the threshold for the acceptable discrepancy?

With best regards,
Kai R.

Read More...