×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Re:Kstars and several scopes ...

  • Posts: 139
  • Thank you received: 31
Hello Jaseem,

First of all, a big thank you to you all for this fantastic suite of yours (Kstars/Indi/Ekos).
Even if this is the first time I'm posting here, I've been using it for decades (Kstars first in RedHat 7 or 8 ) and for years for INDI/Ekos.

Now here's an idea, I hope not so silly, about one purpose I'm trying to achieve. My idea is to manage 4 telescopes (identical) with a single (client) computer.

Reasons are :
- Power consumption. I have only a 800/1000 peak Watts generator on site, so (60W*4 for the mounts) + (100W*4 for the laptops) + accessories (4*Raspis, 1 router, red lights etc...) Well it's too close to the limit of the generator and a bigger generator means more weight (much more actually, from 12kgs to 33).

- 4 times more light gathered with four scopes while you only move the weight of ONE Scope at a time.
( Don't laugh, you'll see when you're 62 :) ) It's getting very interesting with 4 C11 ie...)

- It's also interesting in a club where several members use the same scopes/mounts.

So far, I can manage several scopes, as long as the mounts are different. I tried one Losmandy + one EQmod and it seems promissing. But if I try with 2 Losmandys or 2 EQmods, then it's game over :(

So here comes my asking: Would it be possible to give something like a simple index to an indi_* module so we can start several of them and address them all in one Kstars ?
Something like: ln -s /usr/bin/indi_simulator_telescope /usr/bin/indi_simulator_telescope1
ln -s /usr/bin/indi_simulator_telescope /usr/bin/indi_simulator_telescope2
then:
indiserver -v indi_simulator_telescope1 indi_simulator_telescope2 ... ...

then in Kstars, click right and you find your 2 scopes in the menu... QED.

Well, I'm aware it's not that simple :) You also need to be able to switch the mount in Ekos, etc...

Thanks for listening! Or am I really crazy ?

Marc.
5 years 2 months ago #33771

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
As far as I know, you can give different names to drivers to avoid clashes. But the blocking point is on KStars.
If I can throw my 5 cents, I fiddled a bit with the possibility of controlling two CCDs by instantiating two Capture modules, but the code requires much tweaking. Scheduler on its own would be nearly able to control multiple CCDs in parallel by relying on multiple sequence files.
Controlling two mounts is also challenging in terms of code, except that in that situation everything is duplicated, a bit like two full Ekos running in parallel. Manager and Scheduler could remain unique, but must be refactored before being able to handle multiple configurations like this.
Specifically, there is a need for the ability to save the settings of Guider and Aligner in an XML file that could be reloaded later. Currently those are stored as single-instance KStars settings. Scheduler could make use of those configuration files too.
All this, of course, being cristal-clear and ergonomically obvious to everyone ;)

-Eric
5 years 2 months ago #33776

Please Log in or Create an account to join the conversation.

  • Posts: 139
  • Thank you received: 31
One other solution would be to create four different accounts each account launching one instance of Kstars. On the client side, you switch between accounts with ctrlaltF2 ctrlaltF3, etc... ctrlaltF1 bringinig you back to GDM.

The scheduler being unique, you create one master and three slaves, the slaves being simply a symlink to the master scheduler file. Also the four indiservers on the four Raspis take sync to the Kstars computer through chronyd and the Kstars clients update the indiservers except for the time. a small GPS module gives the exact time and location.

A bit heavy, but it should work. Not sure I'm crystal clear myself ;)
5 years 2 months ago #33778

Please Log in or Create an account to join the conversation.

Interesting idea, thanks for sharing.

I tried to work on the idea on controlling two CCDs at the same time (it was requested several times), but even that is quite challenging and would require quite a bit of rework. If we plan to add support for controlling multiple items, then it needs to be done for N items, not just two or three, but any arbitrary number. Different cameras also have different downloading times, so the scheduler/sequence have to wait until the slowest one finishes before it can move forward.

In KStars, you can assign Driver Aliases from the Custom Drivers tool. It's found in Tools --> Devices --> Custom Drivers. Here you can assign as many aliases as you want and then select them from Ekos. For managing different users, there is no solution currently to handle this in KStars. One would is to have each of time a different account on a Linux machine so they have to login to have their own settings applied.
5 years 2 months ago #33789

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
The multi-client facet (one kstars per setup) is relatively easy to consolidate, as long as you know what data should be shared (the observation plan) and what configuration is unique (the scope/focus/align settings). Currently the sequence embeds the CCD to which it applies, and the schedule embeds à number of séquences ? Thus to keep the schedule unique requires similar CCD/scope names for all setups.
Probably quite a few other points, but, well, in the end, that's like multiple users working in parallel. Is there a real added value facilitating this configuration from the kstars code? I suppose, but not to the extent of everything duplicated.
So yeah I'm under the impression that what we need (need? really?) to support is mainly that kind of stuff: astronomynow.com/2015/05/26/dragonflys-c...nt-galaxy-structure/. Still a fairly limited amount of users I suppose. But oh the hype around kstars...

-Eric
5 years 2 months ago #33805

Please Log in or Create an account to join the conversation.

  • Posts: 139
  • Thank you received: 31
Thanks for your answer Jasem,

I suppose the whole Ekos is a block in terms of programming. So, why not "pthread" it so each time you connect to a new indiserver, you start a new instance of Ekos. As for the data, you just store them in a folder, the name of the folder being the address of the indiserver. So, Ekos_1 stores in /home/user/.local/kstars/fedberry_1, ..., Ekos_n stores in /home/user/.local/kstars/fedberry_n.

Thanks for your time.

-Marc
5 years 2 months ago #33806

Please Log in or Create an account to join the conversation.

  • Posts: 269
  • Thank you received: 53
Maybe the answer is a new kind of driver that acts as the hub for the other drivers. So EKOS could talk to that one driver and have it route the requests to each of the connected drivers.
5 years 2 months ago #33831

Please Log in or Create an account to join the conversation.

Time to create page: 0.260 seconds