Bill Tschumy replied to the topic 'Another ZWO EFW question' in the forum. 2 weeks ago

I get this message as well. As you say, it doesn’t seem to cause an issue as the filter names are correct afterwards.

Read More...

Bill Tschumy created a new topic ' Hiding Ekos on macOS' in the forum. 2 weeks ago

When running KStars/Ekos on macOS, I find I cannot hide the app using Cmd-H or the Hide command in the menu. It briefly disappears and then pops up again under whatever app was brought to the foreground. Interestingly this only happens when the Ekos panel is open. If I am only showing KStars, the app hides correctly. Is there some Ekos seeing that might be causing this? If not, it would be good if one of the Mac developers could look at it.

Read More...

Is it possible to manually edit the guiding parameters that are determined during calibration? I would like to tweak a few things as an experiment.

I assume these are stored in a text format (JSON??) somewhere in the file system. If I connect to Ekos on an RPi from a Mac client, I also assume the parms would be stored on the RPi rather than the client. Correct?

Assuming they are editable, can someone give me the path?

Bill

Read More...

I’ve never used a Skywatcher mount, so this may be way off base. When you power up a mount neurally assumes you have it in the expected “home” position. For an EQ mount, that would normally be pointing towards the celestial pole (NCP). I would check your manual to see what the Skywatcher expects or to see if you have inadvertently changed it.

Often the first align will actually do a sync, telling the mount “I’m pointing exactly here”. Sounds like that sync is expected to have already happened to say you are at the NCP.

I disagree that plate solving near the NCP is inaccurate. The polar alignment routine works by doing plate solves near the NCP and that works. I agree that any small errors will be magnified if you do a sync or align based on the plate solve very close to the pole, but it should not cause what you are seeing.

Read More...

Bill Tschumy replied to the topic 'No frame dimensions in Ekos??' in the forum. 4 weeks ago

Have you double checked that your ASI183 camera is in the Primary optical train?

Read More...

Excellent!

Just to be clear, is this a client change or a server change? Do I need to grab the nightly KStars client for macOS?

Read More...

Yeah, that makes no since that the first delay is missing. It would be great to get that fixed. I think delays should be “first class citizens” just like exposure times. Neither should be skipped.

I do have a workaround for now, so there is no huge rush.

Read More...


Not sure I understand why these two situations would be different. If you had a single capture with a delay of (say) 1 minute and repeated it 5 times in the scheduler, I would expect:

image 1
[1 minute delay]
image 2
[1 minute delay]
image 3
[1 minute delay]
image 4
[1 minute delay]
image 5
[1 minute delay]
Done

I would expect the same pattern if the sequence had 5 images, each with a delay in it. Could you explain which one would be different and why? I just want to be sure the fix is going to solve my issue.

Thanks,
Bill

Read More...

Wolfgang,

In my case there is no great accuracy requirement. If the delay is accurate to a couple of seconds, that is good enough.

Thanks for responding,
Bill

Read More...

OK, I just tried this. As I feared, delays seem to be ignored even if in the middle of a sequence. Maybe there is a good reason for this but it would be nice if it were possible.

Another workaround is to just expose the dummy image for the length of the delay. Not sure there is a disadvantage to doing that over the other workaround.

Read More...