As far as I understand, each time I delete the call, all fields of the "new QSO" window are reset to the value of the last QSO previously completed (in a situation without any CAT). In my opinion, that makes little sense. The frequency field should not auto-change back. And, once at it, the mode, both RSTs, and pwr are also better left alone, at least in my opinion.
Here is a story that actually happened to me last Saturday:
I'm operating a QRP multiband rig (blue cool radio, in my case) with no CAT control and use cqrlog for logging. I operate on 20 m and make a few QSOs. I don't bother to have the precise frequency in my log, the "14.000" default is fine for me.
I decide to switch from 20 m to 40 m. Antenna re-tuning, rig re-tuning, the usual band-change steps. As part of those, in cqrlog's "New QSO" window, field "frequency", I choose 7.000. I hear some station call CQ, so I enter their call into the "call" field. Alas, they don't hear me. So I delete their call and tune on. Find a second station calling CQ, enter their call in cqrlog, complete the QSO, and log it.
Expected outcome: The QSO is logged with frequency 7.000.
Outcome actually seen: The QSO is logged with frequency 14.000.
Workaround: I have started to log a "QSO" with "call" XXXXX after each band change. Those are easily deleted after end of operations.
The problem occurred with an older version, but was reproducible with 2.3.0.
HI !
It is so, but you can make new default value preferences/TRXcontrol/default values /freq /change default and make an empty value and choose it.
It does not help, but at least does not set wrong value as default.
You may check also this: https://www.dl8bh.de/cqrweblog/
It keeps default band.
You can enter qsos via web browser. And if you have public IP at home you may set up webserver/database and contact it with smartphone or tablet when you are doing qrp peditions.
Of course it is usable also inside home network.
--
Saku
OH1KH
Thank you for acknowledgement and for pointing out the other workarounds!
If you don't mind the curious question: Is this present behavior useful (not for me, but maybe for someone else)?
Or is it simply a bug that should be fixed?
Hi!
I do not know why, and for what reason, this is designed.
Neither I do not think it is a bug.
I works just as it should; When you clear New Qso default values will take place, or last used frequency if there has been one or more qsos during this session.
It is most likely that you will have next qso on same frequency as the last one you already logged.
Normally nowadays the CAT is most often used and then the problem does not exist.
If there is no CAT it is not predictable when operator will change band and what happens then; qso or canceled qso.
You can clear all defaults to empty values and uncheck "auto", but still frequency will return back to last logged frequency in case of canceling qso after one is already logged during current session.
--
Saku
OH1KH
Hi, Saku,
Normally nowadays the CAT is most often used and then the problem does not exist.
I completely agree. The problem exists only in the (hopefully somewhat unusual) case of no CAT. Raising this issue, I just hope cqrlog wants to serve that (corner) case as good as it can, too.
If there is no CAT it is not predictable when operator will change band and what happens then; qso or canceled qso.
Exactly. Cqrlog does not know anything about frequency.
Presently, when the very first QSO attempt on a new band is not completed, cqrlog assumes that the user immediately gives up on that band and changes back to the previous band.
I can't help thinking this is a very wild guess. It may occasionally turn out true. But most the time, it will be rather counter-productive and annoying.
As it was in my case. Cqrlog logged some three QSOs to the wrong (previous) band before I noticed the problem. I then found it difficult to remember which QSOs were genuinely in the previous band, which wrongly logged? This was not the kind of research I enjoyed being forced to, in the middle of the IARU HF contest.
In the absence of CAT, cqrlog knows nothing. So far, so obvious. Instead of wild, highly speculative guessing, it could simply leave alone the frequency the user has manually entered. Wouldn't that be better?
In the absence of CAT, cqrlog knows nothing. So far, so obvious. Instead of wild, highly speculative guessing, it could simply leave alone the frequency the user has manually entered. Wouldn't that be better?
Yes, you are right, it would be much better. I also sometimes operate without a CAT and have the same problem. I'll look at it, maybe the fix won't be so hard. Thanks!
73 Petr, OK7AN
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com