Added Info for Logged WSJTX Contacts

[aa5sh]

Search through DXSpots (filtered to FTx and DIGITAL) and if a callsign and frequency match +- 5 Khz will update POTA, IOTA, SOTA or WWFF references if exists in a DXSpot entry.

[foldynl]

@aa5sh Michael, let's ignore the code for a moment — I believe I understand what you're trying to achieve. However, I'm not convinced that DXC is a fully reliable or consistent source of information for this purpose.

What should QLog do in cases like this?

1. Example from DXC:

13:00:00 OK1XXX: FT8 POTA A  
14:00:00 OK1XXX: FT8  (no POTA info)

In this case, we could assume that the second spot (14:00) means the operator is no longer on a POTA.
But is that always a safe assumption? We can’t be sure if the station was still on POTA after an hour — maybe they forgot to include the POTA reference the second time.

A more questionable case:

13:00:00 OK1XXX: FT8 POTA A  
13:05:00 OK1XXX: FT8 (no POTA info)

Should QLog use the POTA A info from the 13:00 spot for a QSO at 13:05?
How far back should QLog look for POTA data or other metadata from previous spots?

2. Special case

There’s a single DXC spot at 13:00:00 with POTA A, but I made the QSO at 15:00:00.
Should that old POTA info still apply two hours later?

In general:

How should QLog decide how long to "remember" previous spot info like POTA?
It seems unreliable to assume that older spots remain valid beyond a certain point — but where should that limit be?

The issue here is that automatic completion for regular QSOs faces the same problem. However, I believe the operator will usually check whether it's a POTA activation and, if possible, ask. With FT8 traffic, though, it's not possible to find out. Or am I wrong ?

[aa5sh]

No I agree it isn't 100%.

I think maybe the code could be tweaked so when it finds its first most recent match then escapes out, then maybe we could add a time limit of first one with in 30 mins or 60 mins? So if an operator moves between parks it should catch the newest one. I typically do keep pota.app up and watch spots so keep an eye on it, but just trying to save time from having to enter it after each contact. I connect to this cluster - [pota-cluster.iz2lsc.eu:7373] which does a good job of putting the parks in a consistent format that your logic in QLog grabs well.

[foldynl]

we could add a time limit of first one with in 30 mins or 60 mins?

That's exactly what can be a big problem. Where is the limit? I don't know how to define it, and leaving it up to the users just shifts the problem onto them — and they will have no idea at all. But maybe there's a way. In issue #482 , it was already suggested to use the API. At that time it wasn't possible, but in the case of WSJTX, where QSO traffic isn't that high, it might be feasible to use the API in such a way that QLog fetches a JSON with spots every 2–3 minutes, and for WSJTX, it always checks that data and, if there's a match, it fills in the POTA Info. I think this could be implemented for SOTA as well.

I still need to look into it in more detail, but I believe this could be a way to get POTA info for WSJTX QSOs.

[foldynl]

Just a quick update. I’ve already reworked this. I tested it with WSJTX yesterday, but so far my change isn’t reliable enough. I’m trying to get it into the upcoming 0.46, but I’m not sure if I’ll manage.

[foldynl]

It seems I finally found the right combination. Could you please try branch POTAQE? Here you should find the POTA querying you suggested, but reworked.

[aa5sh]

Ok I'll take a look at it this evening after work. I played around with testing0.46 yesterday.

[aa5sh]

I really like what you did. I would only ask for one change. And that would be to add the Pota Reference when a contact is logged in WSJTX. Like this.
potaqe.patch

[foldynl]

Michael, I don’t think this patch is necessary. During your testing, was the pota_ref field not being saved?

The WSJTX contact saving process is a bit complex, but in simple terms: the QSO is passed via the addContact signal into NewContact::saveExternalContact. This method processes the received QSO and supplements it with the information currently available in the NewContact form.

When a new contact from WSJTX is saved, the callsign should already be present in NewContact along with additional data such as Callbook details and the POTA Ref, since the callsign is sent from WSJTX at the beginning of the QSO. As a result, the final saved QSO should contain both the data received from WSJTX and the extra information from NewContact (Callbook and POTA).

That’s how it worked for me. If it doesn’t work the same way for you, then there’s a bug somewhere.

[aa5sh]

Ok I’ll test again but I don’t think it pulled it in, but maybe I had a bad test case. I tried to watch for people calling CQ POTA and searching on the pota.api to see if they were there. But I may have goofed it. I will try to spend some time with it tonight.

…

On Aug 27, 2025, at 9:50 AM, Ladislav ***@***.***> wrote: foldynl left a comment (foldynl/QLog#703) <#703 (comment)> Michael, I don’t think this patch is necessary. During your testing, was the pota_ref field not being saved? The WSJTX contact saving process is a bit complex, but in simple terms: the QSO is passed via the addContact signal into NewContact::saveExternalContact. This method processes the received QSO and supplements it with the information currently available in the NewContact form. When a new contact from WSJTX is saved, the callsign should already be present in NewContact along with additional data such as Callbook details and the POTA Ref, since the callsign is sent from WSJTX at the beginning of the QSO. As a result, the final saved QSO should contain both the data received from WSJTX and the extra information from NewContact (Callbook and POTA). That’s how it worked for me. If it doesn’t work the same way for you, then there’s a bug somewhere. — Reply to this email directly, view it on GitHub <#703 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXX4QZ5YG2E6EGO6MQL3PXASBAVCNFSM6AAAAACBVRB6LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMRYGUZDMMBTGY>. You are receiving this because you were mentioned.

[foldynl]

I'll try to test it as well, but I probably won’t have a chance before the weekend.

[aa5sh]

Ok this was my mistake. I had some messups in my config running in a test db on my work laptop so when I tested here at my main shack computer it does work as expected. Thanks for reworking this, it looks like a really good implementation and works a desired. Thank you

[foldynl]

Many thanks for testing and confirmation that it is working.

However, I am still not sure if this is the right approach. When I tested it, I found stations that reported, for example, grid JO80 via WSJTX CQ message but had JO81 registered in POTA.APP. This raises the question of how to handle such cases. We’ll see based on user feedback, and perhaps improve it later.

[aa5sh]

In my opinion in that scenario I would go with what is sent in WSJT because that is what the operator entered and is sending. The POTA.API I think is just based off of spots so although the POTA ID would be "accurate" it could be the default grid for the POTA but not necessarily where the operator is working from. But like you said may just have to watch and see how it works out.