Topics

Importing an ADIF file


Knut Meland
 

Why does not DXLab follow the ADIF standard?
According to this standard SSB is a mode and USB and LSB submodes. See:
http://www.adif.org.uk/311/ADIF_311.html
I encountered problems with this when handling a file export. I edited it in LogConverter (shareware) and had all my LSB and USB QSOs listed in the error file when I tried to save under a new file name. Frankly, I did not know that USB and LSB are just submodes in the ADIF standard. But they are. The mode is SSB!
If we get an update of DXKeeper on this, I hope we will have a script file to help us update our log files.
73 de LA9RY Knut 


Dave AA6YQ
 

+ AA6YQ comments below
According to this standard SSB is a mode and USB and LSB submodes. See:
http://www.adif.org.uk/311/ADIF_311.html
I encountered problems with this when handling a file export. I edited it in LogConverter (shareware) and had all my LSB and USB QSOs listed in the error file when I tried to save under a new file name. Frankly, I did not know that USB and LSB are just submodes in the ADIF standard. But they are. The mode is SSB!
If we get an update of DXKeeper on this, I hope we will have a script file to help us update our log files.

+ Please post an example of one ADIF record that DXKeeper rejected?

     73,

            Dave, AA6YQ

 


Dave AA6YQ
 

+ AA6YQ comments below
Why does not DXLab follow the ADIF standard?
According to this standard SSB is a mode and USB and LSB submodes. See:
http://www.adif.org.uk/311/ADIF_311.html
I encountered problems with this when handling a file export. I edited it in LogConverter (shareware) and had all my LSB and USB QSOs listed in the error file when I tried to save under a new file name. Frankly, I did not know that USB and LSB are just submodes in the ADIF standard. But they are. The mode is SSB!
If we get an update of DXKeeper on this, I hope we will have a script file to help us update our log files.

+ When I import this ADIF record:

<Band:3>40M 
<Call:6>KP4JRS 
<DXCC:3>202 
<Freq:5>7.047 
<Mode:3>SSB 
<SUBMODE:3>LSB 
<QSO_DATE:8>20091124 
<TIME_OFF:6>010927 
<TIME_ON:6>010927 
<RST_Rcvd:3>599 
<RST_Sent:3>599 
<TX_PWR:6>1500.0
<PROP_MODE:2>F2 
<STATION_CALLSIGN:5>AA6YQ
<EOR>

+ DXKeeper correctly added a QSO whose MODE is SSB and whose SUBMODE is LSB.

+ I'm anxious to see the ADIF for one of the SSB QSOs that you imported.

         73,

                 Dave, AA6YQ

 


Dave AA6YQ
 

* more AA6YQ comments below
+ DXKeeper correctly added a QSO whose MODE is SSB and whose SUBMODE is LSB.

* And when I exported the new QSO to a second ADIF file, that file correctly specifies the MODE and SUBMODE.

         73,

                Dave, AA6YQ


Knut Meland
 

Good to know, Dave. It seems that the problem has to be solved in Log Converter, making SSB mode and USB/LSB submode.

73 de Knut LA9RY

Den 10.11.2020 03.03, skrev Dave AA6YQ:

* more AA6YQ comments below
+ DXKeeper correctly added a QSO whose MODE is SSB and whose SUBMODE is LSB.

* And when I exported the new QSO to a second ADIF file, that file correctly specifies the MODE and SUBMODE.

         73,

                Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below

Good to know, Dave. It seems that the problem has to be solved in Log Converter, making SSB mode and USB/LSB submode.

+ What led you to ask "Why does not DXLab follow the ADIF standard?"

+ From what format are you converting QSOs to ADIF?

73,

Dave, AA6YQ


3a2mw Franco Lucioni
 

Hi Dave and the Group,
The problem could be in old QSOs. Exporting them from DXK in Standard ADIF, they are all SSB with no submode. I stopped SSB in 2014 and the last QSO, registered with DXKeeper, has no submode (like the other 9529, starting in 2000). The DXKeeper export of this last follows:
<Band:3>20M <Call:4>9Y4D <APP_DXKEEPER_DXCCPREFIX:2>9Y <DXCC:2>90 <Freq:8>14.13461 <Mode:3>SSB <Name:11>Christopher <Operator:5>3A2MW <QSO_DATE:8>20140307 <TIME_OFF:6>190710 <TIME_ON:6>190710 <QTH:12>San Fernando <RST_Rcvd:2>59 <RST_Sent:2>59 <TX_PWR:5>100.0 <CONT:2>SA <ITUZ:2>11 <CQZ:1>9 <IOTA:6>SA-011 <GRIDSQUARE:6>FK90gg <PFX:3>9Y4 <PROP_MODE:2>F2 <STATION_CALLSIGN:5>3A2MW <OWNER_CALLSIGN:5>3A2MW <DISTANCE:7>7530.84 <LAT:11>N010 16.250 <LON:11>W061 27.500 <APP_DXKeeper_LotW_MEMBER:1>Y <APP_DXKeeper_EQSL_MEMBER:1>A <QSL_SENT_VIA:1>B <QSL_RCVD_VIA:1>B <ANT_PATH:1>S <APP_DXKeeper_SELECT:1>Y <LOTW_QSL_SENT:1>Y <LOTW_QSL_RCVD:1>V <APP_DXKEEPER_LOTW_VERIFIED:1>V <LOTW_QSLSDATE:8>20140907 <LOTW_QSLRDATE:8>20140907 <APP_DXKeeper_ClubLog:1>Y <APP_DXKeeper_ClubLogDate:19>2015-04-14 17:28:50 <APP_DXKeeper_LotWConfirmation:3>GMZ <APP_DXKeeper_DXCCCreditNumber:10>605849963L <CREDIT_GRANTED:41>DXCC:LOTW, DXCC_BAND:LOTW, DXCC_MODE:LOTW <APP_DXKEEPER_MY_QTHID:6>Monaco <EOR>
Maybe could be useful a table, determining the LSB/USB submode depending on the band and a script to apply to the whole log.
73
Franco 3A2MW


Dave AA6YQ
 

+ AA6YQ comments below

Hi Dave and the Group,

The problem could be in old QSOs.

+ What is the "problem", exactly?

Exporting them from DXK in Standard ADIF, they are all SSB with no submode. I stopped SSB in 2014 and the last QSO, registered with DXKeeper, has no submode (like the other 9529, starting in 2000). The DXKeeper export of this last follows:
<Band:3>20M <Call:4>9Y4D <APP_DXKEEPER_DXCCPREFIX:2>9Y <DXCC:2>90 <Freq:8>14.13461 <Mode:3>SSB <Name:11>Christopher <Operator:5>3A2MW <QSO_DATE:8>20140307 <TIME_OFF:6>190710 <TIME_ON:6>190710 <QTH:12>San Fernando <RST_Rcvd:2>59 <RST_Sent:2>59 <TX_PWR:5>100.0 <CONT:2>SA <ITUZ:2>11 <CQZ:1>9 <IOTA:6>SA-011 <GRIDSQUARE:6>FK90gg <PFX:3>9Y4 <PROP_MODE:2>F2 <STATION_CALLSIGN:5>3A2MW <OWNER_CALLSIGN:5>3A2MW <DISTANCE:7>7530.84 <LAT:11>N010 16.250 <LON:11>W061 27.500 <APP_DXKeeper_LotW_MEMBER:1>Y <APP_DXKeeper_EQSL_MEMBER:1>A <QSL_SENT_VIA:1>B <QSL_RCVD_VIA:1>B <ANT_PATH:1>S <APP_DXKeeper_SELECT:1>Y <LOTW_QSL_SENT:1>Y <LOTW_QSL_RCVD:1>V <APP_DXKEEPER_LOTW_VERIFIED:1>V <LOTW_QSLSDATE:8>20140907 <LOTW_QSLRDATE:8>20140907 <APP_DXKeeper_ClubLog:1>Y <APP_DXKeeper_ClubLogDate:19>2015-04-14 17:28:50 <APP_DXKeeper_LotWConfirmation:3>GMZ <APP_DXKeeper_DXCCCreditNumber:10>605849963L <CREDIT_GRANTED:41>DXCC:LOTW, DXCC_BAND:LOTW, DXCC_MODE:LOTW <APP_DXKEEPER_MY_QTHID:6>Monaco <EOR>

+ DXKeeper exports the information you recorded in each logged QSO. If you didn't record a SUBMODE item in a logged QSO, DXKeeper won't include a SUBMODE field in the ADIF record exported from that QSO. Similar behavior occurs if you don't record your QSO partner's name.

Maybe could be useful a table, determining the LSB/USB submode depending on the band and a script to apply to the whole log.

+ To fill in missing SSB SUBMODE items based on frequency (assuming you always followed the 10 MHz sideband convention),

1. Backup your log (Configuration window, Log tab, Backup button)

2. filter the Log Page Display with the SQL expression

(LEN(APP_DXKEEPER_SUBMODE)=0) and (MODE='SSB') and (FREQ<10)

3. use the "Advanced Sorts, Filters, and Modifiers" window's "Modify QSOs" panel to set APP_DXKEEPER_SUBMODE to LSB in all QSOs in the Log Page Display; see

<https://www.dxlabsuite.com/dxlabwiki/QSOModifying>.

4. filter the Log Page Display with the SQL expression

(LEN(APP_DXKEEPER_SUBMODE)=0) and (MODE='SSB') and (FREQ>10)

5. use the "Advanced Sorts, Filters, and Modifiers" window's "Modify QSOs" panel to set APP_DXKEEPER_SUBMODE to USB in all QSOs in the Log Page Display

+ A script could be constructed to implement the above actions.

+ Why is DXKeeper's SUBMODE item named APP_DXKEEPER_SUBMODE? Because DXKeeper supported a SUBMODE item before ADIF did. When the SUBMODE field was added to ADIF, I extended DXKeeper to import and export SUBMODE fields in ADIF QSO records to and from each QSO's APP_DXKEEPER_SUBMODE items, respectively.

+ DXKeeper could be extended to record USB and LSB as the SUBMODE in SSB QSOs. No one has requested this. Is there a reason to do so?

73,

Dave, AA6YQ


Knut Meland
 

Den 10.11.2020 08.05, skrev Dave AA6YQ:
+ AA6YQ comments below

Good to know, Dave. It seems that the problem has to be solved in Log Converter, making SSB mode and USB/LSB submode.

+ What led you to ask "Why does not DXLab follow the ADIF standard?"
In my DXKeeper log - imported from DXBase via ADIF the SSB QSOs show "SSB" in mode field and nothing in Submode field. I did not dive deeper into this.

73 de Knut LA9RY


+ From what format are you converting QSOs to ADIF?

73,

Dave, AA6YQ







Dave AA6YQ
 

* more AA6YQ comments below


Den 10.11.2020 08.05, skrev Dave AA6YQ:
+ AA6YQ comments below

Good to know, Dave. It seems that the problem has to be solved in Log Converter, making SSB mode and USB/LSB submode.

+ What led you to ask "Why does not DXLab follow the ADIF standard?"
In my DXKeeper log - imported from DXBase via ADIF the SSB QSOs show "SSB" in mode field and nothing in Submode field.

* Did the SSB QSO records imported from DXBase contain SUBMODE tags?

73,

Dave, AA6YQ


3a2mw Franco Lucioni
 

Thanks Dave, I applied the SQL expressions, and I could correct my log.
My question is now: is it compulsory having the submodes LSB & USB in an ADIF 3.1.1 compliant export file?
Thanks!
Franco 3A2MW


Peter Laws / N5UWY
 

On Wed, Nov 11, 2020 at 2:35 AM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ To fill in missing SSB SUBMODE items based on frequency (assuming you always followed the 10 MHz sideband convention),
(LEN(APP_DXKEEPER_SUBMODE)=0) and (MODE='SSB') and (FREQ<10)

Seems imprecise in 2020. There are only 3 bands where LSB is the
default, 160/80/40 m. Some "linear" satellites, too, use LSB on the
uplink, but those are probably safe to ignore. Not 100% certain which
sideband is being suppressed along with the carrier on the new bands
(2200, 630) but would hope folks there are using USB 'phone like
everywhere else.

--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!


Dave AA6YQ
 

+ AA6YQ comments below

Thanks Dave, I applied the SQL expressions, and I could correct my log.

My question is now: is it compulsory having the submodes LSB & USB in an ADIF 3.1.1 compliant export file?

+ No. Just like it's not compulsory having your QSO partner's name in ADIF 3.1.3-compliant file.

+ The ADIF specification means "If you're going to export information about X, do so using tag Y and format Z". There is not even specification of a minimum set of fields to be present in a QSO record; I proposed such a requirement ~15 years ago, but it was rejected (by vote). So this QSO record is valid ADIF:

<NAME:6>Franco<EOR>

73,

Dave, AA6YQ


Dave AA6YQ
 

* more AA6YQ comments below

On Wed, Nov 11, 2020 at 2:35 AM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ To fill in missing SSB SUBMODE items based on frequency (assuming
+ you always followed the 10 MHz sideband convention),
(LEN(APP_DXKEEPER_SUBMODE)=0) and (MODE='SSB') and (FREQ<10)

Seems imprecise in 2020. There are only 3 bands where LSB is the default, 160/80/40 m. Some "linear" satellites, too, use LSB on the uplink, but those are probably safe to ignore. Not 100% certain which sideband is being suppressed along with the carrier on the new bands (2200, 630) but would hope folks there are using USB 'phone like everywhere else.

* Is it imprecise to not log your QSO partner's shoe size?

73,

Dave, AA6YQ


iain macdonnell - N6ML
 

On Wed, Nov 11, 2020 at 9:42 AM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

* more AA6YQ comments below

On Wed, Nov 11, 2020 at 2:35 AM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ To fill in missing SSB SUBMODE items based on frequency (assuming
+ you always followed the 10 MHz sideband convention),
(LEN(APP_DXKEEPER_SUBMODE)=0) and (MODE='SSB') and (FREQ<10)

Seems imprecise in 2020. There are only 3 bands where LSB is the default, 160/80/40 m. Some "linear" satellites, too, use LSB on the uplink, but those are probably safe to ignore. Not 100% certain which sideband is being suppressed along with the carrier on the new bands (2200, 630) but would hope folks there are using USB 'phone like everywhere else.

* Is it imprecise to not log your QSO partner's shoe size?
I think the point was that assuming that all SSB QSOs made below 10MHz
used LSB may not be entirely accurate. One case where it is probably
inaccurate is the 60m band. I'm not sure if there are others - e,g,
those experimental bands mentioned.

73,

~iain / N6ML


Peter Laws / N5UWY
 

On Wed, Nov 11, 2020 at 11:49 AM iain macdonnell - N6ML <ar@dseven.org> wrote:


I think the point was that assuming that all SSB QSOs made below 10MHz
used LSB may not be entirely accurate. One case where it is probably
inaccurate is the 60m band. I'm not sure if there are others - e,g,
those experimental bands mentioned.
Right. 60 m is limited to USB by regulation (for a while that was the
ONLY mode permitted). I don't know how much, if any, 'phone is being
used on 2200 and 630 (which are regular bands now) is being done -
2200 m hardly seems wide enough for analog phone of any type as it's
only 2100 Hz wide! I would hope that if SSB is used that it would be
USB like the rest of the spectrum, amateur or otherwise. Neither band
is balkanized by mode in Part 97 as most of HF is so it will be
interesting to see how it shakes out.

Still "(BAND='160m' OR BAND='80m' OR BAND='40m')" seems less ambiguous.

--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!


Dave AA6YQ
 

+ AA6YQ comments below
Right. 60 m is limited to USB by regulation (for a while that was the
ONLY mode permitted). I don't know how much, if any, 'phone is being
used on 2200 and 630 (which are regular bands now) is being done -
2200 m hardly seems wide enough for analog phone of any type as it's
only 2100 Hz wide! I would hope that if SSB is used that it would be
USB like the rest of the spectrum, amateur or otherwise. Neither band
is balkanized by mode in Part 97 as most of HF is so it will be
interesting to see how it shakes out.

Still "(BAND='160m' OR BAND='80m' OR BAND='40m')" seems less ambiguous.

+ Good point, as I'd forgotten about 60m. Iain N6ML is correct that the conventions are not always followed.

+ The question is still "why is this information useful to record?".

     73,

            Dave, AA6YQ


Peter Laws / N5UWY
 

On Wed, Nov 11, 2020 at 12:23 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:


+ Good point, as I'd forgotten about 60m. Iain N6ML is correct that the conventions are not always followed.

+ The question is still "why is this information useful to record?".

No idea! All my drama was predicated on "someone thinks it's important". :-)



--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!


Dave AA6YQ
 

+ AA6YQ comments below
No idea! All my drama was predicated on "someone thinks it's important". :-)

+ SUBMODE is not presently accessible via the Capture window. Properly supporting USB and LSB as submodes would mean replacing SSB in the mode selectors with USB and LSB, and then updating all of the code that previously looked for SSB to look for USB and LSB. Not rocket science, but a significant development and testing task that if taken on would delay other efforts that will deliver value.

+ If there were awards or operating activities that distinguish between USB and LSB, I'd have done this years ago; to my knowledge, there aren't.

      73,

             Dave. AA6YQ


Peter Laws / N5UWY
 

On Wed, Nov 11, 2020 at 1:29 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:


+ SUBMODE is not presently accessible via the Capture window. Properly supporting USB and LSB as submodes would mean replacing SSB in the mode selectors with USB and LSB, and then updating all of the code that previously looked for SSB to look for USB and LSB. Not rocket science, but a significant development and testing task that if taken on would delay other efforts that will deliver value.

+ If there were awards or operating activities that distinguish between USB and LSB, I'd have done this years ago; to my knowledge, there aren't.
It's not important to *me* but I assumed someone was jonesing for it.
And understand about the lack of awards for it (thank goodness).

To that end, I encourage *everyone* to stop using LSB anywhere ... :-)



--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!