Hi Pit,
I'm not 100% sure but it looks like you stepped into a bug that must have appeared recently. I tested it and had the same problem.

I would recommend that you go back to commit c55eb81a - and you need to re-create the capture sequence file, since it's syntax changed.

HTH
Wolfgang

p.s.: If that is working, you could take a closer look how to use the scheduler. I would recommend using "Repeat for ..." and having shorter sequences in the capture sequence file. I for example typically use a LLRGBLLL capture sequence file and repeat it 15 times followed by a LL sequence that is repeated 50 times. In combination with "Remember job progress" selected, you can run such a schedule over several days or weeks until you have 15xRGB and 100xL.

Read More...

Hi Matthias,
should be sufficient, but if you are not very limited with disk space, better tick all EKOS devices. You never know...

Wolfgang

Read More...

Happy to hear!

Clear skies
Wolfgang

Read More...

Scott,
could you please take a closer look whether you have a setup for refocusing on filter change? Maybe in combination with defining another filter for focusing you are creating an endless loop?

At least I can see in your log file that after the successful autofocus a filter change happens which triggers focusing and this seems to lead to another filter change.

HTH
Wolfgang

Read More...

Hi Matthias,
the log from Sunday to Monday is on INFO level, unfortunately. The meridian flip is initiated at 1:08, but there is no entry that the flip completes. So it remains difficult to explains what happens...

Nevertheless, even if you did it already, please check in the INDI dialog whether your mount has the same location as KStars and is working on the same time. A delay of 0.3h seems too much for me.

Just another idea: maybe your Raspberry or your mount changes time after the initial sync between KStars and the mount happened.

It would be great if you could provide a log on VERBOSE level where the MF fails.

Cheers
Wolfgang

Read More...

Scott, Supaii,
could you please be so kind and turn on the verbose mode - at least for focusing and capturing. The behavior is strange, but it is not clear what happens.

Cheers
Wolfgang

Read More...

The only difference I could find between the two log files is this entry in the second one:

[2020-09-10T00:39:06.040 CEST DEBG ][   org.kde.kstars.ekos.capture] - setMeridianFlipStage:  "MF_NONE"
When capture sets the meridian flip stage to "MF_NONE" directly after receiving a "FLIP_COMPLETED" this means that capture thinks that there is no capture sequence job left to continue - i.e. it assumes that all jobs are completed.

This explains why there is no re-alignment and no guiding startup, but it does not explain why focusing and capturing continues. Strange...

Could you reproduce it with the simulators?

Read More...

Did you build KStars from the source? If yes, it would be great if you tell us the exact commit number you are working on.

Read More...

Ah, sorry, did not see your post with logs. It would be great if you could try to reproduce it with simulators. What I can already say that it is not linked to the bug with the second flip. In the meanwhile, please turn the log level to „verbose“. This gives much more insight.

Cheers
Wolfgang

Read More...

Without logs it‘s difficult to answer, but maybe an explanation helps how restarting aligning and guiding after a flip works.

If you are using the capture module directly without the scheduler (which I personally would not recommend for unattended sessions), it depends on the exact situation directly before the meridian flip happens, what will be restarted afterwards.

If guiding was running, it will be restarted. But if it aborted before due to a cloud or whatever, it won‘t be after the flip. For aligning it depends, whether the mount has not been moved after the last alignment. If you did not move the mount after the alignment when starting the capture sequence, an alignment should take place. And both guiding and alignment are independent.

If you need more details, please share the logs.

Wolfgang

Read More...

Hi Matthias,
the only thing were I'm almost 100% sure: it's not correlated whether the logs are on and off.

For the rest: please post logs, and best with verbose mode on and at least INDI and mount selected in the logging options. This is the only chance how we could drill it down, the rest is speculation...

Wolfgang

Read More...

Hi Max,
slightly off topic here :-)
Assuming you have downloaded oacapture.deb into that directory where you want to issue the "apt-get install", I think you need to add a path to the package. Otherwise apt-get tries to get it from it's repositories.

Try

sudo apt-get install ./oacapture.deb

HTH
Wolfgang

Read More...

Hi Matthias,
did I get it right, it's the second meridian flip that does not work? There is indeed a bug in the most recent version of KStars that prevents a second meridian flip.

We are working on it. If you know how to compile from sources, you could try to use the sources from my KStars clone from https://invent.kde.org/wreissenberger/kstars.git

And do yourself a favor: leave the logs on. Using KStars is komplex and if you want to get help, you will need log files.

Wolfgang

Read More...

Hi Matthias,
your logs show, that the meridian flip has been started and completed - but everything within 1 or 2 seconds. So obviously no pier side change has happened.

What does that mean? Well, it's at least no KStars bug, the problem is somewhere in your setup. Please check the following:

  1. Are the time and location of KStars and mount in sync? There is a KStars / INDI option to sync KStars and mount. Is it enabled?
  2. Is meridian flip enabled for your mount?

Maybe it's helpful if you increase the delay.

Hope that helps
Wolfgang

Read More...