fldigi-operating

Operating fldigi: TX/RX handoff and RX polling

The one rule that matters most

Never poll the TX buffer to decide when to stop transmitting. fldigi never auto-stops on an empty buffer — it holds PTT and sends idle until something explicitly returns it to receive. Detecting "buffer empty" from outside always lags, and you transmit idle carrier on top of the station answering you.

Instead, end every over with the inline return-to-receive control character ^r. The transmit → send operation does this for you.

Transmitting an over

transmit → send "<over text>\n"   (return_to_rx=true, the default)

One call: clears the TX buffer, appends ^r, keys the radio. When the modem reaches ^r — the exact sample the last real character finishes — fldigi drops to RX instantly. No polling, no lag, no lingering carrier.

• End each message with a real newline character (\n) so the receiving station's display advances a line. Do not use the two-character string ^n — it is transmitted literally as caret-n.
• If an over must be built incrementally with text → add_tx, the last add_tx must end in ^r before transmit → tx, and nothing may be added after it.

The three ways to stop, and when to use each

Operation	Behavior	Use for
^r in stream (via send)	Graceful auto-return the moment the over ends	Every normal over
transmit → abort	Immediate stop, discards queued text	Panic button: caller came back early, wrong message, operator says stop
transmit → rx	Returns to RX only after the buffer drains	Almost never — it is slow and is not the stop button

Waiting for TX to finish

After send, poll controls → get_trx_status until it returns "rx". A BPSK31 over of 2–4 short lines takes roughly 15–30 seconds; poll at a relaxed interval rather than hammering the API.

Listening: RX buffer discipline

Track the RX stream by position, reading only deltas:

1. text → rx_length → current end position.
2. text → read from your last known position to the new length.
3. Save the new position.