FT8: don't key up deep into a TX slot - partial transmissions are wasted - #116
Open
vroOoms wants to merge 1 commit into
Open
FT8: don't key up deep into a TX slot - partial transmissions are wasted#116vroOoms wants to merge 1 commit into
vroOoms wants to merge 1 commit into
Conversation
The FT8 transmit trigger in ft8_poll() fires anywhere inside the 15s parity window, and ft8_start_tx(seconds % 15) starts the waveform at the current offset into the slot. When a transmission is requested late in the window - typical for auto-sequenced replies, because a decode batch often completes a second or two before the slot boundary - the radio keys up and transmits only the last second or two of the message. Nothing on the receiving side can decode that fragment, ft8_repeat is consumed, and the operator sees a transmission that keys and stops immediately (a TX with no measurable output in the logs). Gate the trigger to the first 3 seconds of the window: a slightly late join still decodes (FT8 sync is distributed across the transmission), and anything later stays pending and keys cleanly at the start of the next parity slot. Observed on an sBITX v2 running auto-sequenced FT8: replies queued at second :14/:29/:44 consistently produced 1-second phantom transmissions; with this change, 8/8 consecutive transmissions keyed on exact slot boundaries and completed at full power.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
The FT8 transmit trigger in
ft8_poll()fires anywhere inside the 15-second parity window, andft8_start_tx(seconds % 15)starts the waveform at the current offset into the slot:When a transmission is requested late in the window — which happens routinely with auto-sequenced replies, because an FT8 decode batch often completes a second or two before the slot boundary — the radio keys up immediately and transmits only the last one or two seconds of the message. Nothing on the receiving side can decode that fragment,
ft8_repeatis consumed, and the operator sees a transmission that keys and stops right away (in our logs: a TX entry with no measurable output power).The fix
Gate the trigger to the first 3 seconds of the window. A slightly late join still decodes fine (FT8's sync is distributed across the transmission); anything later stays pending and keys cleanly at the start of the next parity slot instead of wasting itself.
Observed / verified
On an sBITX v2 (v3.021) running auto-sequenced FT8: replies queued at second :14/:29/:44 consistently produced ~1-second phantom transmissions (PA keyed, no decodable signal, attempt lost). With this change, 8/8 consecutive transmissions keyed on exact slot boundaries and completed at full power, confirmed against the TX log.
More bugs found while building on this codebase (with fixes) are documented at vroOoms/sbitx-vu3exh — UPSTREAM-BUGS.md. Happy to send follow-up PRs for the isolated ones (SIDETONE handler, rigctl thread-safety, mid-TX abort in
ft8_on_start_qso).73, VU3EXH
🤖 Generated with Claude Code
https://claude.ai/code/session_011QxAdKpedpdffNuLUtkdse