031fcbd543d04f9def13a98345aa20fb14a17b91
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 rouggy
|
72696a5c0c |
feat(sat): the uplink keeps the correction the operator makes
A transponder does not translate by exactly the published difference — the oscillator on board is decades old on some birds and a kilohertz or two out. So an operator who sounds right to themselves comes back off frequency, corrects it on the transmit VFO, and the tracker put it back one second later, every second, for the rest of the pass. Reported on an IC-9700 against HRD, which keeps the shift the operator sets. The tracker already worked this way for the RECEIVER: it reads the dial back and treats a move as the operator choosing a new station. The transmitter had no equivalent — its comment even said so, "derived from the nominal and never argued with". Now it is read back too, and the difference becomes a standing trim on the nominal uplink. Applied to the nominal rather than the corrected frequency, because a translation error is a fixed offset in the uplink band and not something that scales with the Doppler. Read only while not transmitting: mid-over nobody is turning the knob, and on an Icom this read switches to the SUB band and back, which is the same path TuneSatellite already uses to write the uplink and not something to do under a carrier. Kept per satellite AND per transponder, because that is what it belongs to: the error is a property of the hardware in orbit, stable from one pass to the next. Capped at 20 kHz so a bad stored value cannot put the station outside the passband for ever, and shown in the tune panel with a reset — an offset taken silently from the VFO has to be visible, and the VFO alone cannot bring it back to zero once the operator has drifted somewhere wrong. SatTuner gains SatTransmitHz, implemented for the native Icom satellite mode and for the Flex uplink slice; anything else reports nothing and the uplink is left to the arithmetic, as before. |
||
|
rouggy
|
052fc4cb80 |
feat(grids): the square map filters by mode, band and satellite
The FTx button is gone. It was the wrong grain in both directions: the Digital class already sat a contest RTTY square next to an FT8 one, and FTx then sat FT8 next to FT4, when what this map answers is where ONE mode has been heard. The four classes stay as buttons and a dropdown beside them offers a single mode. Its contents come from the log, not from a list in the code. That is what settles FT2: it is not a registered ADIF mode yet, so a hardcoded list meant either leaving out the operators already using it or shipping a mode that does not officially exist. A query does neither, and needs no change here the day it is registered. The mode offered is the SUBMODE where there is one, because ADIF files PSK63 under PSK and "PSK" is not the name anybody is looking for. The band list is the station's own, unioned with anything worked outside it so nothing in the log is unreachable, ordered by frequency through the band plan's index — sorting the names puts 10m between 1.25m and 12m. The satellite list is drawn from SAT_NAME on the squares themselves and the control is absent altogether on a terrestrial log: a VHF square worked through AO-91 and one worked line-of-sight are not the same achievement, and until now nothing separated them. The mode dropdown shares the scope with the class buttons rather than narrowing on top of them — mode is one question, and two controls both answering it is how a map ends up showing PHONE ∩ FT8 and nothing else. A stored FTX preference is read as Digital, so it cannot leave the map filtered by something no control shows as selected. |
||
|
rouggy
|
2615365684 |
fix(sat): the per-band antennas reach the satellite slices
Settings ▸ FlexRadio stores the band→antenna map keyed by the band name
in capitals — that is what the panel writes and what the entry form reads
back. applySatRadio looked its two bands up through bandForHz, which
returns the band plan's own spelling ("70cm"), so both lookups missed,
both antennas came back empty, and the early return left the pass on
whichever antenna the radio was last used on. An operator with XVTA on
2 m and XVTB on 70 cm had configured exactly the thing being ignored, and
nothing said so: the downlink ran through the wrong transverter in
silence.
The key is now computed by flexBandAntKey, which exists so the next
caller cannot make the same mistake, and a test pins the case in the
direction that broke. Both outcomes are logged — the resolved antennas,
or the bands nothing was configured for — because from the outside a
setting never made and a lookup that missed look identical.
Alongside, three things the same pass made obvious:
- Tracking shows the satellite's own azimuth, elevation, distance and
altitude beside the frequencies. The strip held where the ANTENNA was
pointing but not where the bird was, which is what says whether a pass
is worth calling on. Elevation dims below the horizon so a satellite
followed before its lever cannot be read as workable.
- Both satellite lists in the settings are sorted by name with the
numbers taken as numbers. The available column followed the order
birds.json happens to be written in and the followed column the order
of the clicks, so finding one bird among sixteen meant reading all
sixteen.
- A followed satellite that has since been renamed is resolved through
the plan's aliases. LILACSAT-2 became LO-90, and the followed list is
stored as plain text, so the bird the operator had chosen appeared as
having no elements while the same satellite sat in the available
column under its new name. Resolved in GetSatSettings rather than
satSettings, which is read at startup before the plan is loaded.
|
||
 rouggyandClaude Opus 5
|
3ac6f7e49c |
fix(sat): the Flex slices get their antenna, their sideband and their tone
Three things the tracker was leaving to chance on a FlexRadio, all reported from a real pass. ANTENNAS. Settings ▸ FlexRadio holds a per-band RX/TX antenna map, and it was applied in exactly one place: the entry form, on a band change, to the active slice. A pass never goes through that path — the tracker arms two slices itself. So both were left on whatever the radio last used, and a station with transverters (XVTA on 2 m, XVTB on 70 cm) heard nothing at all, having configured precisely the thing being ignored. The two slices are on two different bands, so they cannot share one setting: the downlink takes the receive antenna for ITS band, the uplink the transmit antenna for its. Per slice, not through sendSlice, which addresses whichever slice is active — during a pass that is the downlink, so the uplink would never have been set. SIDEBAND. satMode forced USB above 30 MHz on both sides. An inverting transponder turns the passband over, so lower sideband up comes back as upper sideband down: FO-29, RS-44 and AO-73 were being worked with the operator's own audio going through upside down. The tracker now decides both sidebands from the transponder's inverting flag and passes them separately; a bare "SSB" still means USB, so nothing else changes. CTCSS. Nothing set it, on any bird. The frequency plan has carried the tone all along — 67.0 on SO-50 and AO-91, 141.3 on PO-101 — and an FM repeater does not answer without it, which is indistinguishable from a satellite that is not there. It goes on the uplink slice, value before mode so the radio cannot transmit the previous tone in the gap between two commands. Written against the SmartSDR slice API and UNTESTED on hardware. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
rouggyandClaude Opus 5
|
b15055ba4a |
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]> |
||
|
rouggy
|
465481f8f1 |
feat(sat): Doppler tracking on the radio
The hard part of satellite tuning is not the arithmetic, it is deciding who owns the dial. A tracker that forces both frequencies fights the operator every time they turn the knob to follow a station across a linear transponder; one that never touches the receiver leaves them chasing a signal that slides nine kilohertz across a 70 cm pass. So the operator owns the receiver and the tracker follows them. Every second it asks the radio where the receiver actually is. Where it put it, nothing has changed. Further than a dial-turn's tolerance, and the operator has chosen a station: what they landed on is converted back into a nominal frequency, and the transmitter is derived from that. Which is the division of labour on a linear bird — the operator listens, the radio does the sums. Three ways to reach the radio, because a satellite pair is a shape of operating rather than a manufacturer's feature. An IC-9700 or IC-9100 is asked for its OWN satellite mode: it pairs main and sub, gives full duplex, and keeps the dials linked the way its designers meant, which is always better than an imitation built out of split. A Flex gets two slices, A the downlink and B the uplink, created when missing, because "slice B does not exist" is not something to make an operator fix at the start of a ten-minute pass. Everything else gets the downlink, and is told so — half the job announced beats half the job hidden. What goes in the log is the NOMINAL pair. Two stations working each other through a transponder read different numbers off their dials at the same instant; the only figure they can both agree on is the transponder's own. FREQ is the uplink and FREQ_RX the downlink — the one place a satellite QSO differs from every other kind, and the reason FREQ alone cannot describe one. |