View Issue Details

IDProjectCategoryView StatusLast Update
00033943 - Current Dev List[All Projects] Generalpublic2019-09-20 12:48
ReporterPD9FERAssigned ToPD9FER 
Status resolvedResolutionfixed 
Product Version 
Target VersionFixed in Version6.7.0.227 
Summary0003394: Add FT4 Mode to standard Mode list in Logbook
DescriptionWhen FT4 got assigned as MFSK submode by LoTW followed
They Accepted it also as MFSK...
However... as of today, LoTW handles FT4 as DATA

We need to edit our default modes list in logbook and add Mode:FT4 ADIF:DATA
This way LoTW will gives a match when downloading.

Steps To ReproduceIn the current V6.6.0.237 open Logbook
Select Tools > Configure > Modes
Click Add
In the Mode field put FT4
In the ADIF field put DATA

This is now the procedure to follow until we implement it in the next build.
TagsNo tags attached.
TestingNot Started



2019-07-25 09:29

administrator   ~0008263

Based on some feedback from one source, they provide the following:


By repeatedly giving incorrect information and urging users to map
FT4 > DATA your support staff are certainly hurting both users and

<snip> (log/export a couple FT4 QSOs and study the
tQSL config.xml file) to determine that the proper short term work-
around would be to "map" FT4 -> FT4 just as you "map" MFSK8 -> MFSK8
and MFSK16 -> MFSK16. That will result in FT4 QSOs being uploaded
to LotW at FT4 and LotW QSLs will "verify".

With the MFSK8 and MFSK16 examples right in front of them, it should
be a simple matter for your support staff to give your users the
correct answer rather than screw things up with manifestly incorrect

*NOTHING* will fix the problem when users upload FT4 as either
<MODE:4> MFSK or <MODE4:> DATA. That QSO data will not "match"
QSO data with FT4 for WAS and will only be accepted for DXCC,
WAZ and WPX (and VUCC which does not care about mode).


2019-07-25 14:41

updater   ~0008267

Agree with Mike here
Think the only solution is to implement full ADIF 3 compatibility


2019-07-29 14:24

updater   ~0008296

Scaling this up.

Ignore this Mantis.
We 1st should prioritize getting ADIF 3 compatible.
We are now telling customers a work around.

That should stop.

Our mode list says Mode - ADIF
Mode is whatever we call it / assign it.
ADIF is the real Mode, and we are lacking the SubMode


2019-07-30 10:23

administrator   ~0008300

Large-scope work items probably dissolve into several smaller work items which should be tracked individually, but at this time I can't find any Mantis issue that tracks ADIF 3 compatibility.


2019-07-30 16:15

administrator   ~0008303

There's no prescriptive advice here, so I'm assigning this back to offer the opportunity to provide clear guidance.

Ferry says "ignore this Mantis", so maybe this should just be closed as won't fix. We can address the issue when work is done to scope and specify what ADIF 3 compatiblility truly means for the product. That's a long conversation and not a quick fix.


2019-08-25 16:28

administrator   ~0008439

We need an interim solution. At this point, this problem can't wait until we can fully implement the current version of ADIF. We need an interim solution that solves the problem of matching FT4 confirmations in the LOTW download.


2019-08-31 06:47

updater   ~0008474

This is how data comes in from LoTW

Generated at 2019-08-29 14:17:11
for pd9fer


 QSL SINCE: 2019-07-29 00:00:00

<APP_LoTW_LASTQSL:19>2019-08-19 13:19:23



2019-08-31 06:55

updater   ~0008475

This is the ADIF + HRD Export of that QSO (keep in mind in Modes I added FT4 as mode and MFSK as ADIF field)

# HRD Logbook version, Copyright © 2003 - 2019 by HRD Software, LLC
# Created: 20190831 135158

<CREATED_TIMESTAMP:15>20190831 135158

<a_index:3>0.0 <ant_az:3>0.0 <ant_el:3>0.0 <band:3>20m <band_rx:3>20m <call:5>LY2FN <comment:32>Tnx for FT4 Contact,73 de PD9FER
<cont:2>EU <country:9>Lithuania <cqz:2>15 <distance:8>1253.206 <dxcc:3>146 <eqsl_qslsdate:8>20190723
<eqsl_qsl_rcvd:1>N <eqsl_qsl_sent:1>Y <app_hamradiodeluxe_eqsl_status:144>Result: 1 out of 1 records added, Information: From: PD9FER To: LY2FN Date: 20190723 Time: 1234 Band: 20M Mode: MFSK RST: -01 SatMode: PropMode:
<force_init:1>N <freq:9>14.081813 <gridsquare:6>KO14xv <app_hamradiodeluxe_heading:6>71.234 <ituz:2>28
<k_index:3>0.0 <lat:11>N000 00.000 <lon:11>E000 00.000 <lotw_qslsdate:8>20190729 <lotw_qsl_rcvd:1>N <lotw_qsl_sent:1>Y
<mode:4>MFSK <my_city:11>Grootebroek <my_country:11>Netherlands <my_cq_zone:2>14 <my_gridsquare:6>JO22OQ
<my_itu_zone:2>27 <my_lat:11>N052 41.250 <my_lon:11>E005 12.500 <my_name:5>Ferry <my_postal_code:7>1613 CE
<my_rig:12>Icom IC-7300 <my_state:2>NH <my_street:13>Schouwwagen 1 <name:8>Ricardas <operator:6>PD9FER
<owner_callsign:6>PD9FER <pfx:3>LY2 <qsl_rcvd:1>N <qsl_sent:1>N <qso_complete:1>Y <qso_random:1>N <qth:6>Kaunas
<rst_rcvd:3>+02 <rst_sent:3>-01 <rx_pwr:3>0.0 <sfi:3>0.0 <station_callsign:6>PD9FER <swl:1>N <time_off:6>123500
<time_on:6>123400 <tx_pwr:5>5.000 <app_hamradiodeluxe_my_antennas:13>Fritzel FB-34 <hrdcountryno:3>146
<qso_date:8>20190723 <EOR>


2019-08-31 15:34

administrator   ~0008481

Still not much detail here. In some emails, I asked if we were trying to fix both uploads and downloads from LoTW and didn't get a straight answer, but it seems like we want the download side to be fixed and don't care (for now?) about the upload side.

I don't have any FT4 contacts to test with, but given Ferry's post it seems like the problem is that we want to translate a record with { MODE = MFSK, SUBMODE = FT4 } into a record with { MODE = FT4 } when downloaded from LoTW.

I tried importing Ferry's file (rather than downloading) using these steps:

1) Start up the Logbook, blank database
2) Use the ALE to add a new record for LY2FN on 14.08181 MHz using FT4, at 20190723Z123400.
3) Close the ALE.
4) Use the dropdown on the "More" button in the database view toolbar to get to the "LOTW" tear-off; use the "Manual Import" command
5) In the resulting "LOTW Import" dialog, press the ellipsis button "..." to open Ferry's file
6) Press OK to process the file
7) The list control in the "LOTW Import" window should indicate "1 of 1 LOTW entries matched"
8) Press "Save To Database"
9) Press "Finish"
10) Double-click the LY2FN QSO in the Logbook database view to open the ALE
11) Activate the "LOTW" tab in the ALE
12) Examine the "Rcvd" field; it should indicate "Verified (Match)" and have the date when these steps were performed

Step #2 shows that "FT4" was added to one of the product's mode lists.

Steps #7 and #12 demonstrate that matching is working for imported records with { MODE = MFSK, SUBMODE = FT4 }.

If my guess is correct, I think we're in good shape. If we need something different, then I would benefit with a chat from someone who understands this problem well enough to articulate what is needed and is able to answer my questions.


2019-08-31 15:36

administrator   ~0008482

The above changes are in this change set:


2019-09-05 04:43

updater   ~0008509

Looks not to be fixed
At this moment I totally an getting No matches on FT4


2019-09-18 08:04

updater   ~0008564

Seems we are not changing the Logbookmodes.xml
After clicking Defaults in modes, it is working.
However... all custom made changes are gone.

Is there a way to only rewrite the FT4 entry in the XML upon installing HRD?


2019-09-18 08:08

administrator   ~0008565

Last edited: 2019-09-18 08:09

View 2 revisions

This morning I did a download from LoTW using the Beta release. Virtually every one of my FT4 contacts have now been VERIFIED in my logbook. It appears that what ever fix Mike B did to the software allows the FT4 contacts to be verified as they should. I believe this bug report can be marked "Resolved" in version 6.7.



2019-09-20 12:48

manager   ~0008567

I have verified with Mike C and our support team and our beta testers - this change works.
Based on Mike C's previous feedback, we are going to defer the conversation about ADIF 3 to a later date.

Issue History

Date Modified Username Field Change
2019-07-19 14:42 PD9FER New Issue
2019-07-25 09:29 WA9PIE Note Added: 0008263
2019-07-25 14:41 PD9FER Note Added: 0008267
2019-07-28 20:09 WA9PIE Project 1 - Backlog => 4 - Business Priorities
2019-07-28 20:09 WA9PIE Category Enhancement => General
2019-07-29 14:24 PD9FER Priority normal => urgent
2019-07-29 14:24 PD9FER Note Added: 0008296
2019-07-29 14:25 PD9FER Severity minor => major
2019-07-29 17:11 WA9PIE Assigned To => K7ZCZ
2019-07-29 17:11 WA9PIE Status new => assigned
2019-07-30 10:23 K7ZCZ Note Added: 0008300
2019-07-30 16:15 K7ZCZ Assigned To K7ZCZ => PD9FER
2019-07-30 16:15 K7ZCZ Note Added: 0008303
2019-08-25 16:28 WA9PIE Note Added: 0008439
2019-08-31 06:47 PD9FER Note Added: 0008474
2019-08-31 06:55 PD9FER Note Added: 0008475
2019-08-31 15:34 K7ZCZ Note Added: 0008481
2019-08-31 15:36 K7ZCZ Note Added: 0008482
2019-09-01 07:27 WA9PIE Project 4 - Business Priorities => 3 - Current Dev List
2019-09-01 07:27 WA9PIE Status assigned => resolved
2019-09-01 07:27 WA9PIE Fixed in Version =>
2019-09-01 07:29 WA9PIE Resolution open => fixed
2019-09-05 04:43 PD9FER Note Added: 0008509
2019-09-05 04:44 PD9FER Status resolved => feedback
2019-09-05 04:44 PD9FER Resolution fixed => reopened
2019-09-18 08:04 PD9FER Note Added: 0008564
2019-09-18 08:08 KB3NPH Note Added: 0008565
2019-09-18 08:09 KB3NPH Note Edited: 0008565 View Revisions
2019-09-20 12:48 KB9PIE Status feedback => resolved
2019-09-20 12:48 KB9PIE Resolution reopened => fixed
2019-09-20 12:48 KB9PIE Note Added: 0008567