×

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

Bi-monthly release with minor bug fixes and improvements

Optical Train for KStars 4.0.0

  • Posts: 527
  • Thank you received: 139
It sounds like there are some development benefits to this idea, but what are the practical end user applications for this? Multiple imaging rigs run at once? Or multiple telescope capture in a single interface?
4 years 2 months ago #47816
The topic has been locked.
The immediate benefits are:

1. Simplify the workflow. You no longer select a camera, filter, focuser, ...etc. in each Ekos module. You just have selection which is the train.
2. It can support multiple cameras to work at the same time.
3. Any number of devices supported, not limited to the current 12 limit in the profile editor.
4 years 2 months ago #47834
The topic has been locked.
  • Posts: 554
  • Thank you received: 138
This looks like a good idea and should make things simpler both for development and the user. I've always thought that the Mount and the optics should be separated.

I'm not convinced that passive components such as focal reducers, Barlow lenses, eye piece projection, diagonals etc., should be included. Calculating the focal length by allowing for all the optics is tricky because the power of a focal reducer or Barlow depends on it's spacing. The focal length of a scope with a moving mirror such as a SCT will also vary depending on the mirror position. I see a vast amount of complexity for something that could generate more problems than help.

One thing is the guiding system. A separate guide scope is clearly a separate optical system but what about a combined guider and imaging systen? Either an OAG with a separate camera or a camera with a guide camera integrated.

The optical train/mount arrangement would be EKOS specific I suppose, there wouldn't be much if any change to how the INDI drivers operate, although some things, such as the OTA properties in the mount drivers ,would become obsolete.

Chris
4 years 2 months ago #47836
The topic has been locked.
Regarding the focal reducer, I thought about it as a simple modified to focal length. So Ekos would calculate the final focal length instead the user. But it's not necessary and we can live without that (make the user enter the focal-reducer effective focal length like they do now.

The system should also cater for OAG, it's the same train as the primary imaging system. You're right, the OTA info would be obsolete and will probably be removed from INDI mount drivers in the future.
4 years 2 months ago #47837
The topic has been locked.
  • Posts: 163
  • Thank you received: 26

Replied by Bart on topic Optical Train for KStars 4.0.0

Perhaps you could break it up into certain packages. For example:
1) The mount, optionally with GPS/ weather station. Maybe also dew heater controller. Essentially all things independent from optics/ imaging train.
2) Telescope with all optics such as focal reducer/ flattener/ coma corrector. I would also like to include the dew heater parameters/ focuser/ shutter with flat-field illumination in this 'package'.
3) Guide scope assembly with dew heater parameters and camera.
3) Imaging module with optionally filter wheel/ OAG camera/ adaptive optics/ ADC.

I think the overall idea is a niche though.
4 years 2 months ago #47840
The topic has been locked.
  • Posts: 139
  • Thank you received: 31

Replied by Marc on topic Optical Train for KStars 4.0.0

This is a pretty good Idea. Actually we had this discussion one year ago, if you remember, Jasem .
The idea of one optical train/Ekos is excellent. But for what I understand, you'll need to start several instances of Ekos (One per optical train) in order to achieve that, am I right ?
So maybe this is all about completely separating Ekos from Kstars, which would give more flexibility and simplicity.
Here's an example : When I start one instance of Kstars (alone, no Ekos) it drains 7.6% of processor time and 3% memory. If I need to drive 4 rigs from a single computer, I waste 3x7.6% and 3x3% memory in useless Kstars, as one would be sufficient if it could monitor my 4 rigs.
Plus, the separation would let the possibility to use any planetarium software along with Ekos. That should increase the number of potential users of Ekos, every one having his own preference on that matter... From this point of view, Kstars and Ekos would act as 2 completely separate clients of the INDI server.

And for those who don't see the practical interest in all this:
- You're in the field imaging with one rig, while watching with the second one. (And you have plate solving/autoguiding for both)
- You're imaging with 2 cameras: one in color (RGB) The other one used for getting luminance (Ha, etc) Both at the same time.
- On a distant observatory suppose you need to double some gear for security purpose. (weather station or dome opening/closing for example)

And think about astronomy clubs, schools, observatories, etc...

- Marc
4 years 2 months ago #47854
The topic has been locked.
  • Posts: 554
  • Thank you received: 138
I expect that an instance of EKOS would have one mount that has multiple Optical Trains (OTs). Ekos would manage synchronising the mount activity with the combined OT activity. Multiple mounts would require multiple instances of EKOS, ideally running on separate systems.

Chris
4 years 2 months ago #47857
The topic has been locked.
  • Posts: 983
  • Thank you received: 375
I would rather think of separating EKOS from KStars as @Marc2b suggested in this thread. Multiple EKOS instances should be allowed though.
I believe that such an approach would get us back to the roots of GNU/linux. Every utility should simply do just one thing, best way it can.
Having said that, I'm against the idea EKOS handling multiple optical trains. It should handle a single train the best it can. Multiple EKOSes should handle multiple trains.
The following user(s) said Thank You: Clive Stachon, Marc
4 years 2 months ago #47861
The topic has been locked.
  • Posts: 1957
  • Thank you received: 420
Perhaps Jasem and the other developers should take one step at a time? First make the optical train change happen, then see if and how Ekos can be disconnected from KStars?


Wouter
4 years 2 months ago #47862
The topic has been locked.
So this is actually pretty simple. A train is just a collection of devices/OTA/accessories together. So instead of selecting camera and filter wheel and rotator..etc. You just select "Imaging Train" and Ekos know what devices are on it. So if it has a rotator, and you are in alignment module, it can change the rotation angle to match a target. If you select another train without a rotator, it will not even attempt to do that.

So it's a simple logical grouping to make sure everything acts correctly in unison. That's the primary idea.

The other idea is to make arbitrary mounts/cameras/aux/OTAs..etc and have the user define any number of trains. Then in principle you can have Ekos manage synchronization of multiple trains in parallel. This is quite complex, but the train idea above would allow for it as a starting point. So perhaps we can start with simply the train aka logical groups idea and then proceed from there.
The following user(s) said Thank You: Wolfgang Reissenberger
4 years 2 months ago #47874
The topic has been locked.
  • Posts: 1067
  • Thank you received: 140
I really don’t see the difference between a set up profile or a set up imaging train... and maybe there are more important things to be moving forward with, rather that re inventing the wheel, at this point.... it seems that as soon as people get a good stable working system that they have learned to use, then it all changes... just my opinion :)
4 years 2 months ago #47877
The topic has been locked.
  • Posts: 139
  • Thank you received: 31

Replied by Marc on topic Optical Train for KStars 4.0.0


You are right from a user's point of view.

But Jasem speaks from a developer's point of view. At some point, some inconsistancies may emerge, due to years of evolution step after step, that make the soft difficult to maintain and make evolve. And some choices may lead to a dead end.

So the best thing to do is to give back some logic to the whole thing by regrouping inside the same structure things that are now in separate places.

If I get what Jasem has in mind, regrouping things that have to be together under a different unique profile should simplify maintaining the separate "tabs" so when you modify something in one tab, you don't have to lose your hair because of secondary effects on other tabs :)

Plus, if you want to deal with parallel processing of several "optical trains", you really need to regroup things under a common flag first, before you can launch several instances of this "optical train".

So it's not about "reinventing the wheel", it's about making some place and order to allow future developments of a more stable software.

At some point, this evolution is probably necessary, even is it asks the users to leave their comfort range for a while ... :)

- Marc
The following user(s) said Thank You: AstroNerd
Last edit: 4 years 2 months ago by Marc.
4 years 2 months ago #47882
The topic has been locked.
Time to create page: 0.938 seconds