QLog 0.6.5, Elecraft-K2 Hamlib4-Test

[dl2ki]

Hi,

CQRLOG does not work with the rig setting "Elecraft K2" (Model 2021). With the setting of "Kenwood TS-2000" (Model 2014), CQRLOG works correctly with the Elecraft K2.

If the Elecraft K2 is set in the Hamlib settings in QLog, the TRX will respond like this after 'Connect Rig':

MVI_0505.mp4

So, since this setting is also not usable here, I experimented with various Kenwood models. Some replacements work, but with various limitations in detail. The "Kenwood TS-2000" also works best here:

• The display of the RX frequency in the "Rig" window works.

• The TX power display in the "My Station" tab works, but only integer power values are displayed. Furthermore, the power display does not work in the 60m band (in all modes). On bands with the CW Reverse setting (15 m, 12 m und 10 m), the TX power display does not work either.

• The switching of the modes "CW, LSB, USB, RTTY" on the K2 is taken over correctly by QLog.

• The switching on of RIT/XIT at the K2 is not taken over into the fields "Rig TX Offset" and "Rig RX Offset" in the tab "My Station".
  (This is also the case with the K3)

• After switching the VFO "A/B" on the K2 (different frequencies), the frequency display in the "Rig" window of QLog does not change. Also the indication "VFO A" remains.
  After switching 'Connect Rig' off and on again (reconnect), the "Rig" window now shows the VFO-B frequency. The indication "VFO A" remains however. (In CQRLOG the frequency display switches correctly when switching the VFO A/B on the K2.)

With the K3, the frequency display in the "Rig" window also switches correctly after switching the VFO at the K3, but the note "VFO A" remains here as well. It may therefore be that the VFO indication is generally not taken over correctly from the rig by QLog.

[dl2ki]

It could be that an option "Disable automatic TX power takeover" in the Hamlib tab solves some problems. However, this would require tests with other rig types.

[dl2ki]

Tomorrow I will check the tests again with 'rigctl' 4.0 and 4.5~git on the command line.

[dl2ki]

Hi,

I have done some small tests with 'rigctl' on the command line.

Rig = Elecraft K2
rigctl(d), Hamlib 4.0
rigctl -m 2021 -r /dev/ttyUSB0 -s 4800

After starting 'rigctl', the K2 cycles filters F1-F4 1 time per mode (CW, SSP, RTTY) (see video). This is apparently to detect the assigned filter bandwidths.

The display of the TX power is done for all bands and also in the mode 'CW reverse'.
However, the displayed values are incorrect.

K2 PWR = 2.7
Rig command: l RFPOWER
Level Value: 0.133333

K2 PWR = 7.3
Rig command: l RFPOWER
Level Value: 0.466667

K2 PWR = 14.8
Rig command: l RFPOWER
Level Value: 0.933333

The modes and the filter bandwidths are displayed correctly.

Rig command: m
Mode: CW
Passband: 1400

Rig command: m
Mode: LSB
Passband: 2000

The switching of the VFO A/B is detected correctly, and the frequency display per VFO is also correct.

Rig command: v
VFO: VFOA

Rig command: f
Frequency: 3537000

Rig command: v
VFO: VFOB

Rig command: f
Frequency: 3614330

If a "Kenwood TS-2000" (m = 2014) is set, the filters are not switched through at startup. This means that the filter bandwidths displayed for the 'm' command are incorrect.

The displayed power values fit better, but are only integers.

K2 PWR = 2.7
Rig command: l RFPOWER
Level Value: 0.020000

K2 PWR = 7.3
Rig command: l RFPOWER
Level Value: 0.070000

K2 PWR = 14.8
Rig command: l RFPOWER
Level Value: 0.140000

So it looks like the data from 'rigctl' is partly not taken over correctly into QLog in this case.

In CQRLOG the "Poll rate" can be set. Default is 500 ms. However, for the K2 it is recommended to set the "Poll rate" higher.

Manual excerpt:

Polling:  Many programs periodically poll the radio to see if the operator has manually
adjusted any of the controls. The K2 can respond very quickly to these requests, but
we recommend a setting of 1-3 seconds to minimize possible computer noise.

TX Polling: Polling during transmit is allowed, but we recommend turning it off.

Perhaps part of the problem is due to the "poll rate" on the K2 being too fast.

debug_log_01.zip
debug_log_02.zip

[foldynl]

Hi,

thanks to your detailed analysis but I'm afraid I can't do much with it because I don't have K2 therefore I cannot test it locally.

Just for your information QLog calls directly the Hamlib's public API - the same API as the rigctl calls - and displays the obtained numbers. Rigctl binary is not used - QLog does not query rigctl but hamlib API. In the other word, what is obtained from Hamlib API is shown by QLog. Qlog does not modified the data.

The "Kenwood TS-2000" also works best here:

* The display of the RX frequency in the "Rig" window works.

OK...sounds good.

• The TX power display in the "My Station" tab works, but only integer power values are displayed. Furthermore, the power display does not work in the 60m band (in all modes). On bands with the CW Reverse setting (15 m, 12 m und 10 m), the TX power display does not work either.

keep in mind that everything is controlled by Hamlib. I have briefly look at the Hamlib code and T2000 does not have a defined 60m band. Maybe, it is a root cause.

• The switching on of RIT/XIT at the K2 is not taken over into the fields "Rig TX Offset" and "Rig RX Offset" in the tab "My Station".
  (This is also the case with the K3)

Currently, Rig TX/RX offsets are not taken from the rig. I need to find out if the public hamlib API has this feature. I will open a "feature request" in the Issue section for it to better tracking the state of work.

• After switching the VFO "A/B" on the K2 (different frequencies), the frequency display in the "Rig" window of QLog does not change. Also the indication "VFO A" remains.
  After switching 'Connect Rig' off and on again (reconnect), the "Rig" window now shows the VFO-B frequency. The indication "VFO A" remains however. (In CQRLOG the frequency display switches correctly when switching the VFO A/B on the K2.)

It is strange. QLog currently calls Hamlib API "rig_get_freq" with the parameter RIG_VFO_CURR, what should return a frequency of the Current VFO - current "tunable channel"/VFO. I need to verify it in the hamlib source code. I will open a "issue" in the Issue section for it to better tracking the state of work.

With the K3, the frequency display in the "Rig" window also switches correctly after switching the VFO at the K3, but the note "VFO A" remains here as well. It may therefore be that the VFO indication is generally not taken over correctly from the rig by QLog.

Yes, you are right. The VFO indicator is a static text now. It should be fixed. I will open a "feature request" in the Issue section for it to better tracking the state of work.

So it looks like the data from 'rigctl' is partly not taken over correctly into QLog in this case.

In CQRLOG the "Poll rate" can be set. Default is 500 ms. However, for the K2 it is recommended to set the "Poll rate" higher.

I will prepare "testing" branch where pool rate will be 1s. See comment in issue #17.

[dl2ki]

Hi,

Thank you very much for your explanations.

I am aware that I cannot contribute much to the improvement of the code without further knowledge about the internal structure of QLog.

Therefore, I can only report what I notice in my experiments with QLog and the transceivers here (K2 and K3). Sometimes these things are a bit hard for me to classify and I don't know if you can use the hints at all as a programmer.

Since QLog uses more functions from hamlib, I now think that setting the K2 in QLog makes more sense than switching to a replacement device like the TS-2000. Only the changing display of PWR/frequency would have to be corrected. For the faulty power display on K2 and K3 there might be a solution later.

However, since there are some users of CQRLog who use K2's, I think these observations will be made by other users later. Other problems will arise with other transceivers. After all, you can't test all of these things yourself in advance.

The development of the K2 starts around 1997, which has to be taken into account in the way it works. Much is very different from modern devices, but it was ingeniously designed about 25 years ago. On the other hand, this is a device which has excited me for many years. Also because you can still do many things on the device yourself. Some years ago I had the luck to buy a K2 in very good condition, equipped with all modules. :-)

[foldynl]

I'm disappointed that you have problems with your rigs in QLog.

I am looking at the hamlib code (example hamlib code) now and the frequency is read in the same way as in QLog.

Just to summarize. If you set K2 model in QLog's Setting Dialog then following thing does not work:

1) an incorrect TX Power is shown
2) an incorrect Freq is shown when switching VFO A/B

in case of K3, following things does not work:

1) an incorrect TX Power is show.

Is it correct?

I guess that using ts-2000 model is not a good way when you have K2/K3 on the table.

Maybe there is another test (or possible workaround). You can use rigctld. It is used in the same way as rigctl but you have to switch to rig mode "Hamlib NET rigctl" model in QLog Setting dialog and set the hostname to localhost. In this case, QLog connects rigctld via TCP and calls the same rigctl commands as you used in your previous examples.

something like this:
rigctld -m 2021 -r /dev/ttyUSB0 -s 4800

And then set Hamlib NET rigctl in QLog - rigctl has to be executed before QLog.

[foldynl]

Please, see my comment in issue #17 - testing the polling interval

[dl2ki]

K2
1) an incorrect TX Power is shown

Yes, the power is represented only as a whole number. e.g. 7.3W => 7.0W, 10.5W => 10.0W. But for the K2 command "PC (Power Output Level; GET/SET)" there are different options, which may be may have to be set by hamlib.

PC (Power Output Level; GET/SET)

Basic SET/RSP format: PCnnn; where nnn is 000-015 or 000-150 watts depending on the POWER range.
Extended SET format: PCnnnx; where nnn is 000-150 (0.1-watt units) or 000-150 (1-watt units) and x is an
optional range selector. If x is supplied, 0 selects the low power range, 1 selects the high-power range.
Extended RSP format: PCnnnx; where nnn is power, and x is 0 (low power range) or 1 (high power range).
Notes: 1. High power range applies only to K2/100, and only if the PA menu entry is on and a high-current supply
is connected. 2. A lower power limit may be in effect for 10/12-meter SSB/RTTY operation (P o 2 8 menu entry),
and on trasnsverter bands (menu entries TRN1-TRN3). 3. Use SW and DS commands to turn PA on/off in menu.

2) an incorrect Freq is shown when switching VFO A/B

Yes,

after changing the VFO on the K2, the VFO and the corresponding frequency on the K2 will switch. However, the frequency display in QLog remains.

The VFO-B frequency is only displayed after a "Reconnct Rig".
However, this could also have to do with the constant change between PWR and frequency display on K2.

K3
1) an incorrect TX Power is show.

Yes, e.g.

K3 = 110W => Power = 10.0W
K3 = 95W => Power = 8.6W
K3 = 46W => Power = 4.2W
K3 = 3.7W => Power = 0.3W

debug_log_03.zip

Using "rigctld" gives the same results in both cases.

---

However, I think that the problems with the K2 do not have to be solved primarily. There are certainly other parts of the software that you would like to develop further.

With the K2, the only thing that comes to my mind is to introduce an option "Automatic query of transmit power on/off". But maybe you have a better idea in the future.

[foldynl]

Another issue with TX power is when you will have a PA behind your rig. In this case, QLog will also display an incorrect value.

I have to think about it. This is a historical code and I don't know if it's good to have it turned on automatically.

[dl2ki]

Yes, you are right.

Same problem when using VHF/UHF or QO-100 transverters. You can only ever record the drive power.

Also a problem with "QRPp milliwatting". As propagation conditions improve, this can be tried again. In the past I have used a constant low transmit power in combination with a 41dB step attenuator in the antenna line. But for this you need interested and patient QSO partners, hi. In CQRLOG you can enter a power with leading "0" and use this as milliwatt.

You can find interesting information about this on the page of "PA1B".
[]https://a29.veron.nl/hams/pa1b/

You could e.g. specify a "default power" per rig in hamlib-settings. In addition in the QSO window, e.g. in the tab "Details", an additional input field, which allows a simple correction of the transmit power per QSO, if necessary.