Hi Ron, thanks for your feedback. It's good to know someone else in the world has the same problem as me!

As you can see, I am in conversation with Steve who I assume is key developer for the guiding module and I will do whatever testing is needed to confirm what the problem is. My rig or the software.

Read More...

Steve, to be clear, are you saying the interface label for image delta is incorrect and it should read seconds and not minutes? Is it better if delta was given in seconds as minutes is a large value for imaging?

Should software be changed to at least give an accurate phrase. Even if underlying guide software has no errors it is really import for the user interface to be clear and precise backed up with on-line documentation. Writing good documentation is a real drag but really important.

I check cables and power supply on a regular basis and will check the mount as that could be the cause. At the moment it's clear the guiding RMS goes very high > 1000 as cloud starts to pass through and I see trailed images with mount going out of position. Turning on verify image position and setting a delta should help and put mount back to correct position but an unnecessary action if mount was left to continue guiding at sidereal rate and not go out of position.

Let me do some checks please and I will report back with results.

Read More...

Steve, I have been turning off in-sequence checks because I was trying to avoid re-focusing as I have a problem with that, but you are right I had verify capture set to 0 frames and a large re-set pipeline value of 30 mins. From what you say the answer to my question is: Set the EKOS Alignment values so Alignment module is called after a period of cloud otherwise guiding continues at current location which may have drifted away from target location.

Should I set verify frames to 1 so it checks immediately and set the image delta to 0.3 as I usually set my-realign accuracy to 20 secs?

There is an underlying issue where the mount goes walkies (star trails) when guiding is suspended. This doesn't happen every time but quite often. The drift each time is different lengths and different directions but the pattern is always the same as below. Dots and lines in one direction.



This could be because my mount has developed a fault so will check that out on next clear night taking a long exposure un-guided.
What does "re-set pipeline" actually mean?

Read More...

Thanks. What you say sounds like my experience.

Read More...

Start guiding is enabled whilst a synced dome is still moving into position?

Read More...

I would be really pleased if someone with detailed knowledge can confirm the process EKOS follows to manage a period of passing cloud. With my setup I often see a few frames with significant drift during cloud and at the far side when visibility returns there has been a significant shift in the image making stacking or my case exoplanet photometry difficult or impossible to continue after cloud interruption.



In the above example, prior to the set of 4 A images, all images are good.
Set A images are considerably fainter as cloud partially obscures but frames remain un-shifted and in correct location.
The 3 set B images remain considerably fainter and exhibit significant shift especially the last 2.
Set C images have regained brightness to pre set A values but remain about 8 min out of position

I notice the alignment module wasn't called after this cloudy interval so does guiding restore pre cloud position?
The impression (only an impression) is that when guiding is suspended due to loss of stars, the mount isn't set to default sidereal rate so significant drift occurs until guiding re-starts. I would have thought when guiding is suspended or abortyed the mount should be set to sidereal rate so it carries on to within the accuracy of its alignment and motors and is then re-aligned when cloud dissipates.

Obviously guiding is re-aligning all the time to keep guide stars in position. When guiding is suspended due to cloud and re-starts, if a shift has happened it will pick a different set of guide stars I think so not sure how it can re-align?

Next clear night will simply put the dust cap on for say 15 minutes when guiding then take it off and see what happens.

Read More...

David Bennett replied to the topic 'Auto Focus failures' in the forum. 3 days ago

Hi John, I did some tests back in July where I captured some images at various step positions from way out of focus to near focus. I didn't use auto focus, just used capture changing the step position between frames.
Below are screen grabs from Fits viewer of about 1/3 of the frame. The HFR values are those as given in the fits viewer and seem to me much what I would expect so good results I thought at the time. I plan to do repeat this test to ensure focuser and optics are good and then on same night run auto focus tests to see how they perform. I have messaged you to see how I can send you these images, 18 in number, about 140 mb zipped

Step=10000 HFR= -1
Step=14200 HFR=12.652
Step=14400 HFR=8.452
Step=14550 HFR=4.743
Step=14570 HFR=4.491
Step=14600 HFR=4.233

Read More...

David Bennett replied to the topic 'Auto Focus failures' in the forum. 4 days ago

indi-asi 2.2 is installed.

Yes the 12" RC telescope I have has a large secondary.

Read More...

David Bennett replied to the topic 'Auto Focus failures' in the forum. 4 days ago

Thanks for explanation on backlash. I understand now. Just need to remember to put it back to its measured value when using the focuser manually. With Fine focus its a small amount about 5 and course 40. I will use a value of 50 to cover all eventualities.
Thanks for explanation of Max Travel. The hint says 'Maximum travel in steps before the autofocus process aborts'. We said it was +/- this value before so I was reading this as a relative value and not absolute. For the ZWO EAF the home position is 0 and max value is 65,000. I guess code wont attempt to move to a negative value so that end is protected and I will set the max value to 65,000 or less if there is insufficient movement in the focuser?
The direction of the focuser can be reversed so zero can be closest in or furthest out. When auto focuser describes motion as motion in it could actually be going out. I notice focusing moves decreasing the count. As telescope is expected to be pointing above the horizontal then its probably best to drive the camera towards the scope (in) to keep slack out of the gears. If that sounds sensible, then I need to set EAF direction so zero is closest towards the scope? With course EAF motor fits on opposite end of shaft and direction is reversed then I need to reverse the reverse to keep zero closest in!

Read More...

David Bennett replied to the topic 'Auto Focus failures' in the forum. 4 days ago

Hi John. ... a further question, how does auto focussing handle backlash? The one pass linear algorithm winds the focuser in one direction when capturing images so no reverse in direction and backlash doesn't come into play, so at the start moving out to initial start position and when winding back to computed focus position is when backlash is important.

The ASI EAF manual describes how to estimate the backlash and this gets saved to the EAF. The Indi driver confirms this as it has the setting I set up using the ASI software on my laptop.

Now there is a backlash value on the mechanics tab and first time it is the same as the indi driver. If I change it here I believe it changes it on the Indi tab which updates the value saved on the EAF. Is this correct please?

Now my knowledge gets muddy. If the EAF is commanded to move to a set position which requires a reverse in direction it will internally adjust for backlash. This means the step count doesn't need to be adjusted by the auto focuser otherwise this will double handle the backlash. However examining the log file auto focussing routine does adjust count for backlash.

If I have got this right (probably haven't) I dont think auto focus should compensate for backlash with a ZWO EAF and I wonder why the backlash is even there on the mechanics tab.

Could you clarify what I have got wrong.

Thanks
David

Read More...

David Bennett replied to the topic 'Auto Focus failures' in the forum. 4 days ago

Hi John,
It is set low because I find the star detection algorithm fails when stars get too far out of focus. With short glimpses when watching auto focus I can see It identifies what is one large star as several smaller stars and returns too low a HFR value for that focus position which throws a wobbly in the best fit parabola estimate. When nearer to focus but star image more of an irregular disk I see a poor HFR estimate. Close to actual focus the star image is good and looks like a fuzzy blob as you would expect and HFR value is OK.
I have tried weights which didn't help. I have tried different combinations of step size and, max travel and multiple out step sizes. The log I sent is just one iteration of different settings I have tried. I will do more testing and I agree with your sound advice of widening the focus motion, I just need to sort out the issue with HFR values being inconsistent. There is almost a pattern that the second point is always too high. Now I you have confirmed how to save the focus images for examination later I can do better testing. I will send you my results when I have had chance after a clear night.
I also need to check out the mechanics of my focuser and optics alignment. I have spent sometime on this already and thought it was good. The focuser is a very solid one and I have 3D printed two brackets to fit the ZWO EAF accurately with no flexure to either the fine or course focus. Currently I am testing on fine focus. I have had the focuser on the bench and there is little backlash which is hard to measure. Backlash is about 40 steps with course and hardly anything with fine. Axial alignment of the focuser and collimation will be checked again as this will contribute to poor star image and then poor HFR estimate.

The other more serious problem is failure in the auto focussing that happens from time to time. (its unpredictable but maybe every 6 to 10 auto focus operations). Auto focussing fails because it fails to capture an image. It looks like a ZWO driver issue to me. This can be seen in the log file around line 176513. Here is the relevant part:
[2022-09-19T02:06:25.614 GMT Summer Time DEBG ][ org.kde.kstars.ekos.focus] - "Focus position reached at 27350, starting capture in 1 seconds."
[2022-09-19T02:06:25.615 GMT Summer Time INFO ][ org.kde.kstars.indi] - ASI EAF : "[INFO] Focuser reached requested position. "
[2022-09-19T02:06:26.615 GMT Summer Time INFO ][ org.kde.kstars.ekos.focus] - "Capturing image..."
[2022-09-19T02:06:26.663 GMT Summer Time DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI120MM Mini : "[DEBUG] StartExposure->setexp : 5.000s "
[2022-09-19T02:06:26.664 GMT Summer Time INFO ][ org.kde.kstars.indi] - ZWO CCD ASI120MM Mini : "[INFO] Taking a 5 seconds frame... "
[2022-09-19T02:06:29.088 GMT Summer Time INFO ][ org.kde.kstars.ekos.guide] - "Exposure timeout. Aborting Autoguide."
[2022-09-19T02:06:29.102 GMT Summer Time DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Guiding" to "Aborted"
[2022-09-19T02:06:29.103 GMT Summer Time INFO ][ org.kde.kstars.ekos.capture] - "Autoguiding stopped. Aborting..."
[2022-09-19T02:06:29.109 GMT Summer Time INFO ][ org.kde.kstars.ekos.capture] - "CCD capture aborted"
[2022-09-19T02:06:29.115 GMT Summer Time DEBG ][ org.kde.kstars.ekos.guide] - Reset non guiding dithering position
[2022-09-19T02:06:29.116 GMT Summer Time DEBG ][ org.kde.kstars.ekos.focus] - Stopping Focus
[2022-09-19T02:06:29.117 GMT Summer Time DEBG ][ org.kde.kstars.ekos.focus] - State: "Aborted"
[2022-09-19T02:06:29.118 GMT Summer Time DEBG ][ org.kde.kstars.ekos.capture] - Focus State changed from "In Progress" to "Aborted"
[2022-09-19T02:06:29.118 GMT Summer Time INFO ][ org.kde.kstars.ekos.focus] - "Autofocus aborted."
[2022-09-19T02:06:29.129 GMT Summer Time DEBG ][ org.kde.kstars.ekos.capture] - setMeridianFlipStage: "MF_READY"
[2022-09-19T02:06:29.130 GMT Summer Time INFO ][ org.kde.kstars.ekos.guide] - "Autoguiding aborted."
[2022-09-19T02:06:29.132 GMT Summer Time DEBG ][ org.kde.kstars.ekos.guide] - Aborting "Guiding"

The odd thing is that I am using 2 sec exposures for autoguiding and 5 second exposures for auto focus on different cameras of course. At this time it has been running for a couple of hours autoguiding at 2 second exposures then here it changes to 5 seconds! Auto guiding Aborts followed by Auto focussing.

I don't know how developers work and co-ordinate efforts but I see Jasem is often mentioned. Anyway as I say, I have created another forum topic on this particular issue and I can only hope someone picks this up.


P.S.
A minor question. If for simplicity, I set backlash to zero then initial step size to 100, out step multiple to four and Max travel to 200 what happens? Surely Max travel must be >= 4*100.

A thought. If the focus position isn't close to the current position when auto focus starts the resultant parabola is asymmetric, with more points one side of the focus than the other and this adds to the problem of poor HFR values for me. Of course we can't know where the focus position is otherwise no point in auto focus but if computed focus position is near one end of the curve would it be a good idea to do another pass with what is hopefully a computed focus near the centre for improved accuracy?

Read More...

David Bennett replied to the topic 'Linear 1 Pass focussing problem' in the forum. 5 days ago

Ah yes that's it thanks. I am experimenting on the lines you mention and having the focus images will really help.

I have just logged a bug that I thought was an Auto Focus issue but now I am not so sure after turning on more de-bugging. Last night I set up just a capture sequence (not a job) to take RGBL images in that order. Because I have problems auto focussing, I decided to turn off most events that trigger auto focus. It took 10 x RGB images and when it got to L an auto focus was triggered because it was the 30th frame. The auto guider failed to get an image so aborted then capture aborted as well and that was it, no more imaging for the night. I think it's to do with the ZWO driver using 2 ZWO cameras. You may not be interested in camera driver issues but would quote you the forum topic number if I could find it.

Read More...

David Bennett replied to the topic 'Auto Focus failures' in the forum. 5 days ago

I had the same problem last night with auto focus failing resulting in loss of imaging time once again!!

I have attached the log file and the analyse file. Last night I had extra debugging turned on.
I can see a bug where autoguiding attempts to capture a 5 second exposure with the ZWO ASI 120 mini camera. I refer to this as a bug as the exposure time was set to 2 seconds and all previous guiding images were captured with 2 second exposures! So what changed this to 5 seconds? Following this autoguiding aborts failing to capture an image and then Capture aborts. Game over for the evening.
I am using 2 ZWO cameras ASI 2600MM as the imager and ASI 120 mini as the guider.
My profile just has a ZWO CCD driver the CCD and nothing set for the guider. I have set the guider to ZWO CCD as well in the past but I think at some point it changed back to '--' . I have read somewhere not to use ZWO Camera 1 and 2 as they are experimental (despite being selectable in the released software). With just CCD set for the imager works anyway and I have read a single driver supports multiple cameras even though the Profile Editor is misleading allowing different driver combinations to be selected. Maybe with one driver there are times when it gets the two cameras muddled?

Auto focussing can be initiated by filter change, 2 conditions in capture and EKOS settings so its possible there will be times when Auto focussing is started simultaneously by 2 or more conditions. I guess this is handled correctly?

Is there an EKOS log viewer which supports filtering of messages and tracing of capture, guiding and focussing events to help with debugging?

Read More...

David Bennett replied to the topic 'Linear 1 Pass focussing problem' in the forum. 5 days ago

Pulling my hair out tonight testing auto focussing. I did some 30 sec image captures manually changing the step count and bracketing around where I can see the sharpest focus. Auto focussing results in step values sometimes quite far from where I know it should be. I am struggling to get a good V graph. It's only an impression so I could be wrong but the HFR value isn't accurate with my images especially away from the best focus position. Here the star images are not perfect more fuzzier round blobs but break up into 2 or 3 spots.
To test further I need to capture the auto focus images so I can load in fits viewer and analyse. I think I came across an option to do that but failing to find it again. Can you point me to the setting please?
I would also like to create a script so I could step the focuser at a given step size and capture my own images. And run it both ways to check if I have any focuser or optical issues. Is this possible?
I may be missing something but I didn't find the simulator useful as it doesn't take an actual image so can't see how it can help. Struggling to find documentation on how to use the simulator.
Thanks.

Read More...