Hi,
Now that PLL provided drivers that solved the angle rotation issue (by adding reverse in the ascom settings for ARCO), I am facing the second issue with SGP.
During platesolve, tested with both astap and platesolve2, SGP doesn’t wait for ARCO to finish rotating, and goes ahead with taking a frame with rotating stars. The rotator does finish its rotation in the background. It ends up on the right angle, so the platesolve works if re-initiated. SGP logs available here.
Please let me know if I can provide any other information that might help.
I seem to recall that there might have been a driver issue that caused this? Maybe I’m wrong… but have you checked to ensure that your drivers are up to date? In any case, SGPro seems to be waiting until the rotator reports it is done before moving on.
Hello Ken,
The driver issue caused it to misread the absolute movement and not rotating correctly. It was rotating in the opposite direction. They solved this with the latest beta they provided it by adding reverse direction in the ascom driver.
This is a new issue. Or at least it wasn’t important last time. The behavior I am seeing is that SGP requests ARCO to rotate, ARCO starts rotating, SGP platesolve dialog window continue with step 3 (a couple of seconds at most) capturing a frame and doesn’t wait for ARCO to finish rotating. Is it visible from the logs that ARCO reports it finished rotating?
Only implicitly. But, you can enable ASCOM trace logs and correlate time stamps (we can assist). From these logs, you would be able to clearly see SGPro asking the rotator if it’s still moving and how the rotator responds to the query.
From the logs, we have this:
[06/30/22 20:47:56.318][DEBUG][Telescope Thread][CE;] ASCOM Rotator: Move is complete. Requested 134; arrived at 238.03
[06/30/22 20:47:56.319][DEBUG][Telescope Thread][CE;] Rotate complete...
Interestingly, you can see that when the rotator reported it was done 7 seconds later, it does not match the requested angle.
I already had the ASCOM log enabled (they have this in their ascom driver settings as well). Uploaded here. I will share them as well with PLL and if there’s something interesting you see, let me know and I will pass it to them.
It seems like there may be other issues here too, but this is the answer to the “SGPro is not waiting for the rotation problem”.
One example (there are several). The rotator starts moving at 20:47:49.829 for that movement request, it’s not clear exactly when it finished, but what we can see is that the rotator briefly reports it is done at 20:49:01.663, then afterward, without any new movement command begins reporting that it is not done moving.
Thanks Ken, PLL provided another beta firmware for testing where they found another bug. So far so good. I will test for another week under clear skies to confirm.
Hi Roger,
The beta was fine and all the fixes are included with the latest firmware and ascom driver publicly available on PLL website. So far I don’t have any issues.
ARCO wise all is default except in the ascom settings I choose reverse direction (click the settings icon in sgp next to it after connecting). As for the ESATTO, the default are fine but the step size needs to be increased a lot. 5000 or 6000 are OK for me.
I can share screenshots tomorrow if you want but the above covers the main changes.
