I couldn't wait to test the new scheduler yesterday and thought I combine that with installing Ekos on a AML-S905X-CC Libre Computer.
I almost succeeded...
Almost.
The problem I could not solve is that the FCUSB autofocus module keeps crashing upon loading.
This problem may be rooted in the fact that the FCUSB plugin is only available in amd64, armhf and i386 architectures, whereas the Libre uses arm64. I added these architectures and then the FCUSB driver installed fine and is listed among the drivers in Indi. But it crashes upon starting Ekos.

Just to confirm: Will the driver be recompiled for the arm64 architecture? I am not sure how I can do this, since the .debs are the only files available on www.cloudmakers.eu/shoestringdrivers/

Can anyone help with this?

The same drivers have installed fine on my Pi3 and on my mini-PC and won't crash there.

Ah combined testing you should ask cloudmakers directly?

-Eric

Ekos was still 2.9.8. I had not yet made your changes. I got hung up on installing FCUSB, which I need to test the scheduler correctly, else my focuser won't work.

This is the reply I received from cloudmakers. Is there any reason you know of that installing INDIGO in parallel to INDI might mess up things?
I need the FCUSB driver, so I will have to make it work one way or another.

sorry, there is no build that driver for ARM64 and we dropped support for INDI already and focused on INDIGO only. But it should be no problem in case of focuser driver, you can try to install INDIGO along with INDI and it should work with Ekos as well. You can find driver description here

github.com/indigo-astronomy/indigo/tree/...rivers/focuser_fcusb

and to download INDIGO from here (there is ARM64 package as well):

indigo-astronomy.org/downloads.html

Regards, Peter

OK, last night it finally cleared up and I had the opportunity to test Eric's new scheduler (I presume that is included in the latest nightly build).





I only imaged two targets last night, the Rosette Nebula and M81/82. The scheduler performed flawlessly on these two sequential targets. My only suggestion for improvement would be to include a line in the code to the effect that

IF [next target >1hr into the future] THEN [park mount] ELSE [do nothing]

Currently, the mount continued tracking the target, although the next execution date was 16 hours in the future. Not a big deal for a mount in the backyard, but for a remote observatory it may lead to the telescope crashing into the tripod or pier.
One other thing one has to keep in mind is that the scheduler will NOT start executing the sequence, even if set to ASAP, IF a lead time > 0 is set AND the altitude limit set for the first target has already been reached. Lead time has to be set to 0 in that case.

The only other quirk I found relates to the exposure settings in the guide module. There, something strange happened. As I was testing the guide module before starting the scheduler on another target, I noticed that the image was blown out despite using a 0 gain setting and the same settings I had successfully used for months (3 s integration time, 1x1 binning). Strangely, SHORTENING the integration time did not yield a picture that was not white, i.e. overexposed, but EXTENDING the exposure time and INCREASING the binning to 2x2 did!?!? However, when I started the scheduler, with the same settings I had previously established optimal exposure for my guide cam image, now the image was blown out and I had to DECREASE the integration time again (to 3s) and the binning to 1x1. ????

After that, the system performed without a hitch for the rest of the night on a Pi3. Even solving was reasonably fast at ~20s.

Here the Dropbox link to last nights log: www.dropbox.com/sh/pints7iwug9r8b8/AAAXH...UOHb2wp33rNBpFa?dl=0

Just in case you need it. The log file was too large to attach.

All in all, the system performed very well.

Thanks to everyone who is putting countless hours into perfecting this!

Jo

For parking > 1h, there is "Preemptive shutdown" option that you can enable in the options for this very purpose. Btw, I happen to fix an issue regarding preemptive shutdown just 2 days ago if you want to test this again, make sure to use the updated nightly.

OK, I will enable preemptive shutdown then. That will only come into play after the last target of the sequence has been imaged, or will this also initiate shutdown during the middle of the sequence, i.e. if there is e.g. a 10 min gap? And will the mount unpark itself again when the time to image the next target has arrived?

I did use the nightly build from December 20th, i.e. from yesterday, so I assume your fix is already contained in that build?

Best wishes

Jo

The option provides a maximum delay after which to shutdown the observatory. In my to-do list, I need to add an option to stop tracking when not shutting down. I also need to display the shutdowns properly in the schedule. Right now only the intervals exceeding the lead time are highlighted.

Thanks for you all your great work, Eric!

Tonight it looks like it is going to be clear, so I might have the chance to test the scheduler again. Worked like a charm last time.

One quirk I could not change, but perhaps I did not look in the right place and you or Jasem can help with this:

When using the filter wheel EKOS will always force refocusing when switching filters. That is time consuming and also an issue because some filters are so effective, there is very little light coming through for the focuser to latch onto. As a result, I need to expose for a long time or the focussing solution is not always the optimal one when I use Ha, O3 or S2 and there are no bright stars in the vicinity, like when I try to image M81 or M51. It generally works quite well with the Luminescence filter in the light path.

What I was wondering is, is there a way to switch off the forced refocusing on filter change? It looks to me like my filters are parfocal or close to it. So I would prefer to focus periodically using the Lum filter and then switch directly and without refocusing to the narrowband filters.

Thanks for your suggestions and again, thanks for this great scheduler!

Jo

Check the filter manager settings, maybe you enabled that yourself. Click on the small Filter-like icon in capture or focus module and configure the filter settings there. You can also set a "Lock" filter. For example, for HA, you can set its lock filter to Lum, so any time a focus is made when HA is active, the focusing is done using Lum. At any rate, you can control all these settings from the filter manager.

Fantastic, thanks! I was almost certain there had to be an easy way to do this and that I was just too dense to find it. I know now where to look, will test it tonight.

Best

Jo

Don't now if you solve this but, I manage to use Shoestring focuser that previously crash with the new version of indi by making a symbolic link from libnova library of actual version of my Ubuntu system to the one that indi driver need.