Nightly 71: Wrong slew - center calculations. Target has an 3 arcmin offset
Hello,
I am executing the same sequence for the third consecutive night. # 69, # 70 ran flawless. # 71 has an issue and misses the target repeatingly when “slew” and “center” by approx. 3 arcmin. It permanently slew to an offset. It looks like offset is falsely calculated.
Maybe related to the latest commits concerning the calculations for distance and the new trigger?
Cheers
Rüdiger
Where do I find the the older versions for downgrade?
Comments (13)
-
reporter -
reporter - edited description
-
repo owner Thank you for the logs.
The relevant extract:
2021-04-26T21:23:08.5543|INFO|CenteringSolver.cs|Center|61|Centering Solver - Scope Position: RA: 13:58:37; Dec: 37° 29' 22"; Epoch: J2000; Centering Coordinates: RA: 13:58:37; Dec: 37° 25' 42"; Epoch: J2000; Solve Result: RA: 13:58:38; Dec: 37° 29' 24"; Epoch: J2000; Separation RA: -00:00:01; Dec: -00° 00' 01"; Distance: 0.00386366715005472; Bearing: -84.4367132475873
It looks like the telescope did not slew to the correct initial coordinates, or at least reports these incorrectly and the Parameter Coordinates are missing from the distance calculation. It’s nothing that recently changed, however it might be responsible for some hickups that were reported but could not be identified. I will investigate this further tomorrow.
-
reporter Hi Stefan,
I had re-run the sequence multiple times. Always same error. Without the center it works, with command it fails. Also with old version before it was fine.
Definitely no hick-up. Also the mount slews perfectly to the target when done manually or with pad. Also the mount’s hardware encoders report perfect and precise slew.
Must be something else.
PS: I will restart every thing and repeat the test and post log. So we can definitely exclude hick-up.
-
repo owner Just from commit perspective the only change from build 70 to 71 was a bugfix inside the CenterAfterDriftTrigger. The Center Instruction was not touched. So it looks like this is a bug that was looming inside for a longer period of time, but can only be reproduced under certain, yet unknown, circumstances
-
reporter - attached 20210426-222104-1.11.0.1072.6012.log
-
reporter Hi Stefan,
I have re-ran the sequence after a NINA restart and then it worked. For times it was working (see log above). I had only restarted NINA, rest kept running (PHD, mount, …). Now the position is correct and the the encoders report also correct positions. I do not know what went wrong internally with NINA. Hence I will close the issue and monitor the center command.
Please see now the position: Now it is correct nothing changed. That is completely strange. Never observed such an behavior before.
-
reporter - changed status to on hold
Monitor problem -> Update for 73
-
repo owner In Nightly 74 I have adjusted the Center logic slightly, so this scenario should not be possible anymore
-
reporter Hi Stefan,
great! I had seen the commit and installed # 74. I will observe it, but bad weather is forecasted for the next few days.
Shall we keep the issue on hold or close it and reopen it in case it reoccurs?Cheers
Rüdiger
-
repo owner I would propose to close the issue and if the problem persists we can just re-open it again.
-
reporter - changed status to closed
fixed with # 74. If problem reoccurs issue will be reopened. Thank you!
Cheers Rüdiger
-
repo owner - removed version
Removing version: 1.11 Nightly (automated comment)
- Log in to comment
This is the result if I kick out the center command. The target is precisely hit. That proves that the distance is not correctly calculated.