Ok, I will try the target name or observer name (if set) or some default, just to prevent the underscore from being there.
Sorry, hadn't spotted the guiding logs (or maybe saw them and then got sidetracked before I had dealt with them). From the look of them all there are big movements (about 300 pixels per step) of the target in response to the initial nudges, so you could try turning down the initial step size from 0.3 to 0.1 or less to see if that helps. The other possibility is that the big movements are actually coming from backlash compensation, since SharpCap now starts the calibration in RA -ve rather than RA +ve, so the initial steps will be counter to the normal tracking direction. If turning down the initial step size doesn't help then it may be the backlash thing.
cheers,
Robin
4.1 bugs
Re: 4.1 bugs
Are these settings interacting with the mount motor speed as set on the hand controller? If the motor speed is 5 vs 7 do you have to have all different settings in SharpCap? If so, that is extremely confusing.
-
admin
- Site Admin
- Posts: 13350
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: 4.1 bugs
Hi,
no, the speed picked by SharpCap should be unconnected to the handset configuration (at least that's the way ASCOM drivers are supposed to work - SharpCap says move the mount at 0.25 degrees per second, and that's what should happen... in theory).
cheers,
Robin
no, the speed picked by SharpCap should be unconnected to the handset configuration (at least that's the way ASCOM drivers are supposed to work - SharpCap says move the mount at 0.25 degrees per second, and that's what should happen... in theory).
cheers,
Robin
Re: 4.1 bugs
And how do you know what those speeds are then? The interface only lists available movement speeds as multiples of some unknown speed or guide speed, whatever that may be.
Re: 4.1 bugs
Also, the scales on the graphs seemed to be fixed instead of adjusting to the selected minimum movement. So if it is greater than 60 pixels, you can’t see what is going on.
What has changed about the FT code that suddenly the initial step needs to be 0.1 instead of the previously recommended 0.3?
Previously, in 4.0, FT would occasionally randomly succeed. Then the calibration stopped moving the image at all, and now the image cruises right off the (fairly large) sensor of the 678 completely.
What has changed about the FT code that suddenly the initial step needs to be 0.1 instead of the previously recommended 0.3?
Previously, in 4.0, FT would occasionally randomly succeed. Then the calibration stopped moving the image at all, and now the image cruises right off the (fairly large) sensor of the 678 completely.
-
admin
- Site Admin
- Posts: 13350
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: 4.1 bugs
Hi,
SharpCap shows the movement speeds in two formats
1) Multiples of sidereal (ie 1x, 2x, 4x)
2) Degrees per second
In the case of feature tracking, it will almost always be the former that is shown. The ASCOM mount driver lists the various movement speeds it supports (which can be distinct speeds or ranges of speeds). SharpCap chooses a selected range of speeds to show from those available that should cover most requirements. There is not necessarily any mapping between handset movement speeds and the speeds that can be set up via the ASCOM driver.
As to what has changed... I came to the conclusion that the cause of most of the failures was that after calibrating the RA axis (positive then negative), the Dec calibration was starting while the RA axis was still taking up backlash caused by the RA negative calibration. That meant that the measurements for Dec calibration would be badly out.
It seemed as though an elegant solution to this problem would be to swap the order of RA calibration so as to calibrate in the -ve RA direction first, followed by +ve RA, then followed by DEC calibration. This would mean that when Dec calibration began, there would be no backlash take up to happen, since the most recent movements would have been in the +RA direction.
I think the change in behaviour is probably related to this change. My suspicion is that the movements in the -ve RA direction are triggering some sort of backlash compensation in your mount that may be overdoing things. I know that some mounts (Celestron ones for sure) can make some fairly substantial anti-backlash adjustments when changing movement direction). It would be useful to know if you see any sign of that happening at the start of calibration, and also to see results of an attempted calibration that gets past the first -ve direction onto RA +ve to see if the step size seen in the +ve direction matches the -ve.
cheers,
Robin
SharpCap shows the movement speeds in two formats
1) Multiples of sidereal (ie 1x, 2x, 4x)
2) Degrees per second
In the case of feature tracking, it will almost always be the former that is shown. The ASCOM mount driver lists the various movement speeds it supports (which can be distinct speeds or ranges of speeds). SharpCap chooses a selected range of speeds to show from those available that should cover most requirements. There is not necessarily any mapping between handset movement speeds and the speeds that can be set up via the ASCOM driver.
As to what has changed... I came to the conclusion that the cause of most of the failures was that after calibrating the RA axis (positive then negative), the Dec calibration was starting while the RA axis was still taking up backlash caused by the RA negative calibration. That meant that the measurements for Dec calibration would be badly out.
It seemed as though an elegant solution to this problem would be to swap the order of RA calibration so as to calibrate in the -ve RA direction first, followed by +ve RA, then followed by DEC calibration. This would mean that when Dec calibration began, there would be no backlash take up to happen, since the most recent movements would have been in the +RA direction.
I think the change in behaviour is probably related to this change. My suspicion is that the movements in the -ve RA direction are triggering some sort of backlash compensation in your mount that may be overdoing things. I know that some mounts (Celestron ones for sure) can make some fairly substantial anti-backlash adjustments when changing movement direction). It would be useful to know if you see any sign of that happening at the start of calibration, and also to see results of an attempted calibration that gets past the first -ve direction onto RA +ve to see if the step size seen in the +ve direction matches the -ve.
cheers,
Robin
Re: 4.1 bugs
I don’t ever recall seeing the planet still moving it RA when DEC calibration began. But maybe I am misunderstanding.
But if I can ever get a calibration to run that doesn’t immediately take the planet right off the chip I’ll let you know.
But if I can ever get a calibration to run that doesn’t immediately take the planet right off the chip I’ll let you know.
-
admin
- Site Admin
- Posts: 13350
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: 4.1 bugs
Hi,
I am going to try changing the order again... New plan
Dec+
Dec-
RA+
RA-
That way the declination calibration happens first and there is no real chance of any dec drift after that is complete affecting the RA. Also the RA is put back in the original order of + then - that appeared to work better
cheers,
Robin
I am going to try changing the order again... New plan
Dec+
Dec-
RA+
RA-
That way the declination calibration happens first and there is no real chance of any dec drift after that is complete affecting the RA. Also the RA is put back in the original order of + then - that appeared to work better
cheers,
Robin
Re: 4.1 bugs
Hi Robin,
Thanks for continuing to work on this.
Last night I downloaded the latest beta 4.1, polar aligned to "Excellent" level, used the entire FOV of the ASI678MC, set the minimum movement to the maximum (250 pixels), set the initial step size to 0.1, and SharpCap failed due to inconsistent angles from axis 0 because 48.3 is apparently not close enough to 48.5. Here's the full video of the test:
https://youtu.be/PCuEB9h04mU
After this, I switched the initial step size to 0.2 and tried again. It ran through the DEC calibration, which looked more or less the same to me, and immediately failed due to inconsistent angles from axis 1, which it claimed were different by about a factor of 3, something like 45 vs. 135. I didn't record this test but it will be in the guide log hopefully:
I also discovered what appears to be a large bug in the autofocus routine that may explain some of the previous bizarre results I've occasionally seen. In the Fourier Detail method, with the focus box larger than the planet (which seemed to work the best), if the focus box size is changed, the focus score changes. This should not happen, because everything excluded by the black level should not be included in the calculation.
Here is a recording of an example:
https://youtu.be/Yweg5xsMiHg
It's worse than this. If the focus box becomes too large (but not crazy large; still less than 1 diameter away from the planet) the focus score becomes completely unreliable, in fact pretty much inverted. Unfortunately I did not record an example of that, but it was definitely happening; maybe the data you need is in the log. It's the attempted Autofocus that ends here:
Info 18:44:51.861156 #1 Focus scan complete/cancelled - no best fit
After that I changed the focus box size on a hunch and noticed that changing the box size changed the score. I made the box tighter around the planet, re-ran the focus, which worked perfectly, and then recorded the video linked above.
Thanks for continuing to work on this.
Last night I downloaded the latest beta 4.1, polar aligned to "Excellent" level, used the entire FOV of the ASI678MC, set the minimum movement to the maximum (250 pixels), set the initial step size to 0.1, and SharpCap failed due to inconsistent angles from axis 0 because 48.3 is apparently not close enough to 48.5. Here's the full video of the test:
https://youtu.be/PCuEB9h04mU
After this, I switched the initial step size to 0.2 and tried again. It ran through the DEC calibration, which looked more or less the same to me, and immediately failed due to inconsistent angles from axis 1, which it claimed were different by about a factor of 3, something like 45 vs. 135. I didn't record this test but it will be in the guide log hopefully:
I also discovered what appears to be a large bug in the autofocus routine that may explain some of the previous bizarre results I've occasionally seen. In the Fourier Detail method, with the focus box larger than the planet (which seemed to work the best), if the focus box size is changed, the focus score changes. This should not happen, because everything excluded by the black level should not be included in the calculation.
Here is a recording of an example:
https://youtu.be/Yweg5xsMiHg
It's worse than this. If the focus box becomes too large (but not crazy large; still less than 1 diameter away from the planet) the focus score becomes completely unreliable, in fact pretty much inverted. Unfortunately I did not record an example of that, but it was definitely happening; maybe the data you need is in the log. It's the attempted Autofocus that ends here:
Info 18:44:51.861156 #1 Focus scan complete/cancelled - no best fit
After that I changed the focus box size on a hunch and noticed that changing the box size changed the score. I made the box tighter around the planet, re-ran the focus, which worked perfectly, and then recorded the video linked above.
-
admin
- Site Admin
- Posts: 13350
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: 4.1 bugs
Hi,
Thanks for testing once again.
The feature tracking calibration one is interesting... The problem isn't that 48.5 is too different from 48.3, the problem is that the angle for the fourth measurement should be something like -132 (180 degrees away from 48), but it seems that the target is still moving in the same direction as for RA positive when SharpCap is sending commands for RA -ve movement. That is weird. I don't think it is the wrong commands being sent to the mount ASCOM driver, since I test using the same Celestron driver (I have an SE8 mount sitting on my desk for this sort of testing) and it moves in the correct directions during the four phases of calibration. Maybe it is something weird about the Celestron driver in RA/Dec mode rather than AltAz? Perhaps it is a mechanical thing? It definitely is weird that the movement continues in the same direction when it should reverse.
End of the X Positive calibration (RA+)
Note that the ImageOffset X and Y are both increasing
End of the X Negative calibration (RA-)
Note that the image offset X and Y are *still* increasing....
It is worth watching the 'Scatter' graph during calibration - this should show the positions of the points as the movement happens and for a successful calibration you should get 4 lines with roughly 90 degrees between them, like the one shown here : https://docs.sharpcap.co.uk/4.0/#Calibration . If you get the two lines for opposite directions in RA (or DEC) not pointing at 180 degrees then something bad is going on.
Ok, focus scores...
What you are seeing with the fourier detection is just how that algorithm works. The algorithm takes a selection of vertical and horizontal slices through the selected area and calculates the average amount of high frequency variation in the data of those slices. The number of slices is fixed, so if you make the box bigger to include more blank space, there will be more slices outside the planet (which pick up basically zero variation), meaning that the value drops.
I don't think there is an easy way around this - doing a fourier analysis of all rows/columns was too slow, and you have to take sample slices whose length is a power of 2 to enable the FFT algorithm to be used, which means either truncating or padding each slice, so it will naturally be sensitive to the size of the selected area.
I think that just means that best practice is to make sure as much of the selection box as possible is 'target' rather than black space to ensure that the value being generated is coming from the image of the target, not black level noise in the surrounding area or being watered down by the zero values used then the pixel value is below the black threshold.
cheers,
Robin
Thanks for testing once again.
The feature tracking calibration one is interesting... The problem isn't that 48.5 is too different from 48.3, the problem is that the angle for the fourth measurement should be something like -132 (180 degrees away from 48), but it seems that the target is still moving in the same direction as for RA positive when SharpCap is sending commands for RA -ve movement. That is weird. I don't think it is the wrong commands being sent to the mount ASCOM driver, since I test using the same Celestron driver (I have an SE8 mount sitting on my desk for this sort of testing) and it moves in the correct directions during the four phases of calibration. Maybe it is something weird about the Celestron driver in RA/Dec mode rather than AltAz? Perhaps it is a mechanical thing? It definitely is weird that the movement continues in the same direction when it should reverse.
End of the X Positive calibration (RA+)
Code: Select all
2022-12-28 18:28:53,097 [Image Process Thread] INFO tracking - Calibration frame : MountOffset={X=3.3000007, Y=-4.4000006}, ImageOffset={X=80.43005, Y=123.56995}
2022-12-28 18:28:53,098 [Image Process Thread] INFO tracking - Nudging mount 0.20000002 in direction XPositive
2022-12-28 18:28:56,577 [Image Process Thread] INFO tracking - Calibration frame : MountOffset={X=3.5000007, Y=-4.4000006}, ImageOffset={X=92.22998, Y=141.31006}
End of the X Negative calibration (RA-)
Code: Select all
2022-12-28 18:29:34,237 [Image Process Thread] INFO tracking - Calibration frame : MountOffset={X=2.9000013, Y=-4.4000006}, ImageOffset={X=302.84998, Y=383.69006}
2022-12-28 18:29:34,237 [Image Process Thread] INFO tracking - Nudging mount 0.050000004 in direction XNegative
2022-12-28 18:29:37,703 [Image Process Thread] INFO tracking - Calibration frame : MountOffset={X=2.8500013, Y=-4.4000006}, ImageOffset={X=326.62, Y=411.21997}
It is worth watching the 'Scatter' graph during calibration - this should show the positions of the points as the movement happens and for a successful calibration you should get 4 lines with roughly 90 degrees between them, like the one shown here : https://docs.sharpcap.co.uk/4.0/#Calibration . If you get the two lines for opposite directions in RA (or DEC) not pointing at 180 degrees then something bad is going on.
Ok, focus scores...
What you are seeing with the fourier detection is just how that algorithm works. The algorithm takes a selection of vertical and horizontal slices through the selected area and calculates the average amount of high frequency variation in the data of those slices. The number of slices is fixed, so if you make the box bigger to include more blank space, there will be more slices outside the planet (which pick up basically zero variation), meaning that the value drops.
I don't think there is an easy way around this - doing a fourier analysis of all rows/columns was too slow, and you have to take sample slices whose length is a power of 2 to enable the FFT algorithm to be used, which means either truncating or padding each slice, so it will naturally be sensitive to the size of the selected area.
I think that just means that best practice is to make sure as much of the selection box as possible is 'target' rather than black space to ensure that the value being generated is coming from the image of the target, not black level noise in the surrounding area or being watered down by the zero values used then the pixel value is below the black threshold.
cheers,
Robin