I joined the ADIF community after the introduction of SUBMODE, version 3 I think. But from some of the discussion, I understand it was an attempt to get a handle on the growing proliferation
of new modes. MODE was an attempt at being limited to modulation technique, and SUBMODE defining the coding.?
So modes like LSB became MODE=SSB, SUBMODE=LSB. And the digital modes similarly. At the time MODE=LSB became deprecated, and allowed to be imported from files created? by unmaintained legacy
apps, but all apps being developed should export it as MODE=SSB, SUBMODE=LSB.?
With the new HELL modes, unfortunately there is no legacy mode to deprecate.?
The Mode change is still occasionally raises its head in the ADIF discussion forum. Most users want to see a single QSO field 'Mode'. And to that extent all SUBMODE values are unique as a 'recommended
' enumeration list. Any app can maintain a single field in its internal database as long as it gets exported as two fields.
It's a can of worms. For my logging app I accept both strict and deprecated values for the mode. And export strict.?
73 Phil GM3ZZA
On 13 November 2024, at 17:35, "Barry, PC1K via?"?<barry@...>?wrote:
Unfortunately just lost my Apple silicon mac last week.
>?but this change was forced upon us by the current ADIF
I know, because I started the discussion, my aim was to make logging more consistent. Before the change I have seen a FSKH105 QSO logged as HELL, FSKH105 and FSKHELL, this causes confirmations not
to happen. In addition LoTW refuses to log FSKH105 (sometimes) as it is not ADIF compliant. This is being worked on in the next ADIF release.
When I look at the ADIF specification, it does not say one can use a submode in the mode field, this is how fldigi implemented it before, and funny enough is also what??does:
Exports as follows:
QRZLogbook download for pc1k
??? Date: Wed Nov 13 17:22:32 2024
??? Bookid: 354929
??? Records: 1
??? <ADIF_VER:5>3.1.1
????<PROGRAMID:10>QRZLogbook
????<PROGRAMVERSION:3>2.0
??? <eoh>
<time_on:4>1721
<my_lon:11>E004 12.400
<eqsl_qsl_sent:1>N
<app_qrzlog_status:1>N
...
<my_lat:11>N052 03.700
<cqz:2>14
<qso_date:8>20241113
<cont:2>EU
<freq:7>7.07498
<tx_pwr:2>20
<lotw_qsl_rcvd:1>N
<mode:7>FSKHELL?????? <- it is not ADIF compliant
<qsl_rcvd:1>N
<app_qrzlog_logid:10>1177766696
<dxcc:3>263
...
<band_rx:3>40m
<eor>
I wonder why submode was added to the ADIF standard??
A good fix for fldigi IMHO would be to also have submode in the logbook.adi and preferably in the UI. So I can still know if a QSO was made in FELD HELL or FSKHELL, because these modes have different
characteristics. I don't need the submode to reflect in?, even though that would be nice. This we did not discuss before implementing
the change in fldigi 4.2.06.
?
Maybe I made everything worse by starting the discussion, if the submode field is not implemented in many applications. In any case thanks for your help, fldigi is great!
73 de PC1K
?
?
On 13-11-2024 17:12, Dave, W1HKJ wrote:
I will look again at the code, but this change was forced upon us by the current ADIF specification.
David
On 11/12/24 22:08, Barry, PC1K via??wrote:
Hello,?
Today I got around to testing fldigi 4.2.06, specifically:?
With this patch, when I log a QSO in FSKH105, fldigi logs HELL in the mode field, which is correct.?
However the submode field, is not in logbook.adi, nor do I see it anywhere else in the UI. This means that all Hell contacts will be logged as HELL regardless of submode. Is there a way to configure fldigi so that it stores the submode to logbook.adi and preferably
show the submode in the UI??
Thanks, Barry?
Gary WA4YMZ