New QSO Callbook Data Using QTH From Previous Logged Contact

[n9gxa]

Is there a way, or could a way be added to optionally not use some of the data stored with a callsign from a previous QSO?

I see this mostly with POTA QSOs where the station was at one park previously and when I find them at a new park, the new QSO Gridsquare and QTH still indicate the park they were at the last time I worked them. I have found that if I place the cursor in the POTA field and press Enter, the Gridsquare and QTH update to the new park. I don't know if the population of fields from a previous QSO is thought to be feature for efficiency or not.

If I am not missing an option, could an option be added to disregard at least some fields from a previous QSO and lookup the callsign's current info from the web??

TNX
73 - Paul - N9GXA

[dimarmnes]

I agree with the issue described in the original post. I see the same behavior and would like to add a few related cases that seem inconsistent.

From my experience:

When entering a callsign, if a previous QSO exists, Qlog immediately pre-fills QTH and grid from that contact.

If the previous QSO was a POTA activation and the current QSO is from the station’s home QTH, the POTA QTH and grid are still pre-filled. To get the correct data, I need to manually clear QTH and grid and press Enter again in the callsign field.

When a station is detected as POTA via a spot, Qlog fills the POTA reference but does not update QTH and grid unless Enter is pressed in the POTA field (as mentioned in the original post).

When editing an existing QSO, entering or changing a POTA reference does not update QTH or grid at all.

Overall, QTH and grid updates depend on specific user actions (pressing Enter in certain fields) and behave differently between new QSOs and edited QSOs. This can make it easy to log incorrect location data without noticing.

LU1IDC Diego, 73

[foldynl]

Gentlemen, do you use the /P suffix for portable stations? Qlog populates the collected data only when the callsign has no prefix or suffix.

[n9gxa]

/P takes care of it. Thank you.

I tend to enter the call as reported to me. Outside of POTA it is not always obvious if someone is portable or not, so I try to stick with absolute instead of interpreted as a rule. There can always be exceptions, though...

Kind of interested, I don't have to enter the /P for a station I have never worked before when they are POTA information is automatically populated: It does not use their home QTH information.

TNX
73 - Paul - N9GXA

[n9gxa]

OK, so when I add "/P" to the call, QLog rewrites the Grid and QTH. In my log, I then have the callsign as A1BCD/P. If I spot these QSO's, it shows up with the /P. I don't see this with most other spots, but that's OK.

Now, I find eQSL is complaining that these QSO's don't match. If I edit my log and remove the /P and upload again, eQSL confirms the contact.

Is there any way to streamline this so it isn't necessary to edit these type of QSOs?

73 - Paul - N9GXA

[foldynl]

Is there any way to streamline this so it isn't necessary to edit these type of QSOs?

No.

And don’t you think that using a callsign without /P from a portable location is actually an operator mistake? If somebody uses a /P callsign, shouldn’t that callsign be registered in eQSL? I don’t think QLog can really improve anything here. Or do you have a different opinion? And the idea that this would be configurable, whether the information is used or not, is not acceptable to me.

[n9gxa]

From what I gather, many POTA operators do not use the /P (I have never had a eQSL unmatch before I started entering the /P). I can understand that the /P is implied, though.

I will have to accept the way QLog works - As with other questions I had/have, I am just checking for intended procedures in case I missed something.

[foldynl]

But otherwise, I think there are some solutions. I'll try to think about it some more.

[kyleboyle]

Would it solve the problem if we changed this query https://github.com/foldynl/QLog/blob/master/ui/NewContactWidget.cpp#L287 to eliminate rows that have information indicating that the operator was not at his QTH.

eg add AND iota is null and pota_ref is null and sota_ref is null

[foldynl]

I think it would solve this particular case. However, I assume there will be someone who has their QTH associated with an IOTA or another program. In that case, it would not work well. I am rather thinking that it is necessary to react more to changes in the grid, but I do not have it fully thought out yet.