Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • satnogs-client satnogs-client
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 56
    • Issues 56
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 10
    • Merge requests 10
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • librespacefoundationlibrespacefoundation
  • SatNOGSSatNOGS
  • satnogs-clientsatnogs-client
  • Issues
  • #275
Closed
Open
Issue created Jun 25, 2017 by Vasilis Tsiligiannis@acinonyxOwner

Add more rotor information to avoid wrapping at max elevation and azimuth boundaries

Created by: oyvkar

Hi,

Over the last couple of days I have been tracking NOAA satellites with my ground station. I have come across an issue with wrapping during a track due to mechanical limits.

I am using a Yaesu G5500 rotor and controller, with the GS232B modem. I run this with "rotctld -m 603 -r /dev/ttyUSB0 -C post_write_delay=5000". Post write delay is needed due to the resolution of the rotor being 4 degree. If the delay is not added the rotor will jump violently, but that is another issue. The rotor controller is able to rotate through 0 to 450 degree in azimuth and 0 to 180 degree in elevation.

The problem is that when tracking statellites that cross the zenith angle, or cross the boundary between 0 degree and 360 degree (or vice versa), tracking is lost for some time due to the rotor having to turn around. Examples:

  • Around 650s in this observation
  • Around 650s in this observation
  • Around 600s in this observation

Consider the following cases: AOS 100 - Max elev 30 deg @ 40 az- LOS 340 The rotor will reach 0 degree, and then has to turn all the way around to 359, losing significant amounts of data.

AOS 160 - Max elev 85 deg - LOS 340 The rotor will move to the max elev point using an az position of approximately 160 deg. Once it crosses the 85 degree point the az position will be updated to 340 deg, causing the rotor to start turning. The rotor spends some time turning and will not catch up to the satellite in time, causing data to be lost. The solution here is to either allow the rotor to move over all 180 degrees, or start turning earlier than the crossing point at 85 deg.

By letting SatNOGS-client know more about the rotor in use, such as the Az and El limits, it can better utilize the hardware. For example if there's a known boundary collision at 0 degree, the rotor can be prepointed to 400 degree instead of 40 degree.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking