Date   

Re: CQ 160 SSB contest submit problem

Phil W9IXX
 

Hi,

Tnx Dave and I used the Capture window in DXKeeper. Did not see anything in
the window that said "RX#". From memory it would show the state in the area
that said "pri sub". I think in the contest mode it that area said "state or prov".

When I imported my ADIF file into N1MM after the test, I did a Cabrillo generation
but the state never showed up. Sounds like there should be a header called "Exch" or
something like that in the ADIF file. My ADIF file shows the state in header called "state"

Sorry for such a minor item.
Tnx agn.
Phil W9IXX


Re: sorting out Log to LotW discrepancies

David Reed
 

Thank you sir; will get right on it!

73 de W5SV - David F. Reed

On Mar 7, 2021, at 20:47, Dave AA6YQ <aa6yq@...> wrote:

Assuming that the table in your post below was generated when you clicked the Compare button in the "DXCC, Challenge, TopList" panel on the "Check Progress" tab of DXKeeper's Configuration window, that's not and indication of how well your log and LoTW match. As described in

http://dxlabsuite.com/dxkeeper/Help/Progress.htm#Verification%20discrepancies

the Compare function displays discrepancies between DXCC award credit shown as granted in your logged QSOs, and DXCC award credit shown as granted in your DXCC record - as maintained by the ARRL.

19 of the 20 discrepancies listed are cases in which your DXCC record contains no credit granted, but a logged QSO shows DXCC credit granted: either its "QSL Rcvd" or "LoTW QSL Rcvd" item is set to 'V'. For each of these 19 discrepancies, determine why each is marked "DXCC credit granted" when there is no such credit shown in your DXCC record: either its "QSL Rcvd" or "LoTW QSL Rcvd" item was erroneously set to 'V', or your DXCC record is in error. If the former, change the erroneous status item from 'V' to 'Y'; if the latter, engage with the ARRL's DXCC desk (dxccadmin {at} arrl.org) and request a correction.

In the case of "Guadeloupe on 20m", your DXCC record shows that DXCC credit has been granted, but no logged 20m QSO with Guadeloupe has its "QSL Rcvd" or "LoTW QSL Rcvd" item set to 'V'. Determine which 20m QSO with Guadeloupe you submitted in a DXCC award application, and change its "QSL Rcvd" or "LoTW QSL Rcvd" item from 'Y' to 'V', depending upon whether you submitted a QSL card or LoTW confirmation, respectively.

       73,

              Dave, AA6YQ

 

On Sun, Mar 7, 2021 at 03:11 PM, David Reed wrote:

Hi folks; taking a break from the contest for a few moments; I thought "I wonder how well my log and LotW match?" so I ran the report to identify any.

No surprise that I have some; my problem is to figure out what to do about them so both are correct and no discrepancies are reported...

Here is what it looks like:

   Entity Prefix     Band or Mode     Log Status    ARRL Status    Entity Code   Entity


               5R              20m              V -            438   Madagascar
               DA            Phone V             81   Germany (deleted)
               DA            Mixed V             81   Germany (deleted)
               FG              20m              W V             79   Guadeloupe
               FG              15m              V -             79   Guadeloupe
              FO0               CW              V -             36   Clipperton Island
               FW              15m              V -            298   Wallis & Futuna Islands
               GD              17m              V -            114   Isle Of Man
             HK0S            Phone V            228   Serrana Bank & Roncador Cay (deleted)
             HK0S            Mixed V            228   Serrana Bank & Roncador Cay (deleted)
              KH6              12m              V -            110   Hawaii
              KH6          Digital              V -            110   Hawaii
              KZ5            Phone V             28   Canal Zone (deleted)
              KZ5            Mixed V             28   Canal Zone (deleted)
               OK            Phone V            218   Czechoslovakia (deleted)
               OK            Mixed V            218   Czechoslovakia (deleted)
               P4               CW              V -             91   Aruba
              YV0            Phone V             17   Aves Island
              YV0            Mixed V             17   Aves Island
               ZS              80m              V -            462   Republic of South Africa


Re: sorting out Log to LotW discrepancies

Dave AA6YQ
 

Assuming that the table in your post below was generated when you clicked the Compare button in the "DXCC, Challenge, TopList" panel on the "Check Progress" tab of DXKeeper's Configuration window, that's not and indication of how well your log and LoTW match. As described in

http://dxlabsuite.com/dxkeeper/Help/Progress.htm#Verification%20discrepancies

the Compare function displays discrepancies between DXCC award credit shown as granted in your logged QSOs, and DXCC award credit shown as granted in your DXCC record - as maintained by the ARRL.

19 of the 20 discrepancies listed are cases in which your DXCC record contains no credit granted, but a logged QSO shows DXCC credit granted: either its "QSL Rcvd" or "LoTW QSL Rcvd" item is set to 'V'. For each of these 19 discrepancies, determine why each is marked "DXCC credit granted" when there is no such credit shown in your DXCC record: either its "QSL Rcvd" or "LoTW QSL Rcvd" item was erroneously set to 'V', or your DXCC record is in error. If the former, change the erroneous status item from 'V' to 'Y'; if the latter, engage with the ARRL's DXCC desk (dxccadmin {at} arrl.org) and request a correction.

In the case of "Guadeloupe on 20m", your DXCC record shows that DXCC credit has been granted, but no logged 20m QSO with Guadeloupe has its "QSL Rcvd" or "LoTW QSL Rcvd" item set to 'V'. Determine which 20m QSO with Guadeloupe you submitted in a DXCC award application, and change its "QSL Rcvd" or "LoTW QSL Rcvd" item from 'Y' to 'V', depending upon whether you submitted a QSL card or LoTW confirmation, respectively.

       73,

              Dave, AA6YQ

 

On Sun, Mar 7, 2021 at 03:11 PM, David Reed wrote:

Hi folks; taking a break from the contest for a few moments; I thought "I wonder how well my log and LotW match?" so I ran the report to identify any.

No surprise that I have some; my problem is to figure out what to do about them so both are correct and no discrepancies are reported...

Here is what it looks like:

   Entity Prefix     Band or Mode     Log Status    ARRL Status    Entity Code   Entity


               5R              20m              V -            438   Madagascar
               DA            Phone V             81   Germany (deleted)
               DA            Mixed V             81   Germany (deleted)
               FG              20m              W V             79   Guadeloupe
               FG              15m              V -             79   Guadeloupe
              FO0               CW              V -             36   Clipperton Island
               FW              15m              V -            298   Wallis & Futuna Islands
               GD              17m              V -            114   Isle Of Man
             HK0S            Phone V            228   Serrana Bank & Roncador Cay (deleted)
             HK0S            Mixed V            228   Serrana Bank & Roncador Cay (deleted)
              KH6              12m              V -            110   Hawaii
              KH6          Digital              V -            110   Hawaii
              KZ5            Phone V             28   Canal Zone (deleted)
              KZ5            Mixed V             28   Canal Zone (deleted)
               OK            Phone V            218   Czechoslovakia (deleted)
               OK            Mixed V            218   Czechoslovakia (deleted)
               P4               CW              V -             91   Aruba
              YV0            Phone V             17   Aves Island
              YV0            Mixed V             17   Aves Island
               ZS              80m              V -            462   Republic of South Africa


Re: NEED HELP IN GETTING COMMANDER WORKING

Dave AA6YQ
 

+ AA6YQ comments below

Dave: Last night I had WW working in AFSK. I could receive and decode I could press the transmit button (in WW) and it would key the
radio, send diddles, with RF out. I could type in RY's TEST then my call in the transmit window and it would transmit that. Today, I
could not duplicate WW working on AFSK.

OK, so today (starting over) I started Launcher, and Commander. Pressing the TX button in commander keyed the radio, produced a
single tone and I did get RF out. I then started WW, which changed the radio to LSB, and I press the TX button in WW. It did not key
the radio and did not produce a tone or any RF even though the software thought it was transmitting. When I checked port five, the
port used to control the radio, WW said it was not available. I'm guessing that is because it was being used by commander. ??

You sent me a link to "Configuring WinWarbler for RTTY Operation" which I followed religiously (both AFSK and FSK) but, it did not
work. I also tried the radio in D1, D2 & D3 but that made no difference. Throughout all of these tests, I could receive and decode
RTTY in WW. I even tried the K0PIR video for N1MM with MMTTY with same lack of results.

+ The article "Configuring WinWarbler for RTTY Operation" does not cover configuring WinWarbler for RX-TX switching (aka "PTT");
that's described in "Switching a Transceiver between Reception and Transmission" in

https://www.dxlabsuite.com/dxlabwiki/PTTMechanism

+ My assumption was that anyone wishing to use WinWarbler would first review "Setting up CW, Phone, PSK, and RTTY Operation in
WinWarbler" in

https://www.dxlabsuite.com/dxlabwiki/Multimode_Setup

+ which introduces configuration topics common to all modes: RX-TX switching, audio connections, and setting audio levels. See the
RTTY subsection in the "General Setup Instructions" section of this article.

+ To prevent this from happening again, I have added a "Configuration Steps You May Have Already Taken" section to the beginning of

"Configuring WinWarbler for RTTY Operation" in

https://www.dxlabsuite.com/dxlabwiki/ConfigureRTTY

+ and added steps for making the required audio settings and level adjustments.

+ Since you're using Commander to control your IC-7610, and since Commander can switch your IC-7610 between RX and TX, on the
Configuration window's PTT tab, set the Mode panel to "Xcvr Ctrl App" and set the Port panel to None. If that doesn't enable
WinWarbler to switch your transceiver between RX and TX, please let me know.

73,

Dave, AA6YQ


FW: [DXLab] DXKeeper auto populate

Dave AA6YQ
 

Re-sending due to a Groups.io malfunction...

-----Original Message-----
From: Dave AA6YQ [mailto:aa6yq@ambersoft.com]
Sent: Sunday, March 07, 2021 6:34 PM
To: 'DXLab@groups.io'
Subject: RE: [DXLab] DXKeeper auto populate

+ AA6YQ comments below


Well that would be better than what's happening now.

Your suggestion sounds like a reasonable solution.


I thought there was a setting that allowed DXKeeper to be populated with previous qso info or not to be populated but still show previous qso info.

+ There is no such setting. As usual, I'm reluctant to add new settings because they increase user-perceived complexity - especially for a "once in 20 years" request.


Since I do not subscribe to any callbooks and have primary call book set to none is that why it is auto populating?

+ Unless an override is specified, DXKeeper harvests information from previously-logged QSOs if its "Display previous QSOs on Lookup" option is enabled:

https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#Display%20Previous%20QSOs%20on%20Lookup%20checkbox


Would subscribing to one of the callbooks and clicking the "automatically use callbook data to initialize new QSO's" eliminate my problem?

+ No, because information extracted from previous QSOs has priority over information provided by a callbook lookup.

73,

Dave, AA6YQ


sorting out Log to LotW discrepancies

David Reed
 

Hi folks; taking a break from the contest for a few moments; I thought "I wonder how well my log and LotW match?" so I ran the report to identify any.

No surprise that I have some; my problem is to figure out what to do about them so both are correct and no discrepancies are reported...

Here is what it looks like:

   Entity Prefix     Band or Mode     Log Status    ARRL Status    Entity Code   Entity


               5R              20m              V -            438   Madagascar
               DA            Phone V             81   Germany (deleted)
               DA            Mixed V             81   Germany (deleted)
               FG              20m              W V             79   Guadeloupe
               FG              15m              V -             79   Guadeloupe
              FO0               CW              V -             36   Clipperton Island
               FW              15m              V -            298   Wallis & Futuna Islands
               GD              17m              V -            114   Isle Of Man
             HK0S            Phone V            228   Serrana Bank & Roncador Cay (deleted)
             HK0S            Mixed V            228   Serrana Bank & Roncador Cay (deleted)
              KH6              12m              V -            110   Hawaii
              KH6          Digital              V -            110   Hawaii
              KZ5            Phone V             28   Canal Zone (deleted)
              KZ5            Mixed V             28   Canal Zone (deleted)
               OK            Phone V            218   Czechoslovakia (deleted)
               OK            Mixed V            218   Czechoslovakia (deleted)
               P4               CW              V -             91   Aruba
              YV0            Phone V             17   Aves Island
              YV0            Mixed V             17   Aves Island
               ZS              80m              V -            462   Republic of South Africa
All suggestions are very much appreciated!

Thanks & 73 de Dave, W5SV


Re: NEED HELP IN GETTING COMMANDER WORKING

Dan Coleman <w8kmx@...>
 

Dave: Last night I had WW working in AFSK. I could receive and decode I could press the transmit button (in WW) and it would key the radio, send diddles, with RF out. I could type in RY’s TEST then my call in the transmit window and it would transmit that. Today, I could not duplicate WW working on AFSK.
 OK, so today (starting over) I started Launcher,  and Commander. Pressing the TX button in commander keyed the radio, produced a single tone and I did get RF out. I then started WW, which changed the radio to LSB, and I press the TX button in WW. It did not key the radio and did not produce a tone or any RF even though the software thought it was transmitting. When I checked port five, the port used to control the radio, WW said it was not available. I’m guessing that is because it was being used by commander. ??
You sent me a link to “Configuring WinWarbler for RTTY Operation“ which I followed religiously (both AFSK and FSK) but, it did not work. I also tried the radio in D1, D2 & D3 but that made no difference. Throughout all of these tests, I could receive and decode RTTY in WW. I even tried the K0PIR video for N1MM with MMTTY with same lack of results. I am getting embarrassed that I can’t figure this out. Dan, W8KMX




On Mar 6, 2021 at 9:23 PM, <Dave AA6YQ> wrote:

Hello Dave and thanks for the information. It worked fine

+ Does that mean that you have Commander correctly controlling your IC-7610?

and in fact I now have WinWarbler working. Or at least I think it’s working I can hear the tones and I’m producing RF and it sounds good at this end through the monitor. I still don’t have MMTTY working and I fully don’t understand because they’re almost the same thing.

+ Your first post in this thread said

"when I press the "TX" icon, it does key the radio (ICOM 7610) but it only sends one steady tone (Mark, I think)."

+ To transmit RTTY with WinWarbler, type some text in its transmit pane, and then click the "Start" button in WinWarbler's "RTTY transmit" panel. See this annotated screen shot:

http://www.dxlabsuite.com/Wiki/Graphics/WinWarbler/RTTY.jpg

+ Later, you can configure WinWarbler to "auto start".

+ A constant mark tone when transmitting RTTY is a classic symptom of having the transceiver configured for RTTY FSK transmission (for an IC-7610, mode set to "RTTY") but not supplying a FSK signal to the transceiver; for an IC-7610, that can be done via the second virtual COM port created by the transceiver, as described in this Icom manual:

http://www.icom.co.jp/world/support/download/manual/pdf/USB_Port_Setting_Ver.1.0_Eng.pdf

+ The alternative is to transmit RTTY AFSK, in which case you'd configure WinWarbler to put your IC-7610 in DATA-L mode when operating RTTY.

+ Step-by-step instructions for configuring WinWarbler for RTTY operation are here:

https://www.dxlabsuite.com/dxlabwiki/ConfigureRTTY


       73,

              Dave, AA6YQ









Re: DXKeeper auto populate

Joe - W9RF
 

Hi Dave,


Well that would be better than what's happening now.

Your suggestion sounds like a reasonable solution.


I thought there was a setting that allowed DXKeeper to be populated with previous qso info or not to be populated but still show previous qso info.

Since I do not subscribe to any callbooks and have primary call book set to none is that why it is auto populating?

Would subscribing to one of the callbooks and clicking the "automatically use callbook data to initialize new QSO's" eliminate my problem?


ie. NOT use old qso info but instead use data found as a new lookup?




73,

W9RF - Joe









On Saturday, March 6, 2021, 11:48:03 PM CST, Dave AA6YQ <aa6yq@...> wrote:


+ AA6YQ comments below

When clicking on a call from Spotcollector or entering a callsign on the main DXKeeper page (new call) the previous qso info is automatically populated in DXKeeper.

This is very problematic when the previous call may have been worked several years in the past.

Even more problematic is entering a special event call, 1X1 calls are very often populated with the incorrect info.


The only way I have found to stop this is the general tab of DXKeeper config, (display previous QSO's on lookup)  but if I uncheck this it will not show any previous qso's.

I need to show the previous qso but NOT to populate the new qso with old info.

+ I can extend DXKeeper so that when you double-click a Spot Database Entry with DXKeeper's "Display previous QSOs on Lookup" option disabled, the callsign will still be placed in DXKeeper's  Filter panel; you can then review previous QSOs with the Entry's Callsign by clicking DXKeeper's  Filter panel's Call button - without information from previous QSOs being used to populate the Capture window.

+ Acceptable?

      73,

                Dave, AA6YQ








Re: Commander with multiple radios

Jim W1RET
 

Thanks Dave.  All good answers.  And binary encoded is no problem.  As long as I know there is something available.

73,

Jim W1RET


2Tone 21.03a

Dave AA6YQ
 

David G3YYD announced 2Tone version 21.03a today. I asked him what changed relative to the 2Tone version 21.02a included with
WinWarbler, here is his response:

-----------------
The Writelog fix and minor changes to the source code - removing old code that is no longer used. I also added the N1MM
documentation that I had left out last time but had intended to add in to make it easier for guys who prefer pictures over words. I
trialled the picture system with some UK amateurs and they found it helpful. However there are words just not as many!

In terms of decode performance no difference.
-----------------

Thus I am not planning to include 2Tone 21.03a in a future version of WinWarbler. If anyone would like access to David's improved
N1MM documentation, it's included in the 21.03a zip archive available here:

https://www.rttycontesting.com/downloads/2tone/

73,

Dave, AA6YQ


Re: Commander with multiple radios

Dave AA6YQ
 

+ AA6YQ comments below

I have, from time to time, connected to 2 radios using Commander. Set-up as multi-radio and it has worked fine. Now I'm attempting to interconnect to 4 radios and as I get this working I've come up with some questions.

First question -- is there any way to connect to more than 4 radios? I suspect no but thought I would ask as I have one more that can be CAT controlled.

+ The limit on primary transceivers is 4.

Second question has to do with user defined controls. Seems to me I have read that as I select from one radio to the next Commander can load the appropriate file for each radio. Is that correct?

+ Yes. See " Setting up User-defined Control Sets" in

https://www.dxlabsuite.com/dxlabwiki/SetupUserDefinedControlSet


Third question has to do with selecting the individual radio. Can a command sequence be written so that selecting a function key can select a different radio?

+ Yes. Command sequences can be invoked via the F5 through F12 keys, and a command sequence can use the <priXcvr N> command to select a specific primary transceiver. See "Command Sequences" in

https://www.dxlabsuite.com/commander/Help/CommandSequences.htm#Command%20Sequences


The fourth and final (I hope) question is about some kind of external notification. If I remember correctly there are pins on a parallel connector, if available, that can go active when a particular band is selected. Does a similar function exist when a particular radio is selected?

+ Yes: the selected primary transceiver can optionally be binary encoded on pins 16 and 14 of the specified parallel port. See "Parallel Port panel" in

https://www.dxlabsuite.com/commander/Help/Configuration.htm#Radio%20panel%20parallel%20port


In other words an active pin for radio 1-4?

+ The selection is binary encoded, not unary encoded. You will need some simple decoding logic to derive a signal that's asserted for each primary transceiver. Let me know if you need help with this.

73,

Dave, AA6YQ


Re: QSO start time rounding problem with eQSL

Dave AA6YQ
 

+ AA6YQ comments below

Call sign, band, and mode all match the specified QSO. I am at a loss to find a cause for the error.

+ So that I can see what's going on, please do the following:

1. place your log file (probably KC1BMD.mdb) in a zip archive

2. place the file eQSLInbox.txt (from your DXKeeper folder) in the zip archive you created in step 1

3. attach the zip archive created in step 1 to an email message that specifies the callsign, band, mode, date, and time of the QSO in question

4. send the email message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ
--


Commander with multiple radios

Jim W1RET
 

I have, from time to time, connected to 2 radios using Commander.  Set-up as multi-radio and it has worked fine.  Now I'm attempting to interconnect to 4 radios and as I get this working I've come up with some questions.

First question -- is there any way to connect to more than 4 radios?  I suspect no but thought I would ask as I have one more that can be CAT controlled.

Second question has to do with user defined controls.  Seems to me I have read that as I select from one radio to the next Commander can load the appropriate file for each radio.  Is that correct?

Third question has to do with selecting the individual radio.  Can a command sequence be written so that selecting a function key can select a different radio?

The fourth and final (I hope) question is about some kind of external notification.  If I remember correctly there are pins on a parallel connector, if available, that can go active when a particular band is selected.  Does a similar function exist when a particular radio is selected?  In other words an active pin for radio 1-4?  I would use this to automatically activate the various ports of my antenna/transceiver switch instead of manual selection.

Thanks in advance and 73.

Jim W1RET


Re: QSO start time rounding problem with eQSL

Norm - KC1BMD
 

Call sign, band, and mode all match the specified QSO. I am at a loss to find a cause for the error.
--
73, Norm/KC1BMD


Re: QSO start time rounding problem with eQSL

Dave AA6YQ
 

+ AA6YQ comments below

eQSL and LotW both accept time mismatches of several minutes; a few seconds is immaterial.

In your first message you quoted a message saying "no QSO matching callsign, band and mode" - if that is an exact quote, then you should be looking at callsign, band and mode. Of these, perhaps the most likely is the mode, especially for digital modes. Note that the ADIF standard for recording digital modes is not always what you might expect (e.g. FT8 is a full mode, whereas FT4 is mode MFSK, submode FT4). Some logging programs don't follow the ADIF standard exactly, adding to the confusion.

+ Rich VE3KI is correct. If an incoming eQSL confirmation matches the callsign, band, and mode of a QSO in your log, but does not match the start time within the range you've specified, an error message like this is displayed:

no matching QSO within 60 minute time window; closest match: 2003-07-08 20:09:40

+ I have the "Maximum time difference..." set to 60 minutes.

+ If the error message "no QSO matching callsign, band, and mode" is displayed, the problem is not in the QSO start times.

+ The error message displays the callsign, band, and mode reported by eQSL; filter your Log Page Display to show all QSOs with the reported callsign.

73,

Dave, AA6YQ


Re: QSO start time rounding problem with eQSL

Norm - KC1BMD
 

That setting was at default 15 min but I had already changed it to 30 min. However, that caused a different error when the partner's start time was > the time set in this box:
"no matching QSO within 30 minute time window; closest match: yyyy-mm-dd hh:mm:ss". I am not referring to that error, since my start time and partner start time are within a minute of one another and I did not receive that error.

--
73, Norm/KC1BMD


Re: QSO start time rounding problem with eQSL

Dave AA6YQ
 

+ AA6YQ comments below

I was previously logging new QSO's to the HRD Logbook and my previous process was to upload the HRD QSO to both LoTW and eQSL. (I would also download the LoTW data to the QRZ logbook to have that log in sync too, although that does not matter for this issue). This all worked fine. I transferred my logging to DXKeeper by exporting the HRD logbook to an ADIF file and importing it into DXKeeper. On investigating some errors of the type: "no QSO matching callsign, band, and mode" I find a discrepancy with the way eQSL and DXKeeper handle rounding of the QSO start time. As an example, the HRD Logbook had a QSO logged with start time: 22:21:20 (since HRD uses hh:mm:ss format). When this would uploaded to eQSL, the start time was rounded up to the nearest minute (i.e. to 22:22). DXKeeper however rounded it down to the nearest minute (i.e. to 22:21) which caused the error to be reported when sync'ing QSLs. My impresssion of the way to round would be to round up for =>30 seconds and round down for <30 seconds. DXKeeper appears to have followed this rule whereas eQSL does not appear to have followed that. To be clear, there is zero chance that I manually modified the QSO start time, so that is ruled out as a possible cause. What would be the best way to resolve this type of error?

+ Assuming that the "no QSO matching callsign, band, and mode" reports your refer to above are displayed when you invoke the "Sync eQSL QSLs" function, on the "QSL Configuration" window's eQSL tab, set the "Maximum time difference for considering a downloaded QSL to match a logged QSO (minutes)" to at least 1 (the default is 15). See the description of this setting in

https://www.dxlabsuite.com/dxkeeper/Help/QSLConfiguration.htm#Maximum%20time%20difference...



73,

Dave, AA6YQ


Re: QSO start time rounding problem with eQSL

Norm - KC1BMD
 

"eQSL and LotW both accept time mismatches of several minutes; a few seconds is immaterial."

-> This does not concern me. I am aware that there is a time difference allowed to confirm a QSO. The discrepancy that I am referring to is the discrepancy between DXKeeper and eQSL. That must match exactly, otherwise an error is produced when synchronizing QSL's in DXK. Also in my case it was CW and band, mode and start time all match.

--
73, Norm/KC1BMD


Re: QSO start time rounding problem with eQSL

ve3ki
 

eQSL and LotW both accept time mismatches of several minutes; a few seconds is immaterial.

In your first message you quoted a message saying "no QSO matching callsign, band and mode" - if that is an exact quote, then you should be looking at callsign, band and mode. Of these, perhaps the most likely is the mode, especially for digital modes. Note that the ADIF standard for recording digital modes is not always what you might expect (e.g. FT8 is a full mode, whereas FT4 is mode MFSK, submode FT4). Some logging programs don't follow the ADIF standard exactly, adding to the confusion.

73,
Rich VE3KI


On Sun, Mar 7, 2021 at 02:40 PM, Norm - KC1BMD wrote:
I could be wrong about the rounding, or at least it is not conclusive. I found another QSO uploaded to eQSL the same way as previously described. The QSO start time in DXKeeper is 21:26 and in HRD Logbook it is :21:26:29 and in eQSL it is 21:26. So there was no rounding (up) by eQSL and the eQSL time matches DXKeeper time. The QSO start time, band, mode and call sign all match between eQSL and DXKeeper. I don't see any reason (yet) for the error. What other parameter(s) must match?
--
73, Norm/KC1BMD


Re: QSO start time rounding problem with eQSL

Norm - KC1BMD
 

I could be wrong about the rounding, or at least it is not conclusive. I found another QSO uploaded to eQSL the same way as previously described. The QSO start time in DXKeeper is 21:26 and in HRD Logbook it is :21:26:29 and in eQSL it is 21:26. So there was no rounding (up) by eQSL and the eQSL time matches DXKeeper time. The QSO start time, band, mode and call sign all match between eQSL and DXKeeper. I don't see any reason (yet) for the error. What other parameter(s) must match?
--
73, Norm/KC1BMD

4541 - 4560 of 204751