Understanding ADD NEEDED function

Kim Carr

+ AA6YQ comments below

I clearly had not read about the aging report. That is exactly what I wanted. Sorry for the wasted bandwidth.

+ No problem, Kim. The reference documentation for that function is here:


I run the 3 column ADD NEEDED report, but I don't print labels or cards for the entire report. There are always a number of cards to be requested via the electronic services like OQRS, M0OXO etc. I only print labels for those I need to send direct or via a manager. I'm careful to use CLEAR to return the QSL RCVD status back to its original value and I manually set the QSL SENT info for the few that are mailed out.  WIth my DXCC totals in the high 280s, I don't have a lot of cards to chase.

Very well thought out process, Dave.  Thanks.

+ Since getting my ticket in 1990, I've sent out ~8K QSL cards, and received ~7K in response. There was plenty of motivation to make the process work well!

This issue is resolved.

Kim, K5TU

----- Forwarded Message -----

From: Dave AA6YQ <aa6yq@...>
To: 'William Carr' <k5tu@...>
Sent: Monday, December 9, 2019, 04:59:20 PM CST
Subject: RE: Understanding ADD NEEDED function

+ AA6YQ comments below

I had previously read the ADD NEEDED information in the help documents, but it was not clear to me that simply requesting a QSL would remove it from the ADD NEEDED function. I incorrectly assumed that the most recent QSO with an entity needed for DXCC would continue to show until a confirmation was recorded (QSL RCVD = Y or perhaps V). In my mind, it's needed until the confirmation arrives.

+ You don't want to keep sending QSL cards to Japanese stations until one of them sends you a card in response, or you receive an LoTW confirmation. If you want to intentionally send a second request for a rare DXCC entity; you can do that by right-clicking the Log Page Display entry and selecting "Add QSO to QSL Queue".

I do upload all my QSOs to LoTW promptly so I am glad that LoTW status doesn't play in this ADD NEEDED function.

+ All logged QSOs can be submitted to LoTW at zero cost. That's a completely different situation then sending an outgoing QSL card.

I now see how this functions. 

Do you have a recommendation for tracking QSLs requested for a DXCC entity needed for an award (or state or zone) that have not been answered?  At some point, I would declare those as "dead" by changing the status of the requested QSO to X and try another QSO or route.

+ DXKeeper provides automation for this. See


ER (Moldova) is a tough QSL to get.  According to the info on ClubLog, ER4A made more than 41,700 QSOs with ClubLog members since 2010, but only 935 of the same ClubLog members have received a QSL from ER4A (also formerly ER4KAA).  Practically zero QSOs from ER4A in 2018 and 2019 were confirmed via QSL. This is one I would track and hope to get through another route.

Should I consider leaving the QSL RCVD field blank for those I QSL Direct of through a manager?  Of course, I would consider it to be requested, but without the R in status, it would continue to show on the ADD NEEDED.

+ No, I wouldn't do that.

+ If you've sent a confirmation request to a station known to be poor at responding, you can do one of two things:

1. Pre-emptively mark it as "expired"; for DXCC, that means setting both "QSL Rcvd" and "LoTW QSL Rcvd" to 'X'. The "Add Needed" function will then ignore the fact that you've requested a QSL card, and will pick some other logged QSOs from which to generate a confirmation request.

2. Mark the QSO invalid for DXCC by setting its "QSL Rcvd" item to 'I'. Not only will "Add Needed" ignore the confirmation request, SpotCollector will act as if this QSO was never logged, and highlight other active stations in the entity as "unworked".

+ Either approach will be updated if you subsequently receive a QSL card or an LoTW confirmation.


              Dave, AA6YQ