Reported with two screenshots: both slices in USB on an inverting transponder,
slice B sitting at exactly 435.100000, and the red TX badge on the 2 m DOWNLINK.
The log named the cause in one line:
flex: satellite armed (rx slice 0, tx slice -1)
Creating a slice is asynchronous — "slice create" is answered later with the
index — and SetSatellite returned without waiting. Everything downstream then
ran against an uplink of -1 and silently did nothing: no antenna, no CTCSS tone,
no sideband, never tuned, and never sent "tx=1". So the radio went on
transmitting on the downlink, which is the one failure here that puts a signal
where it must not go, and the frequency and mode on screen were simply the ones
the slice had been created with.
Three fixes, because the ordering can fail in more than one way:
- Arming waits for both indices before reporting the pair armed, and says so
plainly when the radio does not produce them.
- The uplink is adopted from the SLICE STATUS as well as from the create
reply. The status needs no sequence-number correlation: if satellite mode is
armed, the uplink is unknown, and a slice is in use that is not the
downlink, that is it — the radio is saying so.
- What the uplink is owed is remembered — its mode, its antenna, its tone —
and given to it when it appears. Those three are sent ONCE; only the
frequency is re-sent every tick, so a slice that arrived late kept nothing.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>