-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.37 doesn't populate field data from FT8 QSOs #405
Comments
Sorry, I do not understand you. Example would be a good starting point. |
Once the QSO starts Qlog correctly pulls from somewhere callsign data displaying it in the QSO form for most callsigns (and not for some, for whatever reason and that's fine). With previous version [0.34 or 0.35] that data was saved when the QSO was logged. It doesn't do it anymore for any QSO, and I couldn't find why. Capture show the last time it happened. Hope it makes it clearer. |
I think we are discussing this in #403. |
could be, I'm not referring to QTH only, mostly operator name and other related data. Anyway to me is a minor annoyance - if anything - it's just the fact that it once worked and now it doesn't. It'll be nice to be able to automatically fill those fields once a QSL is received. |
I think I will disappoint you in this. Your expectations from the automatic filling of QTH and other fields cannot be met. LoTW or eQSL provide only limited set of ADIF fields. ADIF fields for QTH are not there. The only thing that can be "extracted" from electronic QSLs is the gridsquare. And yes, here you can say that you have an exact locator for the given Callsign and QLog can query the QRZ or HamQTH for details. But imagine importing a few hundred or a thousand electronic QSLs. The authors of LoTW or eQSL would not be very happy if QLog search the information about the QSO after receiving of each electronic QSL. This would also increase the import time. |
I'm afraid that issues isn't the right place to discuss this, and I am fine whatever you decide about it. My point was a "heads up" about something that worked once [even as a "feature bug" ] and then not. I loved the previous behaviour and will like to keep it, but won't make the discussion longer than necessary if it's not really an issue. BTW To me looks clear what I'll do, I'll keep the data already imported (or looked up) at the start of the QSO (name, etc) except what will come from the ADIF once confirmed. If it cannot/should be, it won't be a deal breaker by any means. |
Opened poll about this feature #420 |
It is part of v0.38 |
when a QSO starts picks up all the data just fine.
None of those are saved when the QSO is effectively logged, as it used to do (0.34 or 0.35). Only the wsjtx data.
Built from source viar AUR package, as previous version.
The text was updated successfully, but these errors were encountered: