Sure, that sounds very logical, but the scheduler does not have this flexibility built in yet. Currently, the scheduler always keeps the defined sequence with the consequence that targets get pushed to the next night.

We have already discussed such situations. Currently, we are in a refactoring phase and reluctant adding new features. After the refactoring we will have a much more modular architecture which will give us the opportunity to add such advanced features. But before, we need to do some code cleanup so that we do not get stuck in complexity.

Read More...

Hi Derek,
your first target is too close to the moon on Jan 16th. If you uncheck the moon limit for KR Aur, the schedule starts immediately.

I would say, EKOS does exactly what you told it to do, but maybe you didn't mean it that way :-)

Cheers
Wolfgang

Read More...

Please be so kind and post such a schedule.

Read More...

Glad to hear, great, have fun!

Read More...

Wolfgang Reissenberger replied to the topic 'Kstars crashing' in the forum. 1 week ago

Typically, the core dump limit is 0, i.e. cores cannot be dumped. To enable it, call

ulimit -c unlimited

A 4GB Pi should be sufficient. The problem is that for large cameras you need 2.5-3GB of memory, but not more. A single frame from a large CCD uses ~100MB as FITS plus ~200MB as pixmap. If you have both FITSViewer and the viewer on the summary page, you already need 600MB. Plus focusing, aligning, debayering, ..., I measured the values mentioned before. But there is no (major) memory leak that causes the crashes.

Read More...

Wolfgang Reissenberger replied to the topic 'Kstars crashing' in the forum. 1 week ago

Do you have a core dump?

Read More...

Wolfgang Reissenberger replied to the topic 'Kstars crashing' in the forum. 1 week ago

Rishi, Dmitrii, do you use 32bit versions of the OS? If yes, this is the explanation since big camera frames use too much RAM and 32bit has an upper limit of around 3GB, which is too little if all images are kept in memory.

Read More...

Maybe you search here in the forum for other iOptron-Users.

Read More...

That's really strange. But I would really be surprised if this behavior results from EKOS. Have you tried to get an answer from an iOptron Forum or their support?

Read More...

Åke, I checked your logs. The first three logs you posted show all the same behavior: there is a slew to a certain position, that succeeds, but in none of the cases EKOS recognizes the necessity of a meridian flip ( I guess you slew to a position close, but east of the meridian) and then either the mount stops tracking (log 1 and 3) or parks (log 2). There is something configured in your mount that triggers this, it does not look like something that EKOS triggers.

In the latest log (that one that has been posted as a single one) the meridian flip seems to succeeds, but immediately after the flip the mount parks. I have no explanation what triggers this parking.

@Ron: in your case, it's different. The meridian flip is triggered by EKOS, but your mount decides not to switch the counterweight position. It seems like EKOS and your mount hardware do not agree whether the position it's pointing to is before or after the meridian. EKOS thinks it's beyond the meridian, your mount has a different opinion. The explanation for this is typically a time or location gap between both. If not, it typically helps increasing the meridian flip delay.

HTH
Wolfgang

Read More...

Hi Åke,
this is a clear indication that mount hardware and EKOS do not have identical time or location settings (or maybe both). Please do me a favour and reverse the time/location synching and sync from EKOS to the mount (currently, you are synching in the opposite direction).
And please post the entire log including the logging for EKOS modules. In yout latest attachment I see only the INDI part.
Cheers
Wolfgang

Read More...