feat(sat): follow the azimuth only

A satellite tracker that insists on an elevation motor is a tracker switched off
for nearly everybody. A pass at the edge of the footprint — which is most of
them — never climbs above ten or fifteen degrees for its whole length, and a
yagi's beamwidth swallows that: the bearing alone is enough, and it is how most
stations that work satellites are actually built. The same switch rescues an
az/el station whose elevation motor has failed.

So it is an option, not a silent fallback, because it does cost something: a
bird straight overhead is a moving azimuth and a bearing that means nothing, and
whether to accept that is the operator's call. With it on, any rotor in the list
can be chosen — the PstRotator, the Rotator Genius, the ARCO, the tower already
turned for HF.

That works because the per-backend command dispatch moved out of the three
RotatorGoTo/Stop/Heading methods into linkGoTo/linkStop/linkHeading, so the
satellite tracker drives any of the seven backends through the same code the
compass uses instead of a second implementation of each. GetRotatorHeading loses
sixty lines of near-duplicate switch in the process, and a rotor with no
elevation axis now says so (HasElevation) rather than reporting a zero that
looks like a real bearing.

One trap, with a test on it: the step check compared both axes, so with the
elevation never commanded its difference stayed above the step for the whole
pass and every tick ordered the antenna to the bearing it was already on. A mast
has a finite number of turns in it.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

app_sat_rotator.go

@@ -55,12 +55,18 @@ func (a *App) newSatRotator(s SatSettings) (satRotator, error) {
 		// rather than failing to connect to an address nobody can see any more.
 		return nil, fmt.Errorf("the rotator chosen for satellite tracking no longer exists in Settings ▸ Rotator")
 	}
+	// Azimuth only: any rotor will do, including the tower the operator already
+	// turns for HF. See SatSettings.RotAzOnly for why this is the common case
+	// rather than a fallback.
+	if s.RotAzOnly {
+		return &azOnlySatRotator{link: lr.Link}, nil
+	}
 	if !lr.HasEl {
 		name := strings.TrimSpace(lr.Name)
 		if name == "" {
 			name = "this rotator"
 		}
-		return nil, fmt.Errorf("%s has no elevation axis — a satellite pass needs one", name)
+		return nil, fmt.Errorf("%s has no elevation axis — tick \"follow the azimuth only\" in Settings ▸ Satellite, or pick an az/el rotator", name)
 	}
 	l := lr.Link
 	switch l.Type {
@@ -90,10 +96,11 @@ type SatelliteRotorChoice struct {
 
 // ListSatelliteRotors returns every configured rotor, elevation-capable or not.
 //
-// Not filtered to the az/el ones, deliberately. An operator who owns exactly one
-// rotator and does not see it in this list concludes OpsLog cannot find it; shown
-// with "azimuth only" beside it, they learn the actual thing — that the tracker
-// needs an elevation axis and this mast has none.
+// Never filtered. Which of them can be USED depends on the azimuth-only switch,
+// and that is a question for the panel: with it off an azimuth rotor is shown
+// greyed and says why, with it on every rotor is fair game. Hiding them
+// outright would only teach an operator with one mast that OpsLog cannot find
+// it.
 func (a *App) ListSatelliteRotors() ([]SatelliteRotorChoice, error) {
 	devs, err := a.GetRotators()
 	if err != nil {
@@ -260,3 +267,47 @@ func (p *pstSatRotator) Heading() (float64, float64, bool, error) {
 // Close: nothing to release. Every PstRotator command is one datagram, and the
 // socket lives for the length of a single write.
 func (p *pstSatRotator) Close() {}
+
+// azOnlySatRotator follows the satellite in azimuth and never touches the
+// elevation axis, whatever the rotor happens to have.
+//
+// It works because of the geometry, not in spite of it: a pass at the far edge
+// of the footprint stays between the horizon and about fifteen degrees for its
+// whole length, and a yagi's beamwidth swallows that. What it costs is the high
+// passes — a bird straight overhead is a moving azimuth and a useless bearing —
+// and that is the operator's trade to make, which is why it is a switch and not
+// a silent fallback.
+//
+// It drives whichever rotor was chosen through the same per-backend dispatch the
+// compass uses, so a PstRotator, a Rotator Genius, an ARCO, a DCU-1, a SPID and
+// the az/el ones all work here without a second implementation of each.
+type azOnlySatRotator struct{ link rotorLink }
+
+// Point sends the azimuth alone. The elevation is passed as -1, the callers'
+// "no opinion", so a rotor that HAS an elevation axis is left where it is rather
+// than being driven to the horizon.
+func (r *azOnlySatRotator) Point(az, _ float64) error {
+	a := math.Mod(az, 360)
+	if a < 0 {
+		a += 360
+	}
+	return linkGoTo(r.link, int(math.Round(a)), -1)
+}
+
+// Heading reports the azimuth. The elevation comes back as whatever the
+// controller said, which for an azimuth rotor is zero — the panel is told
+// separately not to draw it (SatTrackStatus.RotAzOnly), because zero is a real
+// bearing and not the absence of one.
+//
+// live stays true when the AZIMUTH was genuinely read: it means "this is a
+// reading and not the last command", and that answer is honest whatever the
+// other axis does or does not do.
+func (r *azOnlySatRotator) Heading() (float64, float64, bool, error) {
+	az, el, _, _, err := linkHeading(r.link)
+	if err != nil {
+		return 0, 0, false, err
+	}
+	return az, el, true, nil
+}
+
+func (r *azOnlySatRotator) Close() {}