Feature Request: Support for Azimuth Range Selection (0-360° vs. -180 to 180°)

[JF9SOM]

1. Background / Current Problem

Currently, the Ground-station rotator control logic appears to be fixed on a 0° to 360° azimuth range. While this works for many passes, it causes a significant issue when a satellite crosses the True North (0°/360°) line.

• The "Unwind" Phenomenon: When the satellite's azimuth changes from 359° to 1°, the software commands the rotator to rotate nearly 358 degrees in the opposite direction to reach the new position.
• Risks:
  • Loss of Signal (LoS): The tracking is interrupted during the long rotation.
  • Hardware Stress: Unnecessary wear on the gears and motors.
  • Cable Wrap: Risk of cable tension or disconnection if the rotation isn't managed correctly.

2. Proposed Feature

I would like to request an option in the Rotator Settings to toggle between two azimuth coordinate systems, similar to the functionality found in GPredict.

Option A: 0° to 360° (Center South)

• Range: 0° (North) -> 180° (South) -> 360° (North)
• Flip/Unwind point: True North (0°).
• Best for: Satellites passing mostly through the Southern sky.

Option B: -180° to 180° (Center North)

• Range: -180° (South) -> 0° (North) -> +180° (South)
• Flip/Unwind point: True South (180°).
• Best for: Satellites passing through the Northern sky (avoids unwinding at the 0° mark).

3. Suggested Implementation

In the Web UI's Rotator configuration, add a dropdown or toggle:

• Azimuth Range: [0 to 360] / [-180 to 180]

When -180 to 180 is selected, the backend logic should translate any target azimuth > 180 into a negative value (e.g., 270° becomes -90°) before sending the command to rotctld (Hamlib), provided the hardware/backend supports negative azimuth values.

4. Why this matters

For amateur radio satellite operators using Alt-Az mounts (like the Sky-Watcher AZ-GTi), the ability to choose the "flip point" is essential for continuous tracking and cable safety. Most modern tracking software includes this as a standard feature.

[sgoudelis]

Please test out 0.2.16 now in the releases page, it should work as you suggested, report any issues

[JF9SOM]

Thank you for your quick response. I noted your changes. I will test it later and report to you if necessary.

[damianross]

Small addition to this. As the same satellite can cross either the north line or the south line. The rotator should be able to cross both otherwise one pass might be fully tacked while another isn't. Perhaps the range could be expanded to 0° to 450° and/or -225° to 225°. This would still limit excesive rotations but would be a more "universal" setting which is needed for the automated tracking.
Another option would be ground station to "automatically select" between the 2 existing modes based on the path the satelite is taking, though that is more complex.

[RikyUnreal]

Adding a real-world case for the Yaesu G-5500 (450° azimuth with overlap)

The G-5500 (the classic satellite Az/El rotator) azimuth has a 450° travel range: full CCW = 0° (North), then it rotates all the way through 360° and continues another 90° of overlap, so full CW ends at what the compass reads as 90° (but is physically 450° of travel).
My interface is a K3NG controller in GS-232B emulation, exposed to Ground Station through rotctld (Hamlib).

What I observed driving the rotator from the Ground Station UI:

Going CW from ~180°, the rotator moved correctly: 200° > 250° > 360° > and continued into the overlap zone up to 90° (full CW hard stop). So the full 450° of physical travel works fine.
Going back CCW, the rotator stopped at 360° and refused to continue, as if it had hit the end stop, when in reality there was still a full turn of physical travel left to get back to 0°.

Root cause looks like azimuth ambiguity being collapsed into a plain 0 to 360° representation somewhere in the GS to rotctld path. In the overlap zone, two physically distinct rotator positions map to the same compass bearing (e.g. "90° first turn" vs "90° overlap / 450°"). The K3NG firmware tracks this internally with an extended raw azimuth (0 to 450°), but if the position is exchanged as a plain 0 to 360° value between Ground Station and rotctld, the "which turn am I on" information is lost, so on the way back the logic treats 360° as the end stop.

Suggested direction: an optional per rotator setting for extended azimuth range / overlap handling (e.g. a configurable max azimuth of 450° plus awareness of the overlap zone), so slow 450° rotators like the G-5500 can use their full travel in both directions without the range being truncated at 360°.

In addition to this (but a bit off topic), the G-5500 elevation has a 0 to 180° range to better handle near zenith passes via "flip mode" (flipping the antenna past 90° instead of doing a fast 180° azimuth slew at culmination). It would be great if GS could support this as well, though I haven't tested elevation on my setup yet.

Setup: Yaesu G-5500 + K3NG (GS-232B emulation) exposed via rotctld (Hamlib).
73, Riky (IU4APB)

[sgoudelis]

I have a G-5500 and I am using the S.A.T. rotator controller, which has some extended travel options, I will look into this and update this thread.

[sgoudelis]

Try out version 0.7.16, in the rotators definition you can set the type to "0 - 450" mode, try that mode. I tested this with a few passes and it worked for me with G-550 and S.A.T. controller.

Regarding this issue and others you mentioned, I see 3 issues here:

1. 0 to 450 travel overlap issue.
2. the azimuth ambiguity issue
3. the elevation flip

the version 0.7.16 I released is mainly about 0 - 450 travel overlap, try this out and tell me if it works for you

[RikyUnreal]

Thanks @sgoudelis, that was fast. I updated to 0.7.16 and set the rotator's Azimuth Range to "0 - 450".
The overlap issue is fixed!

The rotator now correctly reaches the 360–450° band instead of restarting the count from 0 (which also removes the ambiguity).
In the screenshot you can see it sitting at AZ 412°, and commanding it back down to ~300° no longer makes it stop/reset at 0° like before.
I also tested live tracking with a satellite crossing the North (rise 280° → 332° → set 25°) and everything works smoothly.

Much appreciated! 73

My setup for reference: Yaesu G-5500 driven by an Arduino K3NG controller (GS-232B emulation) over Hamlib rotctld.

[RikyUnreal]

A little update (and I'm not sure if it's possible to fix this, or maybe I'm doing something wrong).

Suppose we have a north-crossing satellite passing from NE to West, with the rotator currently holding in a near NE position.

I noticed that when tracking begins, the rotator goes directly to the NE position without taking the "overlap feature" into account (Fig. 1).

Because of this, after tracking the satellite counter-clockwise and reaching the zero-limit, the rotator has to do a full 360-degree clockwise rotation just to continue tracking.

It would be much better if, during these specific passes, the rotator automatically pre-positioned itself in the overlap zone (Fig. 2).

This would allow it to track the entire pass without interruptions. It would be a very useful upgrade for better managing scheduled, automatic passes when Ground Stations in "unmanned".

[sgoudelis]

Indeed that is a case where we can do something about, I ll have a look at it

[sgoudelis]

Try out version 0.7.17 and let me know how it goes

[RikyUnreal]

Hi Efstratios,
I finally had some time to run a few tests, and I'm attaching a video showing a tracking issue.
https://www.youtube.com/watch?v=_dNnWz74DMA (FYI As you can see, I don't have the elevator motor installed at the moment).

For instance, during a SOUTH → EAST → NORTH pass, at around 65° elevation Ground Station decided to move into the overlap zone: the rotator wasted a lot of time going all the way around, ended up re-tracking from ~400°, and only then finished the pass.
In this case it should have simply continued tracking to 0°, and possibly only at that point rotate to try to cover the remaining 5 degrees to reach 355°.

73,
Riky (IU4APB)

[sgoudelis]

Yes there seems to be an issue indeed, I ll check it out, thank you

[sgoudelis]

Try out version 0.7.19, I tested this and it worked fine, please let me know how this works for you.