# ACOM built-in ATU — what we know, and why OpsLog does not drive it

Session of 2026-08-02 on F4BPO's friend's **ACOM 500S**, serial link, telemetry
trace. Written down so nobody repeats the work. **Conclusion first: the tuner
cannot be started over the serial link, and the attempt to work around that was
abandoned.**

## The tuner is PA state 8

Frame byte 3's high nibble is the PA status. ACOM's own list (recovered by the
ACOM-Controller project) has no entry for 8; it is the antenna tuner. Confirmed
twice, front-panel TUNE, with the byte-level trace running:

```
14:47:20.745  state 8 step 0   ← TUNE pressed. err=FF
14:47:22.588  operator keys a carrier (FT-891, FM, 31 W, 3.6358 MHz)
14:47:24.006  state 8 step 2
14:47:25.201  state 8 step 4
14:47:27.457  state 8 step 5
14:47:30.092  state 5 STANDBY  ← accord finished
```

Byte 3's **low** nibble is a step counter through the accord: `0 → 2 → 4 → 5`.
Step 0 means *armed, waiting for RF* — in the first of the two runs the
amplifier sat there **30 seconds** untouched before the operator transmitted.

`paStatusNames[8] = "TUNE"` in acom.go is the only thing kept from all of this.

## The command does not exist in the state-command family

Every action byte of `55 81 08 02 00 XX 00 CHK` was tried, each one from a
**verified** STANDBY (an earlier sweep was worthless because its second code
parked the amp in SERVICE, where it silently refuses everything — 17 false
negatives). Result:

| byte | effect |
|------|--------|
| 0x01, 0x02 | **reboot the amplifier** — it prints `AMPLIFIER: ACOM 500S / HELLO ME…` |
| 0x04 | → SERVICE (state 4) |
| 0x05 | → STANDBY (state 5) |
| 0x06 | → OPERATE (state 6) |
| 0x0A | → OFF (state 10) |
| 0x03, 0x07..0x09, 0x0B..0x18 | nothing, state unchanged |

The action byte **is** the target PA state — four independent confirmations.
Which makes 0x08 the obvious candidate for TUNE. **It was tried, from a verified
STANDBY, and does nothing.** State 8 is reachable from the front panel only.

Going further would mean varying the other bytes of the frame. That is a large
space, and 0x01/0x02 prove that bad values reboot a 500 W amplifier. Not worth
it.

## The workaround that was built and removed

Since the amp waits, armed, for a carrier, OpsLog could watch for state 8 and
supply one: memorise the mode, drop the power, switch to FM, key the PTT, wait
for state 8 to clear, unkey, restore. It was implemented (`acomtune.go`, opt-in,
Settings → Amplifier) and **removed** after the first hardware test:

- the power change did not take effect, and
- **the PTT was not released when the tune finished.**

A logger that can leave a transceiver keyed is not acceptable, and the whole
thing was scaffolding around a protocol we do not actually control. Removed at
the operator's request: *"je veux qu'OpsLog soit solide et ça c'est de la
bidouille."*

If it is ever revisited, the unexplained part is why the tune-finished detection
did not fire — `anyAcomTuning()` polled `StateRaw == 8` every 200 ms and should
have seen the drop to STANDBY. Suspect the status snapshot, not the amplifier.

## Loose ends worth knowing

- **Frame byte 6 is a multiplexer.** The tail of the frame changes meaning with
  it: `0x93` = bytes 48/49 carry the TX frequency in kHz (`62 1B` = 7010 while
  the rig was on 7.010 MHz), `0x9D` = something else. Byte 70 looked like a
  tuner flag for a while purely because of this — it toggles on its own several
  times a minute. Do not read tail bytes without checking byte 6.
- **Byte 5 bit 0x80 alternates frame to frame.** It is a sequence/parity bit,
  not a command acknowledgement.
- **Byte 66 (the error code) shows 0x14 / 0x8E / 0x69 / 0x0F during a normal
  tune and during transmission.** `errText` renders those as "ERROR — see
  display" and "Remove drive power", so an ACOM operator probably sees a false
  alarm. This was never confirmed with the amplifier in OPERATE (it was in
  STANDBY throughout, where drive genuinely is an error) — worth a look with a
  clean log before touching the table.