Optical Train for KStars 4.0.0
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.
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.
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.
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.
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...
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.
Astroberry Server | NEQ6 | Atik 460EX | Atik EFW2 | ASI 120MM
ASI1600MM-Pro Cooled and filter wheel with an 8" TS Ritchey-Chrétien on a SkyWatcher EQ6-R
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.
Skywatcher EQ8 pro
Meade series 5000 80mm triplet Apo & Meade 8” SCT (de-forked)
Starlight Xpress SXVR H18, SXVR M25c, Lodestar Guide Camera
Pegasus Ultimate Hub for all USB & Power
Pegasus focus motors on both scopes
AstroNerd wrote: 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
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 ...