Band change frequency

[dl2ki]

When changing bands via the rig widget, the VFO on the rig always sets itself to the beginning of the band. When switching back to the last used band, the VFO on the rig must therefore always be reset to the last used frequency.

Maybe it would make sense not to transfer any VFO settings via the rig widget when changing bands, so that the last frequency set there can always be used on the rig.

[foldynl]

I am not sure if I understand you correctly. I will test it and let you know.

[dl2ki]

Hi,

an additional extension could be to add additional columns for 'default frequencies' in 'Settings, Bands'.

For this the column 'State' could be omitted. Band-Enabled could be replaced by checkboxes to reduce the column width. Checkboxes are also easier to mark or unmark in my view.

(This could also be done in the 'Modes' tab).

Then you could add columns for 'default frequencies', which are then set after band selection. In CQRLog this is provided.

Also columns for 'TX offset' and 'RX offset' could be added here, if this is useful.

This would mean that the rig would always be set to the respective default frequency when changing bands, and not to the last frequency set on the rig. Two different approaches.

You could bring this together by entering the default frequency in the 'Settings, Bands' tab only if you want this when changing bands. Otherwise the field would remain empty.

When changing the band, it would then only be necessary to check whether a standard frequency is entered. If yes, this would be set, otherwise no frequency change would be transmitted to the rig.

I have put together a simple example view here.

From my point of view, columns with frequency information could generally be set right-justified.

[foldynl]

Hi,

you wrote some time ago, that you are able to execute SQL query via SQLStudio. Please, would it be possible to execute following SQL against your database?

SELECT band, mode, round(AVG(freq),5) median FROM (
    SELECT *, (
        SELECT COUNT() FROM contacts AS _ 
        WHERE band=contacts.band AND mode=contacts.mode AND (freq>contacts.freq OR freq=contacts.freq AND ROWID>contacts.ROWID)
    )-(
        SELECT COUNT() FROM contacts AS _ 
        WHERE band=contacts.band AND mode=contacts.mode AND (freq<contacts.freq OR freq=contacts.freq AND ROWID<contacts.ROWID)
    ) AS m FROM contacts WHERE m BETWEEN -1 AND 1
) GROUP BY band, mode;

and try to evaluate whether the calculated frequencies for each band and mode correspond to your proffered frequency for band switch combobox?

I have an idea to calculate preferred frequencies according to historical QSOs and I need to verify my idea. For my log, the calculation was successful, but I am not a representative sample of the hamradio operator.

[dl2ki]

Hi,

here is the result of the query. print.pdf

and with comments. Band change frequency.pdf

In addition it is to be said that I am QRV for some years only in CW. Also I enter only CW QSO's into the logbook, because I manage my paper QSL cards with it.

The few logged SSB, FM and PSK QSO's are from the time when I was not yet active in CW.

So my log is certainly not a reference for your idea.

My default frequencies when changing bands are either those of the QRQ point (https://www.qrqpoint.com/), or the QRP activity centers. When I call CQ, I additionally have my own default CQ frequencies, which I then set by hand. e.g. '3,566.20', '5352.20' or '7,034.20' ...

Most of the time, users will use their specific frequencies for listening or CQ calling. If QSO's come about, they don't necessarily take place on these frequencies.

I think there are many individual variations. Your idea is one of them. You can implement it. Let's see how other users (I hope there will be some more soon) see it.

[foldynl]

Many thank for provided statistic.

In the end, it's not as good as I expected. I have implemented several variants and it seems to me that from the user's point of view the most understandable variant is when the last used frequency is stored for future use. Everything else lead to unexpected surprises for user.

[dl2ki]

Yes, that is also a possibility that seems viable. We'll see how that looks in practice.

[foldynl]

QLog v0.11 contains this enhancement. Closing the issue report. Please, open a new issue report when the last used frequency approach is user "unfriendly".