I may have misunderstood but it is up to you to set your AVX to the start position and do some sort of align - a quick align will do.
EKOS has no way to know where the mount is pointing or how to move it to the start position.
It is possible to use the Celestron Hibernate/wake up process but that requires starting with some sort of alignment.
A Log showing the initial align process, the flip and the align process after the flip is absolutely essential. Also raw fits images taken after both aligns. Details of when the various processes happened would help.
Vague anecdotes and screenshots are, I think, worse than useless. Worse because they waste time, encourage speculation and are frustrating for the people who would like to help.
If you expect people to spend their time going through this and working out what is going on then spending a little time to help them do so seems reasonable.
As for the DSS images it looks as if no flip was done because a flip will rotate the image by 180 degrees - well unless DSS has rotated one of the images back. If the flip failed I would still expect that an alignment would be done, but who knows. We don't.
It's very difficult to debug this sort of communication problem without the developer having access to the hardware.
In this case none of the commands are returning any sort of response, this could be a hardware problem, such as the reply connection not being connected, or some problem with the commands being sent.
I get the impression that True Tech are gone, and there was never much support for this wheel.
One thing I wonder about is how the checksum is calculated, I would have expected that the sum of the first three bytes should be negated so that the sum of all 4 bytes including the checksum adds to a multiple of 256.
But without a close connection to the hardware it's probably not practical to try.
Something I heard of at work was that people were analysing the waste from gold mines to see how much residual gold was left and if it was worth reprocessing it using more modern methods.
Lots of analyses were done, and some came up with negative amounts of gold. You can't have less than nothing so they were set to zero and the results averaged - and there was enough gold to be worth processing. I'm not sure how much waste they got through before they discovered the error of their ways.
It looks as if this is just the same, one side of the distribution is being clipped and that will inevitably affect the average value.
It's a feature of the way that Celestron have implemented their slewing. When the mount does the slow final approach slew it moves to the axis position that the object was at when the slew command was sent. The slew takes several seconds so by the time the mount stops the object has moved on. This gives an error in Ra of 15 arc seconds per second that the final slew takes so usually something between 30 and 75 arc seconds.
I've been trying to get them to fix this for years, it's quite easy, just estimate how long the final slew will take and adjust the target position to allow for this.
I've been hoping they would fix this but it looks as if the only way will be to fix it in the driver - adjust the target position by the difference between the target position and where the mount stops. I've already done it for the ASCOM driver and will do it for the INDI one as well. I'm in lockdown at the moment so will get suficiently bored to do this fairly soon.
In the meantime the best thing is to relax the position tolerance, 60 or 70 arc seconds should be OK.
DerPit wrote: With 50+ stars you might as well do a winzorized sigma clipping. Or maybe even linear clipping. For only one 'pixel' the computational overhead is not noticeable.
What benefit does this have, other than be more complex?
From a look at the code the HFR array is already sorted so getting the median is easy.
ChrisRowland wrote: Some focus problems are caused by outliers - hot pixels and extended sources such as galaxies. Would these be more effectively removed by changing the full field HFR determination to use the median rather than the average HFR value. This will cause extreme values to be ignored quite naturally.
Or even better discard the 5% smallest and biggest outliers and take the mean of the remaining detections.
Better? Why? How does an arbitrary change to the data make it better?
In actual fact the current code has an undocumented feature where the full set of HFRs is averaged, the standard deviation is determined, values that are more than two standard deviations from the original mean are removed and a new 'average' is determined.
This is statistically dubious, not only does this reduce the mean but the amount by which it is reduced will depend on the data. Maybe extended objects will be included sometimes but not in others.
The median is at least a valid way to determine a central value.
Some focus problems are caused by outliers - hot pixels and extended sources such as galaxies. Would these be more effectively removed by changing the full field HFR determination to use the median rather than the average HFR value. This will cause extreme values to be ignored quite naturally.
I'm not doing this and don't have that camera so can't help. Sorry.
Are you using the Moonlite motor? That is unipolar while most stepper controllers are bipolar. Bipolar motors have 4 wires while unipolar motors have 5 or 6 wires. If you have a non Moonlite motor then this may be irelevant.
Don't see why not, my Quantum wheel rotates to the filter 1 position when power is applied.
The protocol seems to be here:
The reset and wheel type identification code seems to return the number of filter positions.