The following website maybe of interest www.astrobin.com/forum/c/astrophotograph...-objective-analysis/
goes on about analysing tilt and back focus using astap
Yes there used to be various problems with the fits viewer but most of these seem to have been either fixed or my switching off sound notifications. I don’t actually see/notice a crash so maybe there’s some intermittent problem. I will turn off auto debayering in the fits setup just in case.
Astroberry is still at 32bit with the update to 64bit being worked on I believe. Silver lining of that cloud is I’m stuck pre-optical train on a reasonably stable build which my constant apt updating cannot mess up
I’ve got an sv305 camera (on my guide scope) and I’ve found using Astrodmx in its auto mode a good way of getting things exposing right as you try and focus.
One thing I’ve found which feels counter intuitive but makes sense is that you can easily over expose things (not entirely sure why this happens) and the fits viewer shows what seems to be a blank screen. In the fits viewer try seeing what the stats say - you shouldn’t have a medium value at 16384 ie the same as the maximum.
With my f/7 210mm focal length guide scope I use exposures of 1 or 2 seconds and a gain setting of 300 to 400 (this is in the indi driver) and I turn the stretch to 16 bits in the indi driver off. Everything else is at the default. I also find phd2 a bit easier than ekos for getting things in focus and as I’m doing guiding with that having had a fallout with the internal guiding I’ve got that running anyway.
found the following warning in the logs while looking into problems.
Not sure if it actually did ignore the image in the focusing routine as I seemed to have the auto focusing routine running fine. Imaging has been running fine. Anyone know what this is about?
This is on astroberry.
I’ve had a number of crashes while focusing (might be due to problems identified elsewhere) so was looking in the logs and saw this weird error message L-
Not sure why it’s complaining about lack of memory while saying it’s got plenty. I’ve not actually noticed any problem but then I wouldn’t have been watching the fits viewer that closely.
This is on astroberry so not the latest release others are playing with as it’s stuck on 32bit currently. This is on a 4gb Pi with kstars/ekos/indi/phd2/fits viewer running. Doesn’t appear to run low on memory nor cpu.
Wondering if anyone else had run into this and whether it’s actually a problem?
Have now been trying different SEP settings and have altered ‘min cont.’ to 0.1 from 0.005 that’s in the default setup. This seems to make the algorithm pick out the donuts better. More testing obviously needed.
ok this is just an idea based on a theory based on reading various websites… so may be completely stupid….
In the C6 manual when it goes on about how to focus, it says to go counter clockwise as the last step (ie lifting the mirror). Then when you have got your target in sharp focus (I’m sort of assuming the target is in the middle here as I’ve not got the manual to hand) to give it an extra turn of 1/12th of a turn for visual use and 1/24th of a turn for photographic use.
What I believe the idea is, is that given the sensor is a flat plane but the image focus point is in a curve with the edges further ‘in’ , that moving it a bit further moves the central part towards the back of the cfz and in doing so brings more of the edge into it.
For my setup C6 with a Celestron focuser we are on about approx 30 microns or 40 steps. This sort of matches somethings I’ve read (specifically the article from sky and telescope in 2010 by Don Goldman and Barry Megdal - In perfect focus - link astrodonimaging.com/tutorials/ ) the cfz for an f/10 is around 40 micron and f/7 around 20 micron in one direction (so I assume 40 and 40 wide).
So once in focus on the target in the middle of the image a step out of 40 would bring more into the cfz.
Possibly this is a bit of a old idea and that doing the focusing using the whole or large part of the frame makes it irrelevant.
CFZ - don’t suppose you are working on some way of putting the central focus area towards the back of the cfz so those who either don’t have flatteners or whose flatteners don’t quite work have more of their image in the cfz? Or is that a daft thing?
How are you working out the cfz? I’ve seen different ideas for working this out which for my setup seem to range from over 150 microns down to 20.
What is this overscan thing? Is it just backlash compensation implemented in the lp1 algorithm? Wouldn’t that be the same as breaking the link between the current backlash entry and any driver backlash? What about the other algorithms? Isn’t there a way to implement backlash compensation somewhere between the algorithms and driver? If that was done all focusers would have bc even if their indi driver didn’t implement any and it would work for all algorithms. People whose focuser drivers had a more sophisticated/specific bc setup could use that and switch off this one.
Let’s split things down a bit.
1. You have the algorithms - they take a set of data and work out where the optimal focus point is. The data could be a set of images plus focuser position or something like the current temperature and some preprocessed info for it to work out where the focus point is.
2. Backlash - this occurs afaik on change of direction of the focuser mechanism. Simplest solution appears to be to overshoot by some amount greater than the max backlash then move to the real position. It doesn’t really matter if the backlash varies each time or in either direction as long as the overshoot is greater. (I’ve no idea why NINA looks to have settings for both - this could just be the gui misleading me and only one is actually used).
3. Final move direction - in the case of sct’s with a focuser moving the mirror final the move direction needs to be against gravity. This move would also need to apply backlash compensation if it was a change of direction.
Current setup seems to not be quite right as it different parts seem to try and solve problems of other parts. I think the link between the backlash setting in the main gui needs splitting off from the focuser indi driver. Then the backlash compensation done independently of the algorithms and drivers if wanted by the user. The algorithms shouldn’t have anything to do with backlash. The indi driver could implement some focuser specific compensation if needed. The final move direction I think would be in the driver and would be active on every move that’s not in the ideal direction. This would shield the algorithms from bad positions without them having to know about it.
ok the relevant code looks to be :-
// implement backlash
int delta = targetTicks - FocusAbsPosN.value;
if ((FocusBacklashN.value < 0 && delta > 0) ||
(FocusBacklashN.value > 0 && delta < 0))
backlashMove = true;
finalPosition = position;
position -= FocusBacklashN.value;
so the answer looks to be yes. If it’s moving inwards - delta <0 and focusBacklash is positive then it will subtract the backlash ie move further inwards, then later in another bit of code move outwards to the final position. This occurs for both absolute and relative moves. Doesn’t seem to worry about whether this is a change of direction or not which in this case is for the good.No idea why it would want to have backlash compensation in the other direction but the code seems to allow that.
Looks like I was misunderstanding NINA.
The relevant page is nighttime-imaging.eu/docs/master/site/advanced/autofocus/
They have two types of compensation.
1.Absolute where it adds on a set of steps at a change of direction - looks to require knowing quite accurately your backlash. Not sure if this can have different numbers of steps for in and out as it doesn’t say but the gui having both seems to point to a possibility.
2. Overshoot which moves past the point then back to it. This has either in or out steps set but only one. This is so the focuser always completes its movement in one direction.
There’s a tip later in the manual - “ Overshoot can be very useful for SCT users to avoid mirror flop. In fact, when setting the Backlash Compensation to IN, the last focuser movement will always be outwards.”. Looks like NINA uses this rather than a switch like I was suggesting. I suppose the extra back and forthing is of little consequence just doesn’t seem tidy to me.
Now time for me to check whether the Celestron sct does the backlash compensation wiggle each move or not..
My two pence worth…
surely it would be better to split off the backlash settings from the actual focusing algorithms given they are more to do with the focuser mechanics than how you work out how to do a curve to determine the best focal point?
Also looking at NINA that seems to have an idea of both in and out backlash compensation. Not sure whether you use both or just one. Which also brings me to in/out direction and sct’s, I’ve yet to try this out at night, but it looks like working in the in direction drops the mirror when really want it to be raising it. Maybe a switch would be of use for that, again maybe as part of the focuser mechanics.