Bug Report: ADIF Export Issues in Ham2K Portable Logger v26.2.11
Reported by: DA2PK
App version: Ham2K Portable Logger 26.2.11
ADIF version: 3.1.5
Date of activation: 2026-05-02
Platform: iOS 26.4.2
Overview
Two separate bugs were identified in the ADIF export of Ham2K Portable Logger. Both bugs cause imported QSOs to be silently dropped when uploading to sotadata.org.uk (and likely other logging software with strict ADIF parsers). The bugs were discovered by comparing the exported ADIF files against what sotadata rendered after import.
Two ADIF files are attached as evidence.
Bug 1: Duplicate GRIDSQUARE / MY_GRIDSQUARE fields in S2S records
File: 2026-05-02_DA2PK_at_DM-NW-219.adi
Description
When a QSO is logged as Summit-to-Summit (S2S) and contains a SOTA_REF field, Ham2K appends a second pair of GRIDSQUARE and MY_GRIDSQUARE fields at the end of the record, after the SOTA_REF tag. This results in duplicate field names within the same QSO record, which is invalid per the ADIF specification (§3.1: each field may appear at most once per record).
Example (from exported file)
<CALL:7>DK3RN/P ... <GRIDSQUARE:6>JO41fe <MY_GRIDSQUARE:6>JO31xe <SOTA_REF:9>DM/NW-026 <GRIDSQUARE:6>JO41fe <MY_GRIDSQUARE:6>JO31xe <EOR>
The fields GRIDSQUARE and MY_GRIDSQUARE appear twice in the same record.
Impact
sotadata.org.uk drops all QSOs following the first malformed S2S record. In the attached log, 3 out of 13 QSOs were lost on import (EA4ACS, OE/IV3HEH, YO5ELA/P).
Affected records in the attached log
| Callsign | SOTA_REF |
|---|---|
| DK3RN/P | DM/NW-026 |
| EA2TP/P | EA2/BI-065 |
| OE/IV3HEH | OE/KT-265 |
| YO5ELA/P | YO/EC-317 |
Expected behavior
GRIDSQUARE and MY_GRIDSQUARE should appear exactly once per record, before the SOTA_REF field (or in any order, but not duplicated).
Workaround
Remove the duplicate <GRIDSQUARE> and <MY_GRIDSQUARE> fields that appear after <SOTA_REF> using a text editor or the following sed command:
bash
sed 's/<SOTA_REF:\([0-9]*\)>\([^ ]*\) <GRIDSQUARE:[^>]*>[^ ]* <MY_GRIDSQUARE:[^>]*>[^ ]* /<SOTA_REF:\1>\2 /g' input.adi > fixed.adi
Bug 2: Invalid STATE field written for non-US stations
File: 2026-05-02_DA2PK_at_DM-NW-204.adi
Description
Ham2K writes a STATE field for non-US stations, populating it with what appears to be a regional/canton/province code from the station’s country. Per the ADIF specification, the STATE field is exclusively defined for US call districts and must contain a valid US state abbreviation. Writing STATE for non-US DXCC entities is invalid.
Examples (from exported file)
<CALL:6>HB9BIN ... <DXCC:3>287 <STATE:2>AG ... ← Swiss station, AG = canton Aargau
<CALL:6>OE6HBE ... <DXCC:3>206 <STATE:2>AT ... ← Austrian station, AT = Steiermark
DXCC 287 = Switzerland, DXCC 206 = Austria — neither is the USA (DXCC 291).
Impact
sotadata.org.uk fails to parse any QSO record containing an invalid STATE value and drops all subsequent QSOs in the file. In the attached log, 5 out of 12 QSOs were lost on import (DM5WW, DK3RN, HB9DIZ, OE6HBE, M1GEO).
Expected behavior
The STATE field should only be written for stations with DXCC = 291 (USA). For all other DXCC entities, the field should be omitted entirely. If regional subdivision data is desired for non-US stations, the correct ADIF field is CNTY (for counties/subdivisions) used together with the appropriate PRIMARY_ADMINISTRATIVE_SUBDIVISION or SECONDARY_ADMINISTRATIVE_SUBDIVISION fields, as applicable.
Workaround
Remove all STATE fields from non-US records using a text editor or:
bash
sed 's/ <STATE:[0-9]*>[^ ]*//g' input.adi > fixed.adi
Summary
| # | Field(s) affected | Trigger condition | QSOs lost |
|---|---|---|---|
| 1 | GRIDSQUARE, MY_GRIDSQUARE |
S2S QSO with SOTA_REF |
Varies (all after first S2S) |
| 2 | STATE |
Non-US station with regional subdivision data | Varies (all after first affected QSO) |
Both bugs can silently corrupt SOTA activation logs on upload. A strict ADIF parser will either reject the affected records or abort the entire import at the first malformed record.
Attached: Both original (unmodified) ADIF exports as produced by Ham2K.
Note: This bug report was created with the assistance of an AI (Claude by Anthropic). The ADIF files, activation data, and observed symptoms are real and were provided by the reporter. The technical analysis and root cause identification were performed collaboratively.
2026-05-02_DA2PK_at_DM-NW-204.adi (3.9 KB)
2026-05-02_DA2PK_at_DM-NW-219.adi (4.5 KB)