RIG Control

[PY2AD]

Updates have been released, but the basics still work poorly.

RIG Control:

I have an FT-950, and if I use the Hamlib that comes with the program, when changing bands, the radio first goes to VFO-B, then back to VFO-A. This happens with every band change.

If I use FLRIG, every time I turn on FLRIG and Qlog, it completely messes up the radio's configuration.

If I use Omnirig, I lose several functions on the Qlog screen, such as power and TX indicator.

Is there any way to add this to the list of improvements?

PS. Windows 10

[foldynl]

Is there any way to add this to the list of improvements?

It may be more of a request for Hamlib. I looked into the situation there a bit and found this.

Hamlib/Hamlib#1576

It should be noted that it is primarily up to the owners of this rig to investigate the issue and prepare a fix for QLog. It is not feasible for me to debug individual rigs and their behavior when I do not own the rig. However, if a fix becomes available, is properly tested, and does not break other rigs, I will be happy to include it in QLog.

[PY2AD]

I understand, but if I knew how to solve this issue, I wouldn't even come here asking for help. I would do it myself.

Your theory that the radio owners should solve the problems is somewhat nonsensical.
We just want to use the program... if I knew how to solve the problems, I would make my own logging program.

It is the developer's responsibility to resolve user issues.

[foldynl]

I understand your frustration, but I have to clarify one important point.

QLog uses external rig-control backends such as Hamlib, FLRIG, and OmniRig. If a specific rig behaves incorrectly through one of those backends, I usually cannot diagnose or fix it without having access to that exact rig and a way to reproduce the issue. In this case I do not own an FT-950, so any fix would need help from someone who can test with that rig.

I am not saying that users must become developers. But for rig-specific problems, it is necessary that users who own the affected rig invest at least some time into investigating the issue and provide actionable feedback: what exactly they tried, which settings they used, and whether the same configuration works correctly with other software. Without this kind of feedback from users who can actually test the FT-950, the issue will not resolve itself.

For the Hamlib case, this looks related to an existing Hamlib issue: Hamlib/Hamlib#1576 Did you test it ?

If the problem is in QLog and we can identify what QLog sends incorrectly, I will fix it. If the problem is in Hamlib, FLRIG, or OmniRig, it needs to be fixed there first, or someone needs to provide a tested workaround that does not break other radios.

[PY2AD]

The problem wasnt only in hamlib:

• Hamlib: when changes band, before go to other band, the radio show VFO-B (blinking on) and then goes to vfo-a on new band.

• Omnirig: Dont show power and TX alert

• FLrig: Dont show TX alert

[foldynl]

Thank you for the clarification. However, I am afraid I still do not understand what new information this adds

[PY2AD]

I've already opened several support tickets here, and the feeling I get is:
"I only fix what I want to fix. You can suggest improvements, but if I don't want to, I'll invent various excuses not to do them."

I've been reporting for a while that the rig control doesn't work as it should, and I've tested several logs, and it works... only the qlog has these issues.

It costs nothing to pay attention to this; it's an important part of the system's operation and prevents damage to the radio at some point... I don't think these jumps during band changes are normal behavior.

I feel the support team is very uninterested in our opinions.

[aa5sh]

I do not have a Yaesu FT-950 to test or verify. But with my current rig a Elecraft K4 - QLog does not make it switch between VFO B/VFO A using HamLib. So that would indicate it is something inside of HamLib doing that for the 950. QLog doesn't maintain any rig definitions inside of HamLib so it is hard to determine what is going on.

For OmniRig - if I looked at their webpage they do not provide power output unless I over looked it. How should Qlog derive that if Omnirig doesn't provide it? Again it isn't maintained by QLog, it can only present what it is given.

For FLRig with my K4 it does show the PTT status but no power. The power isn't shown in FLrig either. So if the 950 doesn't show PTT it is either not implemented in FLrig or you need to validate it is checked in QLog 'PTT State'.

Like you say it is up to the developers so have you checked with Hamlib, OmniRig or FLRig? What all other logs have you used that provides the hamlib/omnirig/flrig experience you describe?

This statement is a little disappointing to me:
"I only fix what I want to fix. You can suggest improvements, but if I don't want to, I'll invent various excuses not to do them."

QLog and most open source projects are free labors of love. Developers like Ladislav give up many many hours of time and lots of money creating these types of projects - for no charge. So yes some things can be fixed easily and some would be terribly difficult so choices have to be made and priorities given. Some he can not fix without having access to hardware to troubleshoot. Not sure what excuses you are referring to here. Many times people say a suggestion and not realize the depth of design and implementation it would take to provide.

[aa5sh]

Did you happen to read the link posted above to the HamLib support site? It describes this problem exactly. It is a limitation of the Yaesu 950s CAT implementation. It also give a work around that may help by using rigctld separately. You could try their instructions to see if it resolves the issue with HamLib. You could connect to a RigCtlD instance in QLog now so it may help with it.

[foldynl]

some changes regarding that in 0.51