Using the Falcon rotator, SGP is not able to rotate to final target angle.
I created a new target sh-112 in F&M; it defaulted to 72deg which looked ok and I crated the sequence.
On the first attempt, the camera was off by 5.5 deg; it moved, off by more; rotator moved, off by even more, until eventually, the centering would fail after 5 attempts.
I initially was using ASTAP for plate solving as I learned that it crazy fast - and it is; but on the next attempt I reverted to PlatSolve2. After it failed, I re-homed the rotator and tried again.
The falcon app is v1.4 and the falcon ascom driver is 1.3.
It seem as if somebody has a sign wrong on the processing. PHD2 had an issue when I first installed the falcon, but once I enabled the āreverse sign of angleā option that resolved it.
I will inform the PA devs too, but wanted to log the info here first.
Aprox time of issue: 10pm
Link to Logs
Useful Info
OS: Microsoft Windows 10 Pro Ver: 3.1.0.539 .NET: 4.8
Another attempt. It moved to 189.7 (via Falcon app) deg, and then never moved again. SGP kept on asking it to move as it was off 3.4 deg. I aborted it after 3 attempts.
A friend of mine has this and he is also struggling, apparently a āreverse motorā firmware update is coming out next week from Pegasus. From what we saw in the logs the rotator kept going away further and further.
Looks like the direction of the rotation needs to be reversed as each new move request is making the error worse. Sounds like Pegasus is working on that for their driver/firmware.
Had this same issue. Made it a no-go for me for the night. Wondered if other software had the same issue. Tried TSX Pro. Worked without issue. Tried it with Voyager and it worked without issue. Tried it with NINA and it worked without issue. Not sure why the ASCOM driver for Falcon Rotator seems to turn the rotator the correct direction for them but not for SGP. Perhaps the āfixā that Pegasus is working on is a toggle that tells the rotator to reverse direction (not presently in their driver). If that is the case then it isnāt really a fix so much as a option made available that can be a work-around for SGP not turning it in the correct direction. Or is SGP turning it correctly and everybody else is backwards?
No one defines a direction to turn the rotator. All the ASCOM platform allows is the ability to specify the angle and itās up to the rotator on how to get there. So if youāre at 90 and you tell it to go to 45 and that has different results between applications then something is likely up inside of the application. Having said that, SGP does allow you to sync a rotator to a specific sky angle and will use that as an offset to get to different locations. This has been in for a while and is working with a multitude of other rotators though. So I would find it odd to not be working with the Pegasus rotator.
Also, no where does ASCOM specify a direction for a rotation. So if youāre at 0 and you ask the rotator to go to 45 it can go clockwise or counter clockwise and either of those are fine. Thus most Rotators provide the option to switch the direction so that everything lines up.
I understand what you mean but I did sync the rotator to a clock wise angle. I think it was 30 degrees. then homed it back to zero with the home button.
Then I set up my target which was set to 87 degrees and started the sequence. I had the same issue as the OP. It reported 87 degrees as a number but the plate solve results were wrong and so it failed. Then it moved the rotator towards zero (further away from 87 degrees) and of course failed again. Then moved further towards zero and ā¦ you see how this is going. When I tested it with TSX Pro it is the same driver with the same calibration. When I rotated the field of view indicator and it asked me if I wanted to rotate the rotator to match and I said yes, a plate solve (image link) verified it was correct. I tested it with a few different position angles and each image link reported it correctly. And as I said I then went into two other pieces of software that can use the rotator and both of them, with no special setup needed on my part, were able to rotate the image correctly the first time which was verified both by the position angle of the rotator software, the position angle reported by the software used and a plate solve with the same matching position angle. I find that curious. I also donāt want to spend a lot of time fighting with SGP + Falcon getting them to be nice to each other. Iāll check back at a later date.
I have previously developed my own DIY rotator including ascom server and underlying driver and didnāt do anything with the angle really. Hereās my relevant code:
bool DoMove(float posInDeg)
{
//0 deg is the MaxSteps /2 midpoint
//never pass through 180 deg point to 179 and never 180 to 181
// to get to 179 from 180, we'll reverse the dir to get there
//0-360 CCW
var zeroPt = _maxSteps / 2;
var steps = StepSize * posInDeg;
long stepPos = 0;
if (posInDeg > 180) //181-359
{
stepPos = (long)(steps + 0.5);
}
else //0-180
{
stepPos = zeroPt + (long)(steps +0.5);
}
...
}
Seems as if PA is doing something weird. Again, I had to enable an option in PHD2 as well to get it top play nice with the Falcon. So this is a PA falcon issue.
Nothing much to add except that I have the same problem. Using a āmanual rotatorā and then following SGPās directions and then using the Pegasus app to move the Falcon everything works fine. For example, a test:
plate solve and then set the results as the current target (so that the rotation of the target is set to the current rotation).
use the Pegasus app to move the rotator off by 10 degrees CCW.
start the sequence with slew & center, SGP correctly tells me to manually rotate by ~10 degrees CW.
use the pegasus app to move the rotator 10 degrees CW.
SGP finds itās on target, rotation error typically 0.2-0.3 degrees. Happy days.
Do the same exercise, except with SGP set to use the ASCOM driver for the Falcon instead of the manual rotator and after SGP tries the first correction itās off by 20 degrees, centering fails, repeat and itās off by 40 degrees, etc. etc.
Seeing what Jared said above about how SGP does rotation this has to be something in the Pegasus ASCOM driver?
This bit in the Falcon manual:
Rotator can move to any degree (with at least 1 decimal point accuracy ā current firmware) and automatically decide in which direction motor should be driven to precisely rotate your camera to designated degrees.
suggests the āautomatically decideā bit isnāt quite right
Issue resolved. I had to disable the āreverse angleā setting for PHD2 in āother devicesā tab and then re-cal but in the SGP/PHD2/Falcon setup is working just fine.
