OpsLog/internal/acom/ATU-FINDINGS.md

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.