add SNR to ftx_candidate_t #48
Open
Conversation
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
We need HAVE_STPCPY defined to avoid duplicating it. We shouldn't depend on CPPFLAGS if building with gcc. It may be necessary to build with a C++ compiler when using portaudio or integrating into a C++ project. Now it builds either way.
kiss_fft is omitted for now: not every program needs it, and the object file can still be linked separately, as before. `FT8_DEBUG=1 make` builds with `-fsanitize=address -ggdb3` and without `-O3` for debugging purposes.
If the given string is longer than the given length (available space), copy one less than the length and then append a null terminator. This guarantees that token will always be null-terminated, to avoid buffer overflow. For example in ftx_message_encode(), if message_text is excessively-long free text with no spaces, we attempt to copy it to call_to, which is 12 bytes long. We must copy only 11 bytes, so that it can be null-terminated. (In this case call_to is not really used anyway: it's not a callsign, and after failing the other encodings, we will call ftx_message_encode_free(msg, message_text), and then fail because it's too long. But don't crash on the way, either.) Discovered with ASAN.
If a ftx_message_t struct is reused for all outgoing messages, it may have leftover i3.n3 values. Make sure to overwrite those. (Although, "telemetry" should really be type 0.5; but we are reusing ftx_message_encode_telemetry() in ftx_message_encode_free(), so I guess the caller who calls ftx_message_encode_telemetry() should set that byte itself.) Also output the "parsed '...' ..." debug log message before checking for errors, to help clarify why the error occurred.
The user of this library should not need to re-tokenize the plain-text message and guess again which field is a callsign, special-token, grid etc.: it's redundant and relatively failure-prone, whereas libft8 already has all the information. It already needed to decode individual tokens out of the bitstream and construct plain text from that. But some users (such as sbitx) color-code the message, and IMO it's best not to invent some ad-hoc markup language. So the message is kept as plain text, and its "metadata" is kept separate, in the form of a start position and a type enum for each recognizable span found in the message text. It could be argued that this could go further, such as splitting "CQ POTA" into two fields, FTX_FIELD_TOKEN and FTX_FIELD_TOKEN_ARG; however, the internal model so far that a std or nonstd message can contain only 3 fields, so we treat the whole thing as a "callsign", then pack28() detects CQ and calls parse_cq_modifier(). And FTX_MAX_MESSAGE_FIELDS is 3 because of this. Likewise, we could separate FTX_FIELD_CALL_TO and FTX_FIELD_CALL_DE: but they have positional meaning anyway. This could be reexamined later.
We need trim_brackets() for the tests, and it may be useful in user programs too. When a CHECK(this == that) test fails, it's helpful to see the values that were not equal; so add and use the CHECK_EQ_VAL(this, that) macro. A failed test needs to end with an extra newline to separate the output from the next test. And FAIL! is subtly better than FAIL: for searching in the terminal (also, I have muscle memory for it, from Qt work).
"TNX BOB 73 GL" (an example from WSJT-X tests) contains 4 tokens (which are not callsigns), but ft8_lib would have previously tried to compose a standard type 1 message. If a program that uses ft8_lib has paid attention to the field types and offsets from previous messages, and has UI for the user to select (for example) a FTX_FIELD_CALL field and start a new QSO, then it has enough information to call a type-specific function. pack_basecall() can be used to disambiguate whether the callsign is standard or not: then the program can call ftx_message_encode_std(), or ftx_message_encode_nonstd() if it detects a non-standard callsign or if ftx_message_encode_std() fails. Likewise, it can call ftx_message_encode_free() if it already knows the message must be sent as free text, or as a fallback if the other encode functions fail. ftx_message_encode() does this fallback sequence already, but it is not given field types to indicate what the message contains, so it could potentially make a mistake (e.g. with "THX BOB 73"). But it is retained for backwards compatibility, and also because it's easier to use; and now it gets more cases right than it did before.
A program could use it to pre-check whether a callsign is standard or not. (But if it's not standard, it may not be a callsign at all.)
Figured out how by reading subroutine pack28(c13,n28) in WSJT-X. The decoding already works, it seems. We now use space as the delimiter between CQ and the modifier, rather than underscore. An end user composing a message by hand would use space, so it must be detectable that way; and BTW CQ may also be a callsign prefix (Portugal, Azores, Madeira), so we cannot simply detect CQ without checking the following delimiter, and assume that it's a CQ message. nnn and a[bcd] are unlike callsigns (a CQ modifier can have letters OR numbers, but not both, whereas a callsign ALWAYS has both); so we can reliably detect modifiers without needing underscore as a delimiter.
The code comes from afarhan/sbitx@3d246a3 But in this version we use qsort() instead of a local sort algorithm.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
one more patch beyond #47