×

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

Bi-monthly release with minor bug fixes and improvements

What's next for EKOS?

Replied by Jasem Mutlaq on topic What's next for EKOS?

Thanks for asking. I think the most important thing for me at least is more stability for INDI drivers. Next comes stability of Ekos + KStars, but Ekos is just one client out of many out there. So if drivers are working great, all clients would benefit equally.

For me personally, I'm currently spending a lot of time on EkosLive now. But my long term plans for Ekos is to make it suitable for scientific data acquisition & analysis. So photometry, variable stars, detection of objects...etc.
The following user(s) said Thank You: Teseo, Jose Corazon
5 years 8 months ago #27629
The topic has been locked.

Replied by Jasem Mutlaq on topic What's next for EKOS?


Thanks for the feedback!

1. Why did it take you several days to find how to start multiple drivers on an INDI server? Was it lack of documentation? If it was, can you please make a summary for new users on the procedure and we'll publish it here in the documentation?
2. Losmandy Gemini is the overall type.. we can't have Losmandy G-8, G-11...etc. as it would clutter the already cluttered menu.
3. Of course there would be two layers of configuration. Because you are using two separate software packages. If you used INDI with any other client (e.g. SkyCharts), it would have its own client-side configurations. INDI configurations are related to the actual driver.
5 years 8 months ago #27630
The topic has been locked.
  • Posts: 985
  • Thank you received: 161

Replied by Alfred on topic What's next for EKOS?


It was lack of documentation. At the time the popup help did not yet work as it does now. I did several search queries in the support forum but didn't find my question answered. I assume it is documented now but will check this later today. [Edit: Hmmm, again I wasn't able to find the info how to start multiple device drivers on the remote machine without using WebManager. If it is already documented, please let me know where! If it's not, I would try to do it. A few sentences should do as it isn't complicated at all.]



The fact that the device and their respective drivers are named differently did cause confusion


I believe that's the programmer's point of view. As a new user of Ekos I don't know what the underlying architecture looks like. Currently the first layer of configuration is in Ekos and sorted application wise while the second layer is found elsewhere (Indi) and is sorted device wise. This is different from what a user is used to and would expect. Imagine we could set *all* settings in Ekos (Ekos simply "forwarding" the Indi-related settings to Indi). The more important/prominent settings could reside in their respective application tabs (guiding, capturing, solving, etc.) while the less important ones would only appear in the same tab once an "ALL setttings" button is pressed much like it is done in VLC, for instance. Indi would remain unchanged and could continue to serve as the foundation for a whole suite of clients while Ekos users would find all settings in the "most logic" place. "Exposure time" as well as "Gain" in the capture tab. That's where I need it (and as a new user would expect it). Nobody would have to know the former is a true "Ekos settting" while the latter is an Indi based one.
Last edit: 5 years 7 months ago by Alfred.
5 years 7 months ago #28404
The topic has been locked.
  • Posts: 527
  • Thank you received: 139
The following user(s) said Thank You: Alfred, Eric
5 years 7 months ago #28406
The topic has been locked.
  • Posts: 447
  • Thank you received: 30

Replied by T-Studio on topic What's next for EKOS?

Ekos thinks that it is a very excellent integrated environment in capturing an astronomical object.

Regarding the requirement of function, it has been described before.

www.indilib.org/forum/wish-list/2665-feature-request.html
indilib.org/forum/wish-list/2792-request...acking-function.html

It is wonderful that you can schedule everything automatically and operate it, but if it is not reliable with the driver you will be in trouble.

Currently I will describe the items that will cause problems in automating on schedule in my environment.

The driver you are using is as follows.

· Mount driver
CerestronGPS, SkyWatcher Alt-Az, Digital Setting circles
· Focus driver
moonlite, FCUSB
· CCD driver
QHY CCD, SX CCD, ZWO CCD, Canon DSLR
· Other drivers
GPSD, SkySafari

We use these drivers according to the usage environment.

1. Park setting
As mentioned above, since there is only one setting file and only the absolute position is recorded, it is not functioning properly with the mount driver which does not have the parking function. My mountain has become extinct.
Since it will be the command used to start and stop automation on schedule, I think that it is necessary to reliably function with any mount driver.

In digital setting, circle park is unnecessary from the purpose of mounting. Rather, I would like to use only the mount driver. (Ekos can not be used unless you add drivers for cameras that are not currently in use.)

2. Solver Options
Depending on the mount driver, the current location of the mount may not be reflected in the configuration file, causing a solver error.
-O - ​​no - plot - no - verify --resort --downsample 2 -3 ooooo -4 xxxxx -5 30
(The part of ooooo, xxxxx will not be reflected in the mount's current location.)

3. Synchronization with GPS
In the current Ekos setting, it is synchronized with Kstars. It is not reflected in the mount. (After synchronizing with Kstars and GPS, it will not take effect until switching from Kstars to all drivers to synchronous setting.

Items other than Park are handled manually, but they are subject to the influence of automation in the attractive remote location of Ecos.

I think it is important to further improve the consistency of these drivers and Ekos.

Postscript

I switched all environments from Windows + Ascom to INDI + Ekos.

There are some operational precautions.
However, flexible integration control of the driver, Ekos is an attraction not seen in other environments.
The following user(s) said Thank You: Eric
Last edit: 5 years 7 months ago by T-Studio.
5 years 7 months ago #28891
The topic has been locked.
  • Posts: 407
  • Thank you received: 74

Replied by Clive Stachon on topic What's next for EKOS?

"I think it is important to further improve the consistency of these drivers and Ekos." - totally agree . I Maybe a newbie to Indi but I totally agree.

A boss of mine used to say "its like the song Lemon Tree" when looking at some work produced by me but he continued " Lemon tree is very pretty but the fruit of the poor Lemon is impossible to eat" - Ekos live might be nice but if the base (Drivers/Ekos) aren't fully functioning (within reason) then you will quickly loose support.

Love Kstars/Ekos/distributed Indi but hate the many basic problems with some drivers (mine AltAz Sky Watcher) - e.g. as already mentioned Parking/Unparking.. Until this sort of basic problem is sorted (ok its on my grab and go) I am not transferring my main Obsys set up to Indi even though it would be using EQMOD.

Its not all doom and gloom not by any means but perhaps it would help to step back sometimes and see what people are saying :-)

Carry on the good work! :-)
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
The following user(s) said Thank You: Eric, T-Studio
5 years 7 months ago #28909
The topic has been locked.
  • Posts: 2876
  • Thank you received: 809

Replied by Rob Lancaster on topic What's next for EKOS?

One item I started working on that should be a future Ekos/INDI feature but haven’t finished yet is Live Stacking. Back in February I got a preliminary interface and live stacking algorithm working, but I had to put it aside for awhile due to other things I have been working on. I did end up putting some of the code into the INDI webcam driver that I wrote back in June. I intend to come back to the feature sometime soon.
The following user(s) said Thank You: T-Studio, Jim
5 years 7 months ago #28943
The topic has been locked.
  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:RE: What's next for EKOS?


I did look into that too, just to see how it could be done. Last month, I used the stacking feature of the V4L2 driver to provide long exposures for streaming webcams. I concluded that if there was a live stacking feature in Ekos/INDI, it could only be implemented efficiently in the FITS viewer.

-Eric
5 years 7 months ago #28944
The topic has been locked.
  • Posts: 2876
  • Thank you received: 809

Yep, thats precisely what I did for INDI webcam as well. I gave it long term exposure capability by either averaging or adding as many frames as it can take in the desired time period. It doesn't align the frames though, it just adds them.

You are correct as well that the actual live stacking with alignment needs to be in the fits viewer. That is where I put the code that I wrote back in February. I do plan to come back to it, but there are a couple of other things I need to finish up first.
The following user(s) said Thank You: T-Studio
5 years 7 months ago #28945
The topic has been locked.
  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:What's next for EKOS?

Please do not hesitate to come back to it, that would be awesome! When in such a mode, I don't think Atik's Air nor Vaonis'Stellina do any alignment: if guiding is started, that would be sufficient probably. That feature would be quite attractive for club presenters. And designing a stacking algorithm suitable for this activity, with short exposures progressively getting longer, would be very interesting.

-Eric
5 years 7 months ago #28953
The topic has been locked.
  • Posts: 447
  • Thank you received: 30
I am very happy to hear that there is a plan for live stacking.

I think that the environment of INDI + Ekos has made remarkable progress over the last two years.

I appreciate the efforts of the development team.
5 years 7 months ago #28965
The topic has been locked.
  • Posts: 447
  • Thank you received: 30
When remotely controlling with VNC etc., I think that it is very convenient to be able to control and stop each function such as mount, focus, schedule, auto guide from the current summary screen.
(Cockpit to supervise each function)

In addition to that function, you can easily register if you can transfer the coordinates of the parts clicked on the star chart with Ekos or click and button operation.
(Star map function of SkySafari like.)

I think that it is convenient to be able to monitor and control by one screen like a sample image. (Especially when operating with touch panel)
Last edit: 5 years 7 months ago by T-Studio.
5 years 7 months ago #28978
Attachments:
The topic has been locked.
Time to create page: 0.534 seconds