I tried the Scheduler tonight and had mixed results. First of all, I set up a job for NGC 891 which was to culminate at 22:57 CET (though it really culminated at 22:29 but I entered my site location wrong) at my location and I set the job to start 10 minutes after culmination. And surely, at 23:07 the job started. It unparked the mount and ... started an exposure! No tracking, no slewing to the object, no guiding, nada. Here's a screenshot of the scheduler:



I have also attached the log file. Please note that I hadn't enabled the scheduler logging so I did that and then scheduled a new job and started that. Let me know if you want more concise logs and I'll repeat with the logging enabled from the start. In any case, the behaviour the second time was exactly the same: no tracking, no slewing, no guiding.


Wouter

Before I forget, I had to actively choose the correct profile in the upper left part of the sequence screen. I would expect the correct profile to be automatically selected based on the current Ekos configuration.


Wouter

"proceeding directly to capture stage because only calibration frames are pending". Would you care to provide the sequence file too? There might be another bug related to sequence management that needs fixing.

-Eric

Here you go, Eric.


Wouter

EDIT wait, wrong file. I'll upload it shortly.

EDIT 2: OK it was the right file but I added the scheduler list as well

@wvreeven Thanks. Unfortunately for your report, the scheduler had the expected behavior: your sequence file is requesting flat frames. Flat frames do not require any step, so all of them are bypassed when Scheduler starts. Capture module will eventually slew to a wall Alt/Az target, but Scheduler will only capture.
This said, we need a better UI both in the Scheduler and in the Capture modules, as it is easy to think modifications were applied while the UI was actually in addition mode.

-Eric

Eric, thanks for the investigation and I am soooo sorry for this! I'll pay better attention to the sequence I create for use with the Scheduler. Unfortunately I will be travelling today and after I am back on Wednesday the weather forecast gets bad so I am not sure when I will be able to test again.


Wouter

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.