Wolfgang Reissenberger replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 4 days ago

Sounds good. It would be great if you create a pull request - or simply send me your modifications directly.

Read More...

Wolfgang Reissenberger replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 6 days ago

Have you already turned on logging to file? With debugging turned on for the Avalon driver, you could find the entire LX200 communication in the log file under ~/.Local/share/kstars/logs

- Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Re:Precise autofocus' in the forum. 7 days ago

The FSQ-85 has an integrated flattener. The problem is, that the flattener requires a perfect focus. A minor de-focus leads to oval stars. But with exact focus, the result is impressive.

OK, I will give it a try with longer exposure times. The problem is - exactly as you describe - finding an acceptable low tolerance with the given seeing. Currently 5% works fine on my TSA-120, but this scope is much more tolerant.

- Wolfgang

Read More...

Wolfgang Reissenberger created a new topic ' Precise autofocus' in the forum. 7 days ago

My FSQ-85 is very sensitive in terms of focusing. Even slight defocusing ends up in oval stars in the corners. Fortunately, the direction of the ovals indicates in which direction I need to shift: tangential ovals are shown in the extra-focal position, radial ovals indicate the intra-focal position of the focuser.

Currently, I use the autofocus routine only for coarse focusing. Afterwards, I need to correct the focus manually until I see round stars in the corners. With the autofocus routine I am not able to reach a focus point that is precise enough.

Any hints, which parameter setup I need to choose for the EKOS autofocus routine so that I can avoid a final manual fine tuning?

- Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 7 days ago

Right, Z1nnn is the response to the :X3C# command.

Read More...

Wolfgang Reissenberger replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 7 days ago

Hi Ken,
hm, that's a strange state. The first "0" represents the motors state showing that both RA and DEC motor are off. The "3" indicates sidereal tracking and the last digit is the motion speed, where "0" stands for "guide speed" and "3" for "slew speed".

In detail: the three last digits represent the motion status of the mount as :Z1<motorsState><trackingSpeedState><motionSpeed> with the following semantics:
motorsState:
// m = 0 both motors are OFF (no power)
// m = 1 RA motor OFF DEC motor ON
// m = 2 RA motor ON DEC motor OFF
// m = 3 both motors are ON

trackingSpeedState:
// t = 0 no tracking at all
// t = 1 tracking at moon speed
// t = 2 tracking at solar speed
// t = 3 tracking at sidereal speed (stars)

motionSpeed:
// s = 0 GUIDE speed
// s = 1 CENTERING speed
// s = 2 FINDING speed
// s = 3 SLEWING speed

- Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Announcing Ekos Live' in the forum. 2 months ago

Fully agree! Having a EKOS web frontend for my PI would be fantastic! Having a cloud service is not my major focus.

Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Got no stars is gsc installed error' in the forum. 2 months ago

Hi all,
I had the same problem with GSC installed under /usr/local. If GSCDAT and GSCBIN are not set as environment, they are set to default values under /usr/share/... .

In this case it is necessary to set the environment variables manually:
GSCBIN=/usr/local/share/GSC/bin
GSCDAT=/usr/local/share/GSC

Cheers
Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Re:Perfecting the Scheduler' in the forum. 2 months ago

Hi Eric,
reusing the interval would be great, this would resolve my problem.

-Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Re:Perfecting the Scheduler' in the forum. 2 months ago

Hi Eric,
I think it depends how the capture part is used. If it is used defining all captures for a single target, it makes sense having these features there. If it is used like I do where the capture part contains only one sequence and the scheduler defines how often it is repeated, at least the time-related features like re-focusing every x minutes is less helpful since one sequence is shorter than a typical re-focusing interval.

But maybe it makes sense to step back and think about the characteristics of the capture tab and the sequence tab. What do you think of the following:

  • The capture tab contains all aspects to ensure, that a certain amount of frames are taken with a defined quality. That means, HFR-based re-focusing and guiding-deviations belong to this tab.
  • The scheduler tab contains overall control and all time-related aspects. That means, time interval based re-focusing should belong to this tab, since such an interval is strictly time related and independent of a selected target. If we think this very consequently, I would propose shift meridian flipping here as well.

What do you think about this?

-Wolfgang
p.s.: forcing focusing before each sequence would not be very helpful in my case. One typical LLRGB sequence takes 2x8+3*4=28 min, that means every half an hour a re-focusing will occur. This is too often, so I would not be helpful. As a workaround, I will enlarge a single sequence so that it is slightly longer than the refocusing-interval.

Read More...

Wolfgang Reissenberger replied to the topic 'Perfecting the Scheduler' in the forum. 2 months ago

Hi Eric,
may I add one topic to the whish list? Currently, re-focussing is determined on the photography tab, where the single sequence is running. In my setup, a sequence is very simple: LLRGB - and then repeated by the scheduler. In the schedule I defined refocusing after 60min.
In this setup refocusing never happens, since one sequence takes 2*8+3*4min = 28min.

Would it not make more sense having these definitions on the scheduler side rather on the sequence tab?
Cheers
Wolfgang

Read More...

Hi Sergio,
I can confirm the problem, my Moravian G2-8300 with external filter wheel shows the same behavior.
My setup: Raspberry Pi 3b with Raspbian 9.0 and INDI 1.7.2.
Wolfgang

Read More...

Hi Markku,
you are right, Alt+Space is the magic combination.
Thanks a lot!
Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Re:Perfecting the Scheduler' in the forum. 4 months ago

Hi folks,
I am not sure whether I got all points right in the thread, so please excuse, if I bring up a topic here that is already addressed.

But first of all: the scheduler is THE killer application for me. Thanks a lot, it brings kstars on a completely new level.

Back to my problem. As far as I understood, when a job fails after several retries (for example during focussing), the job is marked as "ABORTED". But this might be too strict for example if clouds pass by.

So it could happen, that a certain job could not be executed for a while. If other jobs are present that could run, OK, let them run. But what happens, if all jobs are aborted? In my case, I only have one single job. In this case, EKOS is terminated, right? At least this happens in my case.

What would be the suggested behavior: I would like having a "retry after a certain amount of time" and restart the aborted job.

Does that make sense to you?
Cheers
Wolfgang

Read More...

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!