View Issue Details

IDProjectCategoryView StatusLast Update
0003394Ham Radio Deluxe[All Projects] Generalpublic2019-11-08 02:32
ReporterPD9FERAssigned ToPD9FER 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.7.0.244 
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.
Testing Beta Successful


related to 0003504 closedDOUG Using QSO Forwarding FT4 is put in the log as MFSK 



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

viewer   ~0008267

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


2019-07-29 14:24

viewer   ~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

developer   ~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

developer   ~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

viewer   ~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

viewer   ~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

developer   ~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

developer   ~0008482

The above changes are in this change set:


2019-09-05 04:43

viewer   ~0008509

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


2019-09-18 08:04

viewer   ~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.


2019-09-23 05:09

viewer   ~0008593

FT4 QSOs verified by LOTW


2019-09-23 13:32

viewer   ~0008615

The workaround works


2019-09-24 00:11

administrator   ~0008622

Several have confirmed this fix. Thanks.


2019-10-08 14:29

administrator   ~0008770

Last edited: 2019-10-09 09:38

View 2 revisions

This was confirmed fixed in I confirmed it and Ron Whitsel confirmed it and many others confirmed it, but it is now broken again in the build. This is also broken in I will be back later to enter more information about this. I'm re-opening this so Ferry can post his findings also.


2019-10-09 09:43

viewer   ~0008773

The problem lies in using QSO forwarding with WSJT-X

WSJT-X Sends ADIF Data as Mode:MFSK Submode:FT4
This causes Logbook to add the QSO as MFSK

Need a workaround so Logbook looks at the Submode string send over via QSO Forwarding.


2019-10-10 05:43

viewer   ~0008775

So logging with JTALERT-X sends Mode FT4
<call:4>LY5O <gridsquare:4>KO14 <mode:4>MFSK <submode:3>FT4 <rst_sent:3>-03 <rst_rcvd:3>-07 <qso_date:8>20190923 <time_on:6>165138 <qso_date_off:8>20190923 <time_off:6>165337 <band:3>20m <freq:9>14.080840 <station_callsign:6>PD9FER <my_gridsquare:6>JO22OQ <tx_pwr:2>15 <comment:33>Tnx for FT4 Contact, 73 de PD9FER <operator:6>PD9FER <eor>

But WSJT-X via QSO Forwarding produces MFSK
<call:4>LY5O <gridsquare:4>KO14 <mode:4>MFSK <submode:3>FT4 <rst_sent:3>-03 <rst_rcvd:3>-07 <qso_date:8>20190923 <time_on:6>165138 <qso_date_off:8>20190923 <time_off:6>165337 <band:3>20m <freq:9>14.080840 <station_callsign:6>PD9FER <my_gridsquare:6>JO22OQ <tx_pwr:2>15 <comment:33>Tnx for FT4 Contact, 73 de PD9FER <operator:6>PD9FER <eor>


2019-10-10 05:47

viewer   ~0008776

I made a mistake in my above comment....
The JTALERT-X data is:
QSO<EOH><CALL:4>LY5O<QSO_DATE:8>20190923<TIME_ON:6>165100<TIME_OFF:6>165300<FREQ:8>14.08084<FREQ_RX:8>14.08084<BAND:3>20m<BAND_RX:3>20m<MODE:3>FT4<RST_SENT:3>-03<RST_RCVD:3>-07<QSL_SENT:1>N<QSL_RCVD:1>N<NAME:7>Bronius<QTH:8>Amerikos<CQZ:2>15<ITUZ:2>29<PFX:3>LY5<CONT:2>EU<DXCC:3>146<COUNTRY:9>Lithuania<GRIDSQUARE:6>KO14wv<DISTANCE:4>1247<TX_PWR:1>5<A_INDEX:1>0<K_INDEX:1>0<SFI:1>0<COMMENT:33>Tnx for FT4 Contact, 73 de PD9FER<MY_GRIDSQUARE:6>JO22OQ<MY_CQ_ZONE:2>14<MY_ITU_ZONE:2>27<STATION_CALLSIGN:6>PD9FER<OPERATOR:6>PD9FER<QSO_COMPLETE:1>Y<EOR>



2019-10-10 06:35

administrator   ~0008777

What I'm seeing here we are chasing our tails. We have people using JTAlert and JTAlert logs to LB and logs the MODE as FT4. Here is an ADI from JTAlert. Take note of the <MODE:3>FT4 field with NO <submode> field.

<CALL:4>LY5O<QSO_DATE:8>20190923<TIME_ON:6>165100<TIME_OFF:6>165300<FREQ:8>14.08084<FREQ_RX:8>14.08084<BAND:3>20m<BAND_RX:3>20m<MODE:3>FT4<RST_SENT:3>-03<RST_RCVD:3>-07<QSL_SENT:1>N<QSL_RCVD:1>N<NAME:7>Bronius<QTH:8>Amerikos<CQZ:2>15<ITUZ:2>29<PFX:3>LY5<CONT:2>EU<DXCC:3>146<COUNTRY:9>Lithuania<GRIDSQUARE:6>KO14wv<DISTANCE:4>1247<TX_PWR:1>5<A_INDEX:1>0<K_INDEX:1>0<SFI:1>0<COMMENT:33>Tnx for FT4 Contact, 73 de PD9FER<MY_GRIDSQUARE:6>JO22OQ<MY_CQ_ZONE:2>14<MY_ITU_ZONE:2>27<STATION_CALLSIGN:6>PD9FER<OPERATOR:6>PD9FER<QSO_COMPLETE:1>Y<EOR>

Here is the very same contact being logged using QSO FWD. Note that <mode:4>MFSK <submode:3>FT4. This is completely different from the way it's logged from JTAlert.

<call:4>LY5O <gridsquare:4>KO14 <mode:4>MFSK <submode:3>FT4 <rst_sent:3>-03 <rst_rcvd:3>-07 <qso_date:8>20190923 <time_on:6>165138 <qso_date_off:8>20190923 <time_off:6>165337 <band:3>20m <freq:9>14.080840 <station_callsign:6>PD9FER <my_gridsquare:6>JO22OQ <tx_pwr:2>15 <comment:33>Tnx for FT4 Contact, 73 de PD9FER <operator:6>PD9FER <eor>

The way QSO FWD is handling the <mode:4>MFSK <submode:3>FT4 is the correct way this should be handled, however, since we don't have a "submode" field in our logbook, we need the qso to be logged so that the <submode:3>FT4 shows up in the "Mode" column of the HRD Logbook when we are logging using the QSO FWD. This way both the logging from JTAlert AND QSO FWD are logging the same in our logbook.

In our Logbook, when the contact is logged, we need it to show as "FT4" in the Mode field for 2 reasons. #1 - Since we don't have the "Mode" and "Submode" fields, we need to have "FT4" indicated in the "Mode" field so we can identify the contact as an FT4 contact at a later date. #3 - If our log shows these FT4 contacts as "MFSK" in the Mode column, if we have logged contacts we actually work in the MFSK mode, and have that logged for those contacts, in the future when we look at our logbooks, how are we going to tell which are FT4 contacts and which are true MFSK contacts?

For more evidence that we are logging incorrectly, please see the test Ron Whitsel and I did in OSTicket #803567.


2019-10-10 06:40

viewer   ~0008778

We need to add some code that monitors QSO Forwarding .
When something with Submode FT4 is seen, then set Mode to FT4 (rewrite the Mode)


2019-10-10 16:18

developer   ~0008786

This issue is about matching the FT4 mode in LOTW downloads. Change set #5155 hasn't been removed, and exercising the repro steps I post in comment #8481 above still pass.

If there's still an issue with LOTW downloads handing FT4, please write up some repro steps and a description and re-activete this issue.

If there's a problem with FT4 in other areas of the product, such as QSO Forwarding, please write up the details and open a new Mantis issue with that information. Keeping each problem documented in its own Mantis issue helps communication, makes testing easier, and expedites the process of fixing the software.


2019-10-18 06:45

viewer   ~0008861

See Mantis 3504


2019-10-23 04:45

viewer   ~0008952

Unable to test.


2019-10-23 07:51

administrator   ~0008965

Is it resolved or not? I hear that it's not.


2019-10-23 09:00

viewer   ~0008978

See 3504

Guess this one is only about adding FT4 > FT4 to the Default modes.
If that is true, this is fixed, need to continue with 3504 for the QSO FWD issue


2019-10-23 21:40

administrator   ~0008997

I'll accept this as validated.

We need to turn our attention to 0003504.

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
2019-09-23 05:09 g3ucq Note Added: 0008593
2019-09-23 13:32 PD9FER Note Added: 0008615
2019-09-24 00:11 WA9PIE Status resolved => closed
2019-09-24 00:11 WA9PIE Testing Not Started => Beta Successful
2019-09-24 00:11 WA9PIE Note Added: 0008622
2019-10-08 14:29 KB3NPH Note Added: 0008770
2019-10-09 09:38 KB3NPH Note Edited: 0008770 View Revisions
2019-10-09 09:39 KB3NPH Assigned To PD9FER => K7ZCZ
2019-10-09 09:39 KB3NPH Status closed => new
2019-10-09 09:39 KB3NPH Resolution fixed => reopened
2019-10-09 09:43 PD9FER Note Added: 0008773
2019-10-10 05:43 PD9FER Note Added: 0008775
2019-10-10 05:47 PD9FER Note Added: 0008776
2019-10-10 06:35 KB3NPH Note Added: 0008777
2019-10-10 06:40 PD9FER Note Added: 0008778
2019-10-10 16:18 K7ZCZ Status new => resolved
2019-10-10 16:18 K7ZCZ Resolution reopened => fixed
2019-10-10 16:18 K7ZCZ Note Added: 0008786
2019-10-10 16:18 K7ZCZ Assigned To K7ZCZ => PD9FER
2019-10-18 06:45 PD9FER Note Added: 0008861
2019-10-18 06:46 PD9FER Relationship added related to 0003504
2019-10-23 04:45 g3ucq Note Added: 0008952
2019-10-23 07:51 WA9PIE Note Added: 0008965
2019-10-23 09:00 PD9FER Note Added: 0008978
2019-10-23 21:40 WA9PIE Status resolved => closed
2019-10-23 21:40 WA9PIE Note Added: 0008997
2019-11-08 02:13 WA9PIE Fixed in Version =>
2019-11-08 02:32 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe