Problem
ADIF export writes a QSL_MANUAL field/tag, e.g.:
<QSL_RCVD:1>N <QSL_MANUAL:1>N
QSL_MANUAL is not a defined field in the ADIF specification (checked against ADIF 3.1.5: https://www.adif.org/303/adif303.htm). It does not appear in the ADIF field list, so exported logs contain a non-standard/invalid tag that ADIF-compliant importers (LoTW, club log, other logging software) may reject or silently ignore.
Where it's emitted
ft8af/app/src/main/java/com/k1af/ft8af/log/AdifRecord.java:115ft8af/app/src/main/java/com/k1af/ft8af/database/DatabaseOpr.java:1255-1257desktop/src-tauri/src/db.rs:378,425ios/FT8AFKit/Sources/FT8Engine/Adif.swift:19
Corresponding tests that currently assert on the invalid tag:
ft8af/app/src/test/java/com/k1af/ft8af/log/AdifRecordTest.java:48,57ios/FT8AFKit/Tests/FT8EngineTests/AdifTests.swift:39,59
There's also a read path that treats QSL_MANUAL as an input field from imported ADIF:
ft8af/app/src/main/java/com/k1af/ft8af/log/QSLRecord.java:191-192 (comment claims it's "present in LoTW" — worth double-checking against real LoTW exports, since it's not in the spec's field table)
Expected
Manual QSL confirmation should be represented using valid ADIF fields. The spec's closest legitimate equivalents are:
QSL_RCVD (Y/N/R/I/V) — already emitted alongside QSL_MANUAL and is sufficient on its own to indicate a received confirmation.QSLMSG — free-text QSL message field, if a note about manual confirmation is wanted.
The non-standard QSL_MANUAL tag should be dropped from export (and the corresponding tests updated), and the import-side handling in QSLRecord.java should be reviewed since it's likely working around this same non-standard tag rather than a real ADIF field.
Impact
Exported ADIF files contain a tag that is not part of the spec, which can cause interoperability issues with third-party ADIF consumers (LoTW upload validators, other logging software, contest/award tools) that do strict field validation.
Problem
ADIF export writes a
QSL_MANUALfield/tag, e.g.:QSL_MANUALis not a defined field in the ADIF specification (checked against ADIF 3.1.5: https://www.adif.org/303/adif303.htm). It does not appear in the ADIF field list, so exported logs contain a non-standard/invalid tag that ADIF-compliant importers (LoTW, club log, other logging software) may reject or silently ignore.Where it's emitted
ft8af/app/src/main/java/com/k1af/ft8af/log/AdifRecord.java:115ft8af/app/src/main/java/com/k1af/ft8af/database/DatabaseOpr.java:1255-1257desktop/src-tauri/src/db.rs:378,425ios/FT8AFKit/Sources/FT8Engine/Adif.swift:19Corresponding tests that currently assert on the invalid tag:
ft8af/app/src/test/java/com/k1af/ft8af/log/AdifRecordTest.java:48,57ios/FT8AFKit/Tests/FT8EngineTests/AdifTests.swift:39,59There's also a read path that treats
QSL_MANUALas an input field from imported ADIF:ft8af/app/src/main/java/com/k1af/ft8af/log/QSLRecord.java:191-192(comment claims it's "present in LoTW" — worth double-checking against real LoTW exports, since it's not in the spec's field table)Expected
Manual QSL confirmation should be represented using valid ADIF fields. The spec's closest legitimate equivalents are:
QSL_RCVD(Y/N/R/I/V) — already emitted alongsideQSL_MANUALand is sufficient on its own to indicate a received confirmation.QSLMSG— free-text QSL message field, if a note about manual confirmation is wanted.The non-standard
QSL_MANUALtag should be dropped from export (and the corresponding tests updated), and the import-side handling inQSLRecord.javashould be reviewed since it's likely working around this same non-standard tag rather than a real ADIF field.Impact
Exported ADIF files contain a tag that is not part of the spec, which can cause interoperability issues with third-party ADIF consumers (LoTW upload validators, other logging software, contest/award tools) that do strict field validation.