The satellite page configured its own EasyComm or PstRotator link while five other backends were configured in the rotator list. An operator with one az/el mast therefore described it twice, and could describe it differently the second time — a station that works on HF and not on a pass, for no reason visible anywhere on screen. Now every interface lives in Settings ▸ Rotator, once, and the satellite page stores only a KEY into that list plus the tracking policy that is genuinely its own (minimum elevation, step, park). The key and not the index: deleting the first rotor must not silently point the tracker at a different mast. migrateSatRotator() turns an existing satellite link into a real entry in the list, selects it, and clears the old keys so it cannot run twice. Which rotors have an elevation axis is now a question with one answer, in Go: rotatorTypes plus rotorHasElevation, exposed to the panel by GetRotatorTypes. The dropdown, the labels, each backend's default port and default baud all come from there, so TypeScript no longer keeps a second copy of the same knowledge to drift out of step. Three cases do not follow from the type alone and are treated as such: PstRotator forwards elevation to a mast that may not have any, so the operator says; a SPID's dialect decides (Rot1Prog has no elevation in its reply format); and an ARCO and an ERC-M speak the same GS-232 while only one of them lifts. Each interface carries an Az / Az+El badge beside it. The satellite rotor dropdown LISTS the azimuth-only ones, disabled, rather than hiding them: an operator who owns one rotator and does not see it concludes OpsLog cannot find it, where a greyed row saying "azimuth only" teaches the actual thing. ERC-M by DF9GR is new — the az/el interface for a Yaesu G-5500. It emulates GS-232, so internal/rotator/gs232 grew the elevation half: W for a two-axis move, C2 to read both, falling back to C+B for the firmware that answers C2 with the azimuth alone. That fallback is the point of the parser tests: reading such a reply as "elevation zero" would put the antenna on the horizon, which is the one wrong answer that looks plausible. EasyComm II is promoted to an ordinary rotator interface, so it can also turn the antenna from the compass and from a spot click. The ERC-M is UNTESTED on hardware. Its Test button reads BOTH axes rather than just the azimuth, so a controller wired for azimuth alone says so there instead of during a pass. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
93 lines
4.8 KiB
Markdown
93 lines
4.8 KiB
Markdown
# Maps and Antennas
|
||
|
||
## Main view
|
||
|
||
The Main view is **two configurable panes** (per profile, Settings → General →
|
||
*Main view*), with a **draggable divider** between them (double-click it to
|
||
even them out). Choose from: great-circle map, locator (street) map, the
|
||
cluster grid, the worked-before grid, recent QSOs, the **FlexRadio** controls,
|
||
the **Icom** or **Yaesu** console, or the **Net control** panel.
|
||
|
||
## Great-circle map
|
||
|
||
- Short/long-path **distance & azimuth** to the worked station.
|
||
- Selectable, **key-free** basemaps: Light / Voyager / Street / Satellite.
|
||
- The **antenna beam lobe(s)** are drawn from the rotor azimuth.
|
||
- **Day/night terminator** and twilight band (button at the top right).
|
||
|
||
## Locator (street) map
|
||
|
||
An OSM street map centred on the contacted grid square — handy for local /
|
||
portable contacts. No API key.
|
||
|
||
## Rotators
|
||
|
||
An azimuthal-equidistant **click-to-turn** compass; the current heading and
|
||
target are shown. The needle follows a turning antenna smoothly — OpsLog polls
|
||
faster while the position is changing and backs off once it is parked.
|
||
|
||
**Two rotors** can be configured (two towers, or a Rotator Genius driving two).
|
||
A Rotor 1 / 2 selector appears on the compass; OpsLog turns and displays the
|
||
one you pick.
|
||
|
||
### Types (Settings → Rotator)
|
||
|
||
Every rotator interface is configured here, once — including the az/el ones a
|
||
satellite pass needs. The satellite page does not configure a rotator; it picks
|
||
one of these.
|
||
|
||
| Type | Axes | Connection | Notes |
|
||
|---|---|---|---|
|
||
| **PstRotator** | Az, or Az + El | UDP | Enable PstRotator's UDP listener (Setup → Communication → UDP). Tick *This rotator has an elevation axis* if the mast behind PstRotator has one — PstRotator itself will forward elevation to a rotor that cannot use it. |
|
||
| **Rotator Genius** (4O3A) | Az | TCP, port 9006 | Native. *Rotator #* picks which of the two the box drives; *Two rotors* adds the second as its own rotor. |
|
||
| **GS-232 azimuth** (microHAM ARCO, ERC) | Az | LAN or USB | Set the controller's CONTROL PROTOCOL to *Yaesu GS-232A*. An **ERC** must be in GS-232 emulation, **not** Hy-Gain DCU-1. |
|
||
| **ERC-M by DF9GR** | Az + El | USB COM or LAN | The az/el interface for a **Yaesu G-5500** and its relatives. GS-232 emulation, 19200 baud out of the box. Pick this rather than the GS-232 azimuth entry: it is what tells OpsLog the mast has an elevation motor. |
|
||
| **Hy-Gain DCU-1** | Az | COM port or serial-over-IP | RotorCard DXA, Idiom Press Rotor-EZ, Green Heron. A DCU-1 is 4800 baud; others may differ — match the controller. |
|
||
| **SPID / AlfaSpid** | Az + El (Rot2Prog) | COM port | Native, so PstRotator is not needed in between. See below. |
|
||
| **EasyComm II** | Az + El | COM port or TCP | What SatPC32, Gpredict, Hamlib and K3NG firmware speak — the usual choice for a home-built az/el controller. |
|
||
|
||
Each interface carries an **Az** or **Az + El** badge beside its name, so you can
|
||
see at a glance which of your rotors can follow a satellite.
|
||
|
||
**Rotator range (360° / 450°)** appears for the interfaces OpsLog drives itself.
|
||
A 450° mast follows a pass straight through north instead of unwinding. It is
|
||
deliberately absent for PstRotator: PstRotator knows which controller is on the
|
||
other end and does its own overlap, and two programs each deciding to go the
|
||
long way round is how an antenna unwinds mid-pass.
|
||
|
||
### SPID / AlfaSpid
|
||
|
||
Pick the dialect to match the controller — they are not interchangeable:
|
||
|
||
- **Rot2Prog** — RAS, BIG-RAS/HR, MD-01, MD-02. Azimuth **and** elevation.
|
||
600 baud.
|
||
- **Rot1Prog** — the older azimuth-only controllers (RAK, RAU). 1200 baud.
|
||
|
||
The two use different frame lengths, so a wrong choice shows up at once: the
|
||
**Test** button reports a reply of the wrong length rather than leaving you to
|
||
find out when the antenna turns oddly.
|
||
|
||
Two towers means two controllers, each on its own COM port and each a separate
|
||
rotor in OpsLog.
|
||
|
||
> **The Test button on a SPID, an ARCO or a DCU-1 only READS the heading** — it
|
||
> confirms the port, the speed and the dialect without moving anything, and
|
||
> says so. (PstRotator and a Rotator Genius are instead sent a move to 0°.)
|
||
|
||
## Motorized antennas (Ultrabeam / SteppIR)
|
||
|
||
Both follow the **rig frequency** (band change → retune) and retune immediately
|
||
when you click a spot, with three modes — **Normal**, **180° reverse**,
|
||
**Bidirectional**:
|
||
|
||
- The **radiating direction** is shown in green and the **mechanical boom** in
|
||
grey, on both the compass and the map.
|
||
- On a FlexRadio, transmit is **inhibited while the elements move**, and
|
||
released as soon as the antenna is tuned.
|
||
- **SteppIR — Tunable range** (Settings → Hardware → Antenna, default
|
||
13–54 MHz): outside it OpsLog leaves the antenna and the TX interlock
|
||
completely alone, so tuning to 30 m on a 20 m–6 m SteppIR does nothing.
|
||
|
||
Related hardware: [[Amplifiers and Switches]] (Antenna Genius switch, Tuner
|
||
Genius, relays).
|