-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zenith Satellite Rotator Tracking #334
Comments
Can you please test the azimuth zenith using rotctl instead of rotctld/gpredict?
Try 10 degree increments and see how it behaves.
I show max azimuth on the SPID controllers is 540 degrees.
Mike W9MDB
On Tuesday, August 1, 2023 at 02:13:03 PM CDT, SMProgrammer ***@***.***> wrote:
I am using GPredict 2.3.37, hamlib 4.5.5, SPID MD01, rotctld, and a Big-Ras rotator, on a Windows 10 64 bit computer.
The commands sent to the rotator for near satellite passes near the zenith do not seem to be working properly. When a satellite passes near the zenith (an elevation angle of 90 degrees) with satellite tracking on and the rotator engaged, the rotator does a full 180 degrees azimuth turn instead of making the elevation angle go past 90 degrees. If the elevation angle was in the range of 90-180 degrees before the satellite, going through the zenith, the elevation angle sent to the rotator will stay above 90 degrees, and if the elevation angle was in the range of 0-90 degrees, the elevation angle will stay lower than 90 degrees. This full 180 degree azimuth turn takes time for the rotator to perform so the rotator does not track the satellite for a while. These high elevation angle passes are critical for communicating with a Cubesat so it is important that it is tracked consistently. I had the settings for the rotator having a maximum elevation angle of 180 degrees as shown in the image, but that did not make a difference. I can use GPredict to manually control the rotator and set it past 90 degrees in elevation, but GPredict does not use the full 180 degree elevation angle capability when tracking the satellite automatically.
https://github.com/csete/gpredict/assets/90346350/b66fc0c3-8218-46ee-ac08-1db61ec1d487
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Hi, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am using GPredict 2.3.37, hamlib 4.5.5, SPID MD01, rotctld, and a Big-Ras rotator, on a Windows 10 64 bit computer.
The commands sent to the rotator for near satellite passes near the zenith do not seem to be working properly. When a satellite passes near the zenith (an elevation angle of 90 degrees) with satellite tracking on and the rotator engaged, the rotator does a full 180 degrees azimuth turn instead of making the elevation angle go past 90 degrees. If the elevation angle was in the range of 90-180 degrees before the satellite, going through the zenith, the elevation angle sent to the rotator will stay above 90 degrees, and if the elevation angle was in the range of 0-90 degrees, the elevation angle will stay lower than 90 degrees. This full 180 degree azimuth turn takes time for the rotator to perform so the rotator does not track the satellite for a while. These high elevation angle passes are critical for communicating with a Cubesat so it is important that it is tracked consistently. I had the settings for the rotator having a maximum elevation angle of 180 degrees as shown in the image, but that did not make a difference. I can use GPredict to manually control the rotator and set it past 90 degrees in elevation, but GPredict does not use the full 180 degree elevation angle capability when tracking the satellite automatically.
Satellite.Zenith.Tracking.Problem.mp4
The text was updated successfully, but these errors were encountered: