Topics

LoTW upload not showing as being Synced with LoTW


Jim Cary
 

When I upload to LoTW the "Upload to LoTW" tab and menu shows the upload was successful.  However, when I try to "sync LoTW QSO's", it only shows a date from a couple of weeks ago.  This occurs even  few days after I have uploaded.

LoTW does not show the QSO's.

I renewed my TQSL certificate on Jan 7th and I have a feeling this might be part of the problem.  

Any suggestions?

Jim
ZF2LC


Dave AA6YQ
 

+ AA6YQ comments

When I upload to LoTW the "Upload to LoTW" tab and menu shows the upload was successful. However, when I try to "sync LoTW QSO's", it only shows a date from a couple of weeks ago. This occurs even few days after I have uploaded.

+ What does "it only shows a date from a couple of weeks ago" mean? Are you referring to the date shown beneath the "Sync LoTW QSOs" button? If so, that's the date on which LoTW last accepted one of your submitted QSOs.

LoTW does not show the QSO's.

I renewed my TQSL certificate on Jan 7th and I have a feeling this might be part of the problem.

+ Please start TQSL, and direct it to display your Callsign Certificate. in the "Certificates Properties" window, what is shown for the following parameters:

Begins:
Expires:
Call sign:
DXCC Entity:
QSO Start Date:
QSO End Date:

?

73,

Dave, AA6YQ


Jim Cary
 

Dave,

When I upload to LoTW, DXKeeper says to the effect, "qso's signed and uploaded.  Wait a few minutes then click "Sync LoTW QSO's" to determine if accepted. "  The date under Sync LoTW QSO's is 1/6/2021, apparently the date the last QSO's were accepted.

Certificate:

Begins 2021-01-07
Expires 2024-01-07
Call ZF2LC
DXCC Entity Cayman Islands
QSO Start Date 1997-01-01
QSO End Date 2024-01-07

Jim


Dave AA6YQ
 

+ AA6YQ comments below

When I upload to LoTW, DXKeeper says to the effect, "qso's signed and uploaded. Wait a few minutes then click "Sync LoTW QSO's" to determine if accepted. " The date under Sync LoTW QSO's is 1/6/2021, apparently the date the last QSO's were accepted.

Certificate:

Begins 2021-01-07
Expires 2024-01-07
Call ZF2LC
DXCC Entity Cayman Islands
QSO Start Date 1997-01-01
QSO End Date 2024-01-07

+ That all looks fine, Jim - but the next time you renew, I suggest not specifying a "QSO End Date".

+ In the TQSL panel at the bottom of DXKeeper's "QSL Configuration" window, what is specified in the "Station Location" and "Station Callsign" boxes?

73,

Dave, AA6YQ


Jim Cary
 

Dave,

It is a ARRL LoTW problem.  When I just checked my LoTW account on the website, it does not show the certificate they sent me!

73,

Jim


Jim McPhee
 

Dave,

Just an observation. You said:

"+ That all looks fine, Jim - but the next time you renew, I suggest not specifying a "QSO End Date"."

I just renewed several certificates without specifying a "QSO End Date". On each of the renewed certificates the
"QSO End Date" is identical to the "Expires" date. I suspect the "QSO End Date" can't be open-ended, and will always be the same as the expiration date. If you specify a "QSO End Date" shorter than the automatic three year renewal period, then the "Expires" date will mirror the "QSO End Date".

73,

--
Jim McPhee
Placitas, NM
W5ABA


Dave AA6YQ
 

+ AA6YQ comments below

It is a ARRL LoTW problem. When I just checked my LoTW account on the website, it does not show the certificate they sent me!

+ That would explain your submitted QSOs not being accepted.

73,

Dave, AA6YQ


iain macdonnell - N6ML
 

On Wed, Jan 27, 2021 at 11:56 AM Jim McPhee <jmcphee@comcast.net> wrote:

Dave,

Just an observation. You said:

"+ That all looks fine, Jim - but the next time you renew, I suggest not specifying a "QSO End Date"."

I just renewed several certificates without specifying a "QSO End Date". On each of the renewed certificates the "QSO End Date" is identical to the "Expires" date. I suspect the "QSO End Date" can't be open-ended, and will always be the same as the expiration date. If you specify a "QSO End Date" shorter than the automatic three year renewal period, then the "Expires" date will mirror the "QSO End Date".
That makes sense - you can't sign a QSO that hasn't happened yet!

That said; you don't know what the expiration date for your
certificate is going to be when you request it, so you should leave
the QSO end date blank and allow the certificate issuance process to
populate it.

73,

~iain / N6ML


Dave AA6YQ
 

+ AA6YQ comments below

Just an observation. You said:

"+ That all looks fine, Jim - but the next time you renew, I suggest not specifying a "QSO End Date"."

I just renewed several certificates without specifying a "QSO End Date". On each of the renewed certificates the "QSO End Date" is identical to the "Expires" date. I suspect the "QSO End Date" can't be open-ended, and will always be the same as the expiration date. If you specify a "QSO End Date" shorter than the automatic three year renewal period, then the "Expires" date will mirror the "QSO End Date".

+ That’s not correct. The "Date of the last QSO you made or will make using this callsign" can be left empty, and should be left empty for a "Callsign Certificate" associated with an active callsign. See step 4.b in

https://lotw.arrl.org/lotw-help/renewing/

73,

Dave, AA6YQ


Jim McPhee
 

Dave,

I am in total agreement with what you are saying about leaving the "Date of the last QSO you made or will make using this callsign" field empty for an active callsign certificate. That is exactly what I did when I recently renewed several certificates. I'm only saying that, even having done it, the "QSO End Date" on my renewed certificates, is identical to the expiration dates of those certificates. Each are three years from the "Begins" date. This is the same for the certificate that Jim Cary posted the details for. The "Expires" date, and the "QSO End Date" are identical, both exactly three years from the "Begins" date, reflecting the default LoTW certificate renewal period of three years.
--
Jim McPhee
Placitas, NM
W5ABA


Dave AA6YQ
 

+ AA6YQ comments below

I am in total agreement with what you are saying about leaving the "Date of the last QSO you made or will make using this callsign" field empty for an active callsign certificate. That is exactly what I did when I recently renewed several certificates. I'm only saying that, even having done it, the "QSO End Date" on my renewed certificates, is identical to the expiration dates of those certificates. Each are three years from the "Begins" date. This is the same for the certificate that Jim Cary posted the details for. The "Expires" date, and the "QSO End Date" are identical, both exactly three years from the "Begins" date, reflecting the default LoTW certificate renewal period of three years.

+ You are correct, Jim: TQSL's "Certificate Properties" for a "Callsign Certificate" renewed with a blank "Date of the last QSO you made or will make using this callsign" show a "QSO End Date" identical to the Certificate's expiration date.

+ Rick K1MU, shouldn't TQSL's "Certificate Properties" window display a blank "QSO End Date" if that's what the user specified when requesting or renewing the "Callsign Certificate"? Alternatively, TQSL could replace the option to leave the "Date of the last QSO you made or will make using this callsign" setting blank with an option to set "Date of the last QSO you made or will make using this callsign" to the Certificate's expiration date.

73,

Dave, AA6YQ


iain macdonnell - N6ML
 

On Wed, Jan 27, 2021 at 4:40 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

I am in total agreement with what you are saying about leaving the "Date of the last QSO you made or will make using this callsign" field empty for an active callsign certificate. That is exactly what I did when I recently renewed several certificates. I'm only saying that, even having done it, the "QSO End Date" on my renewed certificates, is identical to the expiration dates of those certificates. Each are three years from the "Begins" date. This is the same for the certificate that Jim Cary posted the details for. The "Expires" date, and the "QSO End Date" are identical, both exactly three years from the "Begins" date, reflecting the default LoTW certificate renewal period of three years.

+ You are correct, Jim: TQSL's "Certificate Properties" for a "Callsign Certificate" renewed with a blank "Date of the last QSO you made or will make using this callsign" show a "QSO End Date" identical to the Certificate's expiration date.

+ Rick K1MU, shouldn't TQSL's "Certificate Properties" window display a blank "QSO End Date" if that's what the user specified when requesting or renewing the "Callsign Certificate"? Alternatively, TQSL could replace the option to leave the "Date of the last QSO you made or will make using this callsign" setting blank with an option to set "Date of the last QSO you made or will make using this callsign" to the Certificate's expiration date.
What problem are you trying to solve here? Leaving the "QSO end date"
blank in the request means "I have no plans to stop making QSOs with
this callsign". In that case, the certificate issuance process will
use the certificate expiration date as the QSO end date, which makes
sense. If my cert expires on January 31st, and I make a QSO on
February 2nd, I will not be able to use my existing cert to sign that
QSO, because it will have expired by then. I will need to have renewed
my certificate (with new expiration and QSO end dates).

73,

~iain / N6ML


Dave AA6YQ
 

+ AA6YQ comments below
What problem are you trying to solve here? Leaving the "QSO end date"
blank in the request means "I have no plans to stop making QSOs with
this callsign". In that case, the certificate issuance process will
use the certificate expiration date as the QSO end date, which makes
sense. If my cert expires on January 31st, and I make a QSO on
February 2nd, I will not be able to use my existing cert to sign that
QSO, because it will have expired by then. I will need to have renewed
my certificate (with new expiration and QSO end dates).

+ It's confusing to the user for a Callsign Certificate's properties to be inconsistent with what that user specified when requesting or renewing that Certificate. If the end date is left blank when requesting the Certificate, then its properties should display a blank end date. If the end date must specify the Certificate's expiration date, then when the user requests or renews a Certificate for an active callsign, he or she should be an offered a "date when Certificate expires" choice rather than a "leave it blank" choice.

      73,

             Dave, AA6YQ

 

 


Dave AA6YQ
 

# more AA6YQ comments below

+ You are correct, Jim: TQSL's "Certificate Properties" for a "Callsign Certificate" renewed with a blank "Date of the last QSO you made or will make using this callsign" show a "QSO End Date" identical to the Certificate's expiration date.

I agree - this seems incorrect. While it's strictly true that if your Callsign Certificate expires on January 1st, 2021 that you can't sign QSOs made past that date, it's hiding the fact that you did not specify an end date.

+ Rick K1MU, shouldn't TQSL's "Certificate Properties" window display a blank "QSO End Date" if that's what the user specified when requesting or renewing the "Callsign Certificate"? Alternatively, TQSL could replace the option to leave the "Date of the last QSO you made or will make using this callsign" setting blank with an option to set "Date of the last QSO you made or will make using this callsign" to the Certificate's expiration date.

I will have a look at this. I think it's a case where the "last usable" date as far as TQSL is concerned is being displayed, where that doesn't really convey the configuration of the callsign certificate as requested.

# Thanks Rick!

73,

Dave, AA6Q


iain macdonnell - N6ML
 

On Wed, Jan 27, 2021 at 7:07 PM Rick Murphy <k1mu.nospam@gmail.com> wrote:
The problem here is that the user said "Allow signing QSOs indefinitely" as it's the holder's current call.
Did they? The TQSL GUI says "Leave this date blank if this is still
your valid callsign". It doesn't say anything about ensuring that the
certificate can be used indefinitely. Obviously it cannot be used
indefinitely, as it has an expiration date.


However, when displaying the callsign certificate's properties, even though the request was for no end date, TQSL gives an end date.
Yes, because that is the last date for which a QSO could be signed
using this certificate.


Note that this is not the date when the Callsign Certificate expires - it's actually the date before.
In other words, if you renew on January 27th 2021 (today), which will give you a certificate valid for 3 years (ending 27 January 2024), the "Last QSO date" in the certificate issued by LoTW is actually the day BEFORE it expires, 26 January 2024 in this case.
Hmmm. Viewing my cert in TQSL, it says that it expires on 2023-08-26
and the QSL End Date is 2023-08-26. Looking at the actual cert, it
expires at "Aug 26 19:06:19 2023 GMT". I wonder if there's a
discrepancy that occurs depending on the time of day when the cert
gets generated?


So, I've got a dilemma. I can suppress QSO end dates when they're one day before the callsign certificate expires. (This seems reasonable to me.)
Or I can just leave it as is. The date displayed is the last date you can sign a QSO for given that callsign certificate.
Or I can try to get the ARRL to update the LoTW codebase to not set an end date for this case. Is this worth diverting their very limited development resources?

While the first case kind of fixes this, it leaves the case where a QSO made on 27 January 2024 is rejected because it's past the valid date range, but that tweak to the callsign certificate properties display leads the user to think the QSO should be OK.

I'm kind of inclined to leave this as is but would love input on that choice.
That's my vote. The cert can never be used to sign a QSO that occurs
after its expiration date, so leaving it blank doesn't solve anything.
People need to understand that certs expire, and they should renew
them *before* the expiration date.

If there's an issue where a user requests a cert with no end date
specified but they get issued a cert where the QSO end date is
different from the cert expiration date, that seems like an issue in
the cert issuance process, not in TQSL.

73,

~iain / N6ML




On Wed, Jan 27, 2021 at 9:33 PM iain macdonnell - N6ML <ar@dseven.org> wrote:

On Wed, Jan 27, 2021 at 4:40 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

I am in total agreement with what you are saying about leaving the "Date of the last QSO you made or will make using this callsign" field empty for an active callsign certificate. That is exactly what I did when I recently renewed several certificates. I'm only saying that, even having done it, the "QSO End Date" on my renewed certificates, is identical to the expiration dates of those certificates. Each are three years from the "Begins" date. This is the same for the certificate that Jim Cary posted the details for. The "Expires" date, and the "QSO End Date" are identical, both exactly three years from the "Begins" date, reflecting the default LoTW certificate renewal period of three years.

+ You are correct, Jim: TQSL's "Certificate Properties" for a "Callsign Certificate" renewed with a blank "Date of the last QSO you made or will make using this callsign" show a "QSO End Date" identical to the Certificate's expiration date.

+ Rick K1MU, shouldn't TQSL's "Certificate Properties" window display a blank "QSO End Date" if that's what the user specified when requesting or renewing the "Callsign Certificate"? Alternatively, TQSL could replace the option to leave the "Date of the last QSO you made or will make using this callsign" setting blank with an option to set "Date of the last QSO you made or will make using this callsign" to the Certificate's expiration date.
What problem are you trying to solve here? Leaving the "QSO end date"
blank in the request means "I have no plans to stop making QSOs with
this callsign". In that case, the certificate issuance process will
use the certificate expiration date as the QSO end date, which makes
sense. If my cert expires on January 31st, and I make a QSO on
February 2nd, I will not be able to use my existing cert to sign that
QSO, because it will have expired by then. I will need to have renewed
my certificate (with new expiration and QSO end dates).

73,

~iain / N6ML


--
Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA


Dave AA6YQ
 

# more AA6YQ comments below

On Wed, Jan 27, 2021 at 7:07 PM Rick Murphy <k1mu.nospam@gmail.com> wrote:
The problem here is that the user said "Allow signing QSOs indefinitely" as it's the holder's current call.
Did they? The TQSL GUI says "Leave this date blank if this is still your valid callsign". It doesn't say anything about ensuring that the certificate can be used indefinitely. Obviously it cannot be used indefinitely, as it has an expiration date.

# The documentation, already cited, says "for an active callsign, the QSO end date should be remain blank".


However, when displaying the callsign certificate's properties, even though the request was for no end date, TQSL gives an end date.
Yes, because that is the last date for which a QSO could be signed using this certificate.

# I understand the technical rationale, but it's not what the user specified, and likely not what the user expects to see.


Note that this is not the date when the Callsign Certificate expires - it's actually the date before.
In other words, if you renew on January 27th 2021 (today), which will give you a certificate valid for 3 years (ending 27 January 2024), the "Last QSO date" in the certificate issued by LoTW is actually the day BEFORE it expires, 26 January 2024 in this case.
Hmmm. Viewing my cert in TQSL, it says that it expires on 2023-08-26 and the QSL End Date is 2023-08-26. Looking at the actual cert, it expires at "Aug 26 19:06:19 2023 GMT". I wonder if there's a discrepancy that occurs depending on the time of day when the cert gets generated?


So, I've got a dilemma. I can suppress QSO end dates when they're one
day before the callsign certificate expires. (This seems reasonable to me.) Or I can just leave it as is. The date displayed is the last date you can sign a QSO for given that callsign certificate.
Or I can try to get the ARRL to update the LoTW codebase to not set an end date for this case. Is this worth diverting their very limited development resources?

While the first case kind of fixes this, it leaves the case where a QSO made on 27 January 2024 is rejected because it's past the valid date range, but that tweak to the callsign certificate properties display leads the user to think the QSO should be OK.

I'm kind of inclined to leave this as is but would love input on that choice.
That's my vote. The cert can never be used to sign a QSO that occurs after its expiration date, so leaving it blank doesn't solve anything.
People need to understand that certs expire, and they should renew them *before* the expiration date.

# There's a separate "Certificate Expiration Date" property. No one is proposing to remove that.


If there's an issue where a user requests a cert with no end date specified but they get issued a cert where the QSO end date is different from the cert expiration date, that seems like an issue in the cert issuance process, not in TQSL.

# If that's happened I'm not aware of it, but it's not the subject of this discussion.

# The subject is "user specified a blank last QSO date, but TQSL set the last QSO date to the Certificate expiration date". I suggest that TQSL or its documentation be modified to make these consistent. I'm fine with changing the LoTW documentation and the text in TQSL to say something like "for an active callsign, leave the Last QSO date blank, and TQSL will fill in the Certificate's Expiration Date".

73,

Dave, AA6YQ


iain macdonnell - N6ML
 

On Wed, Jan 27, 2021 at 9:23 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

# more AA6YQ comments below

On Wed, Jan 27, 2021 at 7:07 PM Rick Murphy <k1mu.nospam@gmail.com> wrote:
The problem here is that the user said "Allow signing QSOs indefinitely" as it's the holder's current call.
Did they? The TQSL GUI says "Leave this date blank if this is still your valid callsign". It doesn't say anything about ensuring that the certificate can be used indefinitely. Obviously it cannot be used indefinitely, as it has an expiration date.

# The documentation, already cited, says "for an active callsign, the QSO end date should be remain blank".


However, when displaying the callsign certificate's properties, even though the request was for no end date, TQSL gives an end date.
Yes, because that is the last date for which a QSO could be signed using this certificate.

# I understand the technical rationale, but it's not what the user specified, and likely not what the user expects to see.


Note that this is not the date when the Callsign Certificate expires - it's actually the date before.
In other words, if you renew on January 27th 2021 (today), which will give you a certificate valid for 3 years (ending 27 January 2024), the "Last QSO date" in the certificate issued by LoTW is actually the day BEFORE it expires, 26 January 2024 in this case.
Hmmm. Viewing my cert in TQSL, it says that it expires on 2023-08-26 and the QSL End Date is 2023-08-26. Looking at the actual cert, it expires at "Aug 26 19:06:19 2023 GMT". I wonder if there's a discrepancy that occurs depending on the time of day when the cert gets generated?


So, I've got a dilemma. I can suppress QSO end dates when they're one
day before the callsign certificate expires. (This seems reasonable to me.) Or I can just leave it as is. The date displayed is the last date you can sign a QSO for given that callsign certificate.
Or I can try to get the ARRL to update the LoTW codebase to not set an end date for this case. Is this worth diverting their very limited development resources?

While the first case kind of fixes this, it leaves the case where a QSO made on 27 January 2024 is rejected because it's past the valid date range, but that tweak to the callsign certificate properties display leads the user to think the QSO should be OK.

I'm kind of inclined to leave this as is but would love input on that choice.
That's my vote. The cert can never be used to sign a QSO that occurs after its expiration date, so leaving it blank doesn't solve anything.
People need to understand that certs expire, and they should renew them *before* the expiration date.

# There's a separate "Certificate Expiration Date" property. No one is proposing to remove that.


If there's an issue where a user requests a cert with no end date specified but they get issued a cert where the QSO end date is different from the cert expiration date, that seems like an issue in the cert issuance process, not in TQSL.

# If that's happened I'm not aware of it, but it's not the subject of this discussion.

# The subject is "user specified a blank last QSO date, but TQSL set the last QSO date to the Certificate expiration date". I suggest that TQSL or its documentation be modified to make these consistent. I'm fine with changing the LoTW documentation and the text in TQSL to say something like "for an active callsign, leave the Last QSO date blank, and TQSL will fill in the Certificate's Expiration Date".
This is the right answer (IMO).

73,

~iain / N6ML


Dave AA6YQ
 

I just renewed my AA6YQ "Callsign Certificate", which fortuitously expires in 59 days. Here's the email message I received in response:

-----------------------
Started processing your Renewal Certificate Request.
For call sign: AA6YQ
For DXCC Entity: UNITED STATES OF AMERICA (291)
For QSOs not before: 1990-10-18 00:00:00
For QSOs not after: <blank>
Your renewal certificate request is accepted and awaiting further processing.
You will receive the certificate after it has been created.
Your certificate request processing is completed.
-----------------------

This is another reason that a user might be confused to see the renewed Certificate's "Last QSO Date" be something other than <blank>.

Since (as far as I know) there are still no developers assigned to LoTW, Rick K1MU's continuing improvements to TQSL are the only game in town for making LoTW less complicated and easier to use.

73,

Dave, AA6YQ


iain macdonnell - N6ML
 

On Wed, Jan 27, 2021 at 9:28 PM iain macdonnell - N6ML via groups.io
<ar=dseven.org@groups.io> wrote:

On Wed, Jan 27, 2021 at 9:23 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

# more AA6YQ comments below

On Wed, Jan 27, 2021 at 7:07 PM Rick Murphy <k1mu.nospam@gmail.com> wrote:
The problem here is that the user said "Allow signing QSOs indefinitely" as it's the holder's current call.
Did they? The TQSL GUI says "Leave this date blank if this is still your valid callsign". It doesn't say anything about ensuring that the certificate can be used indefinitely. Obviously it cannot be used indefinitely, as it has an expiration date.

# The documentation, already cited, says "for an active callsign, the QSO end date should be remain blank".


However, when displaying the callsign certificate's properties, even though the request was for no end date, TQSL gives an end date.
Yes, because that is the last date for which a QSO could be signed using this certificate.

# I understand the technical rationale, but it's not what the user specified, and likely not what the user expects to see.


Note that this is not the date when the Callsign Certificate expires - it's actually the date before.
In other words, if you renew on January 27th 2021 (today), which will give you a certificate valid for 3 years (ending 27 January 2024), the "Last QSO date" in the certificate issued by LoTW is actually the day BEFORE it expires, 26 January 2024 in this case.
Hmmm. Viewing my cert in TQSL, it says that it expires on 2023-08-26 and the QSL End Date is 2023-08-26. Looking at the actual cert, it expires at "Aug 26 19:06:19 2023 GMT". I wonder if there's a discrepancy that occurs depending on the time of day when the cert gets generated?


So, I've got a dilemma. I can suppress QSO end dates when they're one
day before the callsign certificate expires. (This seems reasonable to me.) Or I can just leave it as is. The date displayed is the last date you can sign a QSO for given that callsign certificate.
Or I can try to get the ARRL to update the LoTW codebase to not set an end date for this case. Is this worth diverting their very limited development resources?

While the first case kind of fixes this, it leaves the case where a QSO made on 27 January 2024 is rejected because it's past the valid date range, but that tweak to the callsign certificate properties display leads the user to think the QSO should be OK.

I'm kind of inclined to leave this as is but would love input on that choice.
That's my vote. The cert can never be used to sign a QSO that occurs after its expiration date, so leaving it blank doesn't solve anything.
People need to understand that certs expire, and they should renew them *before* the expiration date.

# There's a separate "Certificate Expiration Date" property. No one is proposing to remove that.


If there's an issue where a user requests a cert with no end date specified but they get issued a cert where the QSO end date is different from the cert expiration date, that seems like an issue in the cert issuance process, not in TQSL.

# If that's happened I'm not aware of it, but it's not the subject of this discussion.

# The subject is "user specified a blank last QSO date, but TQSL set the last QSO date to the Certificate expiration date". I suggest that TQSL or its documentation be modified to make these consistent. I'm fine with changing the LoTW documentation and the text in TQSL to say something like "for an active callsign, leave the Last QSO date blank, and TQSL will fill in the Certificate's Expiration Date".
This is the right answer (IMO).
Well, technically it's not TQSL that fills it in. Maybe something like
"if you do not specify a QSO end date, it will automatically be set to
the expiration date of the new certificate when it gets issued".

73,

~iain / N6ML